Stoos gathering took place. Maybe, we’ll be talking about Stoos in 2022 the same way we now talk about Snowbird. Maybe, the Stoos Communique will be as important as the Agile Manifesto is now. One thing everyone seems to have learned about Agile is that, while helping improve software development, it does expose a lot of organizational problems. Solving those problems is what Stoos is about. Once again, a group of gurus (not the same people) gathered at a mountain resort.

• To learn about Stoos Network in more detail, Jurgen Appelo’s seven-part series is a good starting point.
• There has been plenty of activity in the Stoos Network LinkedIn group and in the Twitter #stoos hashtag.
• Translations of the Stoos Communique in many languages are underway. Draft Russian version is here.
• I’ve read one critical opinion of Stoos (by Dave Snowden).

RIM (Research In Motion) was in the news a lot as the company sacked its co-CEOs and installed a new leader. (It was important because I live in Canada, actually in Waterloo and not far from RIM’s headquarters.) While many speculated what may be next for RIM, Jeff Anderson summed up the best advice for RIM in his post, Three People and Their Feedback Loops That Can Transform RIM.

SOPA (Stop Online Piracy Act) and PIPA (PROTECT (Prevent Real Online Threats to Economic Creativity and Theft) IP (of Intellectual Property) Act) protests took place and the bills have been put on hold. Scott Hanselman in his blog examines various clever ways to black out site context, their impact on SEO, etc.

Lean Startup Machine (LSM) Toronto took place on January 26-29. From the winning team, Jason Little shares his story.

• Build-measure-learn Is a Kanban System Optimized For Response Time. Build-measure-learn is one of the principles of Lean Startup. The post explains how Kanban can help Lean Startup and why it is important to understand Kanban to execute the build-measure-learn approach. I have an article on this subject in the works that will be more detailed and about three times the size of this post. Stay tuned.
• Book Club Meeting With Steve Blank. Yes, our local agile book club had an opportunity to meet (by teleconferencing) with the Lean Startup pioneer Steve Blank. He didn’t have a lot of time for us, be we got great, detailed answers to all our questions.
• A Goldratt Reader’s View of No Child Left Behind, an attempt to think about learning and applying the Theory of Constraints at the same time.
• Learning at the Coding Dojo. A report from our local gathering of software craftsmanship enthusiasts that took place in May 2011.
• About My Personal Kanban Workshop. I have presented it several times in 2011, introduced quite a few people to Kanban and Personal Kanban, will present a few more times in 2012.
• What the Heck Is Adjusted P-Value and Why It Is Important. This post is heavy on statistics and is about situations when it may be very difficult to tell chance from assignable cause variation. Things may be highly probable and appear nearly impossible if you aren’t careful enough with your numbers.
• How “Agile” Tools Fail. Yet another argument for the whiteboard.

I don’t find anything to object to in the article, but I feel that a stronger argument can be made for Kanban than the supposed freedom from iterations.

Time-boxes Aren’t Scrum’s Impediments

The freedom-from-iterations argument sounds like treating a symptom. The iteration length should not be an obstacle to more frequent releases if those are important to users or customers. Demos at the end of a time-box (say, on Business Day 10 of a two-week sprint) are not the right time (too late) for a product owner to become aware of a completed feature and they are not for sort of acceptance tests to decide what’s shippable and what’s not. Suppose a feature is ready by Day 6, the product owner is aware and approves it. It’s the right feature, built right and it’s shippable. If it’s really important to ship it to the users the same day, the ops people can do it. They are part of the team, sit nearby and not in a different building, right? When Scrum is without “buts” (“we do Scrumbut, our PO is never around”), time-boxing shouldn’t hold it back. Scrum has a built-in retrospective process to get rid of “buts” holding teams back.

“We are constrained by Scrum’s time-boxed iterations, so we need to try the iteration-less Kanban process” is a weak argument. Kanban is a meta-method for improving other processes and its main strength is that it can bring many teams closer to their problems and understanding the science of their operations.

Flow Problems

This is a class of problems faced by many software organizations. Take a feature that your paying customer wants, don’t take your eyes off it, and follow it from concept to cash (or from hypothesis to happiness, if you will). Now consider all your features. That’s your flow. That’s how software work behaves. (Some people don’t see it that way. They prefer to look at the org chart. But that doesn’t change the reality.)

Today’s reality for many in the software industry is that our work doesn’t flow very well. There are pools, back currents and even dams (often built by us because of our lack of understanding of flow). What we need to do is to understand how work flows in our context, study the flow and make improvements. This is exactly where the Kanban method comes in with its “improve collaboratively using models and the scientific method.”

What models and methods, you may ask. A short, incomplete answer is: Goldratt (qualitative), Reinertsen (quantitative) and Mary and Tom Poppendiecks’ lean principles as super-useful approximations. Consider the Theory of Constraints. When Goldratt’s Jonah asks Alex about quality control in his plant, he thinks about exploiting a bottleneck by inspecting parts before the NCX-10 gets them. That’s “building quality in.” Specification by example is an attempt to apply similar logic to software development. Check out Donald Reinertsen’s Principles of Product Development Flow. You can find many things in this book, among them charts quantifying what we approximate by using the principle of “deferring commitment.”

Distance Between Teams and Their Flow Problems

Consider one team. They didn’t do XP 10 years ago. They’re mainstream, maybe late adopters. You may have met a team like this one recently. They seem to be doing this:

If you were an XP pioneer or an early Agile adopter, there is something important in this picture that is not actually shown in it: the customer, standing pretty close to it on both sides. Your XP or Scrum framework may not say much about the economics of your product development flow, but the way you work and retrospect are aligned with the desired economic results reasonably well. This is not the case for the mainstream or late-adopting team in our example. But let’s zoom out and see what they’re actually doing:

This is a fairly typical case: a two-week iteration cycle, a quarterly release cadence, and the total cycle time through the whole value stream of more than one year. What is needed here is a dose of lean thinking. Kanban can deliver it and help this team get underway on their lean journey, understanding and studying their flow and finding solutions to their problems. And they may even decide to keep their iterations, or as we call them in Kanban, input, release, and retrospective cadences.

I totally agree that we shouldn’t throw the Scrum baby out with the bathwater. Dropping iterations is not a good reason to do so.

• Esther Derby: Scrum Masters and Agile Coaches: More Than a Title – requirements and considerations for hiring for these roles, very specific.
• Jeff Anderson: Applying Lean Startup techniques to Kanban (or any other) Organizational Transformations – a unique blend of lean startup with Kanban.
• Alexis Hui: Five Step Illustrated Guide to Setup a Kanban System in an Enterprise Organization – liked the logical breakdown of this complex activity.
• Michael Dubakov: Current Kanban Board of TargetProcess Project – a helpful example of what it looks like at a company that makes 25-30 releases per year and eats its own dog food.
• Also by Michael: Flow. Discover Problems and Waste in Kanban – 2 Years Later. Visualization of how each individual work items gets to “done” and finding inefficiencies in the flow.
• Elizabeth Hendrickson: From the mailbox: selecting test automation tools
• Pawel Brodzinski: Get rid of estimation. Several interesting moments in the article, such as (1) diminishing returns from finer estimates, (2) the emergent behaviour of the system where estimation meets specifying standard-sized features, (3) link to a PM StackExchange thread which shows how difficult it is for many people to understand these ideas, (4) the focus on getting value out of estimates, which many estimators take for granted.
• Martin Fowler: Infodeck and Slideument. Both are created with PowerPoint or similar presentation software, but Infodeck is good while Slideument is something to avoid!
• SkillsMatter: Douglas Squirrel’s presentation on how to do Five-Whys right.
• InfoQ: Feature Injection: Three Steps to Success, a detailed article on Feature Injection by Chris Matts and Gojko Adzic

• Explain This Picture
• The Lean Startup
• The Marshall Model

The Session

The session was proposed and moderated by Kate Megaw. Kate showed everyone the book, Personal Kanban: Mapping Work | Navigating Life by Jim Benson and Tonianne DeMaria Barry (with Jim’s autograph), thoroughly presented the principles — visualize what you do, limit work-in-progress — and demonstrated how to set up and user Kanban board.

(This is an example how open space conferences bring people and ideas together and produce complex behaviour. Kate is from Los Angeles, she was in town to attend Lyssa Adkins’ and Michael Spayd’s Coaching Agile Teams class. The class was in Montreal, because the coach camp was there. If she weren’t in Montreal, this session wouldn’t have taken place.)

Kate also showed several examples of Personal Kanban boards, some electronic, running on a laptop or an iPad, some low-tech, made of spiral notepads and sticky notes.

I added a bit to the session, reflecting on my experience with lean coffee (Personal Kanban applied to conducting a meeting), which I introduced in our local agile book club.

We talked a little bit about electronic tools, but I don’t remember which ones were mentioned. I guess it is unimportant.

Pictures are worth a thousand words and if you click on any picture on the right, that will take you to the Flickr set of photos taken at this session.

Long-Term Effects

Since I’m writing this up several months after the fact, I have a huge benefit of hindsight. The session definitely influenced several people. A software development manager who attended it started using Personal Kanban at work the following Monday (and still uses it). A famous agile coach began to use lean coffee to moderate meetings.

My own interest in Personal Kanban increased as well. I started running Lean Coffee meetings in Waterloo. I also designed a Personal Kanban workshop that fits nicely into a 60-to-90-minute user group meeting or a conference session. I have presented it several times already and more people became Personal Kanban users as a result.

The picture to be explained was the one on the cover of David J. Anderson’s Kanban book (to the right). The session was an invitation to all Kanban enthusiasts to compare their notes from reading this book and their experiences applying Kanban. People unfamiliar with Kanban had a chance to explore it.

The first set of questions we got out of the way was: who is stuck, who is too busy, who is idle, why, and what is their role on the team. The book had been in print for more than a year, so everyone knew the answers. If you want to know, read the book and/or talk to someone in your local agile community, they’ll explain.

How to Kill Kaizen

More interesting were the questions about trying to improve the situation. One option we didn’t consider was to simply increase work-in-progress limits. That way we can give someone who is busy with three tasks a fourth task. And someone who has started more tasks that can fit on the board can start even more. This option means doing things the same way that got the team in this difficult situation and avoiding the conversation about improving the process. It ensures that the team will not benefit from kaizen, the culture of continuous improvement.

Limit WIP Upstream

The first option suggested by the group was to reduce WIP upstream. Indeed, if we reduced it from 20 to 10, this would underutilize the analyst, but would shorten his feedback cycle from 23 cards to 13, probably improving quality of whatever he is doing. The team’s throughput may about the same, but the quality will likely go up. Interesting that such result may be achieved by working less.

Hire More Developers

This option is often considered and taken by managers of real-world teams. It obviously elevates the bottleneck, doubling its capacity. But it does nothing to address the flow problems affecting the team. The prolific analyst can still overwhelm the developers and, as the total WIP goes up, the feedback cycle will lengthen, putting quality at risk.

Five Focusing Steps

The Five Focusing Steps method, introduced by Eli Goldratt in The Goal states that before elevating the bottleneck, we should exploit it. The exploitation action is often away from the bottleneck, so that makes it very clear that hiring another developer right away is not the solution.

One source of inspiration for such exploitation solutions is the Goal episode when Jonah (the wise consultant) visits Alex’s plant. Shortly before leaving he asks: “One more thing. Show me where you do quality inspection on bottleneck parts.” Interesting that Jonah asks where, not how. All he cares about is if the quality control is ahead of or behind the bottleneck.

What follows from here is not about the team on the book cover – we don’t know enough about them to say this will solve their problem – but it’s a real solution for real-world teams as long as it fits their context. (Everybody who attended nodded their heads here.)

Example

Let’s move the idle tester over to collaborate with the analyst and, assuming the tester has some automation skills, get specification by example going. Automated acceptance tests make the developer more effective and reduce the amount of defects that escape into the testing phases. The tester presumably will still have some time left for exploratory testing.

Together, the attendees redrew the book cover picture on a flipchart to look like this:

We’re not stuck, I’ve got slack, I’m kinda busy.

The book is not new, written in the 1980s, when many American manufacturers struggled to compete with the Japanese. The book introduces the so-called Theory of Constraints, which the basis of lean manufacturing. The value of this book to today’s knowledge workers is that it the TOC is still relevant and understanding it puts one’s understanding of lean software development principles and Kanban on a more solid foundation.

The Goal is very different from most textbooks; it is a novel, set in a fictional small Midwestern factory town of Bearington. The main character, Alex, is a plant manager, whose plant is struggling. It has the latest and greatest machines, its machines and workers work hard, but if you look at the assembled goods leaving the plant’s shipping dock, there is little throughput. Orders are constantly late, shipping dates are unpredictable, customers are frustrated. The company is losing business to foreign competitors, who can ship their product faster and make it cheaper and with higher quality. Alex’s superiors give him three months to turn the plant around or else the have to close it.

Boyscouts on a Trail

Alex turns his plant around in the end, but he has to learn the Theory of Constraints to do it. He learns it using Socratic method, taught by a wise consultant named Jonah. One of Alex’s discoveries happen during a weekend when he leads a troop of boyscouts (his son’s classmates) on an overnight hike.

The scouts must hike 10 miles of narrow trail to reach their campsite. The strongest kid, Ron, is in front and sets a reasonable pace, two miles per hour. But Alex discovers at the midpoint that the column is moving at only one mile per hour pace and there is no way they can reach the campsite before sunset at this pace! It turns out that scouts’ speeds vary randomly. The positive deviations don’t accumulate, because you bump into someone. The negative deviations do accumulate, slowing down the column. The slowest kid, Herbie, is way behind, sometimes walking, sometimes stopping, sometimes running, and very tired. The only kid able to sustain two miles per hour is Ron who is comfortably in front.

The fluctuations and dependent tasks remind Alex of something that happens inside his plant. There are statistical variations of tasks performed by workers and machines and there are dependencies: just as Ron must walk over a point on the trail before Dave can walk over it, some machine must process a part before it goes to another machine. (In software development, variability and dependencies between tasks and the economic effects of variability and dependence are even more severe!)

What All This Means to Education

The scouts are our children. The trail is what they need to learn.

For public education to fulfill its mission in the XXI century, it must figure out how to move the whole column at two miles per hour. We live in the era of knowledge economy and globalization — sorry for the cliché — and countries that figure it out will have advantage.

As we know from reading Goldratt, letting the kids walk at their own paces gets us one mile per hour, so that is not an answer. Putting the slowest kid in front and holding back everyone else is not an answer. Measuring kids’ speeds individually on a straight, flat part of the trail (if you get my drift) is not an answer.

What do you think? Makes sense?

It can also visualize the following vicious circle.

There is too much work in progress. Because of that, many work items are late and even their lateness is unpredictable. Because of the unpredictability and lateness, the level of trust with the upstream partners is low. The low level of trust means more work is pushed into the system — because “we have to show progress.” More work in progress means more delays, more rework, less predictability, and even lower trust.

Rick Simmons, in reply to my questions about his Agile2010 presentation, wrote: “Stable sigma (in the context, it meant the variation of lead time within a class of service -A.Z.) trumps low sigma.” And: “It is the key to predictability.”

Stable variation allows creation of service-level agreements that can be executed consistently. This builds trust. Trust means actually sticking with limiting work-in-progress to capacity. It means pull wins over push. It means avoidance of muri. It means better results.

0. The model is given, not done from scratch. This is the starting point of our checklist. The analysis, the conversations with domain experts leading to this model have already been done at the earlier design stages (and in the earlier chapters of the book).
1. Prune class relationships. Get rid of unnecessary relationships, especially many-to-many.
2. Identify applications — users of the domain model. In a shipping domain model, examples of such applications are a booking application or a tracking query for cargo. Remember that the application and the domain model live in different layers of the layered architecture.
3. Distinguish between entities and value objects. Enough said.
4. Design associationsbetween entities and value objects. Figure out directionality. For example, value objects shouldn’t reference their owners.
5. Figure out aggregate boundaries. Think not what to include in an aggregate, instead, look for reasons to exclude it. If someone wants to look up Y without X that owns it, then Y doesn’t belong in the aggregate where X is root.
6. Select repositories. Limit consideration to the roots of aggregates. If you are implementing an association between two classes as a collection, you don’t need a repository; if you are implementing it as a query, then you need a repository.
7. Walk through scenarios. Remember there is no penalty for throwing away a value object, even a complicated one. Think about associations and what happens to them when your model objects change, especially in aggregates.
8. Design object creation. Decide where to use constructors, what to pass to those constructors, where to use design patterns such as Abstract Factory, Factory Method and Prototype. Make sure you create valid objects that fulfill their invariants and create associations when they’re required.
9. Refactor. Note that we’re talking about refactoring the design, not the code that implements it. There is no general rule on how to do it. The only example in the book shows a refactoring move driven by a performance requirement. An important takeaway is that you need excellent model documentation in addition to its diagram! Otherwise, it may be impossible to tell why you did a particular refactoring move.
10. Think about modularity. The model may be large enough to divide it into several modules. In the shipping model example, such modules could be shipping, billing, and customer contact.

Very quickly, here are some of the key points.

The five principles of Lean Startup are:

1. Entrepreneurship is management
2. Entrepreneurs are everywhere
3. Validated learning
4. Innovation accounting
5. Build-measure-learn

“Entrepreneurs are everywhere” means they can be two founders in a garage or they can be in multinational, century-old, global company. The “startup” part of “lean startup” does not refer to an organization’s age or headcount, only to their mission: discover a new scalable business model in the conditions of uncertainty.

Validated learning is the only unit of progress.

The build-measure-learn loop is the central concept. The result of “build” is a product, which you use to measure; the result of that is data, which you use to learn, which results in ideas that you use to build the next version of the product. The goal is to get through this loop as fast as possible.

In the months since the coach camp, Eric Ries’s book The Lean Startup was published and this much became crystal clear: build-measure-learn is essentially the lean startup’s value stream. At the end, you have produced a unit of validated learning. At the start, you have an unvalidated hypothesis. Part of this long value stream is “build”, which resembles the traditional SDLC value stream in the sense that you start with a request to build a product feature and end with a built feature and its release to users.

At the end of the session, I got up to talk about Steve Blank’s customer development model. (Steve Blank is a venture capitalist, one of the pioneers of the lean startup movement, and the author of The Four Steps to the Epiphany.) I also mentioned a bunch of important points from my book club’s conversation with Steve Blank. There is no reason to repeat them here, but I do recommend that you follow this link.

I am downplaying the customer development model here, because – and this is one of my surprises from reading Eris Ries’ book – Eric downplayed it in his book, giving much more space to lean things, like Kanban and Five Whys. (And you should know that he gave a glowing recommendation to Donald Reinertsen’s book, “Principles of Product Development Flow” — that should give you an idea where I’m going.) Steve Blank’s main message (“there are no facts inside the building, so get the hell out”) is very important to forming a lean startup leader’s mindset. But to really operate this type of organization, you need to go way beyond that and understand Eric’s book. Lean startup in a nutshell is good old lean applied to a new value stream pattern.