By Graeme Frost, CEO Brilliant Software
Lean development isn’t new –it is just a new label for what highly innovative development teams, often in startups, have always done. Why is lean development vital now? Because industry desperately needs it. Historically IT systems usually focused on driving efficiencies, especially in accounting and manufacturing. But now the focus has moved to customer engagement and if a business can’t give customers the online service they now expect then someone else will. In this high velocity world the old software development methodologies just don’t cut it any more. Companies need new systems now. Oh, and it needs to be much more cost effective too.
A well-documented reference for lean development comes from two developments for systems that fulfilled essentially the same requirements in two states of the US. Florida and Minnesota both developed Statewide Automated Child Welfare Information Systems. Florida started their development in 1990, it was estimated to take 8 years and cost $32 million. In fact it was finished in 2005 and cost $230 million. Minnesota started their system in 1999 and finished in early 2000 at a cost of $1.1million. Not only is that a cost difference of over 200:1 – Minnesota had the business benefit of the system in under a year rather than in 15 years.
We see the same thing in our business. Often a price for a “big name” software company will be 5 to 10 times (or more!) what we deliver for. These are the cost savings that is available from using lean methodologies.
So what are the principals of lean development? As you will know lean manufacturing was invented by Toyota, and revolutionised the car industry…and most other manufacturing since then. The principals also apply very well to manufacturing software.
Eliminate waste
Waste is anything that the customer doesn’t perceive adds value to the product. Old school development methodologies specialise in waste, with piles of documents customers don’t understand. Software is then laboriously produced according to specification and then when it is delivered sometime (possibly years) later the customer discovers that the system doesn’t do what they needed then and certainly not what they need now. They then go into a change process which takes months or years and costs another fortune.
In the Lean methodology there are two phases in a development project that add value – analysis and coding i.e. finding out what the customer wants and then developing it straight away. Anything that gets in the way of that is waste. Software defects not discovered quickly are a major source of waste. The way to reduce the waste due to defects is to test immediately, integrate often, and release to production as soon as possible.
Amplify learning
Somehow, the idea that variation is bad has found its way into software development, where people have tried to develop standardized processes to reduce variation and achieve repeatable results every time. But development is not intended to produce repeatable results; development produces appropriate solutions to unique customer problems.
Rather that producing a huge functional specification that no customer fully understands, we quickly create a wireframe prototype that focuses on the user experience. As well as showing how the data is laid out, all the buttons and links work, so the users get an excellent feel for the system flow. A lot of new ideas are formed using the wireframes. We then start development and show them frequently where we are up to. By frequently I mean every 1 -2 weeks. Not only does this iterative approach give them the opportunity to correct our misunderstandings, it gives them the opportunity to hone their thinking and implement changes and their new ideas in the next iteration. The end result is that they get a system that actually does what they need rather than necessarily what we thought they initially asked for.
Using old methodologies we may celebrate that we have delivered exactly to specification “on time on budget” but that often counts for zip in delivering actual value to the customer.
Decide as late as possible
For complex systems this is particularly valuable. Decisions on the detail of how some parts of the system will work can be delayed. The advantage of this is that the decision will usually be easier and better when made in the context of what has already been developed, especially for the customer. This can’t be used as an excuse for procrastination though – if the developers can’t get a decision when they need it the waste time.
Deliver as fast as possible
Customers are smart enough to know that if you deliver software quickly there will be some mistakes. The advantages to them in the rapid development process are huge so they don’t mind at all, especially since the mistakes are identified and fixed so quickly. The shorter the feedback cycle the more that can be learned and the better fit the delivered system will be.
Empower the team
Great execution depends on getting the details right – and no one understands the process as well better than the people who actually do the work. Technically experienced managers, or more so managers who haven’t “been there, done that”, have to resist the temptation to tell their teams how to suck eggs. When equipped with the necessary expertise and guided by a leader, working to a schedule they came up with, they will inevitably deliver their best work.
Build integrity in
The art of software development is delivering exactly what the customer wants in such a way that it all works together very smoothly and it is going to easily adapt to what they want in the future. This depends on good foundations – and in software that is largely the database design. It’s a bit like getting the foundation right before you build a house. If it isn’t right then it’s always going to be a pig to fix it – whereas changing rooms around etc. is relatively straight forward. A good software architect will instinctively design a good database based on the detail of the first bits and an overview of the whole system.
See the whole
The initial wireframes are important so that everyone understands at the whole picture. At least some of the detail will probably change but the overall framework usually won’t. This is important from a software architectural perspective.
OK, that sounds smart – how do I implement it?
The concept of lean development is far from new, and it is now in use around the world. It’s pace has been slowed by well paid consultants that have a huge vested interest in the status quo. They will likely say lean development is just too higher a risk for mission critical systems.
How can something where the customers (or users) are an integral part of the development process possibly be higher risk? The example of Florida and Minnesota says it all. One state had a system after 15 years – one after less than a year. If Florida were running a business where the system was critical to their competitiveness – they wouldn’t be around anymore.
If you are new to lean development, probably the best way to get started is to bring in a team experienced in developing software in that environment to develop an individual module. Typically companies are looking to develop customer engagement type systems that are ideal for an iterative approach.
Graeme Frost is CEO of Brilliant Software Limited. Graeme has practiced the lean methodology (without necessarily having that label for it!) for over 25 years. One of the systems he managed the design and development of under that methodology runs the practice management for the largest law firm in the world, operating in over 30 countries.
Acknowledgement:
This article is largely based on a reference book: Lean Software Development: An Agile Toolkit: by Tom and Mary Poppendieck, published by Pearson Education. I recommend this book if you want to understand the methodology more.
