Connected Knowledge

I’m starting a delayed series of blog posts to report on my trip to the 2012 Agile Coach Camp Canada that took place in Ottawa at the end of June. In each post, I plan to cover one interesting topic or session that took place there. I want to start with Agile in Professional Services.

This session was led by Richard Gore and resulted in a lively discussion. Insights came from several different directions and I may not even remember all of them anymore.

Lean Economic Models and Real Options

Professional services projects are especially susceptible to large transfer batches: user stories, features, smaller projects making up larger projects accumulate, then there is late integration, followed by delivery to the customer. Both customers and vendors of such projects need a serious conversation about batch sizes! “We want you to deliver this whole thing to us at the end” only reveals ignorance. “We will demo and push it every two weeks” isn’t much better. I know my audience may be getting tired of this recommendation, but Donald Reinertsen’s The Principles of Product Development Flow is a must-read. Batch sizes affect economic outcomes, so start learning about them.

One particular kind of batch transfer deserves special attention. It is the one near the end of the project Vendor’s part of the value stream, for example, from ready-to-deploy to deployed. It is a very recent insight, presented at the LSSC’12 by the German duo of Arne Roock and Markus Andrezak: avoiding a large batch transfer at that part of the value stream increases the value of the options upstream! (Links to the video of their presentation and the conference proceedings where you can find their paper). On the flip side, doing the opposite increases the project risk. Both the Vendor and the Customer are exposed to it and neither should ignore it.

Professional services projects are also susceptible to another combination of anti-patterns: converting options to obligations at the start, followed by backlog-driven development. Backlog-driven development is economically sub-optimal as demonstrated by Mike Burrows in his LSSC’12 talk (and here Reinertsen’s economic models of flow come in handy again!), but there is more. Once you’ve exercised all your options, you’re out of options and you need to replenish them. If your option-replenishment process isn’t working, it’s a serious business problem and improving the development process cannot solve it.

Design the Engagement, Not the Solution

This six-word gem uttered by Andrew Annett (and the six words included two articles) opened the door to applying our improved understanding of project economics to practical situations. The conversation between the Vendor and the Customer on how they approach building their relationship comes before the conversation about managing their project.

The two sides “should talk from the positions of equality”, “neither side should have the upper hand” and then it becomes possible for the Vendor and the Customer to have a conversation about optimal economic parameters and reducing project risk. If the Vendor is more Agile-inclined, selling Agile to the Customer as “Agile” may be counter-productive. Better present a choice between two options: low-risk and high-risk.

In the real world, the two sides are quite often not on the equal level. One of them is much more powerful and can push the other side around and shift the burden of underwriting the shared risk to them. This is an abusive relationship. Recognize it when you see it, know that that is the problem, and don’t expect Agile to solve it.

A short summary of this session could probably fit in one tweet: design the engagement, not the solution; neither side has the upper hand; lean economic models; real options.

I wrote in my previous post that I wasn’t done yet with my LSSC’12 conference report, but I haven’t blogged in a while and it has been more than two months since the conference ended, so I guess I was done. So, this post is going to be a quick wrap-up of what I haven’t written in my previous blog posts about this conference. And those posts can be found here, here, and here.

Lean Coffee

Lean coffee is becoming increasingly popular at conferences and it was a must-do at the main lean software development conference, of course. Lean coffee is a way to moderate a meeting using a Personal Kanban board. The basic form of a lean coffee kanban board is: ready – talking about (WIP limit 1) – done. There are some nuances to moderating a lean-coffee meeting, but I’ll talk about them in a separate blog spot.

Anyway, if you showed up in the LSSC’12 cafeteria at 7:30am, one hour before the daily announcements and the keynote, you had a chance to participate in great discussions with some of the leading Lean thinkers and practitioners. By the third day of the conference, Lean Coffee expanded to four tables.

Lightning and Ignite Talks

Each day of the conference program allocated half-hour to six five-minute lighting or ignite talks, eighteen such talks throughout the conference. Four of the eighteen speakers were Canadian and they all hit the ball out of the park. All chose one point or story to talk about, didn’t speak too fast, trying to cram as much as possible into five minutes, and thus made their talks very clear. These four speakers were:

• Gerry Kirk, who spoke about using Agile techniques in civic engagement.
• Charan Atreya, who told a story about a Chinese restaurant where few waiters served a large number of customers in a very short amount of time and how he went where customers usually don’t go to learn about their lean kitchen.
• Taimur Mohammad spoke from the Deloitte experience in Lean Startup for Change and gave the gist of it to those how missed Jeff Anderson’s Lean Startup for Change session
• Alexis Hui spoke about a marketplace of IT projects and how the capacity and not the money is the scarce currency that can make it work.

There were also memorable talks by Liz Keogh about complexity and The Rhythm of the Board brought from Italy by Gaetano Mazzanti – a Kanban board that plays music as cards move across it so that you can hear, not only see important patterns.

There were also great keynotes, extending the trend of inviting speakers from outside IT and software development to challenge the audience with ideas from their fields. I cannot possibly cover everything in my blog spots, so I’ll end this post with a number of useful references:

• Collection of LSSC’12 videos on Vimeo. Most of the talks have been posted.
• The conference program
• The conference proceedings, where you can find additional insights on certain topics that go beyond what the speakers could get into their allocated time.

I’m continuing reporting my impressions from the 2012 Lean Systems Society Conference that took place in Boston last week. The start of my report is in these two posts: Batch 1 and Batch 2.

Benjamin Mitchell: What Comes After Visualizing the Work? Conversations for Double Loop Changes in Mindset One important takeaway here was the Ladder of Inference. The five rungs of this ladder are: select, describe, explain, evaluate, propose action. A conversation of two people at the top rungs of their respective ladders of inference is basically a shouting match – they propose competing actions without understanding or discussion the underlying reasons residing on the lower rungs. It is important to keep this concept in mind, realize what you or your partner in conversation may be inferring and ask questions that help climb down the ladder to unwind disagreements.

Benjamin also used several examples to reinforce double-loop learning. “Visualization alone doesn’t address systemic problems underlying people’s behaviors,” he said. He gave an example where the WIP limit was 2, but the column had 3 cards. After the limit was increased to 3, the column soon had 4 cards. Instead of teaching practices and behaviours, we need to effect changes in mindset from which the future actions will follow.

Mike Burrows: Who Moved My Risk?

Coming to this session, I was prepared to hear about using WIP limits to transfer information upstream to enable better risk management, using classes of service to manage risk, and visualizing the risk information inherent in different work item types. Mike indeed said during the session, “Making different types of work visible is the killer feature of Kanban.”

But the biggest highlight of this session for me was Mike’s inquiry into the flip side of risk — the declining ROI. Mike coined an awesome term — backlog-driven development and explored the grim economics of it. It turns out this is a classic U-curve optimization. Now, dear reader, please refer to the Principles E6 and E7 in Donald Reinertsen’s The Principles of Product Development Flow – the ROI is relatively insensitive to the backlog size near the maximum – so the conclusion is to shrink the backlog to reduce risk and improve mutual understanding.

Mike has also blogged about his session and his slides are available on Slideshare.

Markus Andrezak and Arne Roock: Are You Sure You’re Doing Project Work?

Almost immediately, Markus and Arne (both were nominated for the Brickell Key award and Arne went on to win it) presented the same U-curve analysis of the optimal batch size in projects.

As you can see on the board at the start of their session, there is a large-batch transfer at the end of the project. The cards (user stories) flow pretty well through the engineering phases (development and testing) but then get bogged down in the downstream deployment steps. This is a common situation in many software development organization and was a recurring theme in the open space and many conversations in the conference lobby. The convenient approach taken by many project managers is to let work items pool in those downstream steps — we will eventually deploy all of them by the end of the project, so what difference does it make?

First, Markus and Arne debunked that “wisdom” with the U-curve batch size analysis. Second, and this was also a recurring theme in several conversations, limiting the output queue shortens the cycle time, which in turn enables better decisions on what to select into the input queue. “Output and mid-stream development queues are about doing wrong things better, but the input queue is about doing the right things right.” Markus has blogged about this session already, giving more detail and there is more about it in the conference proceedings.

I also left with the impression that the question in this session title was rhetorical and that project is really just a fancy term for a large-batch transfer to the downstream partner. Running projects this way always has an implicit assumption that the partner can ingest a batch of the certain size into their own value stream and not choke on it, but this assumption is more often false than it is true.

I am not done yet! Stay tuned for more reporting.

I’m continuing to write those perishable thoughts out of my head after attending the Lean Systems Society Conference in Boston last week. Batch 1 is here, more to follow.

Again, in no particular order…

Jeff Anderson: Enabling Enterprise Kanban Transformation through Lean Startup Techniques Jeff spoke about his work at Deloitte, where he leads Agile/Kanban transformations of clients that are large, conservative, change-resistant IT organizations. The novelty of his approach (for which he was nominated for the Brickell Key award) is in the application of Lean Startup techniques to guide such transformations. The room was packed, many people stood in the room while some stood outside in the corridor.

Some mental remapping of concepts is needed to understand how lean startup for change works. The transformation itself is a “startup”, the agile consultant is this startup’s “founder”/”entrepreneur”, and the change-resistant organization is complex and thus provides a lot uncertainty. Instead of laying out a plan, the consultant-entrepreneur uses the build-measure-learn loop to acquire validated learning about how the organization responds to the lean initiative. Then the innovation accounting enables him to decide whether to stick with the current plan (persevere in lean startup-speak) or change it (pivot).

Jeff and his Deloitte colleagues blogged about their work on lean startup for change for several months. But after the LSSC’12, it seems a lot of people are interested in this approach and we’ll be soon hearing about their case studies and the improvement of techniques. Follow #ls4chg hashtag on Twitter.

The slides from this session are available here.

Jeff’s Deloitte colleague Taimur Mohammad gave a lightning talk on Tuesday summarizing the lean startup for change in five minutes. And just before him, Alexis Hui spoke on Kanban as an economic bargaining system for portfolio management. To make this system function like an efficient marketplace and not like a black market, you need a scarce currency! And in an IT organization, that currency is not dollars, but the capacity of IT knowledge workers to do the work – a profound insight. Alexis’ slides can be found here.

More to come – stay tuned!

I came back from LSSC’12 in Boston with a lot of perishable information that I need to write down in a blog post. I am not sure about one long post actually – lets do it in small batches.

In no particular order…

Michael Kennedy: Set-Based Decision Making – Taming System Complexity to Ensure Project Success

This was a great talk by the account of everyone who was there. I saw and liked Michael Kennedy’s 45-minute Lean Kanban Benelux 2011 talk on set-based decision making, so I expected this 90-minute session to be even better. The material is a must see for anyone who wants to ever use the word set-based. Set-based decision-making is way more than set-based design or pursuing multiple options guaranteeing that at least one will be successful.

Kennedy traced the history of set-based decision-making to the invention of the airplane by the Wright brothers. Many inventors before them failed. How did they fail? They spent thousands of hours designing and building their aircraft and about five seconds testing them and the test usually resulted in a crash. The Wright brothers’s work followed a different pattern: experiment and test, repeat until feasible, only then design, then build. They conducted hundreds of experiments and when they knew flight was feasible they were able to quickly design the aircraft that would take the historic flight.

Many successful companies followed a similar approach, particularly Toyota. Toyota product development system is completely different than the Toyota Production System! As David Anderson pointed out, this is real options theory in action. By testing and experimenting, they learn what is feasible and what is not and create options. The eventual design is pulled from this set of options. This is how Toyota was able to create Lexus, which went from non-existence to dominance in two years, and later repeat the same feat with Prius. If they started designing Prius up-front – we know what would have happened by looking at their competitors.

Set-based decision-making has important implications for the software world. Simon Bennett instantly saw relevance to Enterprise Architecture.

I also have a theory that some free products that we’ve seen recently that nobody seems to have any idea how they will eventually earn revenue – Google Earth? – they’re not products themselves, but may be just public mashups of feasible options to be pulled in the future to quickly design an entirely different product when that becomes necessary – that’s how they generate economic value for the company.

Troy Magennis: Effective Modeling and Simulating Kanban Projects Using Monte Carlo Techniques

Troy gave a demonstration of his software: how you can specify an existing process, load some data, run many simulations and get the probability curve showing possible outcomes of the project. By looking at the curve and, say, the 95th percentile, we could make good project estimates. This is very compelling, but wait – there’s more.

Here is a very important insight from this session. While a project can be “run” thousands of times in Monte Carlo simulations, it is run only once in the real world. It ends up not as a probability curve, but just one spot somewhere on that curve. By simulating the project repeatedly, playing with various inputs, and feeding information into the simulator as soon as it becomes available during the project, we can identify risks early on and have a chance to address them and rewrite the project’s history. So, the simulator becomes much more important than an estimation tool.

It is fascinating that someday Monte Carlo simulations may be run as part of Continuous Integration – Monte Carlo Jenkins plug-in anyone?

This session was a great manifestation of the scientific, inquisitive, experimental mindset of the Lean-Kanban community. It also sends a not-so-subtle message to all Scrumbut and “we-do-agile-here” teams out there, getting an uncertain value from planning poker: while you are at it, your competitors may be doing Monte Carlo!

I’m approaching the end of my timebox, so thanks for reading so far and wait for Batch 2!