[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.

Bad Agile Management Burns Scrum Teams

Last month Giles Bowkett wrote a scathing blog post about scrum called: Why Scrum Should Basically Just Die in a Fire. It’s a provocative article that shows how damaging bad agile and scrum can be to a team.

Ms. Glaze | Flame | Flickr

Ms. Glaze | Flame | Flickr

I’m not going to go point by point and argue with Mr. Bowkett about his experiences with scrum. They are his experiences, and they are truly awful. I have sympathy for him and those who have been burned by a botched agile transformation.

With waterfall, teams know what they are signing up for at the start of a project. They know there will be problems and that a death march is likely. They also know that the date set at the beginning of the project is likely wrong, but still they soldier on.

But with agile and scrum it’s supposed to be different. The agile manifesto is a developer play aimed at making the lives of engineers better. Scrum specifically puts the team in control of how they accomplish their work. Everything should be great.

But often, it isn’t.

Mr. Bowkett makes this point by calling out many common scrum anti-patterns that he has experienced:

These are all valid – and unfortunately common – problems on scrum teams. However, the conclusion that he draws from the existence of these problems misses the mark.

In other words, in its best-case scenario, Scrum’s a dog-and-pony show. But that best-case scenario is rare. In the much more common case, Scrum covers up the inability to recruit (or even recognize) engineering talent, which is currently one of the most valuable things in the world, with a process for managing engineers as if they were cogs in a machine, all of equal value.

Rather than cover up individual inabilities, scrum exposes the bad practices of organizations. Quickly. Work becomes transparent, impediments become obvious, and old practices become extra painful.

The culprit here are manager who thought they were getting hyper-productivity for free. They want the benefits of scrum, without having to change.

Mr. Bowkett’s problem is with lousy managers, not scrum.

The agile community is also partially to blame. The tendency is to focus coaching and training on the scrum team. But it is the management team members that we need to be working on the most. Bad scrum cannot take root in an organization that embraces the scrum values from the top down.

Part of embracing the scrum values is accepting the twelve principles of agile from the agile manifesto, which Mr. Bowkett also railed against.

I don’t think highly of Scrum, but the problem here goes deeper. The Agile Manifesto is flawed too. Consider this core principle of Agile development: “business people and developers must work together.” Why are we supposed to think developers are not business people?

We’re not. The intent of this agile principle is the end the “us vs them” mentality between IT and “the business”. With Scrum, the expectation is that the product owner is co-located with the development team and available to answer questions about the product backlog items.

This isn’t a slight against the business acumen of developers. It’s a call for close collaboration between stakeholders and engineers. How else can the development team know if they are working on the most valuable features for the business?

Question: Have you been a part of a poor agile transformation? What went wrong? How could things have gone better? You can leave a comment by clicking here.

Agile Coach Camp 2014 Was A Huge Success

During the closing circle of Agile Coach Camp 2014 our facilitator – Deb Hartmann Preuss – asked us: Which word described our experiences during the conference? The word that immediately came to mind was “humbling”.

CS | Share | Flickr.com

CS | Share | Flickr.com

Agile Coach Camp is an open space event. It’s an “unconference” where agile coaches network and develop relationships while inventing ideas, concepts and practices. The attendees come up with high-level topics and create their own conference agenda – better known as the marketplace.

They then gather around the topics that interest them and collaborate, plan, discuss, and dig deeper as a group to develop new “things”. You can fine more information about the open space concept here.

One of the interesting parts about this format is that the presenter is actually a facilitator. They are responsible for proposing a problem or an idea, but after that the session turns in to a dynamic group discussion.

At this year’s Agile Coach Camp, some of the biggest names in the industry showed up. People like Diana Larsen, Esther Derby, Don Gray, George Dinwiddie, and Tim Ottinger facilitated and presented alongside the other 90 participants.

While it was humbling, it was also amazing. Getting to exchange ideas with some of the best coaches in the industry was tremendous fun. That kind of interaction is simply not possible at the larger conferences. It is a level of sharing that I’ve never seen in a community.

In fact, many of the topics we discussed would not have made it in to the agenda of a traditional conference. Those events are filled with talks on metrics, agile tools, and scaling scrum.

At Agile Coach Camp, the focus is squarely on individuals and interactions and not process and tools.

To give you an idea of this, here are some of the sessions that I attended:

  1. Agile Game Mechanics (@paul_boos): A discussion on how traditional game mechanics – random event decks, dice rolling, character creation, quest mechanics, and action points – can be used to develop agile games and simulations.
  2. Conjoint Coaching (@gdinwiddie): Coaching teams as a whole and how to model behavior. Also a great discussion on observing teams and feedback loops to get to the core of what drives the way people interact on an agile team.
  3. Thinking for a Living (@tottinge): The challenges of breaking away from the factory mindset in an age where your job is to think, not assemble. We looked at how the brain works, how naps make people more productive, and even the best time to have a parole hearing (ego depletion example).
  4. BA’s Role on an Agile Team (@agilesquirrel): Where does a BA fit on an agile team? Should they be a scrum master or a product owner? Is “business analyst” a valid agile role? These questions and how to avoid a squirrel attack were covered in detail.
  5. Agile Coaching is Dead (@howardsublett): An incredibly honest discussion about whether or not agile coaching is a bubble ready to burst. We also dove in to the role that certification bodies play in the impending demise of the agile coach, along with what agile coaches can do to change direction and bring value to their customers.

The outcomes of these talks led to what many of us called “ideas too big to tweet”. The conversations were rich and we all walked away with new ideas and more importantly new friends.

This is now my favorite “unconference” that I will keep on my schedule for years to come. Next year Agile Coach Camp is in DC. I hope to see you there.

To read more about Agile Coach Camp 2014 and  the sessions you can visit the event log site here.

Question: Have you attended a conference that changed the way you look your work? Your life? Please share in the comments below. You can leave a comment by clicking here.

The Transition from Project Manager to Scrum Master is Hard

After years of following the PMBOK and delivering projects using traditional project management methods (waterfall) your organization has decided to try out scrum. What are you in for and how much is it going to hurt?

Business Man |Flicker

Business Man |Flicker

The short answer is:  a lot.

I once attended a one day workshop on scrum led by Ken Schwaber and a few other instructors as part of a Microsoft ALM conference. It was a great experience that made an impression on me.

Towards the end of the day, I asked one of the instructors which role a project manager should ideally transition to during an agile adoption. Many in the room were expecting to hear an answer of scrum master or maybe even product owner.

Instead he replied, “Perhaps a project manager could test code…but even that’s unlikely.

I was not surprised.

Having lived through the change from project manager to scrum master I understood the answer. Look, I know this is not what people want to hear, but it is very difficult to make the switch from a traditional project manager to a scrum master.

I’ve written about my struggles with giving up the command and control mindset. The pitfalls during this type of transition are many and you – as a newly minted scrum master – are giving up many of the tools and techniques that brought you success in the past.

In fact, I think it’s abusive to force traditional – PMP certified – project managers become scrum masters. The skills and mindsets are wildly different between the two roles.

For those willing take the leap and learn something new, I’ve come up with 3 thoughts to help you along when things get tricky:

  1. Servant leadership is all about enabling autonomy:  As a scrum master your highest goal is to foster a self-directing team. You are empowering people to make decisions about how their work gets done and thereby am creating the conditions necessary for people to do their best work. Daniel Pink’s “Drive” is a great place to start to learn more about this concept.
  2. Promote the whole team concept whenever possible:  The last thing you want to do as a scrum master is single someone out on the team. Your goal is to instill the mentality of “we are all in this together” whenever possible. Protect the team from outside influences and help them all row in the same direction.
  3. When in doubt, ASK THE TEAM:  You are no longer the smartest person in the room. Actually, you never were. Sorry. The team is smarter than any one person and is capable of figuring out incredibly complex things together. Not sure what to do next? Ask the team AND wait for an answer. Someone will eventually speak and a great conversation could follow.

Clearly, command and control is out the window. Scrum masters do not dictate how much work the team does. They also do not have direct authority over the scrum team members. But these are the tendencies that traditional project managers will have to fight against as they learn how to be a scrum master.

We learn scrum iteratively. My bonus tip is to practice introspection. After a difficult team meeting or a situation that you feel you could have handled better, take the time to think about how you will change things for next time. Becoming aware of your tendencies and behaviors is the only way to correct them and move forward.

A book to help you become a great scrum master is Geoff Watts book, Scrum Mastery: From Good to Great Servant Leadership. This is the guide to getting in to the mind of scrum master. My copy has copious notes and quite a few highlighter marks. Highly recommended!

Question: What was your experience like when you made the move to Agile? Do you have a tip that you would like to share below? You can leave a comment by clicking here.

Do Scrum Teams Need to Be Collocated?

Where waterfall projects went wrong is where agile principles were born. The war room – gathering the team in one location for a short burst of effort – is a perfect example of this concept.

camknows | War Room | Flickr

camknows | War Room | Flickr

I remember early in my career working on a distributed team. My team was on the east coast while a fellow developer led a team on the west coast. We were struggling with getting both teams in sync on how to use the latest internal API’s.

Code was changing rapidly and the written word didn’t have the bandwidth to keep up. Instant messenger worked ok, and emails got some of the points across. But there was still a major gap in communication.

Finally, after way too many late nights of spinning our wheels, I stormed in to the CEO’s office and asked, “Can we just fly out to the west coast for a few weeks and get this figured out?”

Surprisingly he said, “Go.”

Once the teams were together, we immediately setup a “war room” and got to work. It took a few weeks, but having the team together in the same room made a significant impact on our progress. I think 3 key things changed once we were together that helped us past our issues:

  1. Feedback was immediate:  The teams were pair programming and peer reviewing features as they were written. Anyone on the team could see or hear what was going on and could interject as needed. No lost emails or missed chat messages to hold us up.
  2. Conversations gained context:  Instead of suffering through the limits of 300 word emails, people could collaborate. The combined team organized in to groups based on the current user story and got to work. Questions were answered and whiteboards were used to clear up any misunderstandings. No mass email could possibly compete with these results.
  3. Face time made a difference: Non-verbal communication IS communication. Your face often says more than your words. So can your body language. These cues enrich the dialogue and help foster stronger relationships and trust between team members. An emoticon in an email just doesn’t cut it compared to a real smile. :-)

Clearly, the co-location of the team for a short time made a major impact on the project. While we were able to carry some of the momentum of that trip in to future releases, we were never as effective apart as we were together.

Back to the question that this post posed:  Do scrum teams need to be collocated? I don’t think it’s the end of the world if you are on a distributed team. Being aware of the moments where face to face meetings are necessary is critical to success. Other tools like webcams can also help. But you are leaving team capacity and trust on the table when you have distributed teams.

My preference is a scrum team in one location.

Question: That is one of my more intense experiences about what happens when a team is not co-located and the project goes bad. What have you seen on your teams? How have you made distributed teams more efficient and effective? You can leave a comment by clicking here.

Encourge Your Scrum Team During An Agile Transformation

Adopting scrum is hard. When organizations decide to take on an agile transformation, the scrum team needs coaching and encouragement.

Steve Rideout | Group Hug | Flickr

Steve Rideout | Group Hug | Flickr

In the midst of an agile transformation, a project manager asked to join me for lunch. We sat down and I immediately sensed that she had some questions about scrum. I was the only Scrum Master at the company and she needed help.

She asked about hybrid models and if scrum and waterfall can co-exist. Rather than use these questions as an opportunity to understand her worries and fears about the move to scrum, I went on a rant against waterfall. Why would anyone want to keep waterfall practices, they’re what lead to failure, right?

My colleague smiled, finished her lunch and politely left the room. I blew it. Later I realized that she wasn’t defending waterfall. The idea of moving to scrum terrified her. She was very successful as a traditional PM and was uneasy about the upcoming change.

I did nothing to help her.

I wasn’t kind.

I talked to this project manager a few days later and we ended up having a great discussion about agile. But my initial mistake stayed with me. I think there is more here than just a mishandled discussion.

I realized that agile transformations scare people…a lot.

Scrum Adoption Personas

When a scrum team talks about story cards, they sometimes use personas. A persona is an example of the type of person or role that would use an application. Personas are also at play when an organization decides to adopt scrum.

  • Brian the manager is still a number of years away from retirement, but is now worried that self-organizing teams means that his role as a leader will be diminished.
  • Bob the programmer loves being the hero coder, but realized that due to team ownership of tasks and code that his style will no longer fit well on a scrum team.
  • Lenny the tester has heard that scrum and extreme programming (XP) incorporates testing in to the development process and now worries that he is out of a job.
  • Bruce the business director loves Gantt charts and project plans during status meetings, but has heard that he won’t get these project artifacts anymore. He’s worried about how the team will deliver without a documented plan.
  • Jenny the project manager who went to a scrum master class and was told by the teacher that there is not a project manager role on a scrum team and that PM’s don’t typically make it through agile transformations.

Depending on your team size, there are many more of these personas in your organization. And they are acting against your agile transformation.

Once we know the personas at play, we – as agile coaches – must be encouraging. What does that look like? Let’s go back to the story that I opened with.

Instead of trying to correct my co-worker, I should have been more encouraging. Listening to her concerns should have been my priority. This is a far better approach than lecturing someone.

I also should have helped her see how her PM skills and knowledge of the organization could translate to a Scrum Master role with a change in mindset and practices. That is encouragement. It’s a boost to a person who is afraid of what’s coming.

To me this approach encapsulates the agile value of individuals and interactions over process and tools.

Question: Which persona do you run in to the most when adopting scrum? How have you approached that type of person? 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.

Scrum Teams Must Set Goals for Their Agile Metrics

Knowing what you want to find before you start looking seems like common sense. Yet many agile and scrum teams blindly gather metrics without really knowing what they want to learn from the data.

Erika | Target | Flickr

Erika | Target | Flickr

The way that most scrum teams approach agile metrics reminds me of the exchange between Alice and The Cat in Lewis Carroll’s classic Alice in Wonderland.

In this scene, Alice has come to a fork in the road and is unsure which way to go:

Alice: Would you tell me, please, which way I ought to go from here?
The Cat: That depends a good deal on where you want to get to
Alice: I don’t much care where.
The Cat: Then it doesn’t much matter which way you go.

Alice did not have a goal in mind while she was traveling along the road, and neither do most scrum teams when they set out to capture agile metrics.

Scrum teams can quickly become enamored with the amount of data that can be collected during a sprint. Story points, velocity, cost per story, cost per story point, throughput, number of stories per sprint, escaped defects, team health, and customer satisfaction are just a few examples off the top of my head.

Give the wide range and complexity of agile metrics that we could capture, we should accept a simple truth about these calculations:

The agile metrics that scrum teams collect are meaningless unless they are driven by a goal.

Why do you track velocity sprint after sprint? Because a training class said to? Or because you read about it in a blog post? No way!

There should be a problem that the scrum team is seeking to either solve or understand with every agile metric that they are collecting. With velocity, a scrum team could be trying to gauge their sustainable pace. Or perhaps they want to provide a means to help the product owner with release planning.

The actual goal is not as important as making sure that the team has one in the first place.

During a particularly difficult sprint retrospective meeting, one of my scrum teams noticed that they were struggling to deliver all of the stories that they committed to during consecutive sprints.

After some discussion, the team decided to track estimated story points per sprint and velocity. The difference between the two numbers would be called “found work”.

The scrum team decided that the goal of tracking these agile metrics – and particularly “found work” – was to measure changes in effort over the course of a sprint. The team felt that effort increased over time, which cause them to miss their sprint goals.

After a few sprints, the scrum team learned that the estimated effort was significantly increasing. But the numbers cannot tell you where the problems actually are. The root cause could have been one of many things:

  • Perhaps the scrum team was not properly grooming their product backlog items which led to “found work” during the sprint.
  • Maybe the scrum team’s definition of done was too stringent given their level of engineering practices which caused an increase in effort to deliver the stories included in the sprints.
  • It’s even possible that after digging deeper the scrum team learned that the relationship between the scrum product owner and the stakeholders was strained which led to poor communication and incomplete product stories.
  • Progressive elaboration could also have been taking place. The scrum team could simply be learning throughout the sprint and everything could be ok.

With the goal of their agile metric work realized, the scrum team focused on the problem during their next sprint retrospective. They were able to realize the high “found work” metric meant that too many epics were being added to the sprint backlog.

Not grooming their stories and slicing them in to smaller pieces hid much of the complexity that the scrum team was agreeing to take on sprint after sprint.

This particular team added a “3 touch rule” for stories to their definition of done. In order for a story to be eligible to be added to a sprint backlog, it had to be groomed and estimated at least 3 times by the team. This change led to the scrum team being more consistent at hitting their sprint goals.

Metrics are alluring, but they can also be deceptive and more importantly abused. Scrum teams should be intentional about how they collect agile metrics, the goal of the data, and what decisions will ultimately be made. Otherwise, why go to all the trouble of collecting the data in the first place?

Question: Does your scrum team collect metrics that do not have clear goals assigned to them? How are these agile metrics used? 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.

#NoEstimates Does Not Stop Agile Metric Abuse

The #NoEstimates crowd wants the agile community to stop estimating stories on scrum projects. Their reasoning:  story points and velocity calculations are gamed and abused.

Christina Welsh | Metric | Flickr

Christina Welsh | Metric | Flickr

And they are right. Management teams, scrum masters, and product owners abuse these numbers…often. But getting rid of agile estimation and a scrum team’s velocity calculations is not the solution.

In fact, you lose quite a few benefits that estimation brings to the scrum team:

  • The conversations that arise from planning poker tends to smoke out hidden issues and drives whole team learning about the story being estimated.
  • A groomed and estimated product backlog gives a transparent view in to the work that the team is getting “done”.
  • The Product Owner has the ability to forecast product releases based on the velocity of the team – driven by the estimates.
  • The development team can use velocity and other agile metrics to drive continuous improvement and to help gauge what their sustainable pace is over time.

The benefits of the agile estimation process leads me to think the #NoEstimates group is chasing the wrong problem. Let’s looks at the reasons to ditch estimating story points and calculating velocity given by some of the more visible proponents of #NoEstimates practices:

The charge filed against estimations and velocity are not new. I’ve covered the abuses of velocity and the gaming of estimations in past posts. Where I disagree with the #NoEstimations group is that the abuses are the fault of the metrics themselves. Estimates and velocity are just numbers.

The problem is the conflict between traditional management and agile teams.

In his recent blog post – Agile Coaches – We’re coaching the wrong people!?!?Bob Galen cuts to the heart of the matter:

Instead of taking the easy road (and money) by mostly training & coaching teams, I’d like us to focus on partnering with and training the management tiers within organizations. In fact, I’m starting to think we’ve been avoiding these folks.

Picture a newly minted scrum master, the ink on their certification not even dry yet, marching in to a meeting with traditional managers and trying to explain how velocity is a team metric, not a management tool.

The scrum master doesn’t stand a chance.

Clearly, management are the very people that need to have a solid understanding of agile principles, practices and values if any meaningful organizational change is going to take place. And we have not helped them get there.

Mr. Galen touches on this as well.

As I reflect on my most successful coaching gigs, these ratios come through—in coaching, conversations, training, and simply influencing change. The middle management tier in organizations, comprised of team leads, managers, and directors, needs the most help in making the transition. And they’re in the position to do the most with the coaching, helping to sustain and grow it.

#CoachingUp is the better way to solve the abuses that the #NoEstimates fans use to justify their movement. Simply deciding to not provide estimates adds to the already widening gap between traditional management and agile software development teams.

As agile practitioners, we should work with our management teams at all levels to get them the knowledge and information that they need to trust us to deliver our work. Otherwise, it does not matter how you decide to slice your stories. Points or not points, they will still seek traditional ways to manage our agile teams.

Question: It’s your turn! Do you think it’s time to stop using story points? Have you seen situations where #CoachingUp helped? You can leave a comment by clicking here.