AvailAgility

Agile 2008 is almost here and I’m looking forward to presenting 3 sessions this year.

Managers Introduction to Test Driven Development (with Dave Nicolete)

Wednesday 6th, 16:00 - 17:30, Civic Ballroom South, Customers & Business Value Stage

The purpose of this session is to help non-technical managers understand the business value of one of the popular agile software development techniques. It is designed to help managers understand the impact on their projects when their technical teams use the agile technique, test driven development (TDD).  We begin by demonstrating the technique of TDD using a tool familiar to nearly all managers: Microsoft Excel. Clarke Ching developed a TDD exercise using Microsoft Excel that many others have used as the basis for demonstrations and presentations on the subject. We use this exercise to demonstrate the red-green-refactor TDD cycle with a tool familiar to nearly all managers so that they can see what the buzzword means and get a feel for the technique. This is followed by a presentation focusing on the effect of TDD on a project’s timeline, code quality, cost of development, cost of ownership/support, and longevity of the code in production. The core of the message is that TDD helps a team control the accumulation of technical debt in the codebase, and this in turn controls costs, reduces time to market, and results in a cleaner product that will have a longer production lifetime.

KFC Development - Finger Lickin’ Good (with Aaron Sanders)

Thursday 7th, 8:30 - 12:00, Essex Ballroom, Breaking Acts Stage

This workshop explores three important Lean concepts - Kanban, Flow and Cadence (KFC) - which can be combined to generate a more pipeline-based approach to software development, as opposed to the more common timebox-based approaches of more traditional Agile methods. We will describe our experiences implementing these ideas at Yahoo! and explain the concepts using examples, simulations and games. In addition, because this is a new and emerging way of working, there will be an opportunity for discussion between the participants about how the ideas might be applied in their own situations, in order to advance the art.

Integrating Scrum with the Process Framework at Yahoo! Europe (with Alexandre Boutin)

Friday 8th, 8:30 - 10:00, Kenora, Agile & Organisational Culture Stage

This presentation describes how Yahoo! International, and in particular, the Yahoo! Europe, has moved from having a very waterfall inspired process framework, to having one which is very lightweight and flexible, and thus compatible with Agile methodologies. This was achieved through Agile teams collaborating with the Process Group in its own iterative inspect and adapt cycle. The Process Group has evolved from being a control-oriented team, with a process-centric framework, to being a coaching-oriented team, with an organisational-centric framework. Thus, rather than telling teams how to run their projects, they help teams ensure they are meeting business needs.

I’ve been involved in a number of discussions about how User Experience work fits into an Agile process.  As a result a trying to articulate my position, I’ve come up with the following explanation of the anatomy of an MMF.

The following diagrams assume the following key:

Lets start by looking at a typical waterfall model:

In this case, all the UE work would happen early on, but obviously, isn’t Agile, so doesn’t allow for iteration and improvement.

A more Agile approach is:

In this case, the UE work is spread across the lifetime of the project, but for each increment, UE work happens early, relative to build etc.

That’s still not truly representative of an Agile project, which is more collaborative, so we have:

Here, everything happens together, as needed, for each Product Backlog Item (PBI, using Scrum terminology) and this is where the problem begins.  In order for a PBI to be sufficiently formed to be able to be planned into a Sprint, there may need to be Analysis and UE work in advance.  So typically these become PBIs of their own in preceding Sprints.  The problem I have found with this approach is that the focus is on the PBI, and the over-arching feature of value is lost, resulting on long cycle times.

So this is how I prefer to think about it:

Throughout the life of a Minimal Marketable Feature, the different disciplines are involved to varying degrees.  More UE earlier on, and more QA later.  However, the focus is still on the over arching feature, and all are still collaborating to deliver the feature as quickly as possible.  Any Sprints or PBIs are simply mechanisms to manage the flow.

Given this view of things, its a small step to allow MMFs to overlap, so that the features can smoothly flow through the system.

One of my background areas of interest is the use of musical metaphors to describe agile software development. I’m a classically trained musician, and I’m always surprised by the number of other musicians I meet in the agile community.  I can’t help thinking that the training and experience gained by musicians is applied by them in their software careers.  I occasionally submit music and agile related sessions to conferences, but they generally get rejected because I’ve not really got my point across very well yet (e.g. Agile 2008).  One common argument is that conductors are perceived to be command and control project managers.

On that note, I’ve just seen Benjamin Zander on music and passion (via Clarke Ching, via Frank Patrick).  Apart from being very entertaining and powerful, he describes his role as a conductor with some choice quotes.

“He depends for his power on his ability to make other people powerful”

and

“To awaken possibility in other people”

And he describes success as:

“If the eyes are shining, you know you’re doing it”

so if he’s not being successful:

“Who am I being that my players eyes are not shining”

All of which can be applied to the role of leadership with an agile software development team.

One of the regular questions I get asked when I talk to people about KFC Development is about how it is different.  As a result I came up with a set of KFC Consequences to try and help articulate this.

• Kanban Consequence - Eliminate backlogs, timeboxed iterations and estimates.

Eliminate might be a slightly strong word, but there is certainly less reliance on these things, and thus less wasted investment in them.  Ultimately a high performing team would not need them in a typically recognisable form, although they may use variations.  For example, an ‘incubation area’ might replace the backlog as a simple place to keeping ideas before they are refined into MMFs.  Similarly, classification might replace estimation.

• Flow Consequence - Use larger, value focussed features

Rather than an emphasis on driving user stories into smaller and smaller pieces, there is more of an emphasis on right-sizing pieces of work based on their value.  User story decomposition is used more as an analysis technique.

• Cadence Consequence - Commitment via measurement and SLAs, rather than planning and timeboxes.

Instead of planning batches of work into timeboxed iterations as a mechanism drive productivity and commitment, the mean lead time of MMFs is measured and used as an SLA aginst which due date performance is reported.  Thus it is actual performance which drives productivity, rather than forecast performance.

Allan Kelly blogged recently about whether kanban systems trade predictability for efficiency.  Its an interesting viewpoint, but I’m not entirely sure I agree!

Firstly, I don’t believe any agile process gives predictability.  One of the reasons for preferring agile methods is that software development just isn’t predictable.  Rather, I would say that agile methods can give reliability and that both kanban and more traditional agile methods give equal reliability.  Secondly, I prefer to focus on effectiveness rather than efficiency and that both agile and kanban value effectiveness over efficiency.

So, if there is a trade-off, it is between the amount of up front effort in planning in order to achieve reliability at the expense of effectiveness.  Scrum (for example) invests time in Product Backlog and Sprint Backlog planning in order to communicate at a high level what should be delivered.  Thus Scrum says “we believe we will deliver this much work over that time period, and that it will be made up those items”.  Kanban, however, simply measures average lead time and due date performance.  Thus Kanban says “we belive we will deliver this much work over that time period *but* we don’t yet know what those items will be - we’ll decide at the last responsible moment”.

Actually, I thinks its more a relationship between trust and effectiveness.  The more mutual trust there is between the business and delivery team, the less up front planning is needed, and the more efficient a team can be.  That’s not to say that Scrum has a heavy up front planning process, or is a low trust method, but Kanban takes advantage of more mutual trust in order to eliminate some overhead and be more effective.

Liz Keogh says “RIP As a… I want… So that…” (via David Anderson). This also ties in with what Chris Matts has being describing as Feature Injection. What I like about this idea is that it provides the link between the MMF and the User Story.

Liz proposes a new format:

• In order to <achieve some value>
• As a <role>
• I want <some feature>

The <some value> is a MMF - Minimal Marketable Feature. However, where minimal is still quite big, then MMFs can be broken down into <features>, which are more traditional User Stories. Thus the format gives a simple way of managing the relationship between the small incremental functionality pieces, and the larger value pieces.

Thanks Liz and Chris!

The final morning of the conference was faily quiet again. I did go to “The Agile Technique Hour” which was fun and interesting. David Parsons has posted the materials online, but in brief, we were split into teams in order to deliver features, which were drawings on functionality on overhead acetate. The features were integrated by overlaying the acetate sheats. Neat idea. Initially we had policies in place to inhibit productivity, and gradaully the policies were relaxed to allow us to collaborate better, refactor, regression test, continuously integrate etc.

What I found interesting was that our teams approach was to have a clear vision (a basic bicycle) and to focus on delivering the simplest ‘minimal’ solution for each ‘marketable feature’ and to focus on delivering the ‘minimal viable product’ e.g. the smallest set of features which gave a valuable useable product. In effect, we limited work in progress. We ended up completing nearly all the features without too much trouble (unlike the other team )

Here’s the final product:

An excellent workshop by Mary and Tom Poppendieck today entitled “Stop Thrashing: Pull Schedule Techniques for Level Workflow”.  It really left me buzzing, for two reasons.  Firstly, Mary talked about her real experiences implementing a kanban system at 3M which was fascinating, and secondly, I ended up being invited up to the front to share my experiences with implementing a kanban system at Yahoo!

Mary described how 3M moved from an MRP (Material Resource Planning) system which was software based and delivered 60% against plan, to a kanban system which was physical token based and delivered 95% against plan.  The reason it worked was that ultimately, the system was designed by the floor workers who operated it - not by management - so when there were problem, the flow workers understand how to solve them.  To quote Mary, “Computers destroy our capability to schedule”.

The key to a kanban system working is what Mary called ’setup time’ - the time to get the system ready for production.  A large setup time means that there need to be large batch sizes to be economically viable, whereas a small setup time means that batch sizes can be smaller.  The smaller the batch size, the more just-in-time is possible, and the better the flow.  Setup time for software is generally the merge/test/deploy process and this matched my experience.  At Yahoo! we had a release cycle of one week, because that was how long the release setup time was.  Reducing the time needed for the release process by employing more automation (e.g. testing) would have enebled us to release even more frequently.  One of the goals for a lean manufacturing organisation is ’single digit setup’, or a setup time of 9 minutes or less.  Mary described a visit to a Toyota factory where the setup time was so small that they were able to achieve a batch size on one - each car in the line was different.

Mary also talked about Building the Empire State which was built in recored time (20 months from the start of the entire project) at a rate of one floor a day.  The bottom floors were being built before the top had been designed by using a number of techniques:

• Collaborative teamwork between the owner, architects and builders
• Deigning such that construction was quick and easy (as opposed to cheap)
• Breaking dependencies so that elements of the building could happen in diffierent orders
• Focussing on the constraint to enable a flow of material
• Eliminating waste - for example having restuarants on the buildng during construction

In the afternoon I ran an OpenSpace session on kanban which had around 15 people come along to and I did a quick run through of my latest KFC slides.  There seems to be a real growing interest in the community about these new ideas, and I think the explanations and understands are gradually becoming clearer.

Dave Snowden’s keynote was entertaining and interesting, although quite a lot of it went over my head.  Dave talked about the need to understand why something works in order for it to scale, with reference to agile development.  His work covers Complex Adaptive Systems, Cognitive Systems and Evolutionary Phsycology and Anthropology.

Some points which stuck out for me were:

• Adopt a safe-fail experimentation rather than a fail-safe design approach
• Hindsight doesn’t lead to foresight
• Manage and monitor boundaries and attractors
• Measure impact, not outcome

I also attended Lasse Koskela’s Retrospective Exploration Workshop.  I was primarily interested in seeing how the exercises worked as I’m putting together our own similar course for Conchango as most of the content was based on the agile retropsectives bible.  Unfortunately, there wasn’t really enough time for a good hands-on simulation, although it was enough to trigger some thoughts.  One key thing is to have a shared context which participants to use.  Another conundrum is whether to do lots of powerpoint up front, followed by a full retropsective simulation, or whether to interleave presentation with experience.  One final nice idea which Lasse used was for situations where you don’t have much wall space.  He lifted a table up onto its end, so the table top became a temporary wall which he could stick paper to.

Finally, Sean Hanly spoke about his experiences with a strartup TicketSolve.  This was fairly standard stuff until he mentioned the magic work ‘kanban’!  It turns out that they had difficulty in release planning due to the constantly changing priorities, so adopted a basic kanban approach whereby they only planned short term for the immediate customer needs, and pulled features in iteration by iteration.  It sounded like they had lost some of the big picture as a result which a quarterly planning cadence could have helped with.

As usual side conversations have been as interesting as the main conference.  A theme that has emereged for me is the shift from delivering ‘working’ software to delivering ’successful’ software.  That’s what Jeff Patton is aiming for, and I think its a goal of the KFC.  Rather than simple asking ‘what do you want?’, ask ‘whats your goal?’ or even ‘what problem are you trying to solve?’.  This helps focus on the value being developed and delivered.

I went to Jeff Patton’s tutorial on User Story Mapping this afternoon.  I first met Jeff in London last year at XP Day and the Scrum Gathering.  We talked about kanban, and his ideas, and the two seemed very compatible, so I was keen to see how they matched in more detail.  Jeff has also been working with former Yahoo! colleagues Joe Arnold and Aaron Sanders on a kanban related article, so he also sees a connection.

Jeff is trying to solve a number of problems with User Stories that I’ve also seen:

• they are difficult to prioritise because it is usually a collection of stories that provide value.
• it can be difficult to understand the dependenies between stories.
• it can be difficult to understand the whole system from a backlog of stories.
• creating more smaller stories makes the above even worse!

Jeff’s solution is to break a system down into the following hierarchy:

Goals -> Activities -> Tasks -> Tools

• Goals are the user centred things which are trying to be achieved
• Activities are role based themes of functionality
• Tasks are more specific, but still high level features, which make up an activity
• Tools are typical more detailed user stories

By creating this hierarchy and generating a physical map using index cards, the relationship between the various parts of the system, and the value that they are delivering, can be communicated and evolved.  Activities form the ‘backbone’ of the system, and Tasks can be prioritised to form a ‘walking skeleton’, or a ‘fully formed, but immature’ system.

From a kanban perspective, it seems to me that the Tasks are similar to MMFs, and are what make up the kanban cards, and that the Story Map is a tool to inform both the value that they generate, and the order in which they should be scheduled.