Scrumerati

Release Duration and Enterprise Agility: Global Webcast on 7 Feb 2012

Short release durations help companies test market theories to maximize profit. When managers measure release duration and advocate its reduction, they drive changes that improve the long-term productivity of the company.

Join me on February 7, 2012 at 11:00am EST, for a Scrum.org Global Webcast on release duration.  Register now at Scrum.org Global Webcast: Release Duration and Enterprise Agility.

We'll discuss how to obtain a release duration history from financial records, and how a finance-based definition can help you assess your ability to innovate profitably. We'll talk about various forms of technical debt and how they affect release duration.

 

Release Duration over a Company Lifetime

We'll show how measuring and restricting release duration helped improve code quality and processes in a mid-size software company. Both as a startup and mid-size subsidiary, the company's technical debt insidiously increased while it used traditional project management practices, even in the first months of its life, accumulating to a level where some projects took over 35 months to realize revenues. After focusing on reducing release duration and adopting Scrum and other agile processes, the company's engineering and product management groups eliminated much technical debt and drove release duration lower than it had ever been. The company's productivity, competitiveness and market share all improved during the same period.

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.

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.

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.

The Demise of NUMMI

A colleague of mine, Kris Niles, sent me this long (59 minute), but compelling audio from "This American Life", on the demise of the Fremont NUMMI auto plant. The GM Fremont plant was shutdown in 1982, restarted as GM/Toyota NUMMI in 1984, adopted the agile “Toyota Production System” through a massive education program (they flew all NUMMI plant personnel to Japan, where Toyota trained them), and almost immediately started producing high quality cars.

This is not a story of failing to change; it is a story of changing too slowly.  GM could not replicate the learning it obtained from NUMMI fast enough. Its first attempt to replicate NUMMI, by converting its Van Nuys plant to Toyota Production System (without retraining everyone), failed miserably. Resentful workers seeing that seniority was no longer valued, rebelled. Managers with cushy privileges and familiar control, pushed back.  GM closed Van Nuys and laid everyone off.

GM President Roger Smith finally started to seriously implement Toyota Production System in 1993, and gradually spread it throughout GM, but it took over a decade: too long to forestall bankruptcy. Some quotes from the piece: "Steering the Titanic with a canoe paddle."  "If you take 30 years to figure it out, you're going to get run over. And they got run over."

GM’s market share dwindled and ultimately it fell to bankruptcy in 2009. NUMMI was abandoned by GM to its partner Toyota. NUMMI was shutdown on April 1, just a couple of days ago, by Toyota.

This episode of This American Life describes cultural issues with eerie familiarity: resistance to agile methods from both individuals and managers. Folks that have comfortable, familiar roles in dysfunctional systems they don't want to give up.

We speak like GM when we postpone automated testing; when we allow ourselves to create new technical debt “because we need to ship features faster”; when we assert it is "impossible" to release new features to the outside world every Sprint; when we fail to sideline toxic employees; when we discourage a team from self-organizing to tackle problems; when we complain about having to interact more with lesser teammates to help them go faster; when we allow impediments to persist; when we fail to train everyone in agile methods "because they aren't managers"; and when we fail to “stop the line immediately” to address and fix process problems. If you are an agile company, you may think these problems are going away, but I bet you aren't making them go away fast enough.

If you are piloting the Titanic, don't steer it with a canoe paddle.

The link: http://www.thisamericanlife.org/radio-archives/episode/403/nummi