Working in Project Management with Agile and Scrum projects for more than six years has provided for me awesome chances to work inside the distinctive group structures all through the organization. It enables a platform to experiment various applications of agile methodologies under different conditions and establishments.
AGILE seemingly is becoming more and more popular, due to reasons not limited to:
- Increasing complexity of the projects from technological and execution perspective.
- Evolving nature of the business and business processes to stay abreast with the competition
- Initiatives to cut down Out the door time
- Also sometimes because it is popular
What is AGILE Project Management or Traditional Project Management?
Before we go into the comparison, project management as a whole is an art of balancing using three main knobs — Schedule, Quality and Cost. Its a bit tricky – more like a juggler handles multiple balls in the air.
In an ideal scenario, Quality has to be the best, Schedule should be as planned and cost must be optimum. Any product create has to meet the standards of quality laid down during the inception phase. As most of the projects, there are challenges that come which are not planned for. As a result, the other two aspects Schedule and/or Cost take the hit.
Stages for the Traditional approach in project management involves high level chronological events like:
- Inception: Identify project goals
- Planning: Plan all the activities in advance and schedule for the activities. This phase also includes designing phase in case of development of a software.
- Execution: Execute the plans as per previous phase
- Quality: Test the quality of product or Software defined during Planning phase
- Deliver: Ship or Deploy the product in market
The challenge is any activity that does not coincide with the plan has a domino effect on the remaining activities creating a rift between planned and actual delivery date. Project Managers keep cushion zones in between also termed as ‘Buffers’ in schedule and cost to absorb these rifts while keeping the Quality factor in line with the plans. However most of the times these ‘Buffers’ serve only upto a certain extent leading to compromise in schedule and cost and sometimes on Quality too.
During the late 80s, a new approach had already come into practice now known as Agile. Agile helps in addressing the challenge in an innovative way. In comparison – Traditional approach was like handling heavy glass balls by the juggler which are now replaced by small sponge balls in Agile approach where the weights of the balls that is reduced is conducive to amount of activities that are handled by a team during a specific time.
Traditional approach fixes the features delivered for the project, and treats Schedule, Cost and Quality as variables. While Agile approach keeps the Schedule, Cost and Quality as fixed and Features vary with time.
One classical argument that I have seen here is that in either case Time-To-Market is a variable. My take is that Agile helps us in making Usability decisions and still enable a working product in the market with a plan to enhance it with later versions. This flexibility is not available in Traditional approach.
The below diagram illustrates the Traditional and AGILE project variables:
Comparison between Waterfall, one of the most popular traditional method v/s Agile method
So how do you determine priority of these features for a better product on a planned Time-To-Market Date? The answer is MuSCoW. Not the one you are thinking, it is a technique.
MuSCoW is a prioritization technique used to reach an agreement on the importance of delivery of each requirement.
MoSCoW is an acronym to categorise the following:
- Must have requirements are critical to a project’s success. If even one MUST HAVE is not included, the project would be considered a failure and cannot go out of the door. Essentially this are the fundamental functionalities of the product and sometimes also the features which enhance reputation of the product.
- Should have requirements represent a high-priority item that should be included in the solution if possible. For example a web based software that is also accessible from mobile platform is a good example. It can still go to market without the mobility solution however giving it together usually gives a better edge to the product.
- Could have requirements are less critical and often seen as nice to have items. Example extending customer care to 24/7 for products that are not critical enough. In that case they can be launched with 18/5 or lesser support hours to reduce the initial investments and provide more time to collect history to take a better decision.
- Won’t haves are the least-critical and will not be covered in the project time frame. These are contingent features, those which do not help or harm the actual product but are good to have. Example associating coupons or discounts on the products that are in niche markets. You may want them for future but may not want to exercise them immediately.
There has to be a top ceiling for the total number of each category to avoid easy pickings of all Must Have. AGILE recommends a project should consist of no more than 60% MUST HAVE requirements with approximately 40% distributed between the SHOULD HAVES and COULD HAVES.
Stages of Agility
The philosophy of agile remains continuous, however it is applied based on the stage that a project is into. These stages are like the layers of project unveiled gradually.
Strategy Level: At the strategy level the artifacts are identifying vision and goals of the project, budget of the project and value that should be brought up into the product.
Release Level: At this level functional and technological aspects take precedence with designs, behavior driven development, estimations and product backlog. Product Backlog, as the name suggests this trickles down from the goals in strategy level, where each goal is further converted into product level features and each feature into a quantifiable activity. All these activities are collectively known as product backlog.
Iteration Level: There are defined iterations planned at the strategy level, where work is done on each activity in the product backlog. Items of prioritized product backlog that are taken up in a particular iteration, are called iteration backlog. Each iteration backlog item is reviewed before end of the iteration time period.
Daily Level: Every day activities are monitored through meetings known as ‘Stand Ups’. These are quick meetings with a focus to discuss accomplishments on previous day, plan for the current day and any road blocks found.
Continuous Level: This machinery of Agile is active throughout the period of project execution and it involves deploying various initiatives. We will discuss more about this in my next blog.
Contrary to what most believe, Agile is more of a philosophy and guidance rather than a method or process to be followed. As with most of the philosophies there are rules and rituals. We will discuss about these rules and rituals in my next blog.
Along with the above we will also go through some of the most popular methods of management deployed withing the Agile framework like Scrum, XP and some of the more complex topics like how to adhere to Agile in a distributed environment and what is the holistic approach to enterprise agility.
Overall, I hope you will appreciate my post to go over the basic fundamental of agility and apply many aspects of the methodologies to your projects going forwards.
As Project Managers face ever expanding pressure to deliver working model for business challenges in limited timescales without bargaining quality. Accordingly, it is our obligation to move with the times and adjust our ways to diverse approach where possible.