When one thinks about project development methodologies, the first thing that comes to our mind are the Agile software development methodology described in PMBOK® guide or PRINCE2® Manual. Therefore a question always arises in our minds, is another methodology really required? What is agile methodology?
The answer to this question lies in the fact that over the last 10-15 years the world of people working in the Knowledge Environment has changed drastically. People working in the Knowledge environments such as Information Technology (IT), Engineering, Teaching, Scientists, Lawyers, Doctors often need to work differently than the conventional Manufacturing environments. The key in the Knowledge environment lies in Communicating, Collaborating, Adapting to provide maximum value, since everyone in the Knowledge world is special – they have something unique and they have something more to contribute than following orders routinely. This is the thought process which has evolved the development methodologies in the recent past in the Knowledge based environments.
Agile software development methods exist on a continuum from adaptive to predictive. Agile methodology lie on the adaptive side of this continuum. One key of adaptive development methods is a “Rolling Wave” approach to schedule planning, which identifies milestones but leaves flexibility in the path to reach them, and also allows for the milestones themselves to change. Adaptive methods focus on adapting quickly to changing realities. An adaptive team changes as per needs of the project. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. When asked about a release six months from now, an adaptive team might be able to report only the mission statement for the release, or a statement of expected value vs. cost.
Predictive methods, in contrast, focus on analyzing and planning the future in detail and cater for known risks. In the extremes, a predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive methods rely on effective early phase analysis and if this goes very wrong, the project may have difficulty changing direction. Predictive teams will often institute a Change Control Board to ensure that only the most valuable changes are considered.
Agile Software Development
Agile software development is a group of software development methods where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen tight interactions throughout the development cycle.
The Agile Manifesto introduced the term in 2001. Since then, the Agile Movement, with all its values, principles, methods, practices, tools, champions and practitioners, philosophies and cultures, has significantly changed the landscape of the modern software engineering and commercial software development in the Internet era.
There are many specific agile software development methods. Most promote development, teamwork, collaboration, and process adaptability throughout the life-cycle of the project.
Some of the common features of Agile software development are as below
Iterative, incremental and evolutionary
Agile methodology break tasks into small increments with minimal planning and do not directly involve long-term planning. Iterations are short time frames (timeboxes) that typically last from one to four weeks. Each iteration involves a cross-functional team working in all functions: planning, requirements analysis, design, coding, unit testing, and acceptance testing. At the end of the iteration a working product is demonstrated to stakeholders. This minimizes overall risk and allows the project to adapt to changes quickly. An iteration might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration. Multiple iterations might be required to release a product or new features. Kaizen is the Japanese management philosophy of continuous improvement and uses Small increments for delivering continuous improvements.
Efficient and face-to-face communication
No matter what Agile software development disciplines are required, each agile methodology team will contain a customer representative, e.g. Product Owner in Scrum. This person is appointed by stakeholders to act on their behalf and makes a personal commitment to being available for developers to answer mid-iteration questions. At the end of each iteration, stakeholders and the customer representative review progress and re-evaluate priorities with a view to optimizing the return on investment (ROI) and ensuring alignment with customer needs and company goals.
In agile software development, an information radiator is a (normally large) physical display located prominently in an office, where passers-by can see it. It presents an up-to-date summary of the status of a software project or other product.
Very short feedback loop and adaptation cycle
A common characteristic of agile software development are meetings such as daily status meetings and Iteration Review meetings. We will learn about the details of the meetings later in the book, however, it is important to note that Agile teams meet frequently to discuss and get feedback from stakeholders. This enables a very short feedback loop which helps in Adaptation (change) just in case the Stakeholder expectations don’t match with what is delivered. Thru the regular feedback loop, the teams internally also discuss and solve impediments quickly so that the project is brought back on track literally on a daily basis.
Quality and Technical Excellence focus
Maintaining technical excellence is one of the key requirements of Agile Methodology. Specific tools and techniques, such as continuous integration, automated unit testing, pair programming, test-driven development, code refactoring and other techniques are often used to improve quality and enhance project agility.
Agile Manifesto
In February 2001, following 17 software developers met at the Snowbird, Utah resort, to discuss lightweight development methods.
| Kent Beck
Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler |
James Grenning
Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick |
Robert C. Martin
Steve Mellor Ken Schwaber Jeff Sutherland |
They were representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others, sympathetic to the need for an alternative to documentation driven, heavyweight agile software development processes.
They published the Manifesto for Agile Software Development to define the approach now known as agile software development. Some of the manifesto’s authors formed the Agile Alliance, a non-profit organization that promotes software development according to the manifesto’s values and principles.
Agile values
The Agile Manifesto reads, as follows:
| We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over Processes and tools Working software over Comprehensive documentation Customer collaboration over Contract negotiation Responding to change over Following a plan That is, while there is value in the items on the right, we value the items on the left more. |
Let us understand the values
- Individuals and interactions over Processes and tools
The message here is that while processes and tools will be necessary on our projects, it is more important to focus on individuals and interactions involved. The projects are a result of effort by people. The problems get resolved by people. The ideas to solve problems come from people. Also the projects are defined by people, scope decided by people and finally accepted also by people. Focusing early on developing the individuals involved in the project and emphasizing productive and effective interactions help set up a project for success.
- Working software over Comprehensive documentation
The message here is that, software without any documentation is certainly problematic, but comprehensive documentation without software is also valueless. The message is to document but documentation should be such that it is barely essential for others to understand whats there in the software.
- Customer collaboration over Contract negotiation
The message here is that one must be flexible and accommodating rather than being uncooperative with the customer. We could build the product as originally specified but it may become worthless if customer recognizes that there needs to be a change to make it more effective. Rather than beat up the customer with a change management process that is really more of a change suppression process, we have to assume right at the start that things will change.
- Responding to change over Following a plan
Initial plan should always be a starting point and the plan should progressively elaborate as time goes. More energy should be spent on responding to the inevitable changes on the project. However, this does not mean that one must throw the plans out of the window and be ad-hoc. We still need to plan. Just that there should be an assumption that plan will change and one must respond to change positively.
Agile Principles
In addition to the four Agile values, the authors of the Manifesto created twelve guiding principles for agile methodology. Following are the 12 principles
- Customer satisfaction by rapid delivery of useful software
- Welcome changing requirements, even late in development
- Working software is delivered frequently (weeks rather than months)
- Working software is the principal measure of progress
- Sustainable development, able to maintain a constant pace
- Close, daily cooperation between business people and developers
- Face-to-face conversation is the best form of communication (co-location)
- Projects are built around motivated individuals, who should be trusted
- Continuous attention to technical excellence and good design
- Simplicity—the art of maximizing the amount of work NOT done—is essential
- Self-organizing teams
- Regular adaptation to changing circumstances
- Customer satisfaction by rapid delivery of useful software
o We should focus on Customer. Satisfying only our own management or PMO should not be our only goal.
o We must structure the project and projects team to deliver early and then deliver frequently
o We must deliver valuable software and not just WBS items, documentation and plans/ The focus should be on end goal.
- Welcome changing requirements, even late in development
o Changes can be great for a project if they allow us to deliver some late high-priority features.
o From a traditional project management perspective, the changes are often seen negatively and finally only the high-priority changes go thru.
o Agile software development projects accept that fact that changes will happen. XP methodology infact states clearly to “Embrace Change”. This principle states that instead of suppressing changes, the teams should embrace change and keep the project adaptive and flexible as long as possible.
- Working software is delivered frequently (weeks rather than months)
o This principle emphasizes the importance of releasing work to a test environment and get feedback at the earliest. Frequent testing and feedback are very important and helps incorporate stakeholder comments at the earliest.
o Delivering within a short timeframe also benefits the team by keeping the Business engaged and keeping a ongoing dialogue about project progress. This helps solve escalations and dis-satisfaction from the customer in the later stages of project.
- Working software is the principal measure of progress
o The effort of creating documentation and designs should be supporting work and should not be primary activity.
o The definition of progress and the binary nature of “working software” creates a resulted oriented view of the project. Interim deliverables and partially completed work gets no external (customer) recognition.
- Sustainable development, able to maintain a constant pace
o Instead of long, intense development periods, agile methodology recognize the value of maintaining a sustainable pace that allows team members to have a work-life balance. Not only is a sustainable pace better for the team but it benefits the organization as well. Log workdays lead to dis-satisfaction which may result in loss of personnel, talent and knowledge.
o This principle advocates that working at a pace that can be maintained indefinitely creates a happier and more productive team.
o Some of the agile methodology like XP recommends not more than 40 hours a week, however the key here is to sustain the pace for long term whatever work hours your team decides as a norm.
6. Close, daily cooperation between business people and developers
o The frequent demos mentioned above are a good example of Business and developers working together throughout the lifecycle of the project.
o By working with business representatives daily, the development team learns about the business in a way that is far beyond what a collection of requirements gathering meetings can ever achieve.
7. Face-to-face conversation is the best form of communication (co-location)
o Face to face communications allow us to quickly transfer a lot of information. Body language, gestures and emotions also play a important part in the face to face communication. Face to Face communication therefore is called “High Bandwidth” communication.
o In the distributed environments where the teams work at different locations, it is still recommended to have atleast the starting point as a kickoff face to face meeting so that the teams can know each other better and help in better communication.
8. Projects are built around motivated individuals, who should be trusted
o While we may not always be in a position to pick our dream team, what we can do is try to motivate our team members. Since the team is such an important factor on the project, agile methodology promote empowered teams. People work better when they are given the autonomy to organize and plan their own work.
o Agile methodology advocate freeing the team from micromanagement of completing of tasks, instead, the emphasis is on peer collaboration, team work which results in higher productivity.
o Traditional HR theories also suggest similar principles, where more than the salary or basic needs, what drives people is motivation to excel. e.g. Herzberg’s theory or Maslow’s theory suggest similar principles. McGregor’s theory X principle does not apply in the knowledge environment for many years even before Agile Manifesto was written.
9. Continuous attention to technical excellence and good design
o While we want the development team to work hard and deliver a lot of value, we also have to be mindful of keeping the design clean, efficient and open to changes. Technical excellence and good design allows the product team to understand the product much better and maintain it much better.
o The project needs to balance the efforts of delivering high-value features with giving continuous attention to the design of the solutions. This balance allows a system to deliver long term value without becoming difficult to maintain, change or extend.
10. Simplicity—the art of maximizing the amount of work NOT done—is essential
o The most reliable features are those that DO NOT BUILD. This statement seems weird, but if we look at 90% of the systems, the 50-60% of features built in never get used actually. DSDM goes to the extent of saying that 80% of the value is delivered by 20% of the features (pareto principle).
o However because of those 50-60% features, the system becomes complex and difficult to maintain.
o Agile methodology seek the “Simplest things that could possibly work” and recommend that this solution be built first. This principle is not intended to preclude further extension and elaboration of a product – instead, it is simple saying, lets build the bare minimum first and then lets add the features as we go along.
11. Self-organizing teams
o The best architectures, requirements and designs emerge from self-organizing teams.
o Essentially the principle says that to get the best out of people, we have to let them self-organize. People also like self organizing. It allows them to find an approach that works best for them.
o By allowing the people to take their own decisions, it puts accountability on them to own the decisions that they have taken thereby resulting in better commitment.
12. Regular adaptation to changing circumstances
o Gathering lessons learned at the end of the project is too late for the current project. Instead agile projects employ frequent reviews called retrospectives to reflect on how things are working on the current project and identify opportunities for improvement.
o On an agile project, the lessons learned are captured from the team as the project progresses so on one can claim they do not apply. Instead the team knows they are relevant and is pushed to tune and adjust their behavior accordingly.