The Big Agile Practices Survey

I made a simulation of an XP-like process. I won’t go as far as to say it’s exactly XP, but it’s a reasonable approximation. The first one is an unconstrained workflow with a single customer. It is a PIPE2 simulation, and the file is here. Multiple customers (or nested stories) would require a colored Petri net, which PIPE2 doesn’t support.

One of the keys to understanding the model is the bidirectional edge between the customer and write a story.  The team keeps writing stories until the customer doesn’t want any more stories and accepts a final build.  Other keys are the bidirectional edge out of accept story and the inhibitor arcs into accept build.  Those things give the model most of the “iterative goodness” you’d expect.

Not surprisingly, the unconstrained workflow rarely reaches a checkpoint where the customer has nothing in process, so the deliver build transition rarely triggers. If we add a stories in process kanban limit, then there is also much more reengagement with the customer as a consequence. That model is here.

I would be interested to hear of any improvements to the model. ]]> http://leansoftwareengineering.com/2009/03/09/extreme-programming-workflow-simulation/feed/ 5 http://leansoftwareengineering.com/2009/01/30/the-modus-cooperandi-card-wall-circa-december-2008/ http://leansoftwareengineering.com/2009/01/30/the-modus-cooperandi-card-wall-circa-december-2008/#comments Fri, 30 Jan 2009 07:06:06 +0000 Corey Ladas http://leansoftwareengineering.com/?p=570

This is the card wall we’re currently using in the Modus Cooperandi office.  It’s not terribly complicated, because there are only five of us, but there are still a couple of interesting things about it.

We’re working on a number of different programs in the office.  Some of these programs have distinct workflows.  Most of them don’t, or more accurately, don’t yet.  So, we’ve split the board into two sections.

The top section is the workflow for software development.  The workflow is yet another variation on the two-tier workflow that I’ve discussed here before.  The green tickets are Minimum Marketable Features (MMFs) and they occupy the outer, slow-moving workflow with states { backlog, ready, busy, demo, verify, done }.  The yellow tickets are User Stories that are decomposed out of the green MMF tickets.  The inner User Story workflow is { ready, busy, demo, done }.  Stories should be done in a few days.  MMFs may take several weeks.  The workflow is not particularly detailed because the team is small and the work is exploratory.  The emphasis on the demo states is because most of the work is done off-site.  We’ve allowed capacity for two MMFs in process at any time, but for now we are only scheduling one.

The rhythm of pull, and the discipline of the MMF make planning a self-regulating activity.  Naturally occuring pull events occasionally trigger planning events, which trigger further pull events and so on.  Demos and process improvement are built into the workflow, so no planning contrivances are required to make these happen.  Keeping the “Minimum” in MMF isn’t always easy, so having a “Minimum Champion” around is pretty important to making this kind of self-regulation work.  Time spent thinking about real options strengthens one’s resolve in this matter.   Enforcing the MMF is still much easier than wasting a lot of time on estimating and forecasting.  And after you gather enough cycle time data, the work begins to forecast itself.

Software development is one thing we’re working on, but we also have a number of other programs which are…not software development.  For now, these are mixed work item types that don’t have well defined workflows.  Instead of assigning them to a workcell, we assign them to individuals, with a generic common-denominator workflow of { backlog, ready, busy, verify, done }.  Backlog tasks are unassigned.  Ready tasks are assigned by affinity or consensus.  At the time that a task is assigned, it is given a due date.  When busy tasks are judged complete by their owner, they are moved to the verify state, where somebody else has to agree that the task is complete.  When a task is verified, it moves to a pooled done state.  Blocked work, as always, gets a pink ticket for issue resolution and/or process improvement.

Some of these programs are content development and we expect that they will develop more regular workflows over time.  When we identify those workflows, we’ll redraw the board and move their tickets out of the personal rows and into new workcells.  Eventually, we may collapse all of the personal rows into a single “miscellaneous” row.  The miscellaneous row is worth keeping because there’s always random stuff to do that still merits tracking.  The card wall is a living system that is subject to evolution as we learn more about how to do our work.

We haven’t set hard WIP limits on the personal rows, because we’re able to manage it through peer feedback…mostly.  The emphasis on controlling WIP still allows us to plan new work and manage the backlog on demand.  We all know that if the WIP ever gets out of hand, we can restore order by setting kanban limits.  The card wall is the focus of the daily standup, where we gather around, point at the tickets, move them around, write new tickets, and make plans for how we’re going to advance the board for the day.

The lesson is that, with or without kanban, the investment in a thoughtfully designed and carefully managed visual control is already enough to obviate time boxing and the planning ceremony that goes along with it.  Go with the flow.

Software development is like golf in that your chosen path to the pin is a primary problem.

The choice involves weighing your capabilities (people), the course (technology), and the conditions (market).

Confident you can do anything?  Bring out the big guns and send it over that treeline on the left. If you make it, you must land it among that sea of traps. This is the most common choice in software development, and the #1 reason why we so frequently turn “par 5″s into 10, 15, and 20s.

Don’t have a team of Tigers?  Then go long down the center if you can avoid that large sand trip on the left and lake beyond it. But is this abstract little map accurate enough?  Does it tell us about the 50 yards of soggy turf there in the middle?  How about wind howling left to right over the lake?  Unless you’ve played this hole before you don’t know.  What makes software development so tricky is by definition we never play the same hole twice.  Technology is changing around us, even while we make our own changes.

Want to make sure you don’t turn a par 5 into a 10?  Land it short of the traps on the fairway and take it from there with comfortable strokes. There’s a price to pay for this caution: no holes in one for you.  You’re less likely to be a hero this way, but in team-scale software development, the hero model will fail you are sure as a week in Vegas, anyway.

And, sometimes, the conditions are particularly bad.  In the downturn of 2008/2009, one could say the conditions for technology products are analogous to “a raging hurricane, with chance of nearby volcanic eruption and ash over the course.”  So take care. Be humble.  And may you keep both your work in progress and your golf scores down.

(apologies to all software developers offended by an anology from the “sport of salespeople and CEOs”.  Think of it as an analogy to bridge the divide)

I think this is going to be a very exciting conference.  The Lean software development community has made explosive progress over the last couple of years, only to discover that we are still in the dawn of our evolution.  I expect to see terrific advancements in 2009 and some of them may very well find their beginnings at this event.

read this paper…

Barry Boehm proposed his Spiral Model of Software Development.

Which bore some resemblance to Deming’s “Plan, Do, Check, Act” cycle.

Boehm’s insights have had a huge positive impact on how we think about software development. But the spiral itself lost some of the beauty of Deming’s model: the simplicity, self-similarity at different scales, and the balance between activities in the quadrants. Which, perhaps, has caused Boehm’s model to be underused as a tool for introducing people to how creative engineering works. This is unfortunate, because the waterfall model, being more obvious, continues to be where most people start. Only then, after they have personally experienced the pain of struggling projects, do they search for a more appropriate model.

The Simple Sprial

Here is a simple love-child between Boehm’s and Deming’s views which has been very helpful to me in keeping a visual model in mind when thinking about how effective software development (or any creative engineering) really works.

Customer	Plan
Test	Design

How does this work?

• The more iterative your development process, the more times you spiral around
• You spiral inward from the high-level descriptions down to the lower level implementation details (note: this directionality is inverted from Boehm – this model doesn’t try to convey the amount of cost or work in each loop around the spiral)
• As you spiral down, the activities change. “Design” at the high level might be on paper. But as you spiral down, design is about turning those paper documents into executable code. Same for the other quadrants.

Quadrants

• Customer. What does the customer think? In one of the better trends of the last 20 years since Boehm’s paper, agile methodologies have recognized the customer as an essential direct participant of the development process. We can try to guess what the customer ultimately will find valuable. But if we don’t regularly check back with them, we’ll get enough wrong to sink our product and company over time.
• Plan. What do we plan to do? This includes requirements analysis, priorities, risks, and schedules. At the very high level, it may be corporate goals. At the very low level, it might be writing an automated functional test before writing the code to make that test pass.
• Design. How will we do it? At the high level, design is done via documents, diagrams, and discussion. At the lowest level, design is expressed as the executable code that constitutes the product.
• Test. Have we done it right? At the high level, we discuss and review ideas and documents. At the lowest level, we execute tests against the functioning product.

The four quadrants align with how we tend to specialize our people and organizations as we grow. In a Microsoft organizational model, it aligns with customer, program management, development, and test.

The “Simplistic Spiral”

The simple spiral is useful, because it is flexible enough to encompass many approaches to development. Take the waterfall model from the top of this post, and wrap it into one loop through the spiral, and you get “the simplistic spiral.”

Customer	Plan
Test	Design

Wouldn’t it be nice if projects could reliably just work this way?

But we know if we apply this model to a large product, we’re nearly certain to have a disaster on our hands where many assumptions made in planning are discovered to be poor in design or test.

But apply it to a queue of appropriately-sized (small) and well-understood functional requests, and it may be an appropriate model for each kanban in a lean production workflow (or perhaps each kanban should be two or more loops round the spiral). In any case, the model is helpful in visualizing all these cases.

The “Product Spiral”

It also helps us create useful visualization of product lifecycle models at various scales.

Company
Product
Project
Feature
Change

At the company level, we are constantly cycling: seeing what the customer/market reaction is to our products, planning new products and enhancements, designing and testing them.

At the product level, it’s the same, but from the perspective of the evolution over a lifecycle. But even when a product enters later lifecycle phases like maintainence, the model is still the same: the customer finds bugs, we prioritize, fix, and test them — and it goes back to the customer for the cycle to start again.

At the feature level, we recognize that this has a lifecycle of its own. Before committing a feature to a product, all aspects (including feedback from the customer) should be covered, likely with several iterations. Perhaps one of the secrets of success to many open source ecosystems is that they encourage/allow individual features to evolve independently and iteratively, before committing to integrate them.

At the change level, we have gotten the granularity small enough that each change may appear to be its own mini-waterfall of plan, design, and test. But even that is a simplification — chances are, the person making the change looped through many interrelated planning, design, and test alternatives in their head before committing the change.

Applications

In future posts, we’ll apply this model to take a look at other aspects of the engineering process.

So — is this a useful model for thinking about engineering, particularly software? Or is this model dangerously simplistic for helping to think about how your organization works?

The other week I attended a panel discussion. This was part of a pilot of a larger course for program managers. Before the panel began, the instructor was relating a conversation where a developer on a project was speaking of it as “sprialing into control.” The instructor left open the possibility that he thought the developer was crazy. The room of program managers laughed. Thoughtfully.

What a great phrase.

We want to clamp down to get our projects under control. Enforce rules to get repeatable. We want to keep our teams on the shortest path from A to B.

But the interesting projects haven’t been to B before.

And they’re dealing with shifting human dynamics on the team, discoveries that don’t reveal themselves until uncomfortably late, and a world around them that isn’t standing still.

We can’t leap to control and stay there. We can only sprial close. And, with constant effort and feedback, we hope to stay close.

Short iterations. Small increments. Minimized work-in-progress. Communication and retrospection. Discretion to adjust the process to keep breaking bottlenecks.

Control through feedback, not prescription.

The trick is “challenging but realistic.” In software, we know there is wide variation in our estimates, because we are almost always creating something unique (if it’s been done before, we just copy the bits). And we have a systemic underestimation bias, because there are lots of ways to cut scope or cut corners in software, and the intangible nature of it all makes anything seem possible.

Unfortunately, when schedules are no longer realistic, it will quickly destroy a project: causing cynicism, demotivation, short-cuts, bad decisions, unwillingness to respond to new information, loss of honesty and trust, and other problems which will fester. We could avoid these pitfalls if only we could estimate better. There are good books on this, including McConnell’s Software Estimation: Demystifying the Black Art and Wiegers’ Practical Project Initiation.

Out of all the techniques covered in those books, one widely-used technique is particularly effective for those critical early estimates of large, not-yet-well-understood projects. Estimates upon which we base our go/no-go decisions and early expectation-setting for upper management and customers.

It’s called Wideband Delphi, and here is a simple spreadsheet template and guide for the Wideband Delphi technique. Take a look, and let us know if this is useful to you and your groups.

When it comes to generalists vs. specialists, there are huge benefits to maximizing our use of generalists for creative/design engineering — in contrast to manufacturing activities, where specialization is always the way to go.

But there is a limit on how far you can take generalists, and there is a pro-specialist argument for design, too — as Corey lays out his case in his thoughtful one-piece flow post series.

I may not buy the broad knocks against “craft production” in that post; or that systems designed around generalists are unlikely to qualify as software engineering. But there is clearly a cross-over point where adding specialists of various types starts becoming a win, and eventually a big win. A good way to analyze where specialization can help is being thoughtful about a lean production flow.

Hand-offs, error, and waste: first, the case against specialization

Specialization in design suffers from a catch-22 problem: Design specifications are not truly complete until they are rendered at full detail (in software, that means coded). But incomplete specification causes errors during hand-offs due to misunderstandings and disagreements. Those misunderstandings and the time to resolve them are magnified to a surprising extent by hand-offs between specialists who don’t share a common foundation of knowledge or perspective.

And because design is a knowledge discovery and creation process, we can’t actually specify a design fully up-front (if we could, it would mean our design isn’t forging much new ground). The most effective solution is to spiral down into a design ala Boehm: breadth-first circling around all aspects of a project (these aspects are potential specialized roles) refining the design from high-level to low-level details, with depth-first spikes into areas with more unknowns or risk.

Every specialist involved in the design requires an additional step in our value-stream map, repeated for each loop we take around the spiral (with some opportunity for parallel processing). If we think about our value stream map for this process, we realize how this can explode our cycle time, including waiting time for people to get back with feedback.

And every specialist is a resource that now needs to be balanced, a potential bottleneck. In a generalist-dominated system, it is much easier to attack bottlenecks by shifting resources.

Perhaps most importantly, as we add specialists with different backgrounds, we have less project knowledge that can be implicit or informal: to reduce misunderstanding, we have to capture more of that knowledge explicitly on paper or via longer, bigger meetings. Achieving consensus on decisions takes much longer. None of this directly adds any value for the customer.

So when does specialization start making sense?

1. When we can get the benefits of both generalization and specialization. We do this by hiring generalists, but having them rotate into specialized roles (like test, project management, architecture, etc.) for the duration of a project or two. This is an excellent strategy to gain the benefits of focus through specialization, while retaining a flexible, low-overhead organization. TSP is a well-known adopter of this strategy. This is also a variation of the recommendation here of division of labor in lean software development workflows.
2. As our projects grow, we can bring in specialists that help the project without gating the inner design loop.
   • System test is one of the first and most common of these opportunities. Because at this point the system has been fully specified (that is, the implementation is “complete” if not error-free) there is a clear, specialized role to fulfill without impacting the design loop.
   • Back-end value adding steps like localization (assuming the core group of generalists knows how to create a localizable product).
   • Specialized roles which are orthogonal to the design loop, like project management. Note that some companies make the mistake of defining hybrid roles like “Program Manager” that encompass project management, requirements analysis, high level design, etc. (Microsoft being a poster child). But this causes all the problems of specialists in the design loop.
3. Finally, specialization is unavoidable when we can no longer find or afford generalists who can handle the typical roles in your project (interfacing with the customer, design, implementation, effective testing, a degree of self-management, etc.). Some organizations (Google would be a poster child) scale to hundreds or thousands of people without having their hiring and organizational structure over-specialize along those lines. But we’re not all Google. When our generalists have had trouble over time covering some aspect of the project, it’s time to accept the other costs to get the benefits of specialists focused on those problems.