Mary Poppendieck and James Bach taught me to look out for lessons in everyday life. Everything is connected with everything else. So, as I visited today during lunch break the local McDonald’s restaurant, I started to observe while waiting for my lunch. Here is what I observed filled in with some lessons from systems-thinking and the Theory of Constraints.

So, the restaurant was unusually full today. There were three counters open, serving the enqueued and waiting people. Whenever there is a queue, there is something locally optimized and the bottleneck around it is not exploited. Therefore I started to look out for the underlying reasons. Since I had previously worked at a supermarket counter, I had a feeling for what to watch out for.

Starting with the first counter, there was a young woman serving. She was obviously helpless as I watched her using the cashier and giving out change. She seemed to be very uncertain and routine hadn’t revealed to her. Obviously for me that queue was a bad choice to wait for food, since I got hungry.

On the next counter, there was a young man serving. He had a bit more routine or experience as the young woman next to him, but he seemed to be rather inexperienced compared to others I had seen in previous visits. In addition that guy seemed to be in the role for catching up on serving the food to the tables, exchanging fries when they were finished, etc. So, this guy was really overworked, and I could sense it by observing him for maybe two minutes. No good choice to wait for, when you’re hungry, either, but I took the queue, since the colleague who went with me was on the last open counter waiting, and I found it a better mix to have us wait in two different lines.

On the last counter, there was a real senior serving. I have seen him several times there in the past, and he was really fast, compared to the others. So, my colleague got seated long before I placed my order.

Now, this isn’t yet the final story. What then happened was that the guy from the counter for the McDrive helped these three out with the cashiers and the serving. Given the fact that the drive-through is the most critical, fast-served place at such a restaurant, that guy was really up to the last cashier. Now, the McDrive guy was not helping out on every counter, but yet on a single one. So, guess where he helped out? Yes, right, on the last of the three that was already way-outperforming the other two. If I had to put a number on it, that counter had double the throughput of the other two counters without anyone helping there.

Why is this a problem? Well, after I got finally served by the last counter – the queue was empty right before I got to order at the second counter – I got to my colleague and explained him the following. There were basically three queues. There was one bottleneck station, the first counter, and the second counter had generated a bottleneck station himself by conducting all the work that the first woman was not getting to, since she was too slow at serving. Last, there is the regular station, which is not a bottleneck.

From the systems point of view the regular station got optimized when the McDrive guy started to help out. The Theory of Constraints taught me that instead everything should have worked towards the bottleneck stations. This could have been to get the McDrive guy helping the second counter guy out on the surrounding preparations with the fries or serving the food to the tables. This could also have been to free up some of the woman’s time by fetching the just ordered food from the customers in the line, so she mainly needs to take care about the coins and the change. Instead a non-bottleneck workstation got optimized, resulting in local optimization.

Another reason this optimization choice was bad, is the fact that the two others did not have the slack to learn how to work faster. The worst performers in that restaurant were constantly under pressure, since there were more and more customers queuing up all the time. Instead of providing slack time for them to be able to think about how to do their work more efficient, their thinking collapsed under the perceived pressure from the customers waiting in line to get served. Surely, they will not have learned anything during these maybe 15 minutes I could watch them, since they were permanently dealing with the next fire to take out.

Finally, how does this relate to software at all? Well, give your people the right amount of slack, the right amount of time to think, and watch out for local-optimizing. Alistair Cockburn uses the analogy of “unverified decisions” as inventory items to transport Lean processes and lessons from the Theory of Constraints to software development. So, find the workstations where these “unverified decisions” pile up. Where in your process are many decisions handed-over to someone else? Where are the most handed-over? These are your bottlenecks. After having identified the bottlenecks in your process, you may start to either exploit them, or to place in quality steps right before the decisions get handed-over (this is the major case for test-driven development), or see how others can bring in some relief for the bottleneck station by taking over some of their work. Taking the problem to the systems view helps understand the dynamics in place – for software development as well as for food serving in a fast food restaurant.

Abby Fichtner – The Hacker Chick – wrote a blog entry asking (and answering) Are we agile yet?. In essence it relates the Poppendieck’s seven principles from Lean to other Agile methodologies. Since I’m currently finishing up the Quality Software Management series from Gerald M. Weinberg, I got to know about the importance to know about many models for developing software. So, I decided to expand the thoughts of her seven key points beyond Lean, Kanban, and Scrum and strive over some of the most common Agile methodologies. In this blog entry I’m going to re-visit the seven principles and expand the view to XP, and Crystal.

Eliminate waste

Eliminating waste is at the heart of Lean. Similarly in Scrum the team is asked to just implement the items from the backlog with the highest priority. In Agile Estimating and Planning Mike Cohn describes very well, that the the items with the highest priority are realized from the backlog first. Thereby the team achieves a software product with the highest business value. In QSM Vol. 4 Jerry Weinberg denotes it as the 90% of the implementation that delivers 99.9% of the value to the customer. Similarly, by working in this manner you will drop the meaningless features if you need the core functionalities sooner. Meaningless features in the product backlog are then of course an instance of waste.

XP favors the principle of simplicity. There is an implication to eliminating waste here. Everything that is not simple, is wasteful and deteriorates the process for maintenance. By focusing on simplicity, waste is eliminated by definition. Similarly, Cockburn separated Crystal into families of methodologies to keep them simple and eliminate methodology weight from smaller teams while still preserving necessary and relevant ceremony for larger teams. Crystal therefore eliminates waste by structure of the methodologies.

Build Quality in

Tackling the quality matter for the several Agile methodologies is a bit more demanding. First, test-driven development from XP is one of the most difficult Agile practices, but it is also the most copied one. Cockburn speaks about it for Crystal, similarly it is in wide-spread use in vital Scrum and Kanban practicing teams. The Pragmatic Programmers speak about quality from the start. Pair Programming from XP is a way to review code as you go. Likewise, customer involvement from XP together with specification workshops and specification by example bring in quality right from the start. These practices are in wide use among methodology boundaries and are shared in the whole Agile community.

Create insights

Personally, I rephrased this to “create insights” from “create knowledge”. The single-most Agile practice that everyone recommends is taking the time for reflection. There are several names for the same concept. Sprint Reviews in Scrum, Kaizen in Kanban, Retrospectives in XP, Reflection Workshops in Crystal all generate insights from a time-boxed interval of the project, and set the team up for knowledge from their past iterations or sprints. Over time, the team piles up more and more knowledge created from projects, tried out ideas to improve the process for themselves. “If you need to adopt just a single practice, use retrospectives, the rest will follow up.”

In addition to regular reflection, transparency is the key to visible progress. Information Radiators, Task Boards, Story Boards, build monitor are all ways to make progress visible among Agile teams. Combined with the insights and actions from the last retrospectives, they set the team up for success. Not only in Scrum and Kanban, but also for XP and Crystal.

Last, involvement of the customer from the start is a key success for visible progress. Showing results from the last work increment to the customers and stakeholders in regular intervals is a vital part of XP, Crystal, and Scrum. Getting the feedback from the people supporting the project also sets you up to build quality in.

Defer commitment

Similarly as the previous two points, deferring actions to the last responsible moment is a common theme across Agile methodologies. The principle is in play for programmers building the programs incrementally and iteratively, for iteration planning in XP and Scrum, and even for process improvement actions to foster.

But I recommend to take care here. “Defer commitment” does not mean in any way to not commit to anything at all. The team commits regularly to the next increment to the product they grow. The team calls this the iteration, the pulse at which Agile software development operates. Like a living system, the iteration is the heart of Agile development methodologies. Accompanied with reflection about the last pulse, the Agile development organism adapts to new situations and sets themselves up for the vital learning in the team. Crystal, XP, Scrum and Pragmatic Programming names this deferred commitment. It’s even a part of Software Craftsmanship, which I personally would include to the Agile methodologies – though they made a value-shift based on the initial manifesto.

Deliver fast

Here I also need to add a note: Don’t confuse speed with progress. Note the ambiguity for delivering fast. One way to deliver fast is to deliver at a high speed, while coding yourself into the corner of Technical Debt. This is not meant. Instead, you have to keep an eye on the delivery for today, but also set yourself up for tomorrows delivery. A sustaining pace is vital for todays fast – in terms of progress – delivery, and for tomorrow’s. This insight is at the heard of the Cooperative Game principle from Cockburn and underlying the Crystal methodologies.

In fact, one key motivation for the Software Craftsmanship movement at the end of 2008 was the realization that the “setting yourself up for the next round” became a common practice for fast delivering teams. The key is not to deliver fast today, but to deliver fast today, tomorrow, next week, next year, and even in ten years. Over the course of the last decade with the widespread of Agile methodology this seems to have been forgotten.

Back to methodologies, the iteration pulse in Scrum, XP, and Crystal creates the basis for the sustainable pace. The team sets themselves sets up for a continuous flow of value for customers and stakeholders. Thereby a steady flow of progress with indeed fast delivery is achieved.

Respect people

XP defines the XP team generating the respect for the people on the project. Similarly Crystal evolved out of the respect for people. Setting up self-responsible teams that take care and pride of their process for themselves, enables them to deliver steady value and – as a side-effect – increases productivity. Leaving people with the choice for their own process, getting them motivated to succeed the project, and rewarding them for their achievements is a core Agile aspect. And there is nothing more rewarding to show a working piece of software to your customer and get the appreciation from them – at the end of every second week or every month.

Optimize the whole

Reflection workshops take insights from the team and action items from good reflection workshops create an optimizing whole. Putting the people together in cross-functional teams, removal the boundaries from decades of separate working, enables everyone on the team to see the whole picture of the project. For example, planning poker puts together the whole team to work out the scope of the next increment. Specification workshops put business analysts, developers, and testers together with customers to get their needs and form a common understanding of the product to build. One key aspect of Crystal is the easy access to expert users among teams. Without this all encompassing view on the project as a whole, there wouldn’t be a way to optimize it as a whole. In companion with self-organizing teams, this optimization becomes natural in Agile projects.

Finally

One final point I would like to raise. Why does it matter for you to be Agile or agile? Instead of hunting for a place or time you may call “Agile”, rather ask yourself, “does it work for you?” If you can seriously without any doubts state, “yes, it works for me and all my colleagues, stakeholders and customers”, then you shouldn’t bother. If not, asking “are we agile” won’t help you either, since you don’t know if you need to be Agile in your situation, of if you should be somewhere else. Following a practice or notation just because it’s the latest hype, is cargo-culting. Instead you find out where you want to be, and plan to get there, but to set yourself up to anticipate any directional changes while trying to get there.

Some while back I read a blog entry from Jason Gorman on Wheel-driven reinvention. His core statement is, that there is nothing new in the world of software development. When you start to trace back any common hype in the software industry, you will most likely end up in the 1960s or 1970s finding the core idea raised by that time. When I first read his blog entry, I was going to write a follow-up describing how little the great old ones help us understand their solutions to the problems of the software industry in the last decades or so. Since I know that I had to incorporate Gorman’s thoughts into my models I decided to postpone it a bit, and get some time to think over it.

There are just a few professionals who actually did what I was claiming, but the more striking point for me is how little time we spent listening to them. One excellent example of a great old one is Gerald M. Weinberg, who worked on project Mercury for the NASA, and was part of the first testing teams when the latest hype was to do testing independently back in the 1970s. Recently I came across a paper from Edsger Dijkstra, written by hand. Into that line fits also Brook’s Mythical Man-month or the No Silver Bullet article. And I know that there are other great examples of great old ones, to which we should pay attention, in order to learn something new.

That said, I read a blog entry from James Shore yesterday on Large-scale Agile. He put up a great effort to describe how to combine the ideas from Scrum and the ideas from Kanban together to scale Agile up on a larger basis with sub-dividing teams. His ideas are interesting, and I gave up half-way through trying to understand all of his premises. Remembering back my math teacher in school when I showed him a proof that one equals two, he stated: “When working from a false premise, you can show anything.” This is even true in writing.

How come there is nothing new about large-scale Agile? The textbooks on Scrum just mention the Scrum of Scrums, but not how to apply them. XP and Kanban just work on smaller teams, so he’s actually writing something new. Really? No. Obviously not. the Crystal methodologies, and recommendations for large-scale Agile. Thought, he stated that there is a barrier to Agile and their light-weight methodologies at project size of about 500 persons. Scaling Agile up, though comes with a prize. Larger teams need other communication channels for example. You may put a team of 12 into a single room. The team can work up with osmotic communication. On a 500 person project, you may have difficulty to find a room large enough, and obviously not everyone will be able to overhear the conversations of all colleagues. There are other penalties you have to pay for scaling Agile up. Whole-heartedly I recommend reading his book on Agile Software development.

Additionally, what I learned from Cockburn is the notion of a sweet-spot of Agile methodologies. The lightweight nature of Agile methodologies has a sweet-spot on a lower team-size with fewer effort put into ceremony overhead for hand-offs. When increasing the team size, you automatically get a larger communication-need. There are non-linear increases in the amount of possible communication channels among team members, as well as slower communication channels like informations flowing across different rooms. That said, if you don’t fulfill the need for more communication, you may find yourself set up for Agile failure.

There are many other factors which need to be increased for the larger team-size in a non-linear way. In case you’re searching for an answer on these questions, I recommend to read all of the following book

• The Mythical Man-month from Frederick P. Brooks Jr.
• Quality Software Management Volume 1 – Systems Thinking from Gerald M. Weinberg
• Agile Software Development – The Cooperative Game (2nd edition) from Alistair Cockburn

Listen to the old ones, or re-invent the wheel.