Lean is based on the principle of creating true value for the customer and meeting his real, rather than perceived, needs.
I’m getting lazy – too much over-analysis is never a good thing. Much better to understand the foundations, then let things happen, rather than chasing them down a rabbit hole. I am talking Agile, of course, and my decade of learning. Though in hindsight, it is difficult to pinpoint any real point of thought-revolution. Even now, I think this is different … but the same. In fact, most software engineering principles outlined decades ago still make a lot of sense. As with anything, it’s about packaging and marketing.
With the word “methodology” rolling off so many tongues these days, you would think we all have a grip of what is happening in our own industry. But too often they are hijacked to the point of being fashionable. These methodologies belie the hidden long-standing problem in software development, that they at the same time try to address – communication, openness, and well-observed development process. People are always the problem when applying process, and the larger the company the harder it becomes. Agile and Lean methodologies are aiming for better efficiency in development and management process. But this takes effort and consistency, and understanding some basic rules, not just the easier or more appealing ones. To do this is to compound your problems by simply avoiding dealing with them by methods of distraction.
No soon as I start get a true grip on Agile, then along comes Lean. There are 7 key principles of lean software development:
- Eliminate Waste
- Build Quality In
- Create Knowledge
- Defer Commitment
- Deliver Fast
- Empower People
- Optimise The Whole
Lean software development has been around a while (and frequently coupled the Kanban for project management). On the surface it appears very similar to Agile ethos, though no real roles as such – except assumption of competent management, and the importance of being able to trust your team. The similarities are not surprising, as software engineering is an evolutionary process – building on top of lessons learnt, the. Agile methodologies contain a lot to appease older-fashioned business emntality, as business is the slowest of all to catch up with IT development advances. And business inherently mistrusts change, unless it is sold well – and herein lies problem. Lean development shares a great many great principles with Agile, but has added elements of speed and cost-effectiveness at it’s. There is also no concept of interations in Lean – it’s a continuous process.
This is not for the faint-hearted or companies that barely have a grip on Agile yet. If you are struggling to incorporate Agile into your company, or things like Exploratory development or testing makes people nervous, then Lean will be a big challenge. Scared about Exploratory testing? How about Exploratory development? There is never one solution to any given problem, but you can identify the best solution for you particular project. As long as you treat the experiments in the same way you treat backlog tasks, you can ensure nothing is too far compromised by experimentation. In extreme Programming, there was something similar with Spikes. Spikes are an approach to more complex tasks, that present a challenge, either in coding or integration.
Don’t be fooled by the simplicity of Lean principles, as it is takes some time and forethought to make sure you get the best out of them. Lean is less about pandering to business neurosis, and embraces them closer to the action, because at it’s core is elimination of waste (work that adds no value to a product). But it can still be oversold and under-implemented. Just as business were getting their heads round the idea of changing their perceptions of milestones and requirements management, along comes Lean philosophy doesnt work to concepts of iterations, sprints or releases (which business could at least process in an old-fashioned way). It’s all down to task management – it’s a continuum where instead of pandering to fixed-term development cycles, which only exist as that seems to be still the only ways for business to manage client expectations. Or so they think.
One of the founding Agile principles is engagement from the client, and if this is exercised, you will find that clients are less worried about formal milestones and more focussed on actual progress. Sure, there are timescales and delivery dates, and if the client is properly embedded in the Agile/Lean processes, they will have ongoing window. Senior management needs to agree and discuss their Lean vision – making such decisions as whether to keep existing Scrum in place for project management, or replace with Kanban (or combined), or simply incorporate Lean principles into your existing project management approach. If pure Kanban is applied for project management, then a strong Scrummaster is essential to prevent the business demands compromising the WIP rules.
The weakness in Scrum was in it’s reliance on iterations is the task management structure, rather than continuum of work-in-progress. It didn’t have to be a weakness, if development was observing continuous build/integration/test cycles on feature development (Agile and Lean IT principles), and continual review&improve evaluations (be it code, or business process). The largest benefit I see for business, is that the Lean and Kanban approach demands good planning and management skills. A bad Scrummaster is hard to identify, as largely they will be performing according to the working culture. If adopting a Lean approach, then if the roles are not fulfilling obligations, the process will quickly fall apart. Using Kanban to project manage, these problems can be highlighted sooner rather than months into a project. How you deal with these problems is down to you, but problems needs fixing either by change or removal.
Failure, bad – Change, good. Change is definitely seen as a positive in business, but it needs to be sold – and Agile has presented a number of ways to do this with many positive and affirming principles. But instead of embracing this spiel, someone should be asking “Yes, but how are going to implement this?” “Who will ensure the change progresses smoothly and consistently across the business?” “How can we monitor progress of projects in this new system of working?”. There are many questions that should be asked, as you do not want to be going Agile without a plan – and a good one! Don’t fall into same trap with Lean – promote it’s strengths, but also weaknesses and the plans you have to cover those. It is important to get across to their business about levels of involvement necessary from them. Develop your own approach, based on Lean principles – every company has their own values and culture, and what is counted as waste in one company may not be in another.
The Lean principles are simple, but we are dealing with people, all with differing temperaments and skills. There may even being a developer or tester in the team already destined to cause huge delays further into the projects. You cannot predict everything though, and this can always be worked with what you are given. Point 6 is also often referred to as “Respect People”, which sounds a little woolly – maybe that is just me, but I do not understand that people would need that directive in a methodology. Empowerment entails respect as many other people-management skills. These are great icentivising phrases that business will like, and provide a good high-level remit for management and the team (who, incidentally must understand what those phrases actually mean!).
Nodding towards Agile/Scrum/Lean/Kanban is far from enough – it might be enough to stave off a project being pulled by the business, but that’s all it will do, delay the inevitable. Its really workable, as along as you set rules in place, processes as framework for things to happen, and good continuous build/integration/test development. But you have to stay on top of it – this all takes more effort to start with, but will become well-oiled development machine over time IF you stick with the principles.
Related posts:
