The audience was full of product owners and project managers interested in the daily life of a ScrumMaster. What does this person do? (Like it’s a mysterious animal out in the wilderness.)
A seasoned panel answered questions and gave insights into their experiences with the implementation of Agile in companies both big and small.
The big questions that were discussed:
- What happens to the project manager role when a ScrumMaster exists?
- How are companies adapting to Agile?
- Can a company be successful doing “Agilefall” (a combination of Agile and Waterfall)?
Let’s start with the project manager. The reality is that the traditional project manager role changes when a ScrumMaster exists. Rather than managing the day-to-day tasks of the team, the project manager will take on a more strategic position providing program and project leadership. This includes stakeholder management, coordination of resources between multiple teams and projects, managing the budget, and assisting with long-term project and resource planning.
One other interesting item to be noted: In the current climate when presented with the need for a ScrumMaster in teams, the project manager (based on skill set and desire), will often change roles and become either a product owner or a ScrumMaster, rather than stay in project management. Overall, this gives the project manager many opportunities to diversify their skillset and show value in several different roles.
How are companies adapting to Agile? One of the panelists said, “When adopting Agile, it’s important to think about whether you are doing it to be fast, or if you truly want to adopt Agile into your company. Is this just a buzz word, something trendy that you want to try? Or are you truly dedicated to the methodology?”
In order for this methodology to work, Agile has to be adopted at all levels of an organization, from the top down, with full support. So how is full adoption going? It’s certainly a challenge in larger organizations. There, the “Agilefall” concept is alive and well. It is very common for companies to embrace the continuous input of Agile while keeping current meeting habits, documents, and reports. They are putting teams into sprints (small timeframes of work) but continuing with most other processes.
During the TAO discussion, the crowd got quite intense when talking about adaptation. One person stated that companies often have a “Pollyanna” ideal of what is possible with the methodology. In reality, it’s extremely challenging for teams to wrangle stakeholders daily to make Agile’s decision tree work. The tight timelines to complete the work can be hard to achieve. And the estimating process is often flawed, which can be a budgeting nightmare on time and dollars.
I have practiced Agile in five organizations now. Agile does have its flaws, just like any other methodology. But when it works, it’s the best software development process I have ever seen. It does require a significant amount of adoption and support by the organization. In my experience, companies with many layers of middle management have the most difficult time.
Agile requires a small amount of stakeholders giving continuous input to a team on a daily basis, thus removing roadblocks for the team quickly. If the process is clogged with the schedules of management who can’t attend but MUST have input, it is extremely difficult to move forward, and the process is broken.
In the pursuit of software development excellence, Agile and its effects on an organization is currently a very hot topic, and will continue to be for many years to come.