The Lean Approach to Agile Software Development

For those of you lucky enough to read Eric Reis’ Lean Startup, you know the basic principle is to build, deploy and test a minimum viable product in very little time, for very little cost before you make further investments. Drilling into the software development life-cycle, the Agile approach to software development is the antithesis of the Waterfall approach — make small investments, typically 2 week sprints with lots of parallel works.

This posting will cover the basic principles behind Agile Software Development.


By now, you’ve googled the keywords ‘Agile Software Development‘ or a variation of that and after getting tens of 1000’s of links you’ve stumbled on this link. Assuming that 90% of the visitors want a quick definition, we are putting this at the top.

For the remaining 10% that want as much detail and supporting information possible, we have compiled supporting documentation from books, articles, our own knowledge and experience and structured it to your benefit so feel free to stay on the site and learn as much as you can.

Definition of ‘Agile Software Development’:

Agile Software Development is a concept, a philosophy and a methodology which evolved in the 90’s as an answer to the long-growing frustrations of the waterfall systems development lifecycle (SDLC) concepts. The term promotes an iterative approach to software development using shorter and lightweight development cycles and some different deliverables.


After extensive research, we have found that like other resources, the term Agile as it relates to modern software development, was being used during the 1990’s in various published articles both on the internet as well as ComputerWorld/InfoWorld. The papers were based on people looking for a new approach to software process. While the ideas were not new, they gained enough steam for people to pay close attention especially while search engines on the internet became very popular. There is another alliance called the Agile Manifesto, which in our opinion, is a disorganized web site that has some claims to doctrines and philosophies, all borrowed and bastardized to look like an original concept. The web producer put a picture from a meeting in SnowBird to resemble the framers of the constitution and the Declaration of Independence. They then hijacked the term ‘Agile’ in early 2001 when a bunch of people who had been heavily involved in the Agile concepts got together to exchange ideas and came up with the Manifesto for Agile Software Development.

The Agile workshop was organized, by Jim Highsmith and Bob Martin. They contacted people who they felt were actively involved in software development communities with these similar ideas and got seventeen of them together for the Snowbird workshop. Initially, they wanted to get together and build better understanding of each others’ approaches. Robert Martin was keen to get some statement, a manifesto that could be used to rally the industry behind these kinds of techniques. We also decided we wanted to choose a name to act as an umbrella name for the various approaches. One next step that did follow, with the active involvement of many of these authors, was the formation of the agile alliance. This group is a non-profit group intended to promote and research agile methods. Amongst other things it sponsors an annual conference in the US.


Under this broad term of ‘Agile Software Development’ there are other approaches such as Extreme Programming, Scrum, Lean Development, and RUP. Each of these more particular approaches has its own ideas, communities and leaders. It is important to understand that Agile is not a specific methodology, but a higher concept representing and Iterative approach with newly defined underlying principles. It is with each approach you can see the specific deliverables and concepts for how to work the process.

XP (Extreme Programming)
Extreme Programming (XP) is actually a deliberate and disciplined approach to Agile software development. One of the first approaches to gain main-stream success, Extreme was found to be most successful at smaller companies especially in the dot-com boom.

XP is successful because it stresses customer satisfaction. The methodology aims to deliver the software your customer needs on time. XP allows the software developers to confidently respond to changing software requirements, even late in the life cycle.

This methodology additionally focuses on team work. Managers, customers, and developers are all part of a team dedicated to delivering quality software. XP implements a simple and effective way to enable groupware style development.

XP improves a software project in four essential methods; communication, simplicity,feedback, and courage. XP programmers communicate with their customers and programmers. The design should be simple and clean. They get feedback by testing their software starting on day one and deliver the system to the customers as early as possible and implement changes as suggested.

Agile Development with Scrum

Agile and Scrum development methodologies aim to correct the problem of projects not having an end in site most likely from out of control software requirements. Scrum solves this by applying what will appear to be common sense after you engage in the methodology for a few projects. This Agile software development method has some very key principles.

1. Deliver products based on need from high-priority down.
2. Deliver the absolute minimum that the customer wants.
3. Eliminate waste from your projects wherever possible.
4. Deliver projects in short bursts, called iterations.

Scrum is a rugby offensive term where a team pushes forward to score as a single unit. Scrum is a communication methodology more than a development methodology and because of that, it can be applied to almost any type of project. Scrum consists of the following core believes:

1. The customer lists all the features they want in priority order.
2. Development efforts are broken into 30 day iterations called sprints.
3. Scrum teams are multi-functional teams of 5-10 that contain all the facets of the team that is needed to complete the projects.

The Agile (Rational) Unified Process Framework

Another well-known process to have come out of the object-oriented community is the Rational Unified Process (sometimes just referred to as the Unified Process). The original idea was that like the UML unified modeling languages the UP could unify software processes. Since RUP appeared about the same time as the agile methods, there’s a lot of discussion about whether the two are compatible.

RUP is a large collection of methods and is a process framework rather than a process. Rather than give a single process for software development it seeks to provide a common set of concepts for teams to choose from for an individual project. As a result a team’s first step using RUP should be to define their individual process, or as RUP calls it, a development case.

The key common aspects of RUP is that it is Use Case Driven (development is driven through user-visible features), iterative, and architecture centric (there’s a priority to building a architecture early on that will last the project through).

Out of all of the Agile iterative software development methods, I find that RUP is the most intensely defined and works very well at larger corporations that need documented processes. Again, RUP provides a toolkit of deliverables and it’s up for the organization using it to decide how it should work. Toyota Customer Services HQ in California has their own brand of RUP called BluePrint.


Having experienced both waterfall projects and Agile projects, it’s easy for me to give a fair assessment on how these two stack up against each other. The short answer is that there is no right answer because both have their place in the IT world. Many of you would grimace at this notion, but the truth is there are large corporate and government environments where projects need to go through a rigid life cycle for them to be successful. This is where Waterfall really pays off.

With that said, for projects that are less than six months in duration, and there is a real need to phase in the project, Agile all the way. Agile software development projects will allow various groups including dev, QA and analysts not to constantly wait for each other. What you’re really doing is taking a big project and turning it into several smaller waterfall projects — each with their own requirements, design, dev and QA stages.

From a customer perspective, typically a fast-paced customer wants to see progress rather than wait for everything at once. Agile practices provide this ability.


Organizations need a way to lower engineering costs, increase software reliability, decrease engineering time and ensure applications are bought off by the business, rather than against them. These four issues are a demanding order for anyone to fill, although Agile software development techniques can do it in many application programming scenarios. Agile makes business sense because you can lower costs by reducing the number of mistakes developers make when building applications. also, Agile programming techniques can eliminate the huge risk of a failed application.

However, even when an application is deployed and you have it installed on your server, reliability costs can erode the gain from an application. The five 9’s of reliability that most companies strive to achieve can happen only with a well-designed application that doesn’t spend more time in the digital repair shop than it does answering users’ needs. Agile accomplishes this by reducing most development errors per program and by providing constant testing that locates errors fast.

Many organizations are looking for a fast ROI for any development project. Instead, most projects get delayed for years as the company waits for the developer to complete the application. Rather than wait for the entire application, Agile software development techniques help you use at least part of the application today, which means you obtain a significantly faster benefit from the system. In short, you can obtain part of the system free because the savings you realize go into the development of the remainder of the system.

Agile software development helps you avoid the scenario of a deployed broken application by involving the user early in the development process. If the vendor had followed this approach, the first iteration of the application would have helped the company realize the expected gain. Instead, many companies spend time and still more money reworking the application.


In non-iterative methodologies like waterfall, there is large upfront design, aiming to predict accurately how much work is involved in each project activity. This leads to a significant investment early in the project, when it is uncertain that the designed functionality is actually desired. Any agile approach to large-scale development has to avoid the reintroduction of the big design up front. One solution is to incorporate levels of planning incorporate a view of ‘the whole.’ Agile planning activities for large-scale development efforts should rely on these five levels.

Level 1 – Product Visioning
The highest-level view that the stakeholder can paint of the future is the product vision. In this vision, they explain what an organization or product should look like after project completion. They indicate what parts of the system need to change and what efforts can be used to achieve this goal.

Level 2 – Product Roadmap
The era of large-scale projects that deliver results in years is behind us. Customers demand faster frequent changes, and delivery is measured in weeks or months. The higher frequency and smaller timeframes force a product owner into thinking in steps – into thinking of a road towards the final product. A product roadmap is created and communicated to fellow delivery people to provide a map so concept is more of a reality.

Level 3 – Release Planning
In small projects, the product backlog can provide adequate project overview. The size, duration and deliverables are easily recognized, and there is no need to synchronize deliverables or teams. All of this changes when applying agile concepts to programs. The first time when rouping activities and allocating them to teams occurs during release planning.

Level 4 – Iteration Planning
For each iteration within the release, a planning session occurs to append detail and increase accuracy. Before or during the session, detail is added to the features by breaking them down into tasks. The actual capacity of the individual teams is known with more certainty than during the release planning session. The combination of these increased accuracies helps the team commit to delivering a number of features during the iteration with a high degree of certainty.

Level 5 – Daily Plan
The stand-up meeting is part of everyday life for agile teams. This daily meeting is not often seen as a planning session, but it certainly is. The people look a day ahead, have learned from the earlier days in the iteration, and tell each other what they plan on doing. Issues are raised, possibly addressed, and the success of delivering the desired features within the iteration can be determined after the meeting.


Agile software development utilizes a “feature driven” approach of rolling up development progress that provides an easily digested summary of project status using Parking Lot diagrams. Yet, their appreciation and use outside of Agile is quite rare. This artifact is a very powerful tool because it provides a high-level and visual depiction of a project as well as the status of different components. Parking lot diagrams are not just for Agile “feature driven” projects, they can be used equally as well on XP, Scrum, or RUP projects. Below is a diagram of a good example of one of these diagrams used in action.

As projects get larger the number of features or use cases you likely have to manage increases. Small to medium size projects with a few hundred features can be managed fine with decks of cards, task boards, and burn-down charts, but as projects scale this information becomes hard to manage and difficult to digest by stakeholders. Parking Lot diagrams roll-up features into functional groups and then these groups into functional areas to better show overall progress against business areas.

Agile Feature Driven Development promotes the idea of a chief programmer, an individual who is responsible for a piece of functionality. Their initials “FB” can be shown above the parking lot diagram. If a stakeholder has a question about this area, then they know somebody is the designated person to speak to. Alternatively, if you are working on an XP project with shared code ownership it may not be appropriate to display initials, in which case simply don’t.

The color of the box indicates status. With the scheme below, white means not started, yellow for work in progress, Green for complete, and Red for late. Standards vary, some people use Blue for work in progress, Yellow for nearing the due date, and Red for late, but as long as there is a consensus among stakeholders for what each color means you should be fine. The main box also contains a percent complete figure based upon the combined status of each of the (15) features within it. The bottom area of the box contains a progress bar that duplicates the percent complete figure to give a more visual measure of this number and the target completion month for this group of features. The real power of this technique comes when these feature groups are combined into feature areas and an overall dashboard for the entire project is created.

Agile Software Development parking lot

This Agile Parking Lot Diagram was created using Rather than trying to pull this document together in Visio or another modeling tool, GatherSpace will create this stunning report for you on-the-fly based on the requirements you have in the system.


While there is no single, agreed to leadership manifesto, industry experts offer similar advice. Based on key findings in the area of Agile Software development, the below leadership methods have been identified.

• Modeling desired behavior
• Creating and communicating a common vision
• Willingness to challenge the status quo
• Empowering others
• Encouraging others

These behaviors have strong correlation with agile project management and software development recommendations.

1. Modeling desired behavior
– agile project managers should demonstrate the behaviors they wish their team to exhibit. Admit your mistakes, promote candid discussion of issues and show humility. Adopt a sharing, abundant mentality to information and focus on communications.

2. Creating and communicating a common vision – Teams need to have a powerful, uniting vision about the project and what the system they are building should do. People need to be pulling in the same direction and a common vision helps align their effort. XP uses the concept of a system metaphor to help create a common vision.

3. Willingness to challenge the status quo
– No process is perfect or optimally configured for the unique demands of every project and organization. There need to be regular reviews to ensure the team and process are on track. In Agile projects, the end of iteration retrospectives where the team is asked, “What went well?”, “What did not go well?”, and “What can we improve for the next iteration?” Is where the status quo is challenged. This is an important leadership concept, never to accept the current process just because it is established.

4. Empowering others
– Really great leaders know that people work best when empowered to make decisions and given the freedom to self organize and think independently. Agile software development teams leverage the benefits of empowered working and gain the benefits of greater commitment and accountability. By allowing team members to sign up for tasks voluntarily, a strong internal commitment to try and deliver timely to a high standard is generated. Couple this with the agile practice of holding iteration planning meetings where team members select tasks in the presence with their peers, that gives a sense of ownership of a product or project which is an incredible way to get employees to feel motivated about the work they do.

5. Encouraging others – Saying thanks is one of the most cost effective, yet under utilized productivity tools available to management. It does not take long to do, but if done appropriately with sincerity it can go a long way towards ensuring continued contribution and motivating staff. Agile projects recognize this tool and use the iteration retrospectives as opportunities to recognize accomplishments.