Jim Ebert is a Project Manager and Principal Scrum Master at ThreeWill. He has over 30 years of experience as a business and technology leader with demonstrated success in managing and delivering mission-critical projects and initiatives.
We Use Agile for Project Management
Our organization follows an Agile process for project management. It’s great as we don’t get bogged down in efforts to define everything upfront, nor do we have all the traditional “overhead” that a more traditional waterfall method can require – e.g. formal tollgates. Following an Agile process allows us to flex and adapt quickly as more information is learned throughout a project’s progression.
Sometimes We Must Use a Traditional Waterfall Process for Project Management
We are a consulting organization, however. This means that we may need to work with client organizations that aren’t Agile-based and, instead, follow the traditional waterfall project management processes. In these situations, how can the differences in these project delivery processes be successfully managed? Well, the key is to find a balance between the two.
The Balance Between Agile & Traditional Project Management Expectations
As a Scrum Master, as well as an experienced traditional waterfall project manager, the following are some challenges that I’ve faced, as well as how I’ve worked to overcome them.
- Terminology – be careful with terminology. In working with a more traditional project management client, it’s important to translate Agile terminology into terminology the client better understands. For example, some clients don’t like the term “Sprints”. Therefore, other terms like “iterations” may work better. “Retrospective” is another one. “Lessons Learned” which, is more traditional, can work in this case. I’ve worked with customers who have specifically stated for our team to not use agile terminology, so be prepared to be agile in your use of terminology.
- Level of Activity/Task Identification – be prepared to work with your Agile team to be a little more specific in defining tasks, client needs, or dependencies. More traditional project management requires that ALL tasks and activities be defined up-front – from project start-up to closure. Such goes against Agile, as Agile gets more detailed as a project progresses. So, a balance between the two may need to be established, especially when it comes to tasks that have interdependencies with the client.
- “Bridge” the Relationship – as a Scrum Master, be the relationship “bridge”.
- Internally, you will likely get pushback from your team members that what the client is asking for doesn’t follow typical Agile processes. It’s important to recognize such, but also explain how and why it’s important for the team to be flexible at times to engage at a level that may be deeper than how it may normally have been done.
- From a client perspective, you will need to be deliberate to explain and manage their expectations. It’s important to find that balance between knowing everything upfront (client expectation) to iterate more detail as the project progresses (Agile expectation) Generally, I’ve found that what’s key for the client is for them to know what’s expected of them and when, as well as when any key milestones will occur, to allow them to properly plan and delivery on their internal organizational change management processes
Conclusion
In the end, the goal for every project is the same: to successfully implement the objectives and desired business outcomes set forth for the project. Overarching terms and processes may be different, but when you get down to the tactical aspects, the delivery processes and goals aren’t all that different. So, as a Scrum Master working with a more traditional project management customer, a balance between the two approaches, including terms, level of activity/task details, and collaboration levels just need to be clearly established.
