News

Harmoniously Balancing Value and Delivery

If you are new to agile - either joining an existing agile team or working in an organisation that is transitioning to agile, you may need to adjust how you think of team roles and team relationships.

The two key roles that really make agile hum are generally called the ScrumMaster and the Product Owner. A very simple introduction to these roles is to think of a ScrumMaster as performing some elements of a project manager role, and the Product Owner as performing some elements of a business analyst role. But they are NOT PMs and BAs in the traditional sense. A project team may or may not have a PM and a BA in addition to a ScrumMaster and a Product Owner. More on that later.

Just to make things a bit more confusing, some organisations are moving away from the title ScrumMaster and are using terms like Agile Team Facilitator or Iteration Manager. An iteration is what the scrum framework calls a sprint. Personally, I prefer to get that word “manager” as far away from my agile teams as possible, as I think “facilitator” describes the role much better. If the ScrumMaster manages anything, it is the process by which the team gets work done. The project is managed by the team. 

In the same vein, some organisations are moving away from the title Product Owner and are adopting titles like Value Manager or Value Team Facilitator. The implication here is that this person is not the almighty owner of the whole product but is focused on seeing to it that the product generates value for both the user and the organisation. A critical function in this role is to establish priorities for the value of features and for the timing of releases and features.

Okay, who’s the boss? In an effective agile team ecosystem, the ScrumMaster and Product Owner are a co-equal partnership that meets between the two (sometimes opposing) poles of value and delivery. They will find themselves in conflict at times, but together they need to negotiate a plan for effectively delivering the intended value. If these two people do not have a willingness to look at issues from the other’s perspective, mutual respect, or the ability to work diplomatically, you will have problems. They have to understand give-and-take.

If you think it’s difficult to have a co-owned “project boss” role, you are right, it is difficult. But as with any good partnership, this duo can be more effective than just two individuals. In situations where the ScrumMaster and Product Owner simply can’t reach an agreement, they will resort to the project sponsor to get a judgement.

Now we’re ready to look at the wider agile team, with these two roles in the central, coordinating positions. Let’s look at a diagram that helps make sense of things.

The two intersecting orbits of value and delivery contain all the key roles that come into play as a project or product are conceived, planned, executed and delivered. In the value orbit, the Product Owner is facilitating the discussions and analysis of business needs, competition challenges, user needs and expectations, and domain experts. As the project progresses, many questions will arise about how to prioritise features, functionality, costs, release timing, etc., and the Product Owner will need to answer those questions or must know who to go to and how to derive the answers to those questions.

The Product Owner must know the all-important “why” of the project. Why are we doing this - what is the value to the business, and what is the value to the customer or user? The Product Owner role is a very challenging and demanding job. It requires someone who understands both business and customers, and who is willing to learn enough about the technical issues to collaborate effectively with the technical team members. A good Product Owner asks lots of questions, is a good listener, engages with all key stakeholders, makes informed decisions, and is willing to stand by those decisions.

If the Product Owner does not have a deep understanding of user experience or customer experience research practices, I like to see the Product Owner team up with a seasoned experience designer to flesh out the user research part of the work. That includes being engaged in user testing of prototypes and early releases. A Product Owner that is not open to learning that initial assumptions may not be validated by testing is not working in an agile manner.

In the other orbit, the ScrumMaster is working with all the delivery roles to plan and execute the “making it” part of the project. Planning the scope (effort, time, sequencing) of the project allows the Product Owner and ScrumMaster to agree on how to balance out value goals and delivery pragmatics. The ScrumMaster will need to answer questions (or know where to find the answers) that allow these balances to be determined. This usually means leading/facilitating the team in the various agile practices that create a good project plan - user story mapping (working from and with the product owner’s project goals and user stories), release and sprint planning, behaviour- driven development, agile estimating and tracking, user testing to validate value assumptions.

Although the two orbits look separate, there is a lot of collaboration, and the best agile teams really feel like one team, not silos or empires or warring parties. A good Product Owner works closely with designers to better understand user needs and works with user testing to validate assumptions about value. A good ScrumMaster understands why some features are more important than others so that he or she can plan ahead to sequence work appropriately.

If the Product Owner and ScrumMaster are seen by all team members to have a healthy relationship that encompasses both learning from each other and challenging each other in a respectful and productive manner, they set the tone for the entire team. This is critically important for an agile team to be at its best.

I mentioned earlier that a team may also include a project manager and/or a business analyst. In those cases, the project manager is often supporting more than one project or is doing the tracking and reporting aspect of a very large project. The ScrumMaster is focused on the near-term scales of the current sprint and the upcoming release, and the project manager is using the data provided by the project team to work at the larger and longer-term budget and schedule scales. A business analyst is likely working with the Product Owner to provide insights into more technical or detailed customer/business analysis to support the gathering of requirements and/or the agile version of requirements - user stories. 

As for the other roles in an agile team, the shift in responsibilities and function is not all that great. Developers write code, testers test, project managers collect and report budget and schedule information, subject matter experts do their thing. The key difference is that they all need to recognise that they will need to expand their desire to understand and contribute to the value that is being generated for business and user. 
Read background papers, ask questions, respectfully challenge assumptions, accept the need to make changes based on user feedback. An agile team member does not sit around waiting to be told what to do. An agile team member is actively involved in understanding the “why” of the work and is always on the lookout for ways to add value to the mission.

If you have team members who are afraid that agile sounds to them like more time-wasting meetings, let them know that a good agile team only gets together for short daily synchronisation meetings and end-of-iteration/release retrospectives, and all other “meetings” are more accurately described as collaborative production workshops where real work gets done. (Okay, I’ll admit that this is an ideal that not nearly enough agile teams get good at right away, but a good agile coach will help a team get this working properly.)

Let me use this as one more opportunity to pitch for the value of retrospectives. An agile team member’s role and responsibilities may need to shift over the course of a project. Analysis of how a team is working and adjustments that will make things work better are ideally addressed as a group when the team is all together in a retrospective. Agreements reached face to face on how to adjust responsibilities and processes are usually accepted and adopted more successfully than when some “management” cabal makes a pronouncement of a change to how things are going to work. A key principle of successful agile project management is “Managers should manage the context in which the teams work; let the team manage the project.”

If you are on an agile team, be a curious, courteous collaborator. Enjoy achieving good things together.

Post by Jim Simmons