Roles and Responsibility, Essential to a High Performing Agile Team

There are three key roles for every Agile team: Product Owner, ScrumMaster and the Team. And, of course, we also have the stakeholders – our customers, managers, board of directors, etc. We’ll take a look at these roles and their various responsibilities and then we will explore how these people gel to form a high performing agile team.

Product Owner

The Product Owner is the proxy for the customer. They are available to the team during the course of their working day to answer any questions about the customer – for instance, the team may want clarification around the problem the customer is trying to solve, or their motivation, or when and where they experience said problem. The Product Owner is a necessary role in every agile team as it ensures that the Team has a subject matter expert on hand and can get their questions answered promptly to avoid being blocked.

Ideally the team would be co-located with the customer and could ask them questions directly. Often this is not the case, which is unfortunate. However, even when the Team is co-located with the customer the role of Product Owner is still necessary.

The key responsibility of the Product Owner is to paint a vision for the product and order the product backlog. They take all of the input from the customer and work with the customer to identify the highest value problems they have – ordering the backlog from highest value to the customer to lowest. Clearly we want to focus our effort on delivering the most value to the customer as soon as possible.

ScrumMaster

The ScrumMaster is another essential role for a high performing agile team. The ScrumMaster has a number of responsibilities and they have a place in both Scrum and Kanban teams – the term KanbanMaster is not in common parlance, although the responsibilities are the same.

ScrumMasters are often considered servant leaders1 as they put the priorities of the Team before their own. They help the Team overcome blocked work, defend the team from scope change, maintain the reports to measure Team progress and facilitate the agile ceremonies such as planning sessions, daily standups, demo’s and retrospectives.

A ScrumMaster may, for instance, help a team write out their Definition of Done and Working Agreement, and help the team stay accountable to themselves for these definitions which they own. Discipline is key to a high performing agile team, to any high performing team, and so the role of the ScrumMaster requires great discipline too.

Team

The Team themselves have responsibilities as well. Ultimately everyone in the Team, including the Product Owner and ScrumMaster, are responsible for the deliverable – if the quality is not up to scratch the team has no one to blame but themselves.

An agile Team works as a cohesive unit – not a loose grouping of individuals. It is important that the team strives to become cross-functional, if they are not already. Being cross-functional helps the Team avoid being blocked and assists with the flow of work ensuring they deliver value to the customer consistently and frequently, enabling a positive feedback loop.

The Team estimates work on the backlog2 to give them confidence that they can meet the sprint commitments (Scrum) or to allow them to measure cycle time with greater accuracy (Kanban). This drives predictability for the Team, and may give the Product Owner the confidence to provide delivery estimates to the customer.

Delivery is another key point, if the Team commits to deliver then they must do so. To do anything else could harm the trust of the customer. Clearly there are unforeseen circumstances that arise and impact this from time to time – these should be the exception and should be explored in a retrospective. When the team commits they also commit to stick to the Definition of Done and Working Agreement that they own.

Chickens and Pigs

Above we’ve looked at the ‘Pigs’. There are also the stakeholders, the ‘Chickens’. The Chickens have responsibilities too. But first, why do they get these terms? Think of bacon and eggs for breakfast (yum!), the chicken is involved by providing eggs while the pig is committed by providing bacon3.

So, what are the stakeholders responsible for? Customers in particular are asked to explain their problems, not merely the first layer but the root cause of their problem. The team will help the customer identify this root cause and work to address it. The customer is also responsible for providing input to the Product Owner around priorities.

Finally, stakeholders should not disturb the Team directly with new work requests, instead they should speak with the Product Owner to get these requests entered in to the backlog.

High Performance

When these roles and responsibilities are clearly defined by the Team people will not abdicate their responsibilities, will work together better, and will hold one another accountable for delivering. The underlying ethos of Agile is to be constantly looking for opportunities to improve, and this is no different. If you find that one person is better suited to being the Product Owner – perhaps they have built a good working relationship with the customer – then feel free to try switching roles.

Clearly defined roles and responsibilities give the team structure to perform at their capacity, minimise disruption, and focus on getting work done.

Now, what’s stopping you from being a high performing team? Follow @VelocityCounts to be notified of future blogs.

Enjoy this essay? React on Twitter:

  1. Is Your Scrum Master a Servant Leader? []
  2. Why do high performing Scrum teams use story point estimation? []
  3. Wikipedia: The Chicken and The Pig []

Commitments & Conscious Business

Five frogs are sitting on a log. Four decide to jump off. How many are left? Five, because deciding is different than doing.

One of the fellas at Twitter brought this to my attention last week. It is from Conscious Business. It made me sit up and take note. It made me think about a teams ability to commit, and to deliver.

The author of Conscious Business, Fred Kofman, goes on to write:

Decisions are worthless … unless you turn them into commitments.

Incidentally, the book comes highly recommended. Add it to your list.

Why do high performing Scrum teams use story point estimation?

There are two common approaches to estimation in Scrum teams: story points and ideal hours. Ideal hours is taken as ‘given what we know today, how long would this story take to implement?’ if everything went according to plan.

It turns out that us humans are pretty terrible at estimating. For example, is this story, with this acceptance criteria, going to take three or four hours? If you’re familiar with this situation you’ll agree it can be hard to tell.

As the team wants to give the client a pretty accurate idea of when they will deliver the story they ask for more information upfront and we find ourselves in the situation where we are defining everything upfront to get a slightly more accurate estimate. This is waterfall people, not what we want!

Estimate = Guess

If we remember one key thing, it is this: an estimate is a guess. That’s it people, an estimate is a guess, it is not a commitment, it is not a firm delivery date. The more time we spend talking about a story to clarify it the closer we’ll be to an estimate in hours that reflects the required number of hours to implement that story. Unfortunately we won’t be any closer to actually delivering it!

Given humans are bad a estimating we can use a relative approach to estimation. For example, what is heavier, 7000 elephants or 1 jumbo jet?

Enter Fibonacci

The fibonacci sequence is used by Scrum teams for story point estimates – 1, 2, 3, 5, 8, 13, 21, and so on. Teams use this sequence, rather than a linear 1 – 10 as it forces them to provide a relative estimate. Easier to ask ‘is that a 5 or an 8?’ than ‘is that a 6 or a 7?’. This is a similar problem to the ideal hours described above.

Further to that, reaching consensus on a story point estimate, and getting clarity on acceptance criteria is made easier with the help of planning poker. With planning poker we hand out a set of cards with the fibonacci sequence (1, 2, 3, 5, 8, 13, 21) on them to each member of the team. As the team reads out a story and the acceptance criteria each team member picks a card from their deck and leaves it face down on the table. Once everyone has selected a card the whole team turns over their cards and compares the estimates.

This has two benefits, it is a quick way to estimate and the team has a fruitful discussion about the story and acceptance criteria.

Finally, when a team uses story points for estimation there is no confusion with the customer as to this being a commitment – what would committing to ‘5 story points’ actually mean? As there are no ideal hours attached the customer is under no illusion as to the time involved. Thus freeing the team from an artificial deadline.

Want to learn more about high performing Scrum teams? Sign up now to be notified of the next blog post or podcast.

Why Agile teams want t-shaped people

On Scrum teams we often speak of ideals. While these may not be immediately attainable by the team they are things a team should strive to attain as it will assist them in becoming a high performing team. One of these ideals is a T-shaped person.

A t-shaped person is one who has breadth in a number of areas, and depth in a few. This allows that person to pick up work that, for example, includes front-end and back-end technology. The t-shaped team member may not be a wizard on the API’s, although they’ll be able to get by.

T-shaped people complement Agile teams

If we’ve got a team of t-shaped people then we’ve got breadth as well as depth in a number of areas. The team members will complement one another.

For example, we have Bob who is a t-shaped person with front-end and back-end experience. Sally is the API wizard though. How does this work in practice? Bob may pick up a story that requires an extension to the API, and he will write that. Sally may provide a code review or have included some points in the acceptance criteria to guide Bob. Ultimately they are working together to deliver value to the customer.

Cross-Functional Teams

A team of t-shaped people, each with different skills and specialities, enables team members to complement one another and form a high performing team. Teams with these cross-functional members, another way of saying t-shaped people, are higher performing as they have less internal bottlenecks and contention for one person’s time.

Of course the final benefit is that the team no longer has a single point of failure (SPOF). Should Sally leave the team then Bob has sufficient knowledge to continue on.

Want to learn more about high performing teams? Follow @VelocityCounts for the latest blogs and podcasts.

Recommended Reading for New Agile Engineering Managers

It’s a common situation. You’re a kick-ass Engineer and you have just been tapped on the shoulder for a promotion to an Engineering Manager, an “EM”. It means your VP has recognised the great work you’ve delivered, the contribution you’ve made. Congratulations!

At this stage you are probably a bit overwhelmed with questions from team members, the training sessions from HR, and dealing with upcoming performance reviews. Perhaps you’re just trying to get software out the door.

Well we want to get you up to speed quickly, and to help you start getting the maximum velocity from your agile team. So VelocityCounts has put together a list of blogs and books that you should take a weekend to read through. No doubt you’re really busy at present, being a new EM and all. Trust us, taking the time to read over this material is going to pay dividends over the coming months.

If you’re in the situation where you are preparing to become an EM this is a great list to give you some insight. However, don’t be afraid to say no to a promotion – some of the greatest Engineers make the worst EM’s, conversely some of the best EM’s are terrible Engineers. Remember, for every agile team we’re trying to work to peoples strengths. If being an EM isn’t for you let your boss know that you would prefer to go back to coding – it’s okay, they will understand1.

Managing Humans – Michael Lopp

Michael Lopp has had Engineering Manager stints at Netscape, Apple and Symantec. Exposure to a broad range of companies in Silicon Valley and beyond have given him plenty of insight into how to manage humans, more specifically, engineers. Get a taste for Managing Humans by reading one of Lopp’s earlier blogs, Managing Nerds.

These are fun to read in the morning – you’ll arrive at the office with a fresh perspective, and a smile.

Scrum Roles and Responsibilities – Agile Developer Notes

You’re now heading up an agile team. You are an Engineering Manager. Where does that place you? Are you a ScrumMaster, or more of a Product Owner? Perhaps today you are wearing both hats – ideally, that should stop.

Have a read of this and help your team identify the various roles and ensure everyone is aware of their responsibilities. It will make your life a whole lot easier!

The Principles of Product Development Flow – Don Reinersten

Still regarded as the original and the best when it comes to flow based software development. Recommended by Dave Thomas of Bedarra Research Labs every time I see him at any Agile event – Dave is a fanboy and so am I.

Flow details the approach commonly referred to as Kanban. An approach to software delivery based on the flow of work through the value stream, as opposed to timeboxed delivery as in Scrum. A great read and useful for Scrum teams too – you’ll pick up some gems and become a ‘Scrumban’ team.

What is this DevOps thing, anyway? – Patrick Debois

Patrick is the father of the DevOps movement, having kicked off the first DevOps Days back in 2009. DevOps is a movement to bring people closer together, to encourage collaboration between Engineers and their counterparts in Operations. You can’t deliver software without the folks in Operations so it makes sense for them to understand you, and for you to understand them. This also leads to an extension of the ‘Definition of Done’ to delivery to customers – no more checked in to master, on to the next task.

Read about DevOps, and recognise that it has evolved significantly since these early days, but that the premise remains the same – get out of your seat, use your two feet, and collaborate with others. Works wonders for interacting with other teams too!

Scaling Software Agility – Dean Leffingwell

Dean guides Enterprises in their adoption of agile practices. While this may not be of interest to you right now it will come in handy as your company grows.

 

Know of a great blog or book we’ve missed? Let us know.

  1. The Peter Principle: Why Things Always Go Wrong []