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.
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