Skip to main content

Agile 101 - Introduction to Agile Project Management Methodology

If you work in the software industry you would have heard about agile project management or you might already be practising it. In this article, we are going to through some of the key concepts of agile, what are some of the key benefits of agile, and how is it better than waterfall.

Agile 101

Traditional Project Management

Traditional Project Management - Waterfall

Going back in history, software development projects used to be run using waterfall methodology. What is a waterfall methodology? In waterfall methodology, all the project phases are sequential. You typically start with the requirements. Once you get all the requirements, you create a business requirement document, you then get it signed off. Only when the requirement document is signed off you move on to the design phase. The design phase is typically split into a high-level design and a detail design phase. When the detail design document is signed off, only then you will move on to the build phase. Once you have done coding for all the components, completed unit testing, got the code review done, you move the code to the quality environment for the testing phase. Testing will have multiple phases. For example, it can have system testing, system integration testing and user acceptance testing. Once you're done with the user acceptance testing, you will move on to the implementation phase. Then you will deploy the code. Once the code is successfully deployed and you're happy with the business verification, you move to the warranty and then support phase.
As you can see, all the phases are sequential and you move to the next phase only when the earlier phase is over.

Problems with Waterfall Project Management Methodology 

Problems with Waterfall Project Management

The waterfall Was the primary method of delivering software projects for a very long time. Around mid-nineties, waterfall started to show some problems. The reason was that the business requirements started to change frequently and the waterfall method was not able to handle changing business needs.
  • One of the problems was that in waterfall let's say you get a change in a requirement in the testing phase. Waterfall requires you to go back to the requirement phase and go through the requirement, design and the testing phases all over again, 
  • Another problem was that customer feedback was received very late. Waterfall project will typically take let's say 2 to 3 years and you will only produce working software at the end of the project and that's the time you will get the customer feedback. If the customer feedback is not good then you would have wasted a lot of efforts in building and delivering something customers didn't even want. 
  • One more problem with Waterfall was that the benefits were realized at the end of the project. The reason is you will implement your project at the end of the project and that is when you start to gain the benefits of your project. 
  • Another problem was that there was a huge lack of collaboration between business and IT. Collaboration between business and IT typically happened during requirements and then only at the UAT stage. This lack of collaboration resulted in miscommunications and misunderstandings. 
  • Waterfall also failed in meeting changing business needs. Let’s you get a change at the testing stage, then you would have to go back to the requirement phase, then do the design and then testing all over again which will take a lot of time. 
  • It is also very difficult to measure progress in agile between phases. For example, if you are in the design phase, you could say that you're 20% done with the design or 40% done with the design, but there's no way to accurately measure the progress. 

Agile Project Management Methodology 

Agile Project Management Methodology

Let's look at how is agile project management different from Waterfall project management. In agile project management all the phases are run in parallel, so you start with the requirement, then quickly get into the design phase, You will move on to the build phase, do the testing, implement it. Once the requirement has been implemented, track and monitor the product and get customer feedback. You will prioritize your requirements based on customer feedback or even change the requirements completely. The continuous cycle ensures benefits are realized constantly and customer feedback is incorporated in future releases.

Waterfall vs Agile Project Management - Triple Constraints 

Waterfall vs Agile Project Management - Triple Constraints

Now let's look at the triple constraint of project management and how do they look in waterfall and agile. In waterfall, remember you start with the requirement phase. Once, all the requirements are gathered, you complete the business requirement document, get it signed off and that signed off document becomes your fixed scope. Whereas in Agile, you fix the capacity by deciding on your team. Let’s say you decide that you will make 6 people team. Then you fix the delivery cycle duration. So let's assume that you decide to go with two weeks of delivery cycles which means that you deliver working software every two weeks. Now that you have a fixed capacity of 6 people and a fixed schedule of 2 weeks. Based on those two parameters you will estimate the requirements that you can deliver in the cycle. And that's a big difference, In waterfall, you estimate the cost and the schedule while In agile you estimate the scope.

Waterfall vs Agile Project Management - Key Differences 

Waterfall vs Agile - Key Differences

Let's go through some of the key differences between waterfall and agile on key software development and project management parameters.
  1. Architecture in the waterfall is assumed to be fixed. Waterfall assumes that architecture is the foundation on which all the code would be built. So, you take a lot of time in defining the architecture, it could take 2 to 3 month to define architecture. 
  2. In agile, architecture is evolving. So, in every delivery cycle, you take some of the architectural requirement and you evolve your architecture over a period of time. 
  3. Integration in the waterfall is done at the end of the test cycle and you have a specific phase called System Integration Testing Phase. Integration in the waterfall is continuous and gets tested constantly. 
  4. The waterfall is based on the specialist skill so you will have many roles with specialist skill, whereas in agile, you have one single cross-functional delivery team and it is expected that the anyone in the team can work on any of the tasks. 
  5. A project manager is the leader in the waterfall and is typically a command-and-control leader and he directs the team to do the tasks. In agile, the scrum master is a servant leader and his job is to make sure that roadblocks are removed which allows the team to focus on working.
  6. Business interaction in the waterfall is very disciplined and it only happens in specific phases which is usually requirements and UAT phases. In agile, business interaction is continuous and it happens every day. 
  7. In waterfall, the responsibility of delivery lies with project manager while in agile, the responsibility of delivery is with the development team and the team is expected to be a self-organizing and competent team. 
  8. Benefit realization in waterfall happens at the end of the project which could be a huge cycle of two to three years whereas benefit realization in agile happens incrementally. You typically deliver your working software every 2 to 3 weeks and that's when you realize the benefits of new features. 
  9. Risk of failure is very high in waterfall because you take 2 to 3 years to develop a software release and then you deliver it which may or may not work and customers may or may not like it. In agile, you constantly deliver working software and get the customer feedback, so all you are risking is one delivery cycle which is typically 2 to 3 weeks. 

Agile Manifesto 

Agile Manifesto

In the year 2001, many agile leaders got together for a workshop to come up with an agile manifesto and they came up with four parameters that agile methodology values. The items on the left have a higher value than the items on the right. For example, individuals and interactions are much more important than the processes and tools. Now that does not mean that the processes and tools are not important. They are still important but we should not be focusing so much on processing and tools that we ignore the individuals and their interactions. Similarly, working software is the key measure of progress not comprehensive documentation. The documentation is still important but you should not be spending two months to clear the documentation while you do not deliver any software feature during those two months. Responding to change is more important than following the plan. Planning is still important but you should not be focusing so much on following the plan that you ignore the changing customer needs.

Twelve Agile Principles 

Agile Principles

When Agile leaders met to define the Agile Manifesto, they also defined 12 principles that are the foundation of an agile framework.
  1. The first principle states that continuous delivery of software is very important. 
  2. The second one focuses on welcoming change in requirement and how it is fundamental to the success of agile. 
  3. The third one talks about the delivery of working software into incremental and short delivery cycles. 
  4. The fourth principle talks about collaboration between business and developers. 
  5. The fifth one says that motivation is key and motivates individuals are the foundation of success. 
  6. The sixth principle speaks about the importance of face-to-face interactions. 
  7. The seventh underlines that the working software is the only primary method of success, not the documentation, not the milestones. 
  8. The eighth principle promotes sustainable development which means that the team should be able to maintain the pace constantly. 
  9. The ninth principle stresses the importance of technical excellence and how good design is critical for agility. 
  10. The tenth one talks about simplicity and the art of maximizing the amount of work not done which means you should only be taking the requirement that is of value to the customer. You should not be taking unnecessary scope in your project. 
  11. The eleventh talks about the benefits of a self-organizing team. 
  12. The twelfth principle stresses the importance of review and retrospection and how it improves the agility of the team. 

Key Agile Framework 

Agile Frameworks

Over a period of time, agile has evolved into many frameworks. Let's look at some of the popular agile frameworks.
  • Scrum focuses a lot on the cross-functional self-organized team. 
  • Kanban values visual nature and transparency in monitoring the work. 
  • Scrumban combines the best of both scrum and kanban. It takes discipline and rituals of scrums such as doing the daily stand ups and doing the retrospectives and reviews. It also takes visual nature of managing the work from kanban. 
  • Lean has a strong focus on eliminating all the fat and focusing on only the critical things. 
  • XP focuses on building the quality in the product as an inherent quality. 

Key Benefits of Agile Software Development 

Benefits of Agile Software Development

Let's go thru some of the key benefits of going Agile. 
  • Agile delivers higher quality. The reason is that the testing is continuous in agile, so defects are identified the moment it is delivered. In agile, you also need to do a product showcase after every delivery cycle which ensures that you are able to get the feedback and incorporate that into the product. 
  • Agile also results in improved customer satisfaction. There are two ways agile achieves it. One, the product owner is always involved. Product Owner is the voice of the customer and if her feedback is incorporated into the product, then you can be assured that the customer will be satisfied. Two, You deploy releases frequently into production and gather the customer feedback which is then again taken back into the product as the new or changed requirements. 
  • Agile also has better control and monitoring. Agile uses timeboxed meetings to make sure that you are always on top of things. Agile also focuses a lot on big visual information radiators and transparency which means anybody can look at the status at any point in time. The agile methodology also has a reduced risk of failure. The reason is that you deliver software frequently and incrementally which means that the customer is always validating the product. 
  • Agile also deliver a better return on investment. Because unlike the waterfall, the software is delivered in short cycles, so you start to gain the benefit very early on. 
  • The team is also better motivated because you are not directing the team to do the work, you let them decide how do they organize themselves and deliver the work. 
  • Agile is also lean and reduces waste because you are not building unnecessary scope into the product making sure that whatever you are building has deep customer value 

Common Misconceptions of Agile 

Misconceptions about Agile

While the agile methodology has become mainstream, there is still a lot of misconception about agile. 
  • Many people feel that agile is unplanned and unstructured. That's not true, agile is very structured. In Fact, in agile, you have timeboxed rituals that you have to follow and that brings a lot of structure to the way you deliver your project. 
  • Some think that the documentation is not required in agile. Documentation is still important even in the agile. All it says is that documentation is less important than working software. So you can continue to evolve documentation while delivering the software. 
  • Many feel that Agile is not a disciplined approach, In Fact, Agile is highly disciplined even more disciplined than waterfall and you have strict timebox rituals to follow. 
  • People also think that development is not predictable. In agile, you plan for the immediate delivery cycle in a very detailed manner, so you are able to predict it perfectly. Deliveries in the distant future are only planned at a high level. 
  • Many people feel that agile is not fit for the large and complex project. In fact, agile is very well suited for large and complex projects because in a large and complex project it is very difficult to define all the requirements up front and that’s why allowing for changes in requirements helps deliver the project in a much better way. 
  • Many think that the agile doesn't work for distributed teams. While it is true that face to face interaction is valued in agile. it can be made to work for distributed teams as well. 
  • Many people also assume that design is not required in agile. Nothing can be far from the truth. In fact. focus on design is one of the fundamental principles of agile. 
With that, we come to an end of the introduction to agile. I hope you have learned a lot about agile methodology and that you understand the benefits and key concepts of agile and start applying these concepts in your projects.


Popular posts from this blog

14 Free Keyword Research Tools for Perfect Keyword Ideas (Updated)

Finding right keywords for your article is the key first step if you want to perform well in search engine. These free keyword research tools will help you find the perfect keyword/phrase for your next article.

26 Proven Work at Home Business Ideas You Can Run Part Time

If you are looking for work at home business ideas, then this list can help you. All of these can be done as part-time business, so you don’t have to leave your job until you are confident of making full time income from your Work at home business.