2010-05-11

Scaling Scrum in the Enterprise with Kanban

I have had the pleasure to hold a lightning talk for the Agila Sverige conference i Stockholm about "Scaling Scrum in the Enterprise with Kanban".
The talk went well but the format (10 minutes) made it more like an elevator pitch.
You can find an enhanced - somewhat longer - version of the slides used during presentation on slideshare.
I will venture deeper in the subject on a comming blog post.

Postad av Christophe Achouiantz

Kommentarer (0) 

2010-01-17

The common goal of agile and lean software development methods

How would you present Scrum (agile) and Kanban (lean) as building from a common principle? What is the common core of these methods? These questions were the topic of recent discussions with colleagues agile coaches Joakim Sundén and Marcus Hammarberg. Based on our reflections, I would like to propose - yet another - definition of agile/lean software development. Yes, a lot has already be written on that subject, yet I find it hard to get a simple and concise proposition that can quickly outline the relevance and significance of agile/lean methods to IT managers.

So, here is one minimalistic definition that cut straight to the core:

The goal of an agile or lean method is to minimize lead-times.

That’s it. Feel the whole power of the agile/lean space folded in a short sentence! Now that we have reached the core, let’s elaborate on how it ties to Scrum, Kanban and other methods.

First, why focusing on minimizing lead-time? Why not maximize throughput or quality? Focusing on lead-time will force you to continuously minimize the time it takes for a product, or service, to travel within the organization from idea to production (or cash as the Poppendieck coined it). It forces you to trim the whole organization to work effectively together and focus all energies on what is really important for success right now. Incidentally, it requires limiting the amount of work in progress in the organization and in each team so that the ongoing work can flow as quickly as possible. In other words, minimizing lead-times creates flexibility – some would say agility – that companies, private as well as public, depend upon to stay competitive (public organizations are expected to perform as well as private ones lets they be outsourced).

So, how would an agile/lean method minimize lead-time? An agile/lean method minimizes lead times by identifying and addressing problems as soon as possible. By not letting problems go unchecked, you gain the time it would take for you to fix those problems at a later stage, when they have become obvious and require a lot of effort.

Now, it is immediately apparent that a lot of communication is needed to identify and resolve those problems. As our focus is minimizing lead times, we want this communication to be as effective as possible, meaning that face-to-face, daily meetings with all involved parties are necessary. We want these meetings to be short, facilitated by big visual maps and charts giving the current status.

Ok, but what kind of problems are we discussing here? There are mainly two categories of problems when developing software: first the problems related to the product or service being developed (does it answer the needs of the customer/user? Are we building the right thing?), second the problems related to the way the product or service is being built (are we building it right?).

Identifying the first type - problems related to “building the right thing” - requires frequent feedback from the customer and users; demos or reviews established at a regular cadence is a good model. Addressing these problems require to be able to often change the scope of what is being worked on, allowing rework of certain parts of the product based on the given feedback; hence working iteratively and incrementally.

This constant feedback allows gaining time-to-market (thus lead-time) by producing the right product as soon as possible; even if the customer wasn’t aware of the exact qualities the product should have from the start. Moreover, by always focusing on producing the features with the highest value first, one can save time by “cutting the tail”; reaching a point during production where the most value-adding features are implemented so that one has a viable product and production can be stopped regardless on how many other features are left in the backlog.

Identifying the second type - problems related to “building it right” - is somewhat harder as it requires introspection, looking into ones own methodology. Identifying such problems is not easy – one gets easily used to the way things are usually done – so that is something that needs to be trained (using regular retrospective meetings, kaizen events, A3 reports, etc.). Yet, here is where most of the lead-time gains can be made.

As we have seen, to gain lead-time we want to discover all the bad news as early as possible. So, we want to build, integrate, function test, performance test, system test as soon as possible, and as often as possible. This may require extending the definition of done per team or to have several teams working concurrently on different aspects of the same product (for example, one team may be responsible for continuous integration, functional and performance tests of the work produced by several development teams). While doing so, we want to remove anything that is impeding our progress; the largest impediments often being an integrated part of the organization (the system).

So, expanding from the tightly packed proposed definition of agile/lean software development, we have just described a set of techniques and tools needed to minimize lead-times by addressing problems as soon as possible. Scrum and Kanban are examples of methods or frameworks that package such techniques and tools. Of course, you will need to use one or the other, or a combination of both, to succeed minimizing lead-times in your organization.

Minimizing lead-times is an endless endeavor: as soon as you have a part of the organization under control you will feel impelled to extend your agile/lean bubble up and down the value flow. Sooner or later, chasing lead-times will require the cooperation of everyone in the organization, all guided by a simple and tangible metric. Once you are there, well, you will have an organization that is finally ready to do some good work and you will realize that this was just the beginning.

Postad av Christophe Achouiantz

Kommentarer (0) 

2009-11-05

A vitamin bomb for the organization

A customer once described the effect I was having on the organization as a “vitamin bomb”. It is a pretty cool comment to get in term of performance appraisal, though it was not quite what I was expecting (“more efficient” or “pleased customers” would have been sufficient). What was I doing as an agile coach that seems to “vitaminize” the organization?

I alone could not generate energy in such amount so that it would be visible to management. Rarely can a person electrify a whole organization, except perhaps a great leader - which I am not, sadly enough. Well, as an agile coach I applied some agile concepts, methods and tools. Abstracting these, what I was actually doing was to focus the existing energy generated by all team members on things that the customer considered most important. My own energy was used to focus others energies on one point, so that the actual vitamin effect was not my own but the teams.

Let’s follow this energy analogy a minute: the people in an organization generate plenty of energy. Now, most of this energy is never reaching the customer as it is consumed by the system - the organization itself.
It is consumed in form of:

• communication costs (unfocused or unnecessary meetings, documentation that is not needed),
• translation costs (expensive knowledge disappearing in hand-overs),
• task switching (due too many parallel activities),
• producing things that are not valued by the customer (wrong prioritization, focus on delivering requirements instead of customer value)
• and finally energy that is simply not put in the system by the team members as they lack motivation (seeing very little return on their energy-spending activities).

The various agile/lean methods and tools actually help you focus energy at the right place at the right time. The effect is that you achieve more of value added activities than before, pleasing the customer and the employees in the process. It seems that you spontaneously generate energy from nowhere, achieving the vitamin bomb effect. In a sense, an agile/lean coach helps an organization find its inner strength.

Such a vitamin effect can be obtained without agile, lean or any other management/organizational methods. You simply need to get yourself a great leader! Because they can easily share their enthusiasm and visions, delegate responsibility and generate commitment, great leaders can electrify a whole organization. This could be the answer to “how did organization manage before any of the agile/lean stuff was even invented?”.

The problem with great leaders is that the energy they pour into the system disappears with them (look at how well Apple did between 1985 and 1996 without Steve Jobs) whereas agile and lean methods allow you to focus energy in a consistent and sustainable manner (Toyota just gets better regardless of who is in charge).

Can they be combined? Can you actually have a great leader leading a lean/agile organization without him or her feeling that the agile/lean system is in the way, because their energy focusing method is different and therefore incompatible?
You tell me.

Postad av Christophe Achouiantz

Kommentarer (0) 

2009-10-19

UK Lean Conference

Last September I attended the UK Lean Conference in London (September 27-29) with colleague coach Joakim Sundén.

That was an exciting conference. Not the least because it was the first time for me that I met in person the Lean and Kanban thought leaders that you can follow on the leanagile and kanbandev mail lists (Mary & Paul Poppendieck, David Anderson, Allan Shalloway, Karl Scotland, and many others).

The conference was about exploring the Lean experience in software development with some input from other domains (construction, services, product development). It was a success (in my opinion) as I got a broader view on Lean and Kanban.

I present here extracts of some of the keynote speeches:

May Poppendieck – The Tyranny of the Plan

Mary took us back to a time before there was any computer and showed us how plans were done. Did you know that in 1930 the Empire State building was conceived, designed and built in less than 16 months? Obviously without any help from a computer to create the perfect plans.

The secret behind the Empire State rapid development is to let your constraints (context) frame your design and design as you go. Today, the building would first be designed completely and then a computer would produce a perfect plan to adjust the production to the constraints. It works, only if everyone do exactly as told any nothing “unplanned” occurs (yeah, right…).

Here are some key takeaways:

* “Design the product after the constraints. Do not come up with the design first and try to make it fit in the constraints later”
* “Establish constraints so that you can do your work”
* “Constraints make you creative!”
* “Workflow is orthogonal to schedule” (This one needs more explanations, in a future post)
* “To succeed you need to break dependencies: both related to architecture and related to schedule ” At least wait until the last responsible moment to commit to a dependency

Jeff Patton – Lean Product Development

Jeff re-explained the old agile principles of iterative and incremental development. I was inspired by his view on how you need to wave in product delivery (solution creation) and discovery (understanding the problem) in each iteration. He attacked the agile principle of having a releasable product after each iteration. His view is that “releasability” of a product is not something you get from the burn-down charts. You need to grade the releasability of each feature after each sprint so that the Product Owner can make timely decisions on when to release.

Jeff also presented a very practical way to slice your stories so that big stories can fit into an iteration:

* First, deliver the bare necessity so that the feature “works”
* Then, increase its capability and flexibility (e.g. alternative flows)
* Then, increase safety (e.g. validation)
* Finally, increase usability, performance and sex-appeal of the feature

Karl Scotland – Kanban 101

Karl held a Kanban presentation for beginners where he covered the Kanban fundamentals. His 5 Kanban concepts are an easy way to get into Kanban.

There are 5 key concepts/principles to Kanban:

1. Map the value stream
2. Visualize the value stream
3. Limit WIP
4. Establish a Cadence
5. Reduce the number of kanban tokens

Other interesting concepts:

* “There is kanban (the actual visual card) and Kanban (the system)”
* “Another name for Kanban could be “Flow-based software development””
* “Cadence is different than timeboxing. Timeboxing is like a metronome – mechanic and constant. Cadence is more like a drummer – the rhythm may change.”

About Kanban

The majority of the people attending did have some Kanban experience and Kanban was regarded as the best approach to succeed. Though, all the persons I met had extensive Scrum experience and Scrum seem to be the default container of the majority of the Kanban implementations.

The conference provided the opportunity to meet the Agile Alliance board. We had interesting and passionate spontaneous discussions (though, after some glasses of wine everything becomes rather passionate) around some white boards in the cellars (“dungeons” would be more appropriate) of the Royal Society for the advancement of the Arts. The subjects touched the actual Scrum versus Kanban debate, how to scale, how to coach and several models (strangely enough all very much v-shaped) about how to scale.

What I get out of the conference are several efficiency-thinking tools that I am eager to try in the real world. I am thinking about organizing these thoughts in some way (some future post).

Overall I had a great time, though not enough to enjoy the usually good London weather.

Postad av Christophe Achouiantz

Kommentarer (1) 

2009-10-14

Welcome to yet another (but different) agile/lean blog!

Hello reader!

My name is Christophe Achouiantz, a consultant at Avega.

Here I will blog about my thoughts and experiences in Agile/Lean space. Sure enough there are already plenty of Agile/lean blogs out there, but I think I have some modest contribution to make that may be interesting for some of you.

I have been working in IT in Sweden for the past 11 years. My interest in Agile and Lean started when I was working as development manager in a small startup in 2000. Creating a “carrier-class” enterprise application back then – from scratch and in Java “SE” 1.1 - was really challenging. Being a small startup we had to be flexible and fast, while delivering high-quality, and with a small team (wait! this seems familiar somehow…). What I recall most fondly were actually the mistakes we made and how we coped with them. For instance, I do recall, late one night before release, trying to sleep – exhausted- on the (too short) sofa at the office, wrapped in the curtains (it can be cold at night in Sweden). In the morning it dawn to me that there has to be a way to make the whole “release” stuff better – at least for me. We eventually came up with this process/framework “thing” with a “prioritized list of functions to implement”, and “regular demos” to the customer, and the “planning how we will implement new functions” meeting, etc. What a surprise it was when I eventually found out about XP and Scrum. It was like an epiphany: someone has just written down, in details, the stuff we were doing – much better mind you. Since then I have been working and consulting as a Scrum Master (about 3 years now).

The focus of this blog will be on how to improve team(s) and organizations. I will share some tools and models that may help other agilist/leanist(?).

This is actually the first time I ever publish my thoughts on the net. Exciting and scary at the same time. Wish me luck (at least I do)…

Postad av Christophe Achouiantz

Kommentarer (3)