Monday, May 25, 2009

Flow, Leveling, and User Stories

Flow and leveling are two sides or the same multi-sided shape. The goal is an understood and controllable cycle time. Without leveling, sustained flow is unlikely. Without flow, improvement is less observable and manageable. Improvement efforts might be rooted more in medieval software superstitions than something closer to a science.

David Anderson talks about the core of Kanban as an agreement that the team has a capacity; that they can only work on so much at a time; and a limit set around that work. Implicit in Lean work management styles is the right-sizing of work items. Reducing the broad variability in work item sizes is a part of the work that goes into flow and into controlling cycle time.

Typically, in a method like Scrum, a team organizes its work efforts around user stories. The user stories that are worked on during an iteration (or sprint) can be any of a number of sizes. Using the Fibonacci estimation technique the variation in story size can be almost infinite.

User stories are a way to communicate expectations, but they're a less effective way to manage work and improvement because of the amount of variation allowed in user story sizes. You could decompose stories into smaller stories so that they're more manageable, but then you'd risk fragmenting the communication value of stories by breaking them into separate chunks that might not carry as much context as the original larger stories.

User stories can be of variable size because they inherently are of variable size. Let user stories be the size that makes sense for the kind of artifact that user stories are: an artifact intended to communicate context and expectations to the development effort. Use right-sized work items to manage work. Decompose user stories into work items and schedule those work items for development in way that takes both customer priority and technical constraints into consideration.

The work items can certainly be linked back the stories that they are decomposed from, but it's the work items rather than stories that go through the development pipeline.

I've sat through enough all-hands Agile planning and estimation sessions to know that while this practice is useful for bringing a new agile team together, it's often a terribly ineffective way to establish design. It's a good way to socialize design, but there are alternatives that don't imply the wastefulness of traditional Agile planning and estimation. Using design as a team-building exercise can put the design at risk.

In the worst cases, the all-hands planning and estimation that is common to Agile development methods can hurt the team. It's just as likely that adversarial conditions can break out in the team if an expectation is set that suggests that product design and implementation design are egalitarian and democratic within a team that is necessarily staffed by people of varying experience and ability.

Design should be done by those who are most capable of doing design. Story decomposition should be done by the person or people who are best equipped to do that work. This doesn't preclude the socialization of that design to the team and the proving of that design by the team.

Rather than all-hands estimation and planning, design and planning can be done in short, effective sessions with the team's designers. Since designers are decomposing to work items that are intended to be of a similar size, the team no longer estimates work, but reviews the decomposition and seeks clarification and raises concerns. The collective intelligence of the team is still leveraged, but the potential waste and ineffectiveness of traditional Agile planning is avoided.

The planning and estimation activities change from larger-scale chunks of time, effort, and team participation to smaller units of tiered work and cooperation that can be done just-in-time rather than on those specific days of the week when the whole team's attention can be coordinated and directed to a fixed-schedule meeting. Consequently, any all-hands team meetings can be scheduled on an as-needed basis as well, eliminating any waste that comes from institutionalizing all-hands meetings according to a fixed timebox.

With planning, design, and scheduling being done in smaller units on a just-in-time basis, some of the fixed time boxes in the development process aren't needed. Features can be queued for packaging and deployment on an opportunistic basis as well. There may still be some fixed rhythms at-play in the effort - customer demos and major market events, for example - but these synchronization events don't have to leak their scheduling mechanics into aspects of the work that aren't dependent upon or necessarily coupled to those rhythms.

Work items aren't just same-sized, they're also small-sized. The larger the work item, the more variability there is between the estimate of the work and the actual work. We understand larger work items with less certainty than smaller work items. That's because decomposing work into smaller items means that we have to think about the actual units of design and work that go into delivering those bigger features. Because we're trying to achieve flow in pull-based systems, the variability inherent in larger work items is a likely obstruction.

The specific amount of work that defines what "small" is depends on the kind of work, the team, and a handful of factors. And the actual size of "small" will likely change over time. In some cases, it might just be impossible to get all work items to be of similar size. Consider whether the work can be scheduled so that groups of similarly-sized work items can to be done together.

Without leveling, flow will continue to be difficult, and Kanban a Japanese word that has come to mean "story wall".



Ampersand GT

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Sunday, May 24, 2009

Pull Harder to Find Problems with Flow, and Improve From There

A focus on flow that leads to continual observation of the health of flow lets us use flow to improve organizational performance. Once flow is happening in a pull system, pull harder. Pulling harder will show you where the next level of obstructions is in your organization that keeps you from the next level of performance.

Lean and Kanban are geared to performance improvement, and their principles are applied regardless of the development process in-play, and in concert with the existing process. As opposed to something like Scrum, Lean doesn't require the wholesale, instantaneous replacement of existing processes with a prescriptive process template like Scrum (or others).

Using Lean principles and Kanban will show you the hotspots in your process where you might need to focus your improvement efforts. The software process mechanics that you end up with could very likely end up looking a whole lot like a prescriptive Agile development process, but the adoption and use of specific practices and mechanics are driven by tangible need, based on the repercussions of several instances of pulling harder and deploying and observing the countermeasures that clear out the chaotic oscillations that result immediately from pulling harder.

Pulling harder means increasing the expectations for the capacity of the system. Lean organizations aren't sitting on their laurels. Successions of pulling harder, solving the resulting organizational, process, and mechanical problems, and understanding and working with resulting performance improvements is Lean's continuous improvement. Continuous improvement means an inculcated value system that doesn't allow its past achievements to distract from the next level of goals, and the inevitable ardors of reaching them.

The organization is there to serve the goal. A Lean organization isn't a goal in and of itself. The organization bends to serve the nexus of value creation at the center of the vaue-add work. An obstruction to the ability to successfully pull harder might be found in a part of the organization outside of the immediate product development team. If that's the case, it's understood that the system as a whole must be optimized in order to continue to improve performance.

Once you've got your bicycle up to speed, pedal harder and see what might get in the way of being able to. And then devise and manage a well-considered plan to adapt the process and the organization to get those obstructions out of the way.

Pulling harder creates process improvement simply by setting expectations that are designed to clearly and brightly illuminate the ugly obstructions the lurk in organizations and processes and even in the tools being used. Simply: improve by improving. Set new expectations for the well-understood process and team and take a principled approach to understanding and working with the team's capacity.

Merely overlaying new process templates on a team isn't really the most reasonable and effective approach to improving performance. A change in process should be goal-driven and executed methodically. You might make some sweeping changes in the process, but the wholesale adoption of something like Scrum's agile project management prescriptions isn't likely necessary, and in some cases such a course might exasperate the effort for performance improvement.



Ampersand GT

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

Friday, May 22, 2009

Flaccid Kanban

A few shops in my professional community have started flying the Kanban flag. This is potentially a great step forward in opening the agile software development dialog to a more rigorous understanding of value, especially in how value is lost and how to defend development efforts from the pervasive value leaks in end-to-end workflows.

XP and Scrum shops - especially those with people with significant XP and Scrum experience - might trip over their unrecognized biases at first.

Iterations and Rolling Wave

Kanban doesn't require iterations. Scrum and XP work management doesn't magically transist into Kanban when we remove iterations. What we get from iteration-less Scrum and XP is Scrum or XP with rolling wave planning. Regardless of the benefit of rolling wave, it's not really Kanban until you're asking (and answering) some fundamental questions about work management, organizational performance, and value.

What is the purpose of Kanban?

The purpose of Kanban in software isn't to merely ditch the overhead of iterations. That overhead is a form of waste that might be avoided when iterations are taken out of the picture, but depending on the surrounding context, just as much compensatory waste might be created when iterations are removed.

The purpose of Kanban - other than visual control systems - is to limit work-in-progress in relation to a team's capacity in order to become sensitive to opportunities for improvement and to see waste and value loss (attribution: david anderson). But it's not enough to just announce in a team meeting that context-switching is now verboten. There's a point to limiting work in-progress, and there are a good number of inter-related practices and principles that benefit the work and the management of the work that come into play.

Flaccid Kanban

Martin Fowler recently wrote an article entitled Flaccid Scrum. The article calls attention to a Scrum implementations and adoptions that try to achieve agile software development's promise without implementing anything but agile project management, ignoring the engineering practices that allow agile project management to yield the promises of agile software development as a whole.

As Lean gains popularity and adoption, it becomes susceptible to the degradations that come of mainstream opportunism. Kanban adoption into relatively mature XP teams seems to be creating a sort of Flaccid Kanban - implementations of Kanban that more or less disregard the underlying reasons and mechanics of Kanban.

The real loss here is that we tend to stop looking for something once we believe we've found it. What has been frequently adopted lately that has been called Kanban appears to be merely rolling wave planning. Not that there's anything wrong with rolling wave, it's likely a necessary component of Kanban in software development, but there's nothing good about reaching for Kanban and coming up short because of the temptation to use Kanban in-name-only merely for the fashionista value.


Ampersand GT

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com

A Metaphor for Flow

Kanban is concerned with flow. Flow brings a group of inter-related concerns into play. Flow isn't as readily-understood in software production as it is in other production industries. Here's a simple metaphor for flow:

Flow is like pedaling a bicycle. As long as you're pedaling, you can continue to pedal, and maybe even pedal faster.

If there's any obstruction to pedaling your bicycle, you certainly won't be able to pedal faster. You'll be pre-occupied with just getting the pedaling happening again. If the chain breaks, you certainly won't be pedaling at anything even approaching your optimum.

So much software development effort is spent trying to get the chain back on the bicycle that we're practically inured to stagnant flow and verily accept it as inevitable.

Waste is only inevitable if you throw your hands up in the air and give up on the field of study and effort that moves software as a production industry into the realm of maturity that other production industries enjoy right now.


Ampersand GT

Working with software developers and organizations to help realize the potential of software product development through higher productivity, higher quality, and improved customer experience

Learn more about my work and how I can help you at ampgt.com