[QUESTION] What Do Managers Control on an Agile Project?

The number one question that I get from managers who are learning about Scrum and Agile is: What do I control on an Agile Project?

Flight Controls - Bryan Burke - Flickr

Flight Controls – Bryan Burke – Flickr

It seems like a simple question to answer, but if you go the purist route and deep dive in to your self-managing teams talk, you risk alienating the manager. After a few failed attempts at answering this question, I think I’ve found a better way to address this very real management concern.

This question usually comes up when I start talking about how agile teams are self-organizing and self-managing. Managers like the prioritized backlogs and the value tracking. Those things can be turned in to forecasts and metrics that map to their past experiences.

Self-organization feels odd to them, but they seem to get it. Self-managing teams on the other hand can lead to this kind of reaction:

“Wait, if teams self-manage, then…what do I control?”

Doubling down on self-management theory has not worked for me in the past. I’ve also tried answering this question by pointing out moments during a sprint where a manager can help the scrum team inspect and adapt their practices and the increment of software, with mixed results. And honestly, this answer is begging for more trouble than it’s worth.

During my most recent encounter with this question I gave a different answer.

A manager on an agile project controls empowerment, which drives how much and how fast value is delivered to an organization.

Every design review meeting, status report, security assessment, dashboard, metric, and inquiry take time (capacity) away from the team. This is time that could be used to get a valuable feature to a “done” state and ready to be shipped at the end of the sprint. In other words, attempting to control the project delays value from being delivered.

The impacts of trying to control an agile project can even be quantified if needed. I like to add the mechanisms that managers use – additional status reports, design reviews, and excessive documentation – to the team’s definition of done.

This creates transparency with the product owner and ensures that the scrum team takes these activities in to account when estimating their work. Future sprints can be run without the overhead of the control mechanisms to determine any differences in velocity.

Honestly, these managers have never had control of their software development projects – regardless of the methodology used. At best they had an illusion of control. Project are made up of people, not status reports. You can try to convince, coerce, inspire, or lead, but in the end people are going to do things that you cannot predict. And there isn’t a metric, meeting, or dashboard that can change that fact.

Question: How would you handle this question? I’d love to hear your take on it. You can leave a comment by clicking here.

[QUESTION] Why Do Scrum Teams Call Agile Iterations “Sprints”?

The Scrum Guide tells us what a “sprint” is and gives best practices around duration and timing, but it says nothing about why scrum teams call iterations “sprints” in the first place.

phgaillard2001 | le depart | flickr

phgaillard2001 | le depart | flickr

This question actually came from a podcast that I listen to called This Agile Life.

John Sextro, Craig Buchek, Amos King, Jason Tice, and Lee McCauley publish this weekly podcast about life as agile coaches and developers.

On This Agile Life episode #64, the topic was Giles Bowkett’s blog post – How Scrum Should Just Basically Die in a Fire. I recently blogged about this same post, but did not comment on Mr. Bowkett’s disagreement with Scrum calling agile iterations “sprints”:

Scrum’s an agile development methodology, and one of its major goals is sustainable development. However, it works by time-boxing efforts into iterations of a week or two in length, and refers to these iterations as “sprints.” Time-boxed iterations are very useful, but there’s a fundamental cognitive dissonance between “sprints” and “sustainable development,” because there is no such thing as a sustainable sprint.

The This Agile Life crew zeroed in on this criticism and mused about asking Jeff Sutherland why he decided to call scrum iterations “sprints”. Fortunately, Mr. Sutherland has a new book out called Scrum: The Art of Doing Twice the Work in Half the Time AND he answered this question:

And so my team embarked on what we called “sprints”. We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and stop to see where we were.

With the origin story in mind, the “sprint” label makes sense for scrum teams:

  1. The goal is intensity:  Scrum teams are laser focused on a sprint goal and work diligently on their sprint backlog items to turn their stories in to working software.
  2. Scrum teams take time to catch their breath: At the end of each sprint is a sprint review meeting. During the sprint review meeting, scrum teams stop to examine the sprint activities, the latest increment of software the team delivered, and the product backlog. The scrum team also conducts a sprint retrospective to examine how the team got to where they are and how they can do things better during the next sprint.
  3. Sprints are short for a reason: Mr. Bowkett is correct when he says that there is no such thing as a sustainable sprint. But short (2-4 week) sprints with time taken to inspect and adapt the work IS sustainable. Not stopping at the end of the time box jeopardizes sustainable pace as does going past the 1 month maximum sprint length.

Inspecting scrum is a great way to become a better agile practitioner. Podcasts like This Agile Life and blogs like Mr. Bowkett’s are great places to help you think about scrum and deepen your understanding about the practices that you use every day. It’s a tip that I’ve given in the past, but I cannot stress it enough as a great way to improve.

In this case, we learned that the label “sprint” is meant to give teams a sense of urgency, but with the intention of taking rest after the intense work it takes to turn sprint backlog items in to increments of software.

Question: What do you think about the term “sprint”? Does it express the right intention, or is it time to go back to “iterations”? You can leave a comment by clicking here.

Scrum Master is a Title, Servant Leadership is a Mindset

If a person believes that carrots and sticks lead to productivity, no 2-day class and a certificate on the wall can change that. But those who seek to empower people and teams can become great scrum masters and servant leaders.

Unknown | Team | Flickr

Unknown | Team | Flickr

In the comments section of my post “Help! The Scrum Master is the Impediment”, Darko asked that I cover servant leadership. Darko seems to also have experience with a scrum master who does not behave well and asked some great questions about the role:

  1. What is a servant leader?
  2. How does a scrum master serve their team as opposed to directing it?
  3. Where in practice does the scrum master meet their servant role – can you give concrete examples?

What is a servant leader?

The term servant leader came about in an essay by Robert Greenleaf title “The Servant as Leader”. In his essay, Greenleaf described a servant leader as “one who makes sure that other people’s highest priority needs are being served.

He offered these question as a litmus test to servant leadership:  “Do those served grow as persons? Do they while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?

How does a scrum master serve their team as opposed to directing it?

The change in mindset necessary to become a servant leader is incredibly hard for a scrum master who comes from command and control background. There are a few changes in thinking that can help with this transition:

  • Favor self-organization:  Don’t make decisions for the team or assign their work, ask them how they will tackle the next sprint goal. And trust them to follow through.
  • Enable self-management:   Scrum teams self-manage their work and their practices. Rather than dictate how the team will deliver value back to their business partners, work to remove the organizational barriers to their success.
  • Let teams fail:  This is more difficult than it seems. Allowing a team to “fail” and learn important lesson that will pay off down the road is difficult. But sometimes it is necessary for the growth of the scrum team. When this does happen…
  • Provide cover for your team:  Your company/organization/business will not initially understand how your scrum team works. Coach up through the management chain so that “failure” and other experiments by the scrum team are encouraged, not punished.

Daniel Pink’s book “Drive” gives insights in to what motivates people and is the best argument against command and control that I’ve ever read. This is the book that project managers making the transition to scrum master should read – and then apply the lessons to their scrum teams.

Where in practice does the scrum master meet their servant role – can you give concrete examples?

A servant leadership minded scrum master should be a servant to their team every day. By challenging the team with a probing question during a sprint retrospective or by recommending a  fist of five check to get everyone involved in a discussion, scrum masters are constantly on the lookout for opportunities to apply their servant role.

I remember a particular situation as a scrum master where I had to work with a design manager who was against scrum and agile. He insisted on design reviews prior to any code being written and would mandate technical solutions that the scrum team did not agree with.

I was obligated by my role to try to coach this person in order to make sure that the scrum team was empowered to manage their work – within the bounds of accepted corporate standards. The discussions were tense and difficult. But the team came first. Eventually, we were able to work out modified design rules for scrum teams and we went on to have many successful sprints.

Situations like that are risky. I was dealing with a member of the management team and had to walk a very fine line in order to help the scrum team and keep my job. Ken Schwaber’s warning was constantly on my mind: A dead scrum master is a useless scrum master.

But things did – and tend to – work out.

Geoff Watts wrote and amazing book on scrum masters as servant leaders called “Scrum Mastery: From Good to Great Servant Leadership”. He goes in to a lot more detail about the habits and behaviors of great scrum masters. It is an excellent resource for any scrum master looking to improve.

Thanks to Darko for asking the questions about servant leadership. I hope that I’ve shed some light on this important topic. If you have a question or would like to see an agile topic covered please send me a message or leave a comment below. I look forward to hearing from you.

Question: What do you think it takes to become a great scrum master and servant leader? You can leave a comment by clicking here.

[QUESTION] The Product Owner Says #NoEstimates From the Team. Now what?

What would you do if your Scrum Product Owner decided that customer value should be the sole focus of the scrum team and therefore wants to eliminate estimation (#NoEstimates) from the scrum development team’s process?

Kerrin Asmundson | Free Estimates | Flickr

Kerrin Asmundson | Free Estimates | Flickr

Perhaps the scrum product owner read the exchange between Neil Killick and me and decided that #NoEstimates is the way to go. Is it possible that I failed to express the benefits that estimates can bring?

Possibly.

But in this case, the answer is pretty simple. As a scrum master I would remind the scrum product owner that he/she does not have control over the team’s practices or their estimates. There is a misconception in some organizations that a product owner is a “manager”.

This simply isn’t true.

The scrum product owner is responsible for optimizing the value of the scrum development team does. This is primarily achieved by providing a well refined and prioritized product backlog.

Scrum teams are self-managing and own their processes. The team is responsible for continually inspecting their practices and results – usually in a sprint retrospective – looking for continuous improvement.

Following that explanation, I would then ask the team what they think about the scrum product owner’s request.

Scrum is a “developer play” after all. So it only makes sense to ask the team what value they see in estimating (or not estimating) their work.

If after such a discussion, the team decided to go the #NoEstimates route, I would fully support them.

There are some topics that the team would need to speak to with capacity being one of them. Forecasting for the product owner would be another. As long as the team as figures out how to meet these business expectations, then why not give #NoEstimates a shot? Scrum is based on empiricism. Inspect and adapt!

In this example, the scrum product owner decided that estimates are overhead. This sentiment is hard to disagree with. Estimates are pretty worthless. They expire quickly. When requirements change they expire even faster. Worse of all, estimates are almost always wrong.

But that is why scrum teams estimate often. We are not trying to hit a date or measure the accuracy of our estimates. Rather, scrum teams uses estimates to guide them on how much work they can complete in a sprint.

The estimates can also be used by the team to discover their sustainable pace and to forecast a few sprints out to see where stories (features) could be delivered. These activities have value to a scrum team and to the product owner during release planning activities.

But these benefits diminish if the estimates are not continually updated. During these multiple planning poker (estimation) sessions, the team learns quite a lot about the story in question and about each other. These interactions can lead to a much better team and product.

As a scrum master you should be looking for opportunities to empower your team to make their own decisions. In this case, the scrum product owner wanted to dictate how the team estimates (or doesn’t estimate) their work. Instead, the better approach is ask the team to discuss the idea and decide for themselves whether or not to give it a try.

Question: Have you ever taken an idea to the team that you may not have agreed with? What did the team decide? Did you support the decision? You can leave a comment by clicking here.

[QUESTION] Why Do Scrum Teams Estimate in Story Points Instead of Hours?

Management wants to know how long it will take to get something done. The problem is that people are terrible at estimating features in hours. Why? Because it is hard work, inaccurate, and not a lot of fun. Scrum teams have a better way – story point estimation.

Steve Dalton | Poker Planning | Flickr

Steve Dalton | Poker Planning | Flickr

Hours or duration is complex to estimate on software projects. Teams and individuals are expected to figure out how many hours a particular user story will take to implement – before doing any actual work. It’s not surprising that 60% of software projects fail at this task.

Hours have a different meaning to different people. Developers have varied skillsets, abilities, competencies, domain knowledge, and experiences. Given a diverse development team, a consensus on how many hours a user story will take to finish will be extremely difficult to reach.

For example, let’s take two developers – Senior and Junior. They have been asked to estimate USER STORY X. Senior, who has many years of experience, thinks that USER STORY X will take 5 hours to complete. Junior, who just graduated from college and is working at his first job, and thinks that it will take 10 hours to complete the story. There is no way to reconcile these estimates and reach consensus.

Even if the hours could be reconciled, the meaning behind the hour estimates are unclear. Is that 5 hour estimate expressed in ideal time or elapsed time? In other words, is that 5 hours of work assuming no interruptions, distractions, and other commitments? OR is that 5 hour estimate really 20 hours in duration because the work was spread over 3 days due to meetings, disruptions, or other life events?

Instead, scrum teams use story points – a unit of measure for the size of a user story. The actual values and units are not as important as the value of the stories relative to one another. A story that is a 10 should be twice the size of a story that is a 5. The estimate is also all inclusive. Everything that is need to get the user story completed is considered in the process.

In our case, Senior and Junior can decide that USER STORY X represents 1 story point. They could then look at other user stories on the product backlog and decide the story point value of the remaining user stories based on their relative size to USER STORY X.

This abstraction removes the complexity of estimating in hours and simplifies the estimate to a relative sizing exercise. Mike Cohn put it best in his excellent book Agile Estimation and Planning:  “A story-point estimate is an amalgamation [consolidation] of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherit in it, and so on.”

Hours based estimating is popular, but it is also more complex. It is also frequently wrong. There are many variables that are out of your control that you end up having to factor in (more guessing) or ignore (bad guessing).

Estimating is waste. Customers do not pay for estimates. You can’t claim ROI from an estimate. Scrum teams do not deliver estimates at the end of every sprint, they deliver working software. Estimates have no intrinsic value. So why invest a lot of time on them?

Since scrum teams know that they are going to be “wrong” when estimating, they use story point estimation to quickly and inexpensively size their user stories. As they inspect and adapt their work during and after each sprint, they can revisit their estimates and adjust as needed.