Imagine for a moment a large project to deliver content and a self-service capability to an organization’s customer base. The project looks to deliver all the features that support that capability in one release, one very large batched release, one single release that services a wide array of customers across a large demographic. The project is anticipated to take two years in total. That is two years to deliver the desired benefits (as outlined in the large Business Case) to the customer.
Now what if that project had kicked off two years ago today, based on what was understood the customer wanted and the knowledge of the prevalent technologies at that time. What technology, and what customer needs would we have missed? Perhaps the uptake in:
- Tablet devices (such as the iPad)
- Mobile devices
The project team may well have been aware of these technologies, but they may well have been in their infancy, not widely adopted by the customer base, or perhaps even dismissed as a fad.
What a customer really wants is very hard to predict. They don’t always know themselves. Sometimes a prediction is no better than a flip of a coin. Throw technology into that mix, and that prediction problem, just became a whole lot harder. Customer expectations grow with the introduction of new technologies, the trick is to understand and accept that change will happen. Embrace it, deliver change quickly and incrementally and look for the next opportunity.
Break that big project down, deliver and test your predictions with the customer early using agile and customer focused development; only then can you hope to deliver what the customer wants with the technology channels and platforms that matter to them.
The recent New Zealand Office of the Auditor General (OAG) publication entitled Realising benefits from six public sector technology projects, makes for interesting reading. It details lessons learned from six public sector technology projects, with the OAG outline good practice for realising these, through six common themes. I have included a high level summary of their key points in the table below:
Based on the above summary, I thought I would add some of my own thoughts to the OAG’s six areas of recommendation:
1. Understand the environment and make the most of circumstances
This is about practising the Lean practice of the “gemba walk”, that is go to the actual place where value is added. Get out from behind your desk and go on the gemba and look at the environment, meet with the customer, understand the problem that needs to be solved.
Is your solution compelling enough for a customer to use it to solve a problem they have today, or does it rank number 11 on the customer’s top 10 of needs?
2. Be business-led, flexible, and agile approach
Technology is not an end in itself, but it needs a clear business purpose. A technology project needs to involve people who know a lot about their business, seconded to the project team. Deliver with the business, not to the business.
3. Have strong leadership and senior support
Senior management need to support the project, remove impediments that prevent it from progressing, and own the business assumptions including their early validation and realization, so that they become benefits.
4. Work effectively with the right people, including end users
Test your assumptions and get early feedback from your customers, to do this you need to first identify who your customer is.
5. Use the right technology tools
It should come as no surprise that I am an advocate for an agile development approach. There are clear advantages to be had, but agile by itself can still result in building the wrong thing as efficiently as possible. Rather like Lean Startup, there needs to be a synthesis of agile, along with Lean principles and a focus on Customer Development and early validation of a Business hypothesis.
Make use of open source technology, with a modular approach to support the rapid deployment of solutions where possible. Modules and open-source, can also be read as Government agencies opening up the source of re-usable, loosely coupled modules to other Government agencies.
Making information open for third parties, such as NZTA has for its Real time travel information, can lead not only to cross Government agency support and learning, but can also support the creation of additional Lean Startups in its own right. The concept of a Government agency enabling such an industry to add value and create jobs through mash-up technology is not new. This concept has been successfully used by Todd Park and US Government HSS department, for the Health Data Initiative.
By providing this data free of charge and without intellectual property constraint and proactively marketing its availability, innovators can use the data to create applications that benefit the public, and the New Zealand economy.
6. Monitor and understand the benefits
It is very difficult to monitor benefits for a project if they get don’t get delivered until the very end; by which time it could well be too late. Any benefit in a business case is a perceived benefit, an assumption that will only be realised through validation with the end customer. Those assumptions should be validated throughout the project, this means benefits need to be quantified and delivered early for validation. If an assumed benefit is invalidated by the customer, pivot and change direction. That means any business case needs to be a living breathing model, constantly validated.
Ultimately to realize benefits effectively you need to understand who the customer is that will benefit from your solution, and then test that solution early with that customer to validate your assumptions. To me, the heart of such an approach requires a business model or Lean Canvas to support the clear definition, tracking and realization (validation) of these benefits.
Some time back, I posted a set of Scrum Meeting Checklists and I continue to find this to be a useful reminder, especially to those new to Scrum. I have updated these based on the new Scrum Guide and feedback from working with teams who have been using these. So here they are, Scrum Meeting checklists version 2.0 !
I have again included Scrum specific meetings only, for example I haven’t included a visioning meeting, or Story Mapping workshop; in fact I haven't referenced User Stories at all, but used the agnostic term 'Product Backlog Item'. I have included a few points which I feel are important within these meetings (such as Definition of Ready, which isn’t a Scrum term). I have also included “Grooming the Product Backlog” as a generic requirements definition meeting, it is included in its own right as in my experience, it’s the area that most Scrum teams forget to put any time or emphasis.
As before in terms of the meeting checks, I have drawn on the following specific resources:
- The Scrum framework guide by Ken Schwaber and Jeff Sutherland,
- Mike Cohn, specifically his work on Agile Estimating and planning
- Jean Tabaka, Collaboration Explained: Facilitation Skills for Collaborative Leaders, a great resource on general agile meeting and team facilitation.
- Esther Derby and Diana Larsen, Agile Retrospectives: Making Good Teams Great, the Definitive guide to retrospectives, they introduce the 5 stage approach that all Retrospectives should adhere to.
Fig1: Scrum Checklist 2.0 Page 1
Fig 2: Scrum Checklist 2.0 Page 2
As before, these checklists are not intended to be an exhaustive list, but rather an aide-memoire. They are a standard that should be continuously improved, through the twin pillars of Inspection and Adaption.
Joe Justice and Tim Myer of WIKISPEED recently gave a truly inspiring talk to the AgileWelly in Wellington. I have included the video of this presentation below.
[[lt]]iframe width=[[quot]]560[[quot]] height=[[quot]]315[[quot]] src=[[quot]]http://www.youtube.com/embed/zN5OEsx4xb8[[quot]] frameborder=[[quot]]0[[quot]] allowfullscreen[[gt]][[lt]]/iframe[[gt]]
The event got me thinking about how WIKISPEED has re-defined Craft Production in the motor industry, especially after I saw a clip on tips for Squaring chassis parts. In the book the Machine that Changed the World, Womack, Jones and Roos, summarise how early motorcar production was low volume and undertaken by craftsman. This was soon supplanted by Henry Ford and his Mass Production approach, which in turn was superseded by Lean; with WIKISPEED have we come full circle?
Craft production in the motor industry, is defined by Womack, Jones and Roos as having the following characteristics:
- A workforce that is highly skilled in design, machine operation and fitting
- Self-employed contractors and assembler firms, many with their own machine shops
- Decentralised organisations, often concentrated within a single city
- Most parts and much of the of the vehicle design originating from small design shop
- System co-ordinated by an owner/entrepreneur in direct contact with everyone involved: customers, contractors and suppliers
- The use of general purpose machine tools
- A very low production volume; no two automobiles exactly alike
The tools and techniques that WIKISPEED use - Lean, Agile, Scrum and XM (eXtreme Manufacturing), have enhanced their Lean Production method. But it is the use of opensource, the sense of community and the fact that the single city limitation (encountered by the early motor car manufacturers such as 'Panhard and Levassor') has been eliminated, due to the global internet city that has been the real enabler. There is no longer any need for a craftsman for a Product to be physically co-located. A single design shop can become an opensource community, where there is no need for a single owner to co-ordinate, and modular design improved over time by a community can result in consistency of production.
What does this mean for software development? Are there parallels that we can draw? The IT mass production approach of waterfall has been countered by Lean Principles, agile, customer development and the rise of software craftmanship. What I believe, is there will be a synthesis of good practice which will see modular and opensource applications integrated and crafted by expert teams delivering value early to the customer. The foundation of modular applications, utilising opensouce designs enhanced and extended by a community of expert craftsmen, means a Product can iterate through a Build-Measure-Learn cycle much more quickly. The Lean Startup goal of validating assumptions quickly, can be achieved rapidly without the need to re-invent our own (let alone the motor industry’s) wheel.
I recently gave a 7 minute no-slide lightening talk, to the Wellington PRINCE2 users group. The talk was around Eric Ries' The Lean Startup in relation to the PRINCE2 Business Case and Principles. (check out my previous Blog - Lean Startup Government presentation for more details). I was asked to blog the notes so here it is...
PRINCE2 is Business Case driven approach, with a strong emphasis on the Business Case being continuously evaluated to ensure the outcome is still desirable; is this project (still) worth investing in? But how do we ensure that the project continues to be desirable and that we are on the right track? This is how Lean Startup can help.
Lean Startup is a synthesis of:
- Customer development: Customer centric, it asks is our solution compelling enough that the customer would want to use it today?
- Agile development practices: A disciplined approach to software development, that embraces evolutionary change.
- Lean Principles: A focus on value, (as defined by the customer), reduction of waste (that is anything that does not add value to the customer) and the Flow of work.
Lean Startup is an Experiment, where you test your assumptions early and get early feedback from your customers. This is achieved through minimizing the time to iterate through a Build – Measure – Learn cycle
Fig 1: Build Measure Learn cycle by Eric Ries
- Build (Manage by stages)
- Build a Minimum Viable Product (MVP).
- PRINCE2 recommends that one of the three default Business Case options is ‘Do the Bare Minimum’; this should be the next default after the ‘Do Nothing’ option
- Undertake Rolling Wave planning and break the project into smaller batches which can be delivered within a Workpackage
- Validate the Business Case assumptions in smaller increments using the vehicle of an MVP, through Learning and Justification
- Measure (Continued business justification)
- We need a justifiable reason not just to start a project, but also to continue it
- The Business Case Justification is based on tangible assumptions which lead to benefits (okay I’m assuming here that a benefit is made up of 1 or many assumptions!)
- We need to accept that these are just assumptions and validate them with our customers early
- To measure our assumptions they need to be objectively quantifiable
- The static Business Case becomes a living Business Model which should be continually updated as assumptions and benefits are realised (or not) and the project progresses
- For a Business Model Consider using the Lean Canvas A3 Lean Canvas by Ash Maurya based on Alex Osterwalder's Business Model Canvas
- The question moves from can the Product be built, to should the Product be built
- Learn (Learn from experience)
- Experience is based on customer feedback
- Learn what the customer wants and needs (project is a learning exercise)
- Drive decision making
- Manage by exception
- Project benefits are all too often reviewed for realization long after the project has closed
- The exception is what if our assumption is proved wrong? This could invalidate our expected project benefit
- We should not pursue a plan to cost and time that is based on invalidated assumptions
- We should accept the assumption is incorrect and ‘Pivot’ and lean to a new assumption and approach; or Persevere and accelerate our approach based on validated customer feedback for our assumptions
- The Project Board should steer the course of the project, set tolerance around assumptions to ensure they are validated
- Incorporate the Benefits Review as part of the process to validate assumptions based on the MVP; confirm that they can be realized before it is too late
- The Project Board should have the delegated authority to make the Pivot or Persevere decisions
- Don’t hide assumptions in a Business Case
Well that’s four of the seven PRINCE2 Principles covered
- Continued business justification
- Learn from experience
- Manage by stages
- Manage by exception
Here are some thoughts on how Lean Startup applies to the remaining three:
5. Defined Roles and Responsibilities
- Ensure you have a clear understanding of the roles
- The ‘User’ the customer who will validate your assumptions
- The Business to ensure that the Business Model assumptions and benefits they support are realised
6. Focus on Products
- Focus the project on the outcome of the Minimum Viable Product, rather than activities
7. Tailor to suit the project environment
- PRINCE2 is applicable to all project types, including Lean Startup
Equinox IT was the sponsor of the GOVIS 2012 Innovation Programme, and as part of our involvement, yesterday I delivered a presentation at the conference Ideas Fair. My presentation was entitled 'Can Minimum Viable Product (MVP) Help Government Innovate Like a Startup?'. The short answer is Yes, and the presentation slides are available below. The MVP approach was popularised in Eric Ries' excellent book The Lean Startup, and we ran a competition as part of the presentation to win a copy of this book. During the presentation the Running Lean work of Ash Maurya was also referenced.
The key for me is the move away from a large static business case, toward a dynamic business model where we validate our assumptions. Don't bury assumptions in a huge document, use an A3 Lean approach to test your hypothesis; the steering committee driving forward and persevering at an accelerated rate or changing direction through a pivot. This is covered on slides 28 and 29, and is based on Alex Osterwalder's Business Model Canvas and Ash Maurya's Lean Canvas. I intend to extend this through further work and blog posts relating to Government.
[[lt]]div style=[[quot]]width:595px[[quot]] id=[[quot]]__ss_13376859[[quot]][[gt]] [[lt]]strong style=[[quot]]display:block;margin:12px 0 4px[[quot]][[gt]][[lt]]a href=[[quot]]http://www.slideshare.net/aboobier/can-mvp-help-government-innovate-like-a-startup[[quot]] title=[[quot]]Can MVP help Government innovate like a Startup?[[quot]] target=[[quot]]_blank[[quot]][[gt]]Can MVP help Government innovate like a Startup?[[lt]]/a[[gt]][[lt]]/strong[[gt]] [[lt]]iframe src=[[quot]]http://www.slideshare.net/slideshow/embed_code/13376859[[quot]] width=[[quot]]645[[quot]] height=[[quot]]538[[quot]] frameborder=[[quot]]0[[quot]] marginwidth=[[quot]]0[[quot]] marginheight=[[quot]]0[[quot]] scrolling=[[quot]]no[[quot]][[gt]][[lt]]/iframe[[gt]] [[lt]]div style=[[quot]]padding:5px 0 12px[[quot]][[gt]] View more [[lt]]a href=[[quot]]http://www.slideshare.net/[[quot]] target=[[quot]]_blank[[quot]][[gt]]presentations[[lt]]/a[[gt]] from [[lt]]a href=[[quot]]http://www.slideshare.net/aboobier[[quot]] target=[[quot]]_blank[[quot]][[gt]]aboobier[[lt]]/a[[gt]] [[lt]]/div[[gt]] [[lt]]/div[[gt]]
How long is a piece of string? That annoying question that often comes up when we are trying to estimate how long a project or piece of work will take. Intrinsically a piece of string has a length, but that length is unknown and variable, as such a quantative answer cannot be given, due to uncertainties surrounding it. How long will it take? How big is it?
You could undertake an investigation to look for a level of precision before you even touch the twine; perhaps a detailed triangulation from afar, with a comprehensive set of assumptions to back it up.
Another approach is to cut the string up into smaller pieces and relatively size each one of those pieces. You know for a fact that the piece of string is twice the length from one end to the middle. So if you were to cut the string in two, you would have two pieces of string, each sized relatively equally to one another.
The same applies when sizing up a piece of work. Break it into logical partitions (e.g. User Stories), and then relatively size them against one another. In essence -
1) Establish the scope of what you are trying to do (and therefore measure)
2) Break that work into smaller pieces (in software that includes everything to get the item to completion analysis, development and testing)
3) Size those pieces relatively to one another
4) Measure on average how long each one of those pieces takes to complete
5) Update your understanding of the whole work piece
6) Update your estimate on how long it will be to deliver the whole
Don’t get tied up in knots trying to get a level of precision and accuracy with your estimates, when you haven’t even touched the work yet. Break up your ball of twine, relatively size it and get on and get a standard measure.
Last week I delivered a presentation entitled 'Lean System Design' at the Agile NZ conference in Wellington. The presentation slides are available below. The presentation was based on content from some of my previous posts on this blog, the work of Steven J Spear in his excellent book Chasing the Rabbit, and also the work of Donella Meadows. The presentation included the high-level approach that I take to review the delivery processes when working with product development companies here in New Zealand.
When used in conjunction with the guiding Lean Principles, in my experience, the steps from the presentation can be used on a system from the very small and simple to the very large and complex. One of the take aways from the presentation is the focus on optimising the whole, rather than parts, while keeping in mind that systems reside within a hierarchy - i.e. don't take on too much and try to deliver the 'moon on a stick'! (see slide 8)
[[lt]]div style=[[quot]]width:595px[[quot]] id=[[quot]]__ss_12261337[[quot]][[gt]] [[lt]]strong style=[[quot]]display:block;margin:12px 0 4px[[quot]][[gt]][[lt]]a href=[[quot]]http://www.slideshare.net/aboobier/lean-system-design[[quot]] title=[[quot]]Lean system Design[[quot]] target=[[quot]]_blank[[quot]][[gt]]Lean system Design[[lt]]/a[[gt]][[lt]]/strong[[gt]] [[lt]]iframe src=[[quot]]http://www.slideshare.net/slideshow/embed_code/12261337[[quot]] width=[[quot]]645[[quot]] height=[[quot]]538[[quot]] frameborder=[[quot]]0[[quot]] marginwidth=[[quot]]0[[quot]] marginheight=[[quot]]0[[quot]] scrolling=[[quot]]no[[quot]][[gt]][[lt]]/iframe[[gt]] [[lt]]div style=[[quot]]padding:5px 0 12px[[quot]][[gt]] View more [[lt]]a href=[[quot]]http://www.slideshare.net/[[quot]] target=[[quot]]_blank[[quot]][[gt]]presentations[[lt]]/a[[gt]] from [[lt]]a href=[[quot]]http://www.slideshare.net/aboobier[[quot]] target=[[quot]]_blank[[quot]][[gt]]aboobier[[lt]]/a[[gt]] [[lt]]/div[[gt]] [[lt]]/div[[gt]]
The diagram on slide 12 shows the four key steps in this approach presented. Note in this diagram that output is step 1, because as W Edwards Deming points out, the customer is the most important part of any system.
I delivered the below "Stick to Your Principles" presentation to the Agile Professionals Network (APN) Wellington branch in February. The theme of cooking in the presentation came after I had undertaken to cook the Christmas Turkey dinner. I did quite a bit of research to find the perfect recipe (thanks Gordon Ramsay). I had my set of instructions for making a delicious dish from a set of prescribed ingredients, a formula for attaining success. But here was the thing, we didn’t spend Christmas at our house, with my kitchen and my surroundings. No, we spent it at a holiday bach on the beach. The kitchen was different, no oven, only a stove and pots to cook with. I could only source tinned carrots. And you try telling my kids that they have to wait an additional 2 hours while the turkey ‘rests’ and re-absorbs the juices. Perfect Turkey dinner became the perfect Turkey hash shown on slide 3 of the presentation.
The thing is even if we have a recipe, the context of the situation can mean we can’t replicate a successful dish in a different environment. The key is guiding Principles. Know your system, know your customer and desired output. Like a good chef know the diner and the dish, have practices that work and produce that dish given the limitations of your environment, but understand the base principles of why things work and use them help them guide you.
[[lt]]div style=[[quot]]width:595px[[quot]] id=[[quot]]__ss_11752038[[quot]][[gt]] [[lt]]strong style=[[quot]]display:block;margin:12px 0 4px[[quot]][[gt]][[lt]]a href=[[quot]]http://www.slideshare.net/aboobier/lean-principles-11752038[[quot]] title=[[quot]]Lean Principles[[quot]] target=[[quot]]_blank[[quot]][[gt]]Lean Principles[[lt]]/a[[gt]][[lt]]/strong[[gt]] [[lt]]iframe src=[[quot]]http://www.slideshare.net/slideshow/embed_code/11752038?startSlide=1[[quot]] width=[[quot]]645[[quot]] height=[[quot]]538[[quot]] frameborder=[[quot]]0[[quot]] marginwidth=[[quot]]0[[quot]] marginheight=[[quot]]0[[quot]] scrolling=[[quot]]no[[quot]][[gt]][[lt]]/iframe[[gt]] [[lt]]div style=[[quot]]padding:5px 0 12px[[quot]][[gt]] View more [[lt]]a href=[[quot]]http://www.slideshare.net/thecroaker/death-by-powerpoint[[quot]] target=[[quot]]_blank[[quot]][[gt]]PowerPoint[[lt]]/a[[gt]] from [[lt]]a href=[[quot]]http://www.slideshare.net/aboobier[[quot]] target=[[quot]]_blank[[quot]][[gt]]aboobier[[lt]]/a[[gt]] [[lt]]/div[[gt]] [[lt]]/div[[gt]]
Further to my Lean Principles blog posts, here is the high level approach I take to designing and reviewing systems. This is based on the work of Steven J Spear in his excellent book Chasing the Rabbit. When used in conjunction with those guiding Lean Principles, in my experience these steps can be used on a system from the very small and simple to the very large and complex.
The diagram below shows the four key steps in this approach. Start with the output first, because as W Edwards Deming points out, the customer is the most important part of any system.
Fig 1: Four steps to designing a system, based on work by Steven J Spear
There are tests and process patterns that I use at each stage, but the key questions to ask are:
- What is the objective?
- What has to be delivered to whom and by when to ensure success?
- Can you match supply with demand?
- What is the sequencing and responsibility?
- What work stages need to be completed by whom in what order to achieve the desired outcome?
- How do you convey information and services between work stages?
- What are the hand-offs between the different work stages?
- What information triggers people to undertake their activities at the correct time?
- What handovers occur?
- What is each work stage’s content, sequence and timing?
- How do you know the method you are using is working?
- What are your local policies and procedures?
I was in Auckland recently, traveling back to the airport, when I noticed they use on-ramp signalling to control the flow of traffic onto the motorway system. Donald Reinersten in his book 'Principles of Product Development Flow', uses the analogy of on-ramp signalling to show the benefits of managing queues, especially the principle of linked queues.
In terms of explaining the use of on-ramp signalling, there is no better site than that of Auckland Motorways by Benjamin Paul. It is that site that I use as the basis for the following comparison between preventing congestion on a motorway and your Kanban system.
Fig 1: North Western to Northern Ramp Signals, Auckland, New Zealand (reproduced here courtesy of Benjamin Paul; AucklandMotorways.co.nz)
Motorway ‘On-Ramp’ congestion control
Congestion is caused on the motorway when there is too much demand in a particular section. This can occur because traffic from the on-ramp (access point) comes in bursts or there is extended high demand with low throughput. Ramp Signals manage this demand, by allowing traffic to enter at regulated rates. Traffic is drip fed into the main route, to prevent and/or lessen congestion caused by excess demand.
Fig 2: How a Ramp Signal functions (reproduced here courtesy of Benjamin Paul; AucklandMotorways.co.nz)
Ramp signalling is a Pull based mechanism, rather than push. Cars are “pulled” into the main flow (motorway) when the system has capacity to support them.
The improvements? Well according to Auckland Motorways, signals in Auckland have resulted in:
- 30 to 50 minute reduction in the peak period congestion
- 600-650 more cars are getting through sections compared to before
- average speeds have increased from 25 km/h to 60 km/h (CMJ)
For the network as a whole there is a:
- 15% increase in travel speeds
- 15% increase in vehicle throughput
- 24% reduction in incidents
- 91% improvement in the reliability of travel times
- reduction in emissions of 54,500kg per day (nine petrol tankers per week)
The benefits of an on-ramp
The positives derived from on-ramp signalling, and WIP restriction for a Kanban system are briefly outlined below:
Can prevent clusters or bursts of traffic causing irreversible traffic congestion on the motorway
Task switching eliminated due to the setting of WIP limits, prevents congestion and Thrashing.
Can decrease peak period length and congestion severity
Flow control to even out demand across the system.
Adapt to conditions
Adapts to changing traffic levels (which adjusts the level of managed flow)
The Kanban board enables immediate adjustments to be made as issues surface.
Travel time for a journey is more predictable
The pull based mechanism can allow for more predictable journeys, where average cycle time through the system can be established.
This does mean that the size of the items entering the system needs to be considered.
Encourages better and more compatible merging behaviour – ‘merge like a zip’
Prevent repercussions through the system by pulling items in as capacity is freed up through WIP limits.
Gives priority to trucks, HOVs (High Occupancy Vehicles) and buses.
This is similar to a Kanban class of service:
Expedite: emergency vehicles, that occur infrequently but when they do, they need to take priority and get to their destination fast.
Fixed Delivery date: Busses, as they need to adhere to a strict timetable
Standard Class: Cars
Prioritisation of work and the use of class of Service (see Kanban by David Anderson).
The use of an Expedite Class of Service, will allow the facility to fast track a limited amount of emergency work. It does not mean capacity is kept back in reserve, it does mean the facility is in place albeit there will be an impact to work already in progress.
This means we do not need to issue a ‘hands off the team’ message to the business for the duration of the Iteration.
Discourage low priority
Discourages short journeys or usage of ramps that cannot handle high volumes of traffic.
Like a Definition of Ready, if you can show a customer/stakeholder the process, your expectations of them; it is likely the items of least value will be dropped.
Visualisation of the process will give a good tangible indicator of the implications and process for the work (important for knowledge based work) and how long the cycle time (journey) will take to complete.
You don’t want to discourage work, but you do want to ensure you are working on things that are of value and importance.
Drawbacks of an on-ramp
Some of the potential drawbacks from on-ramp signalling and the Kanban equivalent are:
Waiting at on-ramps.
Some journeys may save time on when accepted in the system but time is lost waiting at the signals.
Customers can become frustrated, waiting for backlog items to be pulled into the system and worked on.
The counter is that customers know exactly what is being worked on.
Trips can be inefficient
A trip was once efficient, now inefficient.
Small work items may need to be amalgamated, this can be done using an Intangible Class of Service.
Increase Rat Running
Can increase rat running.
That is the use of secondary roads instead of the intended main route, to bypass lengthy traffic signals.
Rat running is typically carried out by motorists who are familiar with the local geography.
Risk that the Customer / stakeholder who try to bypass the system by going direct to the development team; networking, who they know.
Visualization, gives a true and honest representation of the work being undertaken.
Congestion control with Kanban
A Kanban board, through its visualisation, allows the optimisation of the whole process. Rather than focus on one drivers experience (sub optimisation), the system is monitored and tuned as a whole to maintain flow. The approach looks to deliver work in a steady stream, rather than in batches or bursts. The board like a motorway is persistent and in constant use.
In a Kanban system Work In Progress (WIP) is limited per workflow state. Items are pulled into the system as capacity becomes spare, the on-ramp is a queue where items are pulled in item by item as capacity becomes free.
Urban areas are using on-ramps and signalling more and more at their busiest sections, especially at those which have a limited amount of lanes in each direction and cannot be widened due to the buildings around it.
And here’s the thing with a IT value stream, the system can only deliver the capacity that the system can deliver. You can only optimise the existing capacity you have through good optimisation. Utilise and make the system you currently have as efficient as possible.
Kanban systems use WIP limits (and the associated buffers and queues) rather like the on-ramp signalling mechanism. This prevents overburdening the system, by ensuring work is only pulled when there is capacity to do so. Like the on-ramp signals, don’t be afraid to use Red lights to drip feed items into your system and prevent congestion from occurring.
I was in Christchurch the other week and only had a short window of time to find something to eat between engagements. I walked into a sandwich shop and through visual cues, I was very quickly able to establish that I could purchase a sandwich and drink (to my liking) in the time I had available. I could see that there was 1 person in the queue ahead of me and 2 people working behind the counter, there were pre-made sandwiches laid out and prices were clearly labelled.
How quickly are we able to establish information and status by just walking into a project team area?
Sandwich similar to the one that I purchased in Christchurch.... (Picture courtesy of Wikimedia Commons)
Management by sight
Visual control or as Taiichi Ohno calls it “management by sight”, is a key aspect of lean production and lean agile software development. Those two terms Visual Control and Management by Sight are important concepts; not only do we want to convey information to see what is happening, but we want to be able to use that information to make informed decisions.
In IT, where we are knowledge workers, our work-in-process is not tangible like manufacturing, our inventory is information. It is all the more important that we have visual control to see what someone is working on. A physical representation of a knowledge based activity can be accomplished through an index card or sticky note which represents a work item.
The Visual Control should be a large workspace that communicates the status to a passerby. It should enable the team to control the process and eliminate waste of additional status reporting. Alan Shalloway notes that visual controls are used to make it easier to control an activity or overall process, through the use of variety of visual signals or cues. The Visual Control according to him should therefore:
The filling of the sandwich
- convey its information visually
- reflect (at least a part of) the process that the team is following
- describe the state of the work-in-process
- control the work-in-process
- be able to be viewed by anyone
So what are some of the things that should be included within a Visual Control board? As Mary and Tom Poppendieck
state the key question is to ask: How do people know their progress toward meeting the overall goal of their work?” To answer that you will need to consider including:
- Product Vision (why are we doing what we are doing?)
- Policies and Procedures
- Working agreement
- Value Stream (columns representing key aspects of the process)
- Exit and entry criteria (especially relating to each column)
- Definition of Ready (what work needs to be done for the team to accept work)
- Definition of Done (how do we know when we are complete)
- Impediments or Problem Countermeasure board
- Release Plan
- Burndown charts
- Cycle times
This visual control board should be supplemented with Andon control. The notification to stop the line due to the introduction of defects or issues. This can be achieved through a visual display such as using a USB light indicator, if the automated build becomes broken following a code check in.
It is key to display important information for all to see so we can make informed decisions.Make sure that you modify your visual control if it is not working or too complicated, and ensure that it is relevant, up-to-date and easy to maintain.
When identifying impediments or issues on a project, I’m struck by that Yogi-ism “It’s Déjà vu all over again”. Teams can be so focussed on resolving an issue and then rapidly moving on, that they don’t take stock as to why the problem occurred in the first place; what was the root cause? Retrospectives are a good way to deal with problems in agile projects, if we can remember the problems that occurred during an iteration and if indeed they were the real issue.
In agile projects, the key is to identify and resolve impediments within a local project team as quickly as possible. An impediment or issue is anything that prevents a team from performing their work as effectively as possible, something that could prevent or delay delivery of the product. In scrum the mechanism to log and monitor these is the Impediments backlog, or Issues or Blockers list.
Each team member has a specific opportunity to identify impediments during the daily Scrum meeting. It is improtant that specific blocked tasks or features, along with more general problems that have been identified are made visible to all. When there's a problem, write it up on the board. Making problems explicit encourages us to deal with them; If it’s not visible it can’t be a problem.
The Scrum Master is charged with ensuring impediments get resolved, taking pressure off the team so that (as Don Reinersten comments) they can feel “If you’re going to worry about it I won’t!”. The role of the Scrum Master should be not just to own and remove these impediments (where practical), but also to diagnose problems, ensure the implementation of countermeasures and assess their effectiveness.
Why wait till the retrospective to look at problem solving for any impediments raised during an iteration? Why not look to continuously Improve organisational policies and procedures. All too often Scrum teams look for local project optimatzation and then teams have to re-learn when a ne w project comes along. While it is good to remove a problem, it’s even better to prevent it from occurring again; even it’s for another team.
Problem Countermeasure board
Mary and Tom Poppendieck suggest using a Problem Countermeasure board and putting this next to the visual control board for the team. By doing this we can extend the Impediments backlog and enable a leaner approach to continuous imrovement.
The following is Problem-Countermeasure board columns are based on the work of Jason Yip
Fig 1: Problem Countermeasure Board column headings
Whenever someone identifies a problem they should:
- write it on the board, along with containment or workaround if problem cannot be resolved immediately
- put a block symbol on the team board on the associated task or feature
- date stamp when it first occurred
- find an owner
If an Issue stays around for too long it has a nasty habit of causing problems throughout the whole system, the blocked area also becomes the bottleneck for our system and constrains the flow of work.
Each time the problem re-surfaces, update the Problem-Countermeasure board. Add a flag to indicate it has impacted the team again and by how much time. This approach:
- quantifies the impact of any impediments, along with effectiveness of their associated countermeasures
- validates actual impediments and eliminates those which do not actually exist (but that we though did !)
- prioritises the impediments which are having most impact upon the team
Fig 2: Problem Countermeasure Board content decscriptions
The key focus is to identify what is the root cause of the problem,(e.g. using 5 whys but never stopping at an individual) how can you ensure it will not occur again or manifest itself elsewhere. Don’t close a problem until you have checked the impact of any countermeasures that have been implemented.
Don’t get stuck in a time loop and solve the same problem over and over again, ensure you find the root cause of your problems and implement preventative solutions in a timely manner so “new” impediments don’t give you a feeling of déjà vu…
Jean Tabaka at a recent Wellington APN session, showed us the importance of understanding what agile Practices we've implemented. But more importantly how do we know which Practices to choose, or even for that matter how to improve upon them? This is where we should engage in the notion of guiding Principles. But why are the Principles there? What is the organisation looking to achieve through lean-agile? What is the Goal we are looking to Deliver upon? Practices by themselves are not enough.
Ash Mauraya states that we should separate principles from tactics "Principles guide what you do. Tactics show you how." The definition of a Principle is “a comprehensive and fundamental law, doctrine, or assumption”. That is, it gives us guidance on how to act. Yes it can be broken, but we need to know that there are consequences of doing so. The Definition of a Tactic is “a device for accomplishing an end”. Now that to me is a Practice; a repeated or customary action, the usual way of doing something; a means to an end.
There are 7 Lean Software development Principles (these are the Principles that I use) as defined by Mary and Tom Poppendieck, but a plethora of agile practices, what we need to understand is when and why to use them. As Alan Shalloway points out Principles apply in all contexts, whereas Practices apply only in certain contexts.
The important thing is don’t implement a practice without having an understanding of the Principles that underpin it. Yes Implement an agile framework and set of agile practices, but select and modify them to fit the context of your organization. Use Principles to guide you in what Practices to use. Don’t be part of a Cargo Cult, using a Practice to achieve your goal, without understanding what those practice are.
The following table outlines the 7 Lean Software development Principles, as defined by Mary and Tom Poppendieck. For a full description of these, check out their website and books. I use the mneumonic “D E L I V E R” as a mechanism to teach and remember them.
Fig 1: Seven Lean Software Developmnet Principles as defined by Mary and Tom
Poppendieck with the DELIVER mneumonic
Remember, agile Practices are only tactics there to support underlying Principles, that in turn DELIVER on a Goal. Don't be driven by your practices, use them given the context or your organization. Always stick to your Principles !.
The concept of a Working Agreement has become common place within agile teams, but what is it? Why is it important? Who is the agreement between?
For a team to work:
- they need to be committed to the success of the whole - have a Goal
- they need to subscribe to the concept of collaboration and co-operation – subscribe to a set of localised working practices
- they need to be accountable to other members and a wider organisation (context) – work to an agreed set of policies and procedures
To achieve this, there are three aspects that need to be considered; a Goal, the Working Agreement itself, and the supporting Policies and Procedures.
You need a Team and the Working Agreement is about creating a team culture; a mutual commitment and reason for individuals to work together to reach a common goal, for a common purpose.
The Goal is the focus for the team, the reason it exists. It should be understood by all and displayed for all to see. Without a goal or purpose, you don’t have a team; you have a group of individuals, that’s sub-optimisation.
The Working Agreement
By definition an agile team has a high amount of daily interaction. This brings out a need to establish a common set of rules that all the team members abide by. A Working Agreement fulfils this by helping a self-organizing team to establish and codify behavioural standards on how they will work together; without having them imposed from the outside. It is as Jean Tabaka notes, a team’s declaration of it’s self governance. If you don’t get this agreed it can result in conflict through tacit approval that a particular behaviour is acceptable.
Israel Gat defines some Key attributes of a Working Agreement for the Team as follows (to which I have added a fifth item):
- Created and changed by mutual agreement (i.e. the Team members)
- Enforced by mutual agreement
- Outside of an Organisation’s agreed policies and procedures
- Made between peers
- Exists for the life of that Team
XP defines a Working Agreement during the Project Charter phase, establishing how the team will work together as effectively as possible given the constraints of the project. This includes Practices and Standards.
The Policy and Procedures
But, if a Working Agreement sits between members of the team there is a gap. Is a Working Agreement by itself enough? How effective is a Working agreement when it is simply a set of written comments agreed between peers, when the wider organisation has not been included? What about a Social_contract, an agreement between the team and its encompassing organisation; with management, or between the team and business. i.e. the Team will undertake xyz in return the Product Owner will commit to xyz and Management will commit to xyz.
The Working Agreements should focus on the team. But that does not mean we should be insular and exclude management. Kanban makes the Policies and Procedures explicit - we are including management and creating a Social Contract which fills that void; in effect it becomes that Social Contract.
(N.B This is where I differ from Israel Gat in that I believe his Social Contract example should be applied across the Working Agreement and Policies and Procedures. He has some great material on Working agements.)
What should be in a Working Agreement?
Here is some example working agreement items that I have used in the past, this includes team interaction. I've tended to break technical practices and coding standards into a seperate set:
- Update team board before the daily stand-up
- Be present for a core set of hours: 10am to 4pm
- Communication in this order: Face to face, phone call, Instant Message then email
- Publish phone numbers and open and share calendars
- He/she who breaks the build fixes the build !
I find it very important to include the Product Owner availability in my Working Agreement. We need to extend the Working Agreement to get commitment from them as to their availability and what the team expects from them. (I don’t want a full time product owner but that’s the subject of another blog...).
- Product Owner availability (contact details, availability, attendance in Daily Stand Up)
The key thing is include the Product Owner in creation and agreement of the Working Agreement. They are a key member of the team.
I used to include in a Working Agreement Policy items, specifically WIP Limits ‘Work on only one item at a time, but if you are blocked, then work on a second item'. I realised this should become part of an agreed policy and procedure. By limiting WIP in a Kanban approach we can visualise this on a Team Board. The agreement to not over commit the Team needs to include management. To ensure they do not introduce additional work outside an iteration, or break agreed WIP limits, they need to understand the implications of their decisions and have brought into that Social Contract.
Jean Tabaka even takes the Working Agreement a step further, with the concept of Ground Rules. These are for use within meetings and general team interaction (which should include Pair Programming) and include items such as:
- Respect the speaker
- One conversation at a time
- Mobile phones on silent
- Start and Finish the meeting on time
- When Pair Programming, turn off distractions (email, IM)
I have not tended to use these explicitly, but they can be useful for large teams and for posting on the wall each time you have a meeting.
The Working agreement forms part of the social contract and reason for the team working together. The three key aspects as I see them are as follows:
The following is a set of steps to keep in mind as you construct the Goal, Working agreement and Policies and Procedures which will form the basis on how you team will work and interact with the wider organisation.
- Set a Vision and Goal so that the team has a purpose
- Risk Assessment and practices selection for the Team
- Define a Team Working Agreement and post it on the Team Board
- Agree between the Team and the Organisation (Management and Business) a set of Policies and Procedures. Make the statement “We have an Agile development process and we all agree to adhere to it”. Management and the Business must sign up for this and see the implications of any decisions that they may make
- Publish the set of Policies and Procedures on the Team Board and make them explicit for all to see and adhere to. This is your Visual Control.
- At the far right of your board, should be your Team’s agreed Goals; that’s why you’re doing what you’re doing, isn’t it?
- Define Definition of Done and Definition of Ready: we need to know and circulate how we expect things to come into the process and how they exit
- Inspect and Adapt. Review your Working Agreement and Policies and Procedures as part of your Retrospective.