“Well, in our country,” said Alice, still panting a little, “you’d generally get to somewhere else – if you run very fast for a long time, as we’ve been doing.”
“A slow sort of country!” said the Queen. “Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!”
This episode, called the Red Queen’s race, has been used as a metaphor in, among other subjects, theoretical biology and marketing. In the third millenium, it is a metaphor which concerns us all; no matter which pursuit you choose in life or in business, the world has become a big race.

.
Career in multiple countries

Dr Jan Bosch is professor of software engineering and co-director of the software research center at Chalmers University Technology in Gothenburg, Sweden and an adjunct professor at the University of Groningen (NL). Formerly, he has held executive positions at Intuit Inc and Nokia Research Center. His research activities include compositional software engineering, software ecosystems, software architecture, software product families and software variability management.

When talking with Jan Bosch, Professor of Software Engineering at Chalmers University of Technology, the message is straight-forward and precise. Through a distinguished career in the Netherlands, USA, Finland and Sweden, working both in industry and academia, Jan Bosch has attained an unmatched overview. His observations could be summarised by paraphrasing the singer Leonard Cohen: “I’ve seen the future, brother: it is swiftness.”
“The biggest, biggest trend right now is a shortening of the feedback system. There is a general need for speed,” says Jan Bosch. “It is your readiness to minimize the feedback loop that decides whether you are going to succeed or fail in the marketplace.”
To Jan Bosch, innovation resulting from “struck by lightning moments” belongs to the past. The innovative companies of the future do not need developed, integrated ideas. Instead, they just need to analyse the customer’s feedback, come up with suggestions on how the company can move forward in the market and then start experimenting in a structured manner. This is also useful for embedded systems, where you can apply the same feedback loop to improve, for example, fuel efficiency in a car, throughput in a telecom system or throughput in a high-performance computing system. Step one: implement. Step two: measure. Step three: replace, drop or improve. Next cycle, please!
The hard currency in Capitalism 3.0 – where only companies focussed on customer needs will succeed – is of course user information from millions of users. If you have a feedback system where you can dynamically test customer behaviour, you have the strongest possible opportunity to move faster than the rest. You don’t need to dig deep, explain or analyse – just use an A/B testing or some other method where comparing is simple, and then start crunching numbers. Google has been ridiculed for testing “500 shades of blue” to find which one generates the most clicks, but apparently they were the ones to laugh all the way to the bank as rumour says that they managed to generate millions of dollars in additional revenue from this …
It seems that these insights promptly need to be communicated to the Scandinavian industry. The need for speed will affect all business areas – not only the traditional software companies. The ones that don’t shift gear to remain where the value is generated, will be left in the dust.
“If we don’t get it right, others will use our platform for their services,” Bosch says.

.
How can Lean & Agile methods help Scandinavian industries to remain competitive?

We have to remember that Lean and Agile methods are means to an end and not goals in themselves. Companies improve their competitiveness by more rapidly responding to requests from customers and by testing their own innovations with customers. The shorter the feedback cycle, the quicker companies can respond to customers and the faster companies learn what innovations generate interest among customers.

.
Which other organizational tools are useful to shorten the feedback loops?

Traditionally, organizations have relied a lot on processes to define the interaction between functions and individuals in their organization as well as with others in their value network. We now see that companies are moving toward small, multi-disciplinary, crossfunctional teams that own the entire process from identifying a customer need to delivering the solution to customers. One of the important techniques that companies use is to put the solution in the hands of customers while it is still under development. The feedback from customers is then fed back into the R&D process and steers the prioritization and implementation of features. In general, the goal is to minimize the amount of R&D investment between customer proof points.
.

Are there any new tools in the making which seem promising?

One of the important trends is that 
in the near future all products will be connected to the internet, ranging from your car to the appliances in your kitchen and the consumer electronics in your living room. Ericsson, for instance, often talks of 50 billion connected devices. That offers three important advantages. First, the software in these products, which is a constantly increasing part of the R&D cost, can be updated even after the product has been sold. Second, connectivity allows the product company to collect all kinds of data from the product as it is in use, including usage metrics, performance, safety and other metrics. Finally, the ability to measure and to push new software to products allows for A/B testing even in embedded systems. In a world where products are increasingly turning to services, these tools are becoming mandatory and necessary.

.
How do we coordinate and align the different levels – individual, team and organization – in this process?

In many domains the age of the top-down steered hierarchical organization is rapidly coming to an end and the role of management is changing quite fundamentally. Successful organizations are starting to organize themselves as ecosystems of activities performed by self-selected and self-directed teams. These teams even manage themselves based on quantitative output metrics. The role of management is now to define the right metrics that cause optimal alignment between team performance and business performance. Second, in the areas where metrics cannot be formulated well, the role of management is to build the right culture in the organization.
For the individual, there are two important implications. First, the ability to choose the team that you want to be part of is exciting and very liberating. Secondly, the fact that you have to have a proactive self-starter attitude rather than waiting for someone to tell you what to do is very important.

An every day situation:
“Where the heck are those test data for this module?”Sam asked.
Silence in the whole office, nobody seems to have them.
“Did we request them from the client?” he asked this time.
More silence.
“And by the way, did we order SubSoft to assist us this week? I haven’t seen them this morning. And where is the test version from HardCore on their damned new gadget?”
A sigh from the corner – but no answer.
All of a sudden question upon question comes up, and the whole developing process comes to a grinding halt. Waste of time all over the place.

This is an every day situation which we can all relate to – nothing out of the ordinary. Sometimes you may also hear conversations like this one:

“I think we should take into account that two sprints from now we are going to add x functionality. Let’s already now make sure we can easily integrate it into the architecture.”

“No – you should not think of that now. We are not supposed to do that in Agile development. Let us cross that bridge when we get there.”

Planning Ahead

It is definitely true that software can be over-engineered and be configurable to handle all kinds of more or less probable enhancements in a distant future. But it is equally certain that it has never been the aim of Agile development to make teams behave more stupidly than they actually are by deliberately ignoring knowledge that is available to them and to make precautions in due time. Teams with this approach are faithful to the letter of Agile methods but not to their intent. They can be compared to a group of scouts going on a hike who, when they start, know they will have to cross a river some time later on the trip. However, when one guy wants to bring some rope the others tell him to leave it at home, because “when we get there, we will find a way to cross the river”.

Anti-planning Syndrome

More of something good is not always better. That holds true for most principles in software engineering. “The simplest thing that can possibly work” does not mean “Ignore everything you know” but rather “Do the simplest thing that may possibly work” (in the context of your current knowledge).

Overdoing this principle can lead to the “Anti-planning Syndrome” which can sometimes be seen in Agile development. We have recognized that Big DETAILED design upfront BDDUF is not good, because we can’t oversee the complex nature of the problem anyway. But that does not mean we should not spend enough time to understand the core of the problem and design at least the outline of a solution we are going to apply, before diving in and starting to write code.

Doing it Right

So how much planning is optimal? One way to look at it is this: if your team are routinely modifying what has been planned in detail, then you are planning too much, too early. If, on the other hand, they routinely have to redo work or get stuck halfway through a task because they miss information, decisions or deliveries from others, you are planning – or rather preparing – too little.

There has been a lot of emphasis on “Done”-criteria and making work really “done-done” in the Agile team process. The other side of the process, “Only working on stuff that is really ready”, has not gained the same attention, even though the consequences of starting work which is not ready is at least as costly as not delivering work which is not really done.

Putting backlog grooming to work

To avoid the waste of starting work that cannot be completed, you may have to implement a process that will ensure that only ready work is undertaken by the development team. On a number of occasions we have implemented the Make Ready Process in Agile teams, to help them bring the stuff they need to cross the river.

The Make Ready Process consists of a process similar to the development process in Scrum and other Agile processes. Make Ready starts with loosely defined user stories or other forms of functional requirements and ends with user stories ready to work on. The process is aimed at giving maximum speed in development, so when a user story is actually ready to be started, it is most likely to be completed in the current sprint.

Guidelines show the way

Bent Jensen is Director and Consultant at the Danish agile consulting firm BestBrains. BestBrains primarily helps software companies implement faster and more effective ways to create software with a Lean and Agile foundation.

The criteria for when a user story or a task is ready to work on, will differ from project to project. However some guidelines can be found in looking along the streams which feed the flow of work and make the work packages “sound”. By a sound work package we mean a task that is in good shape regarding:

Dependencies
Is there any development work that needs to be completed before this should be done? Do we need to coordinate with other teams?
Skills
Do we have the skills on the team to complete the task?
Space
Can we actually get to make the change. What is the state of the code we are looking at?
U.X designs
Does the User Story have an associated U.I design and workflow?
Stakeholders
Is there anyone that needs to be informed and involved in this user story that maybe later can disapprove?
Work ahead
Is there anything coming later that this development work needs to take into account?
Following work
Are the receivers of this work in place and ready to receive it?

Stuff ready to work on

Sven Bertelsen has worked for 40 years as consulting engineer and project manager and has been partner in NIRAS for 25 years. Today he is an external lecturer at the Danish Technical University as well as working as consultant.

In practice this means there is a perspective on the projects that have a range of 4–8 weeks. It is not focussed on detailed planning, but on making sure there is stuff ready to work on when the time comes. And here we are not only looking at previous work but at all the prerequisites for the task – internal and external. By “ready” we mean really ready with no exception or maybe. A smaller group will usually be responsible for the Make Ready process. Someone from the customer side will ensure the needs are well understood. A technical lead or architect will together with developers make sure we can actually do the work in the code. Developers may spend time making a spike to outline a solution. UX designers may work on high-level designs and people from other teams may participate to ensure that work between teams is coordinated.

The Core of Coordination

The group should have joint responsibility and their performance should be monitored. A reliable flow of work is the key to higher productivity, shorter development time and lower costs. The process will usually we supported by a weekly meeting and progress will be tracked on a task board especially designed to visualize the make ready process. Often this process has its home in a development team, but on multiteam projects, the Make Ready Process and associated meetings belong to the overall project and are the core of coordinating several Agile development teams. A general question at all sprint and scrum sessions should be “Is this task ready”, and – if not – “By whom and when will it be so?” More from this inspiring initiative will be coming up in our consultancies and in future editions of Lean Magazine.

Download PDF-version of article: Make Ready PDF (54)

Don Reinertsen at Lean Tribe´s seminar in Lund

Anders Sixtensson: In most of the examples you give in articles the cost of a month’s delay is often surprisingly big (at least for someone who has never done the calculation). Is it often a surprise for those that really make the effort?
Don Reinertsen: There are usually three surprises for newcomers to calculating cost of delay (COD). First, they are surprised at how large the number is. Second, they are surprised at how little time it takes to do the calculation. Third, they are surprised at how much consensus they can reach on the value. All three of these surprises occur because people’s intuitive sense of cost of delay is way off. The intuition of members of the same team typically differs by 50 to 1, so the real estimate surprises most team members. In general we have good intuition about things we have seen more than once. People who have never calculated COD have no basis for any intuition on the subject.

.
In pure software development, you do not usually have any high production costs. On the other hand you have maintenance and bug fixing. In your life-cycle profit model, where do these running and variable costs fit in?
For manufactured products the majority of the recurring cost is the cost of manufacturing which is proportional to the quantity of product sold. Software also has recurring costs that are proportional to the quantity of product sold. For example support costs are typically proportional to sales volume. On the other hand, software also has costs that are relatively independent of the quantity of software sold, such as bug fixes. Both of these costs influence the P&L of a software company, and they should be reflected in any economic model that is used in a software company. It is a solid general principle to have life-cycle profit models keep score the same way management keeps score in their P&L.

.
Technical debt is a term often referred to. Usually this means that previously done work has led to bad architecture, high failure rate, high complexity, etc, which make future development and maintenance even more expensive. In a life-cycle profit model, it could be worthwhile to amortize your debt by refactoring or cleaning up the code etc. Where do these kinds of activities fit into your economy-based decision model?
I do not find that technical debt is sufficiently similar to financial debt to reason by analogy on this matter. Financial debt almost always has to be repaid and the total cost of repayment rises as a function of time. In contrast, there are many cases where technical debt will never have to be repaid, and other cases where it can be repaid at a lower cost in the future than the present. When a developer makes the choice to defer work they are generally doing so to achieve another economic benefit such as earlier introduction. Deferring work may have an economic cost. If this added cost is less than the financial benefit of deferring work, for example the value of early introduction, then creating technical debt is a good economic choice. To correctly model such a situation one should include the one-time and recurring costs caused by the technical debt. In general, although I recognize this is not the practice in the software industry, I prefer to refer to this problem as “deferred work” rather than “technical debt”.

.
Our customer runs a portfolio of projects in parallel and tries to manage this pipeline of ongoing projects in such a way that the pipeline as a whole delivers as much business value as possible over time. If we have a bottleneck and need to sequence a number of projects, first to go is for example Project A, then Project C and finally Project B. This sequencing decision should be based on some kind of accumulated cost-of-delay for all the projects together. Have you used or seen Cost-of-delay as an input to portfolio management? Would it be possible?
To maximize the economic benefit of a portfolio of projects the sequencing of projects should consider both the cost of delay of each project and the amount of time that the project will block scarce development resources. This approach is known as a weighted-shortest-jobfirst (WSTF) queueing discipline and it is discussed in the book, “The Principles of Product Development Flow.” The sequence of projects that will produce the best total return will prioritize projects with the highest cost of delay per unit of scarce resource consumed. This illustrates a key point: in product development we can reduce the cost of delay without shortening average cycle time. We can do this by ensuring that jobs that are delayed the most are jobs with the lowest cost of delay.

.
I have read somewhere that one way to get a better understanding of cost-of-delay could be to imagine the following: “How much would I be willing to pay for a ‘magic consultant’ to solve my existing problem NOW?” So, that price divided by the time difference from NOW until I have solved it myself is really the cost of delay. Could you argue like that?
I would not use this approach. A cost-of-delay calculation establishes the value of time on the critical path of the project. Whenever we pay less than this amount for time we are improving the economics of a project. Let’s say cycle time is worth $25,000 a week. If we can save a week of cycle time by spending $500 to expedite a shipment this is attractive. If we can save the same week of cycle time by hiring a consultant for $10,000 it is also attractive. However, neither of these amounts are the cost of delay, which is $25,000. In general the maximum price you would be willing to pay to maintain a project schedule will be the project’s cost of delay, however using your intuitive sense of a maximum price is a very poor way to calculate cost of delay. This price will be determined by intuition which, as I mentioned earlier, typically can vary be a factor of 50:1. It is much better to calculate a cost of delay

For Åke Sundelin quality issues have always been absolutely central. It began in his student days, when he decided to study engineering at Linköping University, initially with a focus on manufacturing. While his fellow students chose to be educated in saving the environment or making money, his focus was on quality. Åke Sundelin’s own description of quality is, in addition to responding to customers’ expectations, “to create a design that is robust enough to continue working, despite any problems and errors that may arise.”

“Whatever technical system you’re using, you cannot eliminate all errors. The important thing is not to let the errors take over so that they affect the entire architecture,” he says at the beginning of our conversation. It soon becomes clear that he is already touching on one of the key issues in what we are really here to talk about: Lean & Agile projects, size XXL.

Large and complex projects

Methods based on Lean & Agile principles in some form or other have been used within the Ericsson Group for just under a decade. Ulf Hansson, Ph.D. in Communication Theory at Chalmers University of Technology, says the company’s “Lean & Agile story” provides a number of lessons and insights that are becoming increasingly clear – especially when we talk about scale. Here we are referring to huge systems with millions of lines of custom code that have to work reliably for 5 to 10 years and sometimes even longer than that.

Åke Sundelin works at Group Function Technology & Portfolio Management, (~ CTO Office). He is the driver for Product Development Strategy work within Ericsson as well as a change agent and facilitator/teacher for Ericsson’s internal SW leadership training

These development projects are not only large but also multifaceted. Today the group works with hundreds of customers, typically telecom companies with widely differing needs and requirements. These include everything from experienced operators with large technology departments to “greenfielders” in the form of new players with no heavy engineering staff and with completely different expectations of the systems.

“We must have a system for product development that can respond to both types of customer,” says Ulf Hansson. Åke Sundelin also underlines the technical diversity between assignments – everything from infrastructure to applications. It is a broad playing field, where different rules apply in different zones. Some of these rules are formulated not by the customer or supplier, but by international standards organizations.

“It is a huge challenge to manage such breadth. An implementation of Lean & Agile methods that works at one end of the spectrum does not necessarily work at the other,” says Åke Sundelin.

Developing a Lean & Agile structure

Lean & Agile is widely used at Ericsson to increase competitiveness. Ulf Hansson recalls a comment from a happy developer: “Nowadays, we use all our brains.”

Dr. Ulf Hansson, Business Unit Networks, is the Deputy Head of R & D Operations and overall driver for deployment of Lean & Agile ways of working within Business Unit Networks.

But how do you create a sustainable Lean & Agile philosophy in a company of Ericsson’s size? First of all you have to understand the size difference that exists between their own projects and those undertaken by other companies in the Lean & Agile community. When Jeff Sutherland writes about “Scrum for the Big Ones” in Lean Magazine (# 1, June 2007), these are medium-sized projects by Ericsson’s standards.

“Agile methods were born in a small-scale context,” says Ulf Hansson. “It is a simplification to think that you can take a carbon copy of The Agile Manifesto and apply it to a large organization such as ours.”

The starting point of the Lean & Agile-based methodology at Ericsson is – as you would expect – out in the field, among the developers. It starts with small teams with shared responsibility for the backlog, clear “ready” criteria, short feedback loops, continuous system growth, and so on. Nothing unexpected, in other words, and so far, so good.

Upscaling is the challenge

The challenge is to upscale to a large and complex task without increasing the actual volume of the project; rather, finding the right methods to divide the task into smaller parts that together make up the whole. Of course this opens up a conflict between large scale and basic Lean & Agile principles. The challenge for method developers is to reconcile bottom-up and top-down perspectives.

There are two approaches. In the traditional model the task is divided into subsystems or components that are eventually pieced together into a functioning system. Experience shows that this integration step takes a long time and can cause more difficulties than the entire initial work on the components. Instead the aim is to slice the task into parts that are each testable on their own at system level. These parts are developed in parallel by crossfunctional teams and are integrated continuously during the development process. This avoids a long integration phase at the end. Furthermore, testability of components at the system level gives the teams the opportunity to take full responsibility for ensuring that their solution really works. No one outside the team “fixes” the quality retrospectively

Good architecture is everything

Good architecture and continuous work on the architecture is central to managing and minimizing the dependencies which in practice always exist between the teams’ tasks. The teams must understand and take responsibility for how they affect the whole. A simple and well documented system architecture is critical for success; it is based on modularity, it is easy to add and subtract features, and errors “do not rattle through and affect the whole system.”

“It’s easy for developers to embrace Agile practices, but if we do not create the right conditions for them, their chances of success will be very limited,” says Åke Sundelin. “The key enabler we can create for them is to work seriously with architecture and to reduce dependencies.”

“The consequence of inadequate system care leads to the teams unwittingly ‘colliding’ and getting in each other’s way, which you simply cannot hide when you’re using Agile methods,” adds Ulf Hansson.

At Ericsson they use the traditional tool of dependency mapping. The more you can understand dependencies, the more control you have over your system and can minimize the risk that teams collide during development.

“The person who successfully analyses dependencies gets no negative surprises. It creates space for solving problems, and attacks them proactively,” says Åke Sundelin.

Part of a community

These two colleagues both think it is important that Ericsson has a generous exchange of knowledge and experience with the rest of the Lean & Agile community. They see it as healthy to allow themselves to be influenced and inspired by other companies. They give as an example the Swedish vehicle manufacturer Scania, which is recognized as an excellent Lean enterprise and whose knowledge and experience of modularisation is valuable, even for Ericsson’s software developers.

“We must be part of the mutual learning process – and then smart enough to apply the lessons to our own development work,” says Ulf Hansson. As one of the biggest players in the industry Ericsson has unique knowledge and experience to offer.

“The large-scale application of Lean & Agile places special demands on our understanding; it’s really, really hard!” says Åke Sundelin.

“The transformation to large-scale Lean & Agile is difficult and disruptive, but it is something that is far too good to be dismissed simply because of the obstacles we often encounter. If we do not share our experiences, chances are that the concepts are watered down to ‘water-scrum-fall’, confidence dissipates, and in a few years people will turn up with a new set of buzz words,” says Ulf Hansson.

By Joakim Karlsson, Softhouse
.

How would you describe a software craftsman?

Corey Haines

I don’t do a lot of focusing on how individuals can call themselves “software craftsmen,” as I don’t know of any good way to define it. I jokingly say that there are two ways to be a software craftsman either a) call yourself a software craftsman or b) work for a company that calls you a software craftsman. Instead, my personal focus is on the ideas around software craftsmanship. To me, Software Craftsmanship is about changing the industry to focus on professionalism. I like to say that we are in a state similar to when a person could get a jar of leeches and hang out a ‘doctor is in’ sign. Clients are gambling when they hire someone, not knowing if they have the skills necessary to perform the work and provide the value their business needs. The core of Software Craftsmanship is a reaction against this, focusing on giving your clients what they need, when they need it and in a way that is sustainable for them. In order to do this, we need to focus on how we bring people into the industry, as well as the tools and techniques we use to provide value to our clients. As the barrier to entry lowers, more people come in without having a solid foundation or experience in building longer-term maintainable software.

When you think of this in terms of the ever-increasing demand for software developers, you can see a less than beautiful future. Software has a pervasive role in the world around us, and I know that I get nervous when I think of relying on inexperienced developers writing that code that will be running our world. There is an ongoing discussion about the goals and effect of the common computer science education from a theoretical point of view, but I prefer to focus instead on the needs of the businesses that hire these newly-minted developers. Is there a difference between computer science and software development? Where do they intersect? And, when are each needed? I think there is a place for both theory-oriented education and hands-on software development training. I’m not convinced they are the same place, though. I am excited when I see an enhanced focus on hands-on mentoring in the form of apprenticeships and trade school-like programs, such as Code Academy, RailsBridge and GirlDevelopIt. I am especially happy to see Ken Auer of RoleModel Software bring out CraftsmanshipAcademy. Ken has pioneered a lot of the ideas around apprenticeship in software development, and his ideas and leadership have influenced many of us in the craftsmanship community.

What can I, as a developer, do to get started on my way to craftsmanship? Are there specific things I should have in my basic skill set?
The path to Software Craftsmanship is to better understand your own skills and techniques and how they relate to concrete value for the business. For example, automated testing can be linked directly to the ability for a business to change rapidly. When you can push a button and verify that your system works in a matter of minutes, you give your client an incredible tool to work incrementally based on real information about their system. Adding test-driven development to the toolset brings focus onto the design of your system, working towards achieving the goals of modular design: decreasing the cost of change to a system.

In what kind of environments do you think software craftsmanship has the best chance of flourishing? Is there anything specific management can do to help?

The key to progress is trust and communication. Professional developers are hired because they have a specific skill. When there is an environment of distrust, skilled developers have difficulty moving quickly and providing value. One specific thing that management can do is to understand that building software is a creative endeavour, not ‘skilled labor’ that can be forecasted from start to finish. Working in an iterative fashion is essential to manage the complexity inherent in today’s systems. The development staff must be treated as a group of professional skilled artisans. Different people have different experiences and skillsets and are not interchangeable. This is predicated on having a staff of professional software developers who have an understanding and appreciation for their own skills, both positive and negative. Developers should be taking an active role in their own training, striving to understand where there are gaps and what they can do to fill them.

Are there settings where software craftsmanship can be more of an obstacle than an asset to an organization?

At its core, Software Craftsmanship can be effective and valuable in any organization. Obstacles arise where the communication and trust breaks down, when people are not given the freedom to apply their skills. The ideas behind Software Craftsmanship focus on creating a world where developers work closely with their business partners, each member of the team using their unique skillset to deliver the most appropriate solutions.

Lean and Agile both create good conditions for handling frequent problems in many IT projects – but in rather different ways. As the concepts are often confused, Krister Kauppi will help us untangle them.

Step 1: What is Lean?
Lean Software Development is Lean principles applied to software development, as originally described by Mary and Tom Poppendieck (2003).
Lean has its origins in the Japanese company Toyota. The aftermath of the Second World War was  tough on the Japanese economy and in order to survive Toyota had to become highly effective with their scarce resources. By visiting a number of Ford factories in the U.S. and Europe Toyota received a greater knowledge of mass production of automobiles. However Toyota lacked the resources needed to fully apply Fords manufacturing process. Toyota streamlined this process to enable fast and cost-effective deliveries, satisfying the demands of a small and multi faceted Japanese market.
Toyota achieved their goals by reducing capital binding inventory, production defects, overproduction and other kinds of waste that did not add value for the customer. This became the basis for the manufacturing process which was named Toyota Production System (TPS) and because of its high effectiveness it helped Toyota handle the oil crisis in the 1970s better than other companies around the world. As a result the interest in how Toyota managed the company grew and in the book ‘The Machine That Changed the World’ (1990) TPS was highlighted as a manufacturing process for resource-effective production. It was in this book that Lean was first used as a term describing Toyota’s successful way of working. Today Lean is adapted to most industries and regardless of which industry Lean is applied to, its core is to eliminate waste by continuous improvement and thereby effectively deliver what the customer really wants.

Step 2: What is Agile?
Agile is not a method in itself but a category for various agile methods.It was during the 1990s that these methods started being used as a reaction to other methods that were process heavy and inefficient in handling uncertainty and change. The category was created in 2001 when a group of leading profilesfrom different agile methods met with the intent of finding a common ground for the agile methods. The outcome of the meeting led to “The Agile Manifesto”, which addresses the values and principles on which Agile is based.
The core of Agile is to develop software more effectively and people-oriented in a changing and complex world. In most agile methods this is accomplished by frequent customer feedback, short iterations, flexible and emerging requirements, with the goal to achieve working software with high business value. Lean Software Development is an agile method because it is aligned with the Agile values and principles. Other commonly known agile methods are Scrum, Extreme Programming and Adaptive Software Development.

Step 3: Conclusion
The facts box to the left sums up the similarities and differences between Lean and Agile. Even if there are differences between Lean and Agile we can conclude that they are closely tied and complete each other. What connects them the most is that they are both based on radical improvement of traditional methods to achieve highly productive software development. This kind of productivity is ultimately about (more often) doing the right things the right way.