Demystifying Agile: Where did my role go?

Traditional projects have roles we’re all familiar with: project managers, business analysts, developers and testers. All of these roles align to specific phases of the project. Sticking with this paradigm brings certainty to the minds of those involved and gives the project a context where everyone knows what is expected of them. But Scrum doesn’t have these roles, nor their respective project phases. While for some people, this uncertainty is sufficient to stop them from adopting agile methods like Scrum, for others it’s merely a question of knowing how the roles change and why. So what are these roles? And if you’re thinking of adopting an agile method and want to know what your existing team will look like, where do each of them fit into this new world?

Pigs & Chickens

Scrum’s roles fall into two categories, oddly named ‘pigs’ and ‘chickens’, in order to distinguish between those who form part of the Scrum and, therefore, do the work, and those who are only involved with the project.

pigs-and-chickens-01

The differentiation is vital from a governance perspective because Scrum relies on commitment-based planning. In essence, this means that those who are actually going to do the work (“pigs”) are the only ones who participate in Scrum’s three core meetings (often called “ceremonies”) — Sprint Planning, Daily Standups, and Sprint Review. The pigs are the ones who determine how much work can be achieved based on their understanding of the complexity of what’s being asked of them, their capacity and capability. This leads to one of the core tenets of agile — the team being “self managing”.

Others (“chickens”) can attend these meetings or become involved at some level when invited to participate by the Scrum Master.

In Scrum, the chicken roles are still an important part of how the team consult with others over requirements and the solution. Roles like those in a project’s steering committee are still needed to approve major scope changes, commit budget, and take action to mitigate risks that are out of the control of the project team to handle. It’s the pig roles, though, that change. If you’re comfortable with the role titles of business analyst, tester, project manager, or developer, while you’ll likely still do similar tasks, you might need to look for a new title.

From BA to Product Owner

Unlike traditional project management techniques that focus on tasks and schedule, Scrum instead focuses on the scope of Products and their delivery in (typically) two or four-week iterations or “Sprints”. This shift to being Product-focused over schedule focussed also shifts the roles of the project to focus on those Products. Being Product focused requires good BAs to manage that scope and continuously break it down into pieces that can be completed in a single Sprint. This occurs continuously throughout the project, not within the boundaries of an analysis phase. In this respect, the BA becomes the Product Owner.

As Product Owner, the BA then takes on many reporting responsibilities that are traditionally undertaken by PM, including:

  • The changes in scope to the project committee.
  • The Products that the team has committed to delivering at the end of the Sprint.
  • The Products that were delivered last Sprint.
  • The pace (“velocity”) at which the team is currently delivering Products and the estimated timeframes in which they may deliver the remaining scope.
  • The issues and impediments that were faced by the team, but were resolved.
  • The issues that require action by the project committee to resolve because they lie outside the power of the team to address and will impact the team’s ability to successfully deliver Products.

A PM doesn’t tell the BA what tasks to do. Nor does he monitor the progress of tasks throughout the Sprint. Instead, the BA simply adheres to the Scrum process — one that tells him when meetings occur with the team to talk about the ranked list of Products, when to meet with the Team at the end of the Sprint to see a demo of those Products developed, tested and in working order ready for deployment. But who owns this process? Who is responsible for making sure a BA sticks to this process? That’s the role of the Scrum Master.

From PM to Scrum Master

The Scrum Master owns and is responsible for the Scrum process. They make sure everyone participates in every meeting and looks to continuously assess and mitigate risks on behalf of the team to make sure they deliver the Products they committed to delivering by the end of each Sprint. These tasks look very similar to the role of a PM, but this is where the similarities end. A PM typically drives and manages the team by setting tasks, but in Scrum, the team are responsible for their own tasks. This legitimate power that a PM holds often impedes sharing of impediments and risks facing the team. While a team member might feel safe in sharing bad news within the team, knowing that the team will step in and help get the job done, they are unlikely to share issues with a PM knowing that this information is likely to go on record and be reported. In my experience, placing a PM with legitimate power in the role of the Scrum Master increases obfuscation behaviour amongst the team — the complete opposite of the transparency that Scrum seeks to deliver.

For traditional PMs, a successful transition to becoming a Scrum Master ultimately requires them to change their normal focus on work packages and tasks and instead move to directly helping the team adhere to the processes of Scrum. It also means stopping being an outside observer, and conduit between the team and the project stakeholders, and instead focusing directly on action that addresses any impediment to the team’s ability to deliver. Obviously, this means getting their hands dirty to rectify the situation, whether its doing analysis, planning, stakeholder engagement, change management or even coding and testing. In essence, this means holding true to a mantra of “Protect and Serve” rather than one of line management.

From Team Member to Scrum Master

If legitimate power can reduce the likelihood of sharing and transparency of emerging issues and risks, then choosing someone without this power can only enhance the desired transparency. One of my favourite things to do as a project’s Scrum Coach is to choose a member of the team to be the Scrum Master. This assumes a number of things of that team member:

  • They know the rules of Scrum and can help team members to stick to them.
  • They have sufficient expertise to help mitigate risks and take action to help other team members when impediments arise.
  • They can estimate how much time will be lost by taking on the Scrum Master’s responsibilities.

This is often not the case with a new Scrum team. So, after training I take on the role of Scrum Master and model the behaviours that the team should adopt. This form of social learning is a powerful way to set the behaviours required of the team before they are required to adopt them.

From PM to Product Owner

Many BAs have advanced through the traditional project structure hierarchy to become project managers. For these PMs, taking on the responsibility of managing the Product Backlog in the transition to an agile methodology is a natural step. They have the expertise to manage scope, through consultation with stakeholders and end-users, and break down it down in sufficiently small pieces, with acceptance criteria for what each of the Products should look like when completed (“Definition of Done”), to empower the team to deliver within the confines of their monthly Sprint. Their PM skills help them to know what to report on, how to manage risks to the scope, and how to engage senior stakeholders when their assistance is required to reduce outside influences that may adversely affect the ability of the project to deliver its goals. In the projects that I’ve coached, where this transition of role has occurred, the project has proceeded much more smoothly.

From PM to project guardian

I’ve known a lot of very smart project managers in the two decades I’ve been in IT. In my experience, these people are more than just your usual Gantt chart or scheduler. Their experience with stakeholder management, governance, risk, change management and reporting make them indispensable in complex environments that are often driven by power politics. In some instances, they are both the project’s manager and the business owner’s trusted advisor. While Scrum is an excellent process for executing a project, there are many tasks that need to be undertaken in these complex environments around the Scrum to both protect the project from interference from others and keep it moving along so that it delivers on-time and on-budget while keeping to Scrum’s requirement of a sustainable pace. In my experience, this role is not the Scrum Master, but their position in formal lines of reporting between the Scrum team and the business owner mean they have position power and expert power to wield to help the team achieve its goals. I love having a project guardian, so long as this PM remembers to respect the process rules of Scrum and remembers that his role is that of a “chicken” and not a “pig”. To me, this guardian role is where a truly great agile project managers shine.

From individual, linear process roles to a single Scrum Team

A traditional project management process is very linear. Documentation is collected at the end of each phase by a few individuals who then pass it on to those in the next step of the process. The hope is that the requirements are sufficiently documented and embedded with knowledge for others to deliver the intention of the project’s outcomes. What we know from knowledge management theory is that documentation can only ever holds a small amount of a person’s knowledge. The failure to document requirements sufficiently is not a requirements issue but a problem associated with attempting to document that person’s experience. The steps people put in place to make requirements documentation more robust and more comprehensive, therefore, are doomed to failure. The only mechanism to increase people’s understanding of requirements is for them to have a shared understanding of them based on a shared experience. This is where the collaboration and collocation of agile methods like Scrum are at their strongest.

Where an individual (or perhaps a few) used to undertake analysis and then document the outcome so someone else could deliver it, instead the whole Scrum team undertakes tasks together in order to plan, analyse, design, test and deliver Products. Through collaboration, less documentation is required to create that shared understanding of the requirements. It’s unfortunate that this led many people to believe that there is no documentation in an agile project. That’s definitely not true. But where the team collaborates well less documentation is required to build knowledge of what is needed.

So while processes used to define the roles required, many Scrum teams that I’ve coached seek out individuals with the skills required to help deliver the Products in the Product Backlog. Often, this results in a core team of a few BAs, a UX practitioner, and developers, some of who have testing experience. The team is then supplemented with expertise as it needs it. In one upcoming project that I’ve consulted on, this means bringing in a solution architect at the beginning, and then at regular intervals to help the team analyse upcoming Products, work with them to do some designs and participate in planning for future releases (“Backlog Grooming”). For me, this sort of diverse team brings about the best outcomes as there is no Groupthink to hold the team to the status quo. Ideas are openly challenged from a number of perspectives that ultimately lead to smarter outcomes. Collaboration ensures that in a Scrum team the whole is greater than the simple sum of its individual parts.

Conclusions

Scrum has a very different approach to project roles and processes that can, at times, conflict with traditional ways of managing projects. In this, the failure to adequately transition to new agile roles can often cause Scrum to fail. It’s not a failure of Scrum but because people feel more comfortable with what they know and tend to slide back into old, familiar, safe behaviours based on their previous roles. That said, Scrum requires the same sorts of skills as projects have done for decades, so there is definitely a place for everyone, whether your’re a pig or a chicken.

pigs-and-chickens-02

Part of the role of a Scrum Coach, therefore, is to help with this change and identify where people can best contribute and into what roles their skills are best suited. This will ultimately ensure the project gets the most out of its transition to agile methods.

M

Advertisements

2 Comments

  1. “the whole Scrum team undertakes tasks together in order to plan, analyse, design, test and deliver Products.” So there are tasks, of different natures. Do these different tasks produce something separate from other tasks? Are there intermediate deliverables that, lightly documented, do exist in some form?

    Also, about documenting requirements does not capture a person’s experience; so the person documenting is the same person that needs the end product? That is indeed a flawed approach. Business Analysis discovers what the sponsor/users need to do things better, it is not necessary to capture all their knowledge and experience, and I suspect it is not necessary to communicate all that knowledge and experience through collaboration; you just need enough to know what the product will be,or how the business process works that the software will support.

    And all this collaboration still produces software that is not expected to meet the business need on the first try, that you need to get feedback and go around again? I know that, unlike building a bridge , software is intangible so early failure is not a disaster… but wouldn’t early success be better?

    Obviously I have not worked in a Scrum environment, but if I was going to, these are the questions I would have.

    1. magia3e says:

      Some good questions David.

      Sprint Planning is done in two stages. In the first, the Product Owner talks with the team about what they want delivered. This could be a document, a diagram, or working software. In stage 2, the team then work out all the tasks to deliver what has been asked of them. All of the tasks must have traceability back to the product that the Product Owner wants.The team also has to work on the products in the order that the Product Owner wants. This can mean workarounds and problems with dependencies, but the discussion that happens during Sprint Planning is designed to work through these issues. But the order of the Products is ultimately the responsibility of the Product Owner.

      On documenting requirements, the team only needs to document as much as they feel is necessary to create a shared understanding of what they are required to do. Ultimately, as you’ve suggested, the team only need to document “just need enough to know what the product will be,or how the business process works that the software will support”. Scrum doesn’t *require* you to document anything else unless the Product Owner has specified it as a Product or perhaps part of the acceptance criteria for a Product.

      In terms of meeting business needs on the first try, for a new project it typically takes about 4 Sprints each of 2-weeks duration to create a skinny solution that will meet end-users needs and the criteria set out by the Product Owner. From that baseline, a Scrum team will then typically work on features that add value to that baseline. Sometimes they don’t get it quite right, even if they do collaborate with users during the Sprint to discover their requirements. But in this case, the demo is a way to see if it meets the Product Owner’s acceptance criteria, and for end-users to see it as well, and then bring any new needs, tweaks, comments and/or suggestions to the Product Owner so that they can be incorporated or corrected in subsequent Sprints.

      M

Comments are closed.