Scrumerati

Proposed: Agile Abandonment Disorder and its Root Causes

Jeff Sutherland, Scott Downey and I have found over the past few years that, more often than we wished, companies sometimes abandon agile methods. In our observations, it hasn't been because agile was performing badly; to the contrary, for the first time these companies had measurably improved their performance.

This year, Scott and I decided to tackle this issue as a research effort. We have looked at six companies, so far, but we hope to study more, with your help.

If you have observed agile abandonment, we'd like to talk to you. Your comments and company names will remain anonymous. My contact information is here.

If you've been working in agile coaching or training for a long time, and you've not experienced agile abandonment, or if you've found ways to counteract it, we'd also like to hear from you.

Scott and I proposed this topic for Agile 2012. Here is our submission:

Agile 2012 Proposal

Agile adoption can lead to dramatic improvements in market adoption, engineering efficiency improvements and engineer empowerment. But many companies have adopted agile practices, and then, despite seeing significant benefits, have abandoned those practices, allowed waterfall practices to return, and saw productivity decline. Why? If agile really helps companies succeed, how can we ensure its retention?

This session will summarize a series of root cause analyses we performed with agile leaders, using a “Root Cause Mapping” approach that helps groups of people identify contributing causes and share responsibility. Companies will remain anonymous in the presentation.

Most of us believe that agile adoption requires initial courage and effort, but agile retention also seems to require sustained courage and effort. Loss of a key leader, addition of a new leader, growth of the company beyond a certain scale, company acquisition, insufficiently refactoring mid-level manager roles, and the inability of product management to exploit agility all seem to correlate with agile abandonment.

Today, we have analyzed six companies that have abandoned agile methods. In discussing this issue with others, we have discovered abandonment is more common than we thought. We hope that this session proposal will inspire others who have experienced this problem to contact us with more examples. Email to dan+abandonment@greening.org.

If feedback is positive on this session proposal, we plan to incorporate additional companies, further analyze the phenomenon, consult with colleagues on mitigation strategies and assemble a set of best practices for protecting agile gains.

Help us out

If you think this topic merits discussion, consider lending your voice in favor of the topic. Registered users can provide public comments on the proposal at http://submit2012.agilealliance.org/node/14003.

Here's to persistent agility!

Could Your Company Lose Agility? Adaptive Portfolio Management can Help

Abstract

Agile methods create conflict. So to retain agility, we must actively promote it even after agile has taken hold. How can we equip a company with the cultural and process tools to sustain agility? Your choices may depend on your perspective. Social psychologists teach organizations to reinvent themselves, but this approach may be too slow for a large company. Change agents study, develop and evangelize specific processes, a more promising approach. "Adaptive portfolio management" is a specific process under development that may help sustain agile-thinking. It maximizes value by rapidly adapting to market and company changes. In using adaptive portfolio management, company leaders exercise agile fundamentals. They can become agile advocates for the whole organization, making agility more stable for developers on the ground.

In the service of productivity, agile methods create conflict. Consider continuous improvement, a canon of agility: It demands that people expose perceived problems and analyze their causes. Try it in any relationship, and you'll create conflict. Agile techniques increase transparency, increase accountability, weaken mid-level managers and deemphasize heroism: just a few more things that make some people mad. Some may start to see agile as the problem. “It was so much easier the old way!”

And so, agile culture requires active support even after it seems to take hold. Many experienced coaches have seen organizations that successfully implemented Scrum, and then stumbled. Some conclude this arises from software development's nature as a complex system. Scrum seeks to lightly control the chaos of software development—allowing for innovation while ensuring productivity; its feedback-driven control requires intellectual energy to sustain.

How can we equip a company with the cultural and process tools to sustain agility? The 2011 Scrum Coaching Retreat brought 70 Scrum coaches together in Boulder, Colorado Dec 7-9 to focus on this. We formed groups to analyse different elements of the problem.

Social psychologists and change agents

How we help a company sustain agile practices depends on our perspective. Some coaches are social psychologists—fostering agile culture and teaching organizations to reinvent themselves; others are change agents—studying, developing and evangelizing specific processes. I'm a change agent by nature.

I love analyzing and designing whole-company processes. The Agile Organization Design group seemed promising: it might have proposed ways to design organizations to support agile principles. However, social psychologists in the group challenged the presumption that we might design organizations at all. They sought strategies to enable an agile organization to design itself. One suggested that we "Fire all the managers." Another wanted the organization to "self organize". Self-organization takes a long time for Scrum teams, and much longer for large companies. As a result, leaders largely design companies by fiat. The change agents among us wanted to help those leaders, documenting organization designs that had worked for others, providing templates they might use as a starting point. The group made no progress; our goals were too different. I switched groups.

Adaptive Portfolio Management

The Adaptive Portfolio Management group provided a refreshing harmony, with likeminded folks seeking the best ways to prioritize, staff, interrupt and cancel projects. The group established a definition:

Adaptive Portfolio Management is the discipline of regularly changing the priority of business initiatives and resource commitments to maximize total portfolio return. This is implemented by:

1. Creating and managing an inventory of strategic initiatives
2. Prioritizing initiatives based on business drivers
3. Allocating budget to initiatives to maximize value
4. Periodically re-evaluating allocations based on changing needs
5. Transparently communicating across the organization

and a credo (really a manifesto, mimicking the format of the Agile Manifesto):

We value:

1. Optimizing the holistic portfolio over Protecting departmental budgets
2. Courage to change over Following a plan
3. Ability to evaluate the portfolio on a frequent basis over Infrequent (i.e. annual) planning cycles
4. Responding to emerging opportunities over Sticking to the plan
5. Maximizing value over Managing cost
6. Collaborating on decisions over Centralized authority

I was excited that 12 experienced people agreed on fundamental principles and worked so productively together. I was relieved that a portfolio management technique we developed at Citrix Online fulfilled the group's principles [gree2010]. We tried out an adaptive portfolio management game, developed by group member Jade Meskill [mesk2011]. In playing this game, competing teams largely developed the same risk-adjusted profit-maximizing strategies to order portfolio backlogs. We thought alike! Many of the graphics developed by the group would be suitable to describe Enterprise Scrum [scrp2011].

While adaptive portfolio management helps maximize a company's profitability, it can also help sustain a company's agile thinking and processes. If key decisions on project funding and prioritization are based on agile principles, those principles become infused in the corporate culture. Executives often own major product decisions. If those executives are using adaptive portfolio management, the rest of the company is likely to follow their lead and support other agile activities.

My colleagues and I are studying and developing better approaches for company-wide agile methods. We help companies become agile and stay that way. Contact me if the topic area interests you.

References

[gree2010]

Daniel Greening, “Enterprise Scrum: Scaling Scrum to the Enterprise Level,” 2010 43rd Hawaii International Conference on System Sciences (HICSS), Koloa, Kauai, Hawaii January 5-8, ISBN: 978-0-7695-3869-3 (10 pages)

[mesk2011

Jade Meskill. Agile Portfolio Management Game. Description and downloadable game materials. Blog entry. 9 Dec 2011.

[ries2011]

Eric Ries. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011.

[scrm2011]

Main Page, Scrum Coaching Retreat 2011, Boulder Colorado.

[scrp2011]

Adaptive Portfolio Management, Scrum Coaching Retreat 2011, Boulder Colorado.

Review: Liz Keogh, Learning and Perverse Incentives

Liz Keogh, Learning and Perverse Incentives, QCon London 2011

This 50 minute talk discusses perverse incentives: situations where incentivizing individual behavior causes an organization to become dysfunctional.  When we attempt to optimize an organization, but fail to use systems thinking (i.e., when we are optimizing from an internal perspective), we can create inappropriate results.

Different feedback mechanisms drive behavior in both positive and negative ways. Some examples: Reinforcing forces, balancing forces, feed forward, delayed feedback (and resulting oscillations). A positive feed-forward example: "Chance favours the prepared mind" (Louis Pasteur). If you prepare yourself properly, good things happen in the future. A negative feed-forward example: over-preparing for avoidance of a negative outcome. If many people worry about limited resources, people can hoard those resources and cause a systemic shortage.  Local optimization caused systemic failure.

We often place a strong emphasis on risk avoidance, but this can kill innovation. Risk is a natural part of any creative process, such as developing software, but some creative attempts will fail. When we take on risk, we learn. If you are in a creative field, you should never take on risk free projects. Some organizations make punishments so great for project failure, and rewards for doing new things successfully so minimal, that innovation stops. One perverse incentive is if someone punishes you for failing to achieve an estimate, you pad your estimates, and then your velocity goes up.  (See Liz's "Estimation Anti-Patterns" on her blog.) Another perverse incentive: requiring architectural review on after people on a team innovate and fail: too frequent reviews will kill innovation.

When we put on our Evil Hat, we say "How can game this system?"  That perspective is great for finding perverse incentives.  KPI's—Key Performance Indicators—are a potential source of gaming and arbitrage (exploiting that true value is different from the KPI). The quicker we're getting feedback from a metric, probably the further away we are getting from measuring true improvement. People tend to game the system for the metric, not the improvement, especially when KPIs are rewarded.

Your brain is brighter than you are. You will game the system, even if you think you aren't consciously wearing the Evil Hat. Rarely do people game the system deliberately, but there are some situations, particularly with middle managers, where people deliberately game the system for their personal benefit. (See Snakes in Suits below.)

How to improve:  Get away from solving a problem, and create a system where problems are solved. Evangelize and embrace frequent Root Cause Analysis, with 5 whys, to get to root causes.  Keep metrics close to the improvement you are trying to measure (see The Goal below.)  Create a learning environment. Even in standups, “This is what I learned today; This is what I hope to learn tomorrow; Can anyone help me find out... ?” could be useful.  Fit the process to reality, not reality to the process.  Try focusing on what's going right as well as what is going wrong. Then we focus on learning: what should improve, what should we keep? Thank people for doing a good job, and think “How can I anchor good work?”

Book List:

• Peter Senge, The Fifth Discipline: The Art & Practice of the Learning Organization
• Tom DeMarco and Timothy Lister, Walking with Bears
• Donald Reinertsen, Managing the Design Factory
• Edward de Bono, Six Thinking Hats
• Paul Babiak and Robert D. Hare, Snakes in Suits: When Psychopaths go to Work
• Eliot Goldratt, The Goal

Is Hiring More the Right Answer?

In my current company, I sometimes here people say “We need more people to handle this workload.” Every group in the company considered in isolation could use more people, no matter what group they are in; at least that's what most people think. But smart folks sometimes say, “We have too many people.”

Here's what the research tells us:  Until you reach about 7 people in a group, adding another person will likely make the group go faster [putn2011]. Specifically, starting from a 1 person group, at first, each time you add a person the value-produced per group goes up, However, something weird happens as you approach 7 individual contributors: The group productivity drops. I.e. An 8 person group produces less than a 7 person group. Why? Because the communication, coordination and mistake costs have overwhelmed the advantage of additional people.

To add one more complexity, the zero-sum game of corporate hiring means if your group hires more, my group must hire less. Smart software executives typically seek an optimal ratio of user experience designers, engineers, program managers, user experience managers, engineering managers, scrummaster, product managers, researchers, etc. to maximize corporate profitability. If your company has the right ratio, when a group is overwhelmed, you are actually over-stressing the whole system, producing technical debt, and should slow down.  

In my current company, user experience is one of our most important brand values.

Recently, a colleague asked me to consider hiring more user experience designers for a product where software engineers develop new features very slowly. Given that insight, you might suspect the software carries a lot of technical debt, and you would be right. If we hire more user experience designers, it would likely generate more feature requests, then more pressure on the engineering team to produce features faster, then more shortcuts in coding, and then even more technical debt.

Technical debt leads to systemic slowdowns in productivity. Its accumulation is insidious and can be disasterous for a company. In the face of a highly competitive marketplace, technical debt scares me.

Here are some sophisticated alternatives to consider when a user experience group is overwhelmed:  

• The ratio of user experience people to developers really might be too low. In this case, reduce the rate you hire engineers to increase the rate you hire user experience designers.
• Engineers might be producing features too fast; you should get more engineers to work on reducing technical debt to make the future brighter.
• Your user experience group might not be saying "No" to unimportant assignments. In some cases, product owners or engineers can do a reasonable job with a little guidance. In other cases, the project isn't profitable enough to bother doing.

You can apply this sort of thinking to any situation where you think you need more people. Will more people make your group more productive?  Even if the group is more productive, will the company be more productive? Take a step back and think about the relative ratios of different types of contributors. Maybe the company would benefit most from adding more people to a different group.

When someone asks you to state your team's top impediment, here is what they are asking: “What is the biggest thing keeping my existing team from contributing most to corporate productivity?”  Hopefully this post explains why “Not enough people” isn't usually a good answer.  Sometimes, in fact, the impediment is too many.

[putn2011]

Doug Putnam, “Team Size Can Be the Key to a Successful Software Project,” Quantitative Software Management, IT Almanac, 2006.

Quality is Not Negotiable? A Contrarian View

In Tradable Quality Hypothesis, Martin Fowler says “as soon as you frame internal quality as tradable, you've lost.” At the risk of being rode out on a rail, I argue that making quality non-negotiable lets engineers off the hook for understanding internal quality. Quality is always negotiable, and you should understand the benefits and costs of internal quality so you can negotiate and prioritize well.

Quality has gotten short shrift in most organizations. Software quality can dramatically affect future productivity. Since we often inappropriately sacrifice quality for features, it can sometimes make sense to stamp your foot and say "quality isn't negotiable."

However, understanding which software quality efforts actually matter requires us to think more deeply. How does software quality affect us? Most software quality problems—copy-paste code, non-standard formatting, bad encapsulation, poor use of modern language features (generics, iterators, etc.), simultaneously maintained code branches—degrade future engineer productivity. Other software quality problems—known bugs, inadequate test coverage—degrade software value.

With a subtle understanding of quality, you can answer daily questions in context. For example, should you refactor a long-untouched body of code for future productivity? Sometimes you shouldn't. But if fear of touching that code holds back new functionality, maybe you should. The Tomcat 7 committers just refactored a lot of long-untouched code, with likely productivity improvements going forward (and a whole bunch of bugs fixed). [see Mark Thomas: Introducing Tomcat 7 at 39:30]

Unless we make engineers defend their quality efforts, they fail to thoughtfully prioritize quality improvement efforts. Should they create unit tests or integration tests first? Most engineers can't give you a thoughtful answer to this question. But they are going to do something first, and that something might be a lot less valuable than the other thing. I've seen poorly conceived quality efforts squander millions of dollars.

That's why "quality is non-negotiable" articles always fall flat with me. They punt the tough questions. They seem well-suited for the "I never think about the value-side" engineering people to deal with "I never think about the effort-side" product people who keep making one-sided demands.  

I like using Net Present Value to think about the cost-savings of quality improvement and the value of features. It helps me prioritize and compare options. Engineers have to make decisions about quality every day. They should hone their decision-making skills, and clichés are not likely to help.

Review: The World is Not Small for Everyone

Many decades ago, my small-world assumptions were incredibly optimistic: I was smart, resourceful and helpful, and the world needed me, therefore capitalists would seek me out and pay me well. I discovered they weren't looking very hard for me: I had to find them. I longed for experts in my own social group—i.e., gay software entrepreneurs—who could advise me, and found few. I even wrote to venture capitalist colleagues asking if they knew any gay VCs: nope. I remember thinking I couldn't talk football and I didn't play golf, therefore I would find few commonalities with straight men. Though I now realize how prejudicial this assumption was, it turns out the main victim was likely me.

New research on the “small-world theory,” that we can find what we need in few steps via our social networks, shows that preferring advice from members of the same social group may damn us to more difficult access to expertise and referrals.

In “The World is Not Small for Everyone” [sing10], Singh, Hansen and Podolny thoughtfully explore how limited access to knowledge hobbles peripheral, junior and female employees. Surprisingly, in all three of these cases, self-reinforced isolation seems to interfere further with access to experts and referrals.

Knowledge is the primary resource in management consulting. It's all about who you know. When a client raises a question management consultants can't answer, they look for an in-house expert. If they don't know an in-house expert directly, they ask a colleague for a referral. The sequence of referrals ultimately forms a search chain. All else being equal, the shorter the chain, the more rapidly a management consultant can offer an answer, the more likely the client will appreciate the consulting engagement, the more engagements the consultant might obtain, and ultimately the higher the billing rate the consultant might command.

Singh et al surveyed 3,150 consultants in a a global management consulting firm to test these hypotheses:

1. That searchers who have low expert-related centrality, have short tenure, or are in the gender minority are less likely to pinpoint an expert in the first step of a search chain,
2. That searchers are more likely to select intermediaries with whom they share a characteristic (expert related centrality, tenure, gender) than intermediaries with whom they do not.
3. That searchers (original and intermediaries) who have low expert-related centrality, short tenure, or are in a gender minority tend to have longer realized search paths.
4. That for searchers who belong to the organizational periphery, those who name members belonging to the core as the next search step tend to have shorter realized search paths than those who do not.

All of these hypotheses appear to be true.

Women, peripheral employees and new employees all suffered longer searches in finding expert knowledge. Of the three, women were the hardest hit. People in these disadvantaged groups who crossed social boundaries to contact people outside their group reduced their disadvantage significantly.

This paper seems to confirm an advantage of cultural assimilation: by crossing social group boundaries more frequently, members of disadvantaged groups can establish stronger connections with experts and well-connected networks, thus improving their economic standing.

Agile management methods may mitigate some of the disadvantages discussed in “The World is Not Small for Everyone.” Agile methods encourage the creation of cross-functional teams [vodd10], making it easier to obtain knowledge and referrals from people in different social. Agile methods encourage integrating senior and junior people in teams: With pair-programming, senior employees build stronger bonds with junior employees, bringing junior employees closer to the expert network [melo03].

At the same time, this paper challenges us to think more deeply about organizational structures, and how they reinforce or diminish social boundaries. I have recently seen situations where disadvantaged employees sought referrals from people in the same cohort, despite their awareness of others with better connections or greater expertise. How can we encourage social boundary crossing, to improve organizational knowledge and profitability?

Finally, it challenges us, as individuals, to introduce ourselves to alien social groups, and to overcome our natural tendencies to seek expertise only from those in our own social groups. The rewards may go beyond the economic: we may find friends in unusual places.

A few years ago, I attended a 25 year high school reunion and participated in the golf outing, despite knowing nothing about golf. The former captain of the football team taught me how to play. I had a blast.

With a slightly tilted perspective, I remain your humble servant. —Dan Greening

References

[melo03]

Thomas Meloche, James Goebel and Richard Sheridan, “Paired Programming in the Software Factory: Questions and Answers,” white paper, The Menlo Institute LLC, 2003. http://www.menloinnovations.com/freestuff/whitepapers/paired_programming_q_and__a.pdf

[sing10]

Jasjit Singh, Morten T. Hansen, and Joel M. Podolny, “The World Is Not Small for Everyone: Searching for Knowledge in Organizations,” Management Science 56:9, September 2010,pp. 1415–1438. DOI: 10.1287/mnsc.1100.1201 http://mansci.journal.informs.org/cgi/content/abstract/56/9/1415

[vodd10]

Bas Vodde, “Feature Team Primer,” http://www.featureteams.org/feature_team_primer.pdf

Learning Science and Agile Training

New cognitive psychology results can help us provide better training. Trainers seek to transform the way you think about tasks, motivation, planning and outcomes, and equip you with enough understanding to succeed. My Scrum Trainings are done in the afternoon, reinforcing learning by exploiting sleep cycles. Further ideas include changing venues from day-to-day, varying ways of applying agile thinking to problems, etc.

As Director of the Agile Program Office at Citrix Online, I train people in agile thinking, including XP, Scrum, Lean and enterprise-level productivity improvement. I'm keenly interested in approaches that enhance learning, especially in Scrum Training. Agile methods are difficult for many to fully embrace, and I want to do anything I can to help.

Scientists have known for years that sleep enhances memory [elle2006] [biel2006]. Traditional trainers provide Scrum Training as two solid 8-hour business days of classes. At Citrix Online, I conduct Scrum Training over four afternoons, with 4-hours each day. I prefer afternoons, to replicate studies that seem to indicate proximity to sleep provides for better learning. [scul2010]

This afternoon approach may provide for better conceptual learning, but it also has other advantages. By spreading out the training, it gives the trainer time to adapt to the interests and experience of attendees. Co-trainer Nick Kim and I used 4-day training to better adapt our team-teaching. Ultimately, we have alternated short lectures and exercises among each other. This made for a more diverse teaching style, and for livelier exercises.

By leaving students with mornings free, training was less disruptive to their work. They had a chance to coordinate with others in the morning and feel more focused in the afternoon. In addition, routine work in the morning allowed students to think about how Scrum, Agile and Lean methods might change how they work.

Research on learning also indicates that some commonly accepted truths are false and suggest surprising approaches worth considering [care2010]. For example, catering to left-brain or right-brain dominance in students apparently has had little value in helping them learn [pash2008].

In contrast, varying the context in which learning takes place, including changing the actual room, can help increase conceptual memory [smit1978]. So, perhaps, I will hold the next Scrum Training I provide in different classrooms on different days; we need to mix it up a little, so the ideas will gel.

Is your trainer applying these techniques when they teach you?

Though an occasional reference section arises vestigially from my academic past, I remain your devoted servant in the present. —Dan Greening

References

[biel2006]

David Biello, “Snooze or Lose: Memory Retention Enhanced by Sleep,” Scientific American News (July 11, 2006). http://www.scientificamerican.com/article.cfm?id=snooze-or-lose-memory-ret

[care2010]

Benedict Carey, “Forget What You Know About Good Study Habits,” New York Times (September 8, 2010). http://www.nytimes.com/2010/09/07/health/views/07mind.html

[elle2006]

Jeffrey M. Ellenbogen, Justin C. Hulbert, Robert Stickgold, David F. Dinges and Sharon L. Thompson-Schill, “Interfering with Theories of Sleep and Memory: Sleep, Declarative Memory, and Associative Interference,” Current Biology, Volume 16, Issue 13, pp 1290-1294, 11 July 2006, doi:10.1016/j.cub.2006.05.024. http://www.cell.com/current-biology/abstract/S0960-9822%2806%2901607-1

[pash2008]

Harold Pashler, Mark McDaniel, Doug Rohrer and Robert Bjork, “Learning Styles: Concepts and Evidence,” Psychological Science in the Public Interest 9:3 (December 2008), pp. 105–119. http://www.psychologicalscience.org/journals/pspi/PSPI_9_3.pdf.

[scul2010]

Michael K. Scullin and Mark A. McDaniel, “Remembering to Execute a Goal: Sleep on It!” Psychol Sci. 2010 Jul;21(7):1028-35. Epub 2010 Jun 2. http://pss.sagepub.com/content/early/2010/06/02/0956797610373373.abstract

[smit1978]

Smith, S. M, Glenberg, A. M., & Bjork, R. A. (1978). Environmental context and human memory. Memory & Cognition, 6, 342-353. http://bjorklab.psych.ucla.edu/pubs/Smith_Glenberg_Bjork_1978.pdf

Meeting Scrum: Part 1, Make Information Flow

Concerned citizens might warn you not to stand to close: I rope nearby bystanders into the crime I'm currently committing. So when Scott Downey, the General Patton of Hyperproductive Scrum, told me he was busy crawling wineries near my Santa Barbara office, I suggested getting together. “How about 11:30am for lunch?” I asked. “Perfect,” he said, “See you then.”

Scott arrived, we had a hearty repast, and after agreeing the world needed our genius, I had to get ready to to teach the second afternoon of Scrum Training at Citrix Online. Did he want to come? “Sure,” he said. As we walked into the conference room, I asked if he might like to present some of my slides? “Why not?” he said. When we started looking at them, Scott felt uncomfortable. Could he use his own slides?

Figure 1. The General Patton of Hyperproductive Scrum

Yes, he could use his own slides, and he did. In 20 minutes, Scott and I eliminated concepts I had already discussed from his very different Scrum Training deck, and restructured slides that would be relevant for that afternoon into short blocks. Scott trained the entire afternoon solo, with me coordinating and heckling. The transition was nearly seamless. Our students liked our surprise guest, and our sparring interaction helped spice up the material.

To make this possible, I relied on a highly-adaptive meeting format I call Meeting Scrum. It can turn dreary, boring meetings into vibrant, audience engaging events. The next time you have a half-day meeting, you might give a try.

Think Iteratively

Meeting Scrum decomposes high-impact training programs and full-day meetings into  digestible chunks. It involves your audience to help reconfigure information and agendas  on-the-fly to adapt to their background, your skills, last-minute opportunities and plain old serendipity.

Meeting Scrum miniaturizes concepts from Scrum, a software management technique. Scrum produces software in short fixed-time iterations called “sprints,” and demands each sprint produces software that customers value. This requires extraordinary discipline, but typically delivers high-quality software to customers faster.

How long should Meeting Scrum sprints last? Whether in Meeting Scrum, Software Scrum or Enterprise Scrum, sprints should always be long enough to provide independent value, and short enough to allow for rapid continuous improvement. One hour isn't always enough, especially when learning games are involved; more than a couple of hours means you won't be able to adapt to feedback even in longer meetings.

Two-hour sprints have worked well for me. Attendees can learn valuable skills and provide useful feedback after two-hours. Agile Training at Citrix Online is 16 hours long, providing 8 two-hour sprints. All-day meetings are 8 hours long, providing 4 two-hour sprints. Even in half-day meetings, you get a chance to change the agenda mid-meeting.

Create a Topic Backlog

Before using Meeting Scrum, prepare your program for iteration. Every program can benefit from an agenda. If you are starting with a giant, unstructured Powerpoint deck, decomposition for Meeting Scrum will improve your presentation.

Work items in Meeting Scrum are called “topics”. Give each topic a clear title, put it in a document or spreadsheet, and then rank-order the list. Of course, cover basic topics first; as you build understanding, cover more advance topics.

If this is a teaching situation, break up lectures with exercises: direct, multi-sensory experiences help people learn. Each exercise is a topic of its own. Remember: you don't have to explain a concept before you do its exercise. Sometimes an audience frustrated by an early exercise is more open to lectures that follow.

Your list of rank-ordered topics and exercises is called a “topic backlog.”

Groom Topics

Excessively broad topics take too long to keep an audience's attention. You should be able to cover 3 or more typical topics in two hours. If a topic is too long, break it down into smaller topics and then wrap them up in a final topic. You don't have to cover all these topics in a single sprint.

How do you know whether a topic will be too long? If your program is slide-driven and you are an experienced presenter, you may already know your approximate slide velocity (slides per hour). I can do about 8-15 slides an hour in Agile Training. I don't like my topics to be longer than 8 slides long. Open-discussion topics and exercises require some estimation. I estimate a non-slide topic in “slide points,” roughly how much time it might take in slide-equivalents.

Figure 2. Restructuring Scott's “My First Sprint” Topic

We had to groom Scott's program in 20 minutes. On the first training day, I had already covered the motivation for agile and productivity fundamentals. We pulled Scott's motivator slides out. We agreed that his “My First Sprint” slides would be a good next topic. But at 49 slides, it had to be broken down. Figure 2 shows the hierarchy we created. In the process, Scott reordered slides to fit into these topics.

Iterate

We then started the two iterations for the day, Sprint 3 and 4. They had this schedule:

Sprint 3	Sprint 4	Activity
1:05pm	3:05pm	Plan
1:10pm	3:10pm	Work
1:50pm	3:50pm	Questions
1:55pm	3:55pm	Work
2:40pm	4:40pm	Review, Retrospective
2:50pm	4:50pm	Snack

In later posts, I'll describe how we structured these sprints, the ultimate outcome of our Scrum Training, and how Meeting Scrum has changed since we started using it.

Challenge Questions

Some questions to think about:

1. How many slides do you think Scott completed in Sprints 3 and 4?
2. If you are familiar with Software Scrum, who are the stakeholders in Meeting Scrum?
3. Who is the Product Owner in Meeting Scrum?
4. What might transpire in a Meeting Scrum standup?
5. What rules might we apply to decide whether a topic could be started (the Topic “Ready Criteria”)?
6. What rules might we apply to decide whether a topic was completed (the Topic “Done Criteria”)?

With a tendency to stretch and shrink things, I remain your humble servant.

Cult of Zero:Free Your Creative Soul

A “Cult of Zero” is developing worldwide. Adherents drive the total emails in their inbox to zero, every day, with great results in improved productivity. I talk about how you can get your inbox to zero, and keep it there.

Unbelievers wonder why cultists obsess about their inboxes. Take a look at the church roster, and you might find a hint. Some are well-regarded executives, who somehow find time for impromptu meetings or a mid-day tennis game. Some are up-and-comers, picking their battles. Some are just calm folks doing a great job, unperturbed by late-breaking drama.

Merlin Mann: Cult of Zero Prophet

OK, OK, I admit it: some are wild-haired entrepreneurs, like Merlin Mann, who post video rants about office temperature. But they all tend to get big projects done. When they say they will do something, they typically do it.

The main skill cultists hone, I've found, is being able to prioritize demands on their time. Getting your inbox to zero every day means you have learned many supporting behaviors: you have figured out how to identify and finish important work and reject or defer the rest.

Why do it?

Most of us use our inbox as one of many To Do lists. We retain emails to help us with future efforts or remind us of commitments. Optimistically, we think we'll return to a thread eventually. Emails build up, and after a few days that important thread disappears into the inbox jungle.

We take a two day vacation, and it dooms us. Buried under hundreds of old emails are time-bombs, spam, demands for response, and questions. And soon, its utility as a To Do list becomes meaningless. Did I really have 3500 things to do?

Defense, Defense

You can find salvation. Start by going to your inbox. Right now.

But before you even delete the obvious spam, let's talk defense. To get long-term benefits, invest some time upfront. If you keep unimportant stuff from landing in your inbox, you will have much less work to do in the days and months ahead.

First, look for spam and stop it from reappearing. If you are using Google Mail or another system with built-in spam detection, most of the unwanted email in your inbox can be stopped.  Instead of just deleting email you don't want, establish a new policy: Don't delete the email until you have unsubscribed. Look for an "unsubscribe" link at the bottom or top. Use it. Only after you've unsubscribed should you delete a spam email.

Be ruthless about subscriptions. If you wouldn't actually pay for someone to send you that subscription email, remember that your time is worth something: maybe you shouldn't receive it at all. When an online store sends you a coupon, remember that you can look up most coupons online when you need one. Unsubscribe. When magazines send you tables-of-contents, remember that you can use an RSS reader, like Google Reader, to create topic lists to browse when you have spare time. Better yet, you can just search the web when you have a need. Unsubscribe.

Teach your friends not to send you unoriginal email. I have a rule: Each friend can forward one unoriginal email (meaning my friend didn't actually create anything in it) exactly once per year. So, if that really funny compilation of jokes is really the best compilation of jokes you're likely to see in the next year, forward it, but now you have to wait another year. When you make this rule, you enlist friends to help you achieve nirvana. Now they think twice: If my friend has limited time, is this how I want to use it?

Reply to each forwarded item from friends with your new once-a-year rule, and delete it. If you want to soften the message, remind your friends that you really want to hear from them, and that means you want to know what they are doing. Forwarded joke emails don't bring you closer.

Convince friends to communicate casual news through Facebook or another social network site. Facebook has helped me stay in better touch with friends and family, while dramatically reducing inbox clutter. When I don't want distractions, I don't visit Facebook. When I want to see the latest on news on friends, even after a long hiatus, I check out their Facebook walls.

Get off most personal and work informational email groups. Make sure the email lists you are on address issues you must deal with. Sometimes, you can ask an organizer to remove you from an email list, but add you on the To: line when an exceptional situation requires your attention. For newsletters, you can often subscribe to view only on the web, using an RSS reader like Google Reader: this is perfect for most situations. Go there when you want to see the latest.

Getting Email Done

Now that we've put defensive barriers in place, let's talk about routine email processing. Driving your inbox to zero is one of many productivity techniques advocated by Getting Things Done: The Art of Stress-Free Productivity (GTD) author David Allen. GTD recommends that we prioritize all incoming work requests, including email.

Create a ritual around managing your incoming mail. If no action is required, archive or delete it. If action is required and it takes less than 2 minutes, do it immediately, and then archive or delete it. If it is a time-sensitive newsletter and it is old, archive or delete: too late to do something now. If you can delegate to someone else, forward the email to them and delete.

Hopefully, at this point, you have less than 20 emails in your inbox. If not, I have sympathy, because you have a lot of big things to do.

Each remaining items in your inbox will take more than 2 minutes to complete. The best thing to do is to move these items into your ongoing To Do list, so you can prioritize them. Once the item is in your To Do list, archive the email.

Now you've reached Nirvana: nothing in your inbox. Welcome to the Cult of Zero!

What's Next?

It took about a month for me to get both work and personal email to zero. I had unsubscribed from almost everything and taught my friends and colleagues to better respect my time. Subscriptions that remained were mostly ones I was paying for. (Funny how that works!)

Nirvana

Days after I hit zero the first time, a nervous tick forced me to check my email every hour or so. Not much new was in there. I wondered whether people still liked me! But, then I said, “OK, now I should work on the most important item in my to-do list.”

Suddenly more things were getting done: the change was dramatic. I finished some tough work projects, one of which saved the company a few million dollars. I filed tons of back expense reports (I travel a lot for work) and have stayed caught up. I set up drip watering systems in the back yard I’d long been putting off. I filed my taxes a month early (I had, more than once, driven to the airport post office 10 minutes before the midnight April 15 filing deadline).

I can better focus on complex issues. I relish that I am minimizing my “work in progress.” Cult membership supports a principle of “lean thinking,” one of the main pillars of agile management: Don’t take on work that you aren’t ready to focus on and finish. Don’t have a lot of projects started but not completed (“work in progress”).

Establishing, grooming and working through prioritized to-do lists is the noble topic of Getting Things Done: The Art of Stress-Free Productivity, a easy-read book that transformed how I work. An approach like GTD can help you sustain Cult membership.

Will you join the Cult of Zero? One of us! One of us!

Eating my own religious dog food, I remain your humble initiate.

Agile 2010 Impressions

Agile 2010 was held in Orlando near the Disney Epcot resort August 9 to 13. I focus on agile enterprises and attended many enterprise-focused talks. If you are interested in the developer focused view, Martin Fowler provides his thoughts here. My impressions follow.

Portfolio management is being implemented in conjunction with quarterly “sprints” in other places beside Citrix Online, including Motley Fool (Max Keeler), Tektronix Communications (Brian Miller) and Progressive Medical (Ben Blanquera). The four of us are starting to share ideas and experiences.

Value and Product Management is a hot topic. More than 50% of the time, speakers strongly argued that NPV and ROI was an inappropriate metric (this was largely from the folks dealing with team-level Scrum), but an intriguing minority asserted that Product Managers who don't assess priorities using NPV and ROI are irresponsible. Deep thinkers, like Luke Hohmann, acknowledge that NPV and ROI are important at the portfolio level. One of the most interesting presentations in this area was the presentation “Extending Agile - to finance (really?),” where NPV is consciously part of every discussion, even at the story level. The CFO is part of the product stakeholder team and sits with engineers weekly. The company has a big chart showing how value and expense get aggregated into corporate financial statements.

Forrester is seeing that Agile engineering processes are transforming the enterprise outside engineering. This was a subtle undercurrent of many other presentations. Of course, we are seeing this phenomenon in Citrix Online, where APO is teaching marketing, customer support and human resources departments about agile processes. A year ago, agile advocates in Citrix Online, especially me, were bitterly disliked by many people both inside and outside engineering. Now we are highly regarded and sometimes sought after.

CMMI+Scrum continues to intrigue, as it demands that the organization find ways to measure and improve enterprise-wide processes, potentially complimenting Scrum's feedback loops and retrospectives at the team level. However, almost all CMMI books provide examples exclusively from waterfall. Many people talked about needing an enterprise capability model  like CMMI that better reflected Agile thinking. Finally, Kent Johnson made a great comment that put it together for me: “CMMI dictates engineering and process quality metrics and improvement, but the real goal is value.”

Like Martin Fowler, I was underwhelmed with the presentation quality, finding myself stupified by many talks whose descriptions initially seemed interesting, but ultimately just rehashed long-argued religious platitudes (“you can't measure value with NPV,” “you really should have teams co-located,” “it's all about team self-organization”). Yawn.

I bumped into Tom Poppendieck, gushed shamelessly about his brilliance and fame, and then complained that I had heard most of the Agile 2010 material before. Why did he still attend? He found that most of the good exchanges happened for him in the hallways during the presentations: that's where the bored people hang out, and many of the bored people are the advanced thinkers. Armed with this alternative, I sallied forth.

Advanced thinkers move beyond the platitudes to ask the tough questions, like “Why can't we measure value with NPV?” and work through the Five Whys. Their Why not? talks captured my attention. Two rare examples from Agile 2010:

• Scott Downey and Jeff Sutherland, the first to strongly argue for the highly-prescriptive Hyperproductive Scrum (Agile 2009), this year demonstrated an Excel spreadsheet that translated team productivity metrics into a letter to the team documenting its likely impediments. They called it RoboCoach. This generated interest from many and outrage from a few. Bravo!
• Ben Blanquera described how his CFO helped develop a hierarchy of revenue and expense to motivate every Product Backlog Item. The CFO sits with the team during Sprint Planning to explain the value of every story to the team, in profit. This session was lightly attended, but I think it had everything to do with the title and description. “Extending Agile - to finance (really?)” sounds to me like a talk about making the finance department agile, doesn't it? It wasn't.

With a perspective on Agile 2010, I remain your humble servant.