I spent some time at the Government Digital Service last week and saw at first hand the race to launch the GOV.UK website on 17th October 2012. Much is talked about the value of using the Agile methodology to develop the software. However to my non software developer eyes there was a familiarity to the work and the approach. I began to realise that Agile, a recent product of the software development industry had a great deal in common with Lean systems. Messrs Ohno and Demming would definitely approve of the way GDS are working. Just how similar are the two methodologies? The Agile manifesto says;
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Jeffrey Liker, in his book The Toyota Way writing about Lean systems, talks about 14 principles which are;
- Principle 1: Base management decisions on a long-term philosophy; even at the expense of short-term financial goals
- Principle 2: Create a continuous process flow to bring problems to the surface.
- Principle 3: Use “pull” systems to avoid overproduction.
- Principle 4: Level out the workload (Heijunka). (Work like the tortoise, not the hare).
- Principle 5: Build a culture of stopping to fix problems, to get quality right the first time.
- Principle 6: Standardized tasks and processes are the foundation for continuous.
- Principle 7: Use visual control so no problems are hidden.
- Principle 8: Use only reliable, thoroughly tested technology that serves your people and processes.
- Principle 9: Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others.
- Principle 10: Develop exceptional people and teams who follow your company’s philosophy.
- Principle 11: Respect your extended network of partners and suppliers by challenging them and helping them improve.
- Principle 12: Go and see for yourself to thoroughly understand the situation (genchi genbutsu).
- Principle 13: Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly (nemawashi).
- Principle 14: Become a learning organization through relentless reflection (HANSEI) and continuous improvement(KAIZEN).
Crash these things together the leadership challenge is to answer these questions;
- Are we designing around customers, only doing things that have been asked for?
- Are we recognising flow and quickly changing the stuff that doesn’t work?
- Are we doing simple stuff that actually works?
- Are we being transparent about our problems and managing them in public?
- Am I providing leadership that enables rather than distrusts my team members
- Do we believe in what we are doing?
- Are we reflecting and learning?
- Are we moving at a pace we can sustain, and improving daily?
Given that today’s operations are so intrinsically linked to software applications we need to aim to manage our business in line with all of these principles, answering the leadership challenge questions in the affirmative. Talking about Lean systems with an IT team that are working with Gantt charts, or an Agile team working with a business looking for tight ‘clear plans’ just isn’t going to work.
Looks simple, hard in practice, but certainly worth the effort.