For many who are implementing Agile, they appear to communicate that they have found a panacea to all project related problems. It seems like they have found a cure for an ailing disease in project management that has myriad symptoms of delayed delivery, scope creep, poor quality, lack of communication with the customer, improper handling of risks and to top it all, a huge burden of conformance to processes. So, some of the agile followers are so averse to these symptoms in executing a project that they tend to delineate themselves from the basic principles and practices of project management, which, as a matter of fact is not the case. When this type of message goes to budding agilists, it gives them a wrong perception about Agile, and in their enthusiasm, they try implementing Agile in whichever project they get their hands on, and the result is many times, devastating.
So, to help bring in some more light on this aspect and to help relate Agile methodology with Project Management practices, let us relook at the key aspects in Agile, starting with the fundamental question on the What and Why of Agile, then relook at the Agile Manifesto, touch upon Scrum and how it gels with project management best practices and finally look what lies outside the sphere of Agile and Scrum.
What and Why of Agile
Agile is primarily a methodology to help develop relatively new complex software projects where the requirements are constantly evolving/ changing or getting added. This is achieved through an incremental, iterative and collaborative approach where quality is continuously added at every single step rather than at the end, with total user involvement to ensure the product developed at every stage is potentially shippable.
So, if Agile is being implemented for a mundane support or maintenance project it might not be that successful, and will not solve the very purpose of Agile at all.
This also reflects on the fact that Agile focuses on the primary aspects of the Project Management practices i.e., quality, scope, communication, schedule and risk management. Rather, it helps achieve the Project Management objectives in a way that Waterfall could not do so and had limitations. But this does not mean that Agile is a one size that fits all; rather waterfall is still a preferred option if your project does not fall in the criteria of agile implementation. Some projects are also run as a hybrid where an iterative waterfall approach is followed, where pure agile methodology does not fit. A modified or tailored agile methodology is also followed if needed.
Agile Manifesto
The Agile Manifesto talks of the following:
Individuals and Interactions over processes and tools: This emphasizes the importance of communication and collocation, but that does not imply that processes and tools are not necessary. It prefers communication, but definitely a minimal set of processes are necessary. There are many successful agile projects that implement tools that help in achieving the objectives of effective communication and getting things done. The core idea is that business professionals and developers must work together and interact often to build projects around motivated individuals, to facilitate the environment needed and to support and trust them to get things done. So, in a nutshell, people ARE important, but processes and tools, too.
Working software over comprehensive documentation: Again, working software is essential, but it does not eliminate the necessity of documentation. It means that minimal and effective documentation is equally important. General misconceptions are “Let’s just make it work and there is no need of documentation”. What is actually needed is a clear definition of done that needs not only a working software but necessary document updates e.g., user stories should be functionally complete.
Customer Collaboration over contract negotiation: Agile manifesto talks of having a strong relationship and collaboration with the customer. This does not mean that a contract is not present at all. It emphasizes on collaboration more than the contract. But contracts are still essential and more preferably to help achieve a positive outcome. Contracts are usually a last resort; Transparency is the key to develop trust.
Respond to change over following the plan: Does this mean that project plans are to be thrown out of the window. No, not yet. Plans are still essential at a high level, but it is not about following a plan, but more about responding to change and keeping the plan up to date. One needs to understand that changes are inevitable and the whole idea is to respond to change with more flexibility. While too detailed planning could be a waste of time, no planning at all is being irresponsible.
Scrum Framework
Scrum is a framework within which you can employ various processes and techniques to develop and deliver complex products. Scrum is based on an iterative delivery approach of what is called a Sprint – a focused effort for a range of 2 weeks to 4 weeks period towards a fixed goal.
The importance of 3’s:
3 Principles:
The 3 principles on which it works is Transparency, Inspection and Adaption.
Transparency is obtained through daily stand-up meetings, training the teams with agile approach, burn down charts on releases and sprints, product demo to stakeholders after every sprint and so on.
Regular Inspection is achieved through code reviews from time to time, testing in each sprint with preferably a test driven approach, presenting each sprint to the customer, and customer testing at each sub release or scrums.
Adaption is attained through regular re-prioritisation of backlogs, while sticking to the priorities in a given active sprint, and continuously updating the out of scope pot and keeping the backlogs up to date.
These 3 important principles are again related to the project management best practices in dealing with effective communication, quality assurance, adapting to change, and handling scope creep in an effective manner.
3 Roles
The 3 roles, that of Product Owner, Scrum Master and the Team helps in meeting the very purpose of Scrum.
1+ 3 Artefacts
The 3 artefacts of Product Backlog, Sprint Backlog, and Burn down chart coupled with the Product Vision help achieve the desired results.
The product vision helps to have a clear overall goal such as: who is going to buy the product, what are the customer needs that the product will address, how the product is compared to existing products, target time frames, budgets etc.
The product backlog contains the requirements, i.e., a list of all desired work on the project. This list is constantly being prioritised by the product owner and reprioritised at the beginning of each sprint. However, remember that this is not just another specification! It contains prioritized user stories estimated in story points.
Sprint backlog comes from the product backlog and contains the requirements with the highest priority. This explicitly defines the Definition of Done for each sprint.
Burn down chart helps in tracking the remaining work and is updated when the tasks are completed by each team member. A good “burn down chart” tells you:
– A linear and ideal burn down line
– The burn down using earned value
– The burn up showing used hours
– The average needed velocity to reach the goal
All this combined, helps one to manage the scope effectively within the stipulated sprint cycle and thereby meet the overall project objective in every release.
3 Meetings:
The 3 meetings are the Sprint planning, Daily scrum and Sprint review and retrospective.
While the Sprint planning helps to plan out how to achieve the sprint goal and estimate the sprint backlog in hours, it is the daily scrum meeting that helps address specific questions on what was done, what will be done each day and any impediments in a given day of the sprint. This helps to focus on the long term goals of the sprint and also the immediate priorities. This helps in scope, schedule and risk management effectively.
The Sprint review is where the team talks about what is achieved in the sprint typically in the form of a demo to the product owner and the Sprint retrospective is where lessons learnt and improvement areas are discussed and recorded. These are again inevitable parts of project management best practices where the product or part of the product is formally delivered and lessons learnt at the end of each cycle in each of the phases are recorded. What Agile Scrum does is it makes it more effective and easy to follow, with complete transparency involving the whole team.
Programme Management’s role:
Programme management still holds a key role outside the sphere of projects being executed in an agile methodology. The basic roles and responsibilities of programme management are even more inevitable in an Agile environment. While the sprints are being delivered on time with quality, it is imperative to see the overall schedule, scope and quality of the release and subsequent planned releases. This also involves the basic fundamentals of understanding the high level requirements of the customer and the overall direction of the programme and its alignment with the portfolio.
An organisation going Agile is an important decision and very tough at times. Whether an organisation is justified to go Agile is one key question that the Programme Management Office can help answer. Once an organisation goes Agile, it is important for the PMO to step in and provide the environment and platform for appropriate coaching through Agile coaches and to help leverage all the teams performing their roles in an agile environment.
During project execution, it is equally important to look at some of the common goals of scope, quality, time and direction at a higher level of the programme.