(This is the second in a five-part series on this topic where we will discuss how organizations can approach or refine their Agile delivery methods.)
In the Part 1 of our series, “Integrating Agile in a Waterfall Practice,” we defined the various project delivery methods, 
described the Agile methodology as it compares with those delivery methods, and briefly talked about the value the various methods can provide. There is no doubt Agile, when implemented effectively can provide tremendous value to an organization which desires to rapidly capitalize on technological advances and shifts in organizational priorities and strategy.
When discussing the integration of Agile into more traditional project delivery practices I often find project managers and PMO leaders have heard of the benefits of Agile without necessarily understanding the implications to their organizations. I often think – do you want agile as a verb or as a noun? There is a difference between becoming more agile as a delivery team (who doesn’t want that?) than there is in transforming your organization into an Agile delivery model.
What Does it Mean to Use Agile?
At its core, Agile is two things, it is a family of methodologies which can be tailored to best fit the organization. In Agile, we find several team methods such as Scrum, Kanban, Test Driven Development, Extreme Programming and others. However, it is also a mindset where we find terms such as servant leadership, decentralized authority, and self-organizing teams.
As you look at these terms some, many, or all may be quite familiar to you. In fact, each of these can be applied in project delivery, in operations, or in organizational culture to varying degrees. Each also came in vogue, so to speak on its own merits. With this understanding, you can take any one of these methods and apply them individually or in pairs. However, to be a truly Agile project delivery team (as a noun) it requires combining these practices in a methodology and culture which brings out the best value for your project delivery.
How to Start Implementing Agile
While each of the team methods described above can be easily researched and defined, let’s focus more on how those methods are used in combination with the mindset aspects of Agile. In most cases implementing Agile means combining within a Scrum framework the elements of Kanban, Extreme Programming and Feature Driven Development to name a few. In every one of these methods there is an impact to the way people work and the roles described. Which brings us back to the mindset shift which comes with Agile. While it is possible for organizations to gain some agility (the verb) with these methods, the true value is in the adoption or transformation of the organization with the accompanying mindset. This can have significant impacts to roles and responsibilities defined in traditional practices, such as waterfall, as we strive to decentralize decision making and interactions.
For example, in a traditional project delivery model like waterfall, the team is directed to the work based on the agreed scope and schedule baselines approved by management. As we discussed in Part 1 of the series, these are intended to closely manage risk and cost. This is often described as “command and control” and include project leadership roles such as Business Lead, Project Manager, Program Manager, etc. However, in order to rapidly respond to change, even embracing change, we need to ensure the team has the most direct access to where the change is emerging rather than through layers of management.
So, where is change coming from? It is coming from the customer, in other words, the person or people with the need for the project deliverables and best understand how it will bring value to the organization. The mindset shift is we remove barriers to those relationships and give the team the authority to make decisions on what they will work on, how it will be done, and what it will look like when it’s done. This is quite different from the project management team distributing the work according to a prescriptive scope and schedule baseline.
What is an Agile Project Manager
That being the case, do we still need Project Managers? Well, typically management would still like to know what is being delivered, when it is being delivered, and at what cost. So, yes, there is still a role for Project Managers, but the role shifts from one of detailed planning to facilitating the project team’s interactions throughout the organization. Let’s look at the three standard roles in a Scrum:
- Product Owner – advocates for the product viability and is accountable to ensure the backlog of work (compilation of user stories) is regularly reviewed to ensure the highest value work is prioritized accordingly.
- Scrum Master – orchestrator for the Scrum, the Scrum Master ensures the sprint meetings are adhered to and is responsible for removing anything preventing work from moving forward. The Scrum Master may also be responsible to ensure the information radiators are maintained daily.
- Team Member – the cross-functional team member is responsible to fully participate in a self-organizing way which enhances and overlaps the other team members’ skill sets. Ideally team members are allocated 100% to the Scrum and where the team sizes are between six and nine members.
There are variations of these, such as if you’re wanting to fully implement Extreme Programming (XP) then it would mean implementing up to six roles. However, these three roles are necessary for every scrum and, while roles such as Scrum Master can be rotated between team members, it is very important to understand who is in what role and each person’s contribution to skillsets and knowledge to achieve a self-organizing team.
Now we understand some of the core concepts of project delivery methodologies and more specifically the Agile methodology, in the next part we’ll open a discussion on how you might come up with an appropriate strategy for integrating Agile into your project management delivery model.