Lean software development is one of the latest hot topics at strategy consultancies like McKinsey. A report conducted by McKinsey dubbed "Applying Lean To Application Development And Maintenance," says implementing the approach can lead to productivity gains of between 20% and 40%, and that quality and speed of execution can improve markedly within a matter of months. Both valuable benefits when the cost of developing and maintaining applications now accounts for about 50% of the average IT budget - a figure that is set to rise in the future.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
So, on the surface of it, lean software development sounds like a boon. But what is it, where does it come from and how realistic is it for most organisations not only to go down this route, but also to achieve the promised improvements?
Adrian Wakefield, IT director at sealing products and services company James Walker, which has adopted lean management, describes lean as "an approach for minimising waste by the obsessive reduction of non-value-added processes to speed efficiencies".
The concept was originally developed by Henry Ford in the 1920s as a means of preventing overproduction, while at the same time improving response times to changing customer needs.
Lean manufacturing principles were later incorporated into software development and eventually morphed into the Total Quality Management strategy, with its focus on measurement and documentation. However, the concept of lean product development is a somewhat newer concept.
This branch of lean was developed by Taiichi Ohno, the father of the Toyota Production System, in the 1950s. Rather than focus on manufacturing, his goal was to manage the design process more efficiently, and from the early to mid-1990s his ideas were taken up and applied to development, manifesting in methodologies such as Scrum and Extreme Programming.
But in 2003, the concept was taken a step further by Mary and Tom Poppendieck when they wrote their book "Lean Software Development - An Agile Toolkit For Software Development Managers".
This laid out seven principles behind lean development and provided 22 toolkits or best practice guides to underpin them. These principles are to eliminate waste, amplify learning, decide as late as possible, deliver as fast as possible, empower the team, build integrity in and to see the whole.
But Fred George, vice-president at custom applications supplier ThoughtWorks, says there is still a lack of understanding as to what lean really is. "We are seeing very little awareness of lean, and a lot of people think it is a new concept following on the coat-tails of agile. However, agile is an engineering method by which code is written, and lean is the process by which to do it, and they dovetail into each other. So there is a broad misunderstanding of what they are and how they differ," he says.
Moreover, because lean and traditional waterfall methods of development come from very different philosophical places, they can be badly mismatched, which means that organisations are likely to encounter difficulties if they try to combine the two.
Jon Collins, service director at Freeform Dynamics, explains, "With the waterfall model, the idea is to design, create and implement, so the assumption is that the specification is fixed in time and space and is unchangeable.
"But if you look at areas such as business applications where there is often a lot of change in line with business requirements, there have to be mechanisms to build in change from the outset, and that is what lean aims to do."
The secret behind this lies in eliminating bottlenecks in underlying development processes and tightening up the feedback cycle. So the focus is on optimising how long it takes to turn something around, rather than on finding ways to deliver set products to a set time scale, which is quite different.
"So if someone is waiting to do something, you measure the wait time and ask why they are waiting. When you focus on the cycle time, amazing things can happen," says George.
This means that lean principles can be applied to any process in the IT department and the business as long as it has a clear feedback cycle.
And this was certainly the case at James Walker, which started its lean journey in 2004. "The big question is how to avoid just digitising your business and ending up being locked into processes that are out of date. So we started thinking heavily about how we could apply the lean toolset to our overall project methods," says Wakefield.
This saw the organisation turn to the Manufacturing Institute for best practice advice and subsequently also to Oracle, which set up a Lean Leaders' Circle in November 2006.
These organisations helped Wakefield understand how to apply lean principles. The basic premise is simple, says Wakefield. "You look at existing processes first in a big picture or holistic manner, because if you do not you can end up producing sub-optimised or fragmented solutions that do not address the whole process."
However, he warns that it is necessary to "Analyse weaknesses not from the top down, but using a bottom-up engaged approach by getting the business to understand the issues. Then you look at how you can design processes better and improve those that have been raised as a concern."
This is necessary because systems and processes are organic in nature. As a result they can, over time, end up being more complex than they need to be, which in turn generates waste, so it is important to understand which are important or are not, says Wakefield.
But such activity involves a lot of planning in advance, and also in some instances a reorganisation of the IT department. James Walker moved to a central services model to make it easier to introduce common processes. It also moved from operating profit and loss centres to a matrix system, to promote more synergy and to focus on the customer better, says Wakefield.
Another key factor was to engage stakeholders in the process, which involved obtaining senior management buy-in. When looking at how to initially introduce common processes across its five smallest businesses, Wakefield ran about 10 workshops, each of which lasted between two and four days and included between 10 and 14 people, including IT staff. This equated to about 50 man-days of work.
"I work for the chairman and am the peer of most of my senior operational colleagues, but initially it took a long time to demonstrate to them why we should be doing this and for them to see the benefits. Senior management support is an old message, but you want the business pulling a solution out of IT, not IT pushing a solution on the business or you get a push-pull disconnect," says Wakefield.
It is this need to change behaviour that is by far the most difficult thing to introduce and embed into the organisation, whether on the IT or business side of things. "It is not practical to deliver too much change too quickly. There has to be some pragmatism involved because this is not a one-off process. It has to be part of a continuing philosophy as to how you introduce business systems," Wakefield says.
This means that, while it is useful for an organisation to define a blueprint of where it wants to go over the next five years, this is likely to change and adapt over time, both with circumstances and experience.
Wakefield believes that James Walker is currently about halfway through its lean journey, and the firm is about to embark on the next step of improving what it now has in place.
George, meanwhile, agrees that a radical shift in thinking is required to make lean work, with one of the biggest sticking points often being the attitudes and fears of project and other middle managers. "The question for them is that if they are used to schedules and milestones, how do they manage the team?" he says. This is not least because lean necessitates changes in how personnel operate and also, in some instances, in their roles.
"Traditional methods measure resources and say that while it may take five times as long to get things out, at least staff are all being used. But lean says that is a bad idea, and rather than worry about the local utilisation of resources, you need to train people in multiple skills so there is always something they can do," George says.
The idea of poly-skilled workers means that, for example, although an individual may not be the best tester or designer in the world "they are good enough and can handle the situation no matter what occurs, which is very valuable", says George.
Such a shift involves training and working closely with pockets of resistance, initially by using pilot projects to help staff understand the benefits to themselves and the organisation. Good communications are key to getting this right from start to finish.
David Norton, a research director at Gartner, confirms that adopting lean can require quite a radical organisational change.
"If organisations have rigid prescriptive lifecycles, with fixed dates and restrictive ways of working, trying to look at the value stream moves people out of their comfort zone. So those that could benefit most often find moving to lean the toughest," he says.
To date, he indicates that about 30% of large multinationals are exploring the concept, although active implementation is only taking place in about 5% to 10%, with manufacturing, financial services and petrochemicals companies leading the way.
"I think that within about five years, most CIOs will be aware of lean and will deploy the principles in some fashion. But it is an area that is ripe for consultancy as it is not just a matter of downloading a specification and implementing it.
"Organisations need to understand the principles and interpret and apply them to their own processes, which means that it is up to them to do most of the hard work," he says.