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.

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

Kindness is the Missing Agile Value

The agile community is vibrant and passionate – full of people with great ideas on how to deliver valuable work. It can also be a difficult place to visit. We need to fix that.

Quinn Dombrowski | Hey Listen! | Flickr

Quinn Dombrowski | Hey Listen! | Flickr

To change the heart and mind of another person you first have to understand where they are coming from. You learn their story by listening. I don’t mean the kind of listening where you wait for your opportunity to drop your agile knowledge on the someone.

I’m talking about actively listening to the person and asking clarifying questions. As you gain knowledge about the person you can begin to make suggestions that are relevant to their present situation.

This does not mean that there will not be resistance to your scrum or agile suggestions. People not used to “just in time” planning or “self-organization” will likely not understand the concepts on the first pass. They will probably reject the ideas immediately.

This happens for a number of reasons:

  1. Fear:  Change is scary. It makes your problems transparent and places you in a vulnerable situation. Change means you are taking on something that is new to you. What if you look stupid? What if you fail?
  2. Success:  Management and project leaders have built careers on waterfall practices. Many have found success and promotions by adhering to predictive processes and practices. Convincing these people that agility is a more productive path is challenging.
  3. Culture:  Even if the results are not perfect – half of all waterfall projects struggle to deliver – people like the comfort of a culture they know and understand. In an agile world many traditional project behaviors do not play well. The rules change.

What this all boils down to is a user story that we are all working against when promoting agile in our organizations:  AS A PERSON I WANT PREDICTABILITY IN ORDER TO FEEL SAFE.

It is a tough nut to crack. But this user story is our reality. Where do we begin?

Be kind.

Do you remember when you were first introduced to agile? For me it was reading Kent Beck’s Extreme Programming Explained. I loved that book. It just made sense to me. And over the past 12 years since reading it, I’ve worked on my agile game. Guess what? I still struggle.

The truth is we all struggle. So be kind!

Agile is nuanced. And it is hard. If it wasn’t hard, agile coaches would be out of work and you wouldn’t be reading this blog. “It depends” is a common answer in our world, we work hard to push new ideas, and the agile space changes constantly. So be kind.

Being kind means that we accept that the first sprint of a new scrum team isn’t going to be perfect. It means that when answering a question online we do not belittle or berate people who are honestly seeking insights and feedback. It means we listen first, then speak.

Kindness is also shown when we are patient with those who still cling to their predictive processes, waterfall tendencies, and command and control mindsets. The path to agility is a marathon, not a sprint. It takes time to create new habits and practices. So be kind.

People do not show up to work with the intention of ruining your day. They have many of the same pressures that you do: spouse, kids, bills, and bosses. I believe that most people want to do the right thing. Let’s be the humble servant leaders that the agile principles call us to be and help them come around to the agile way of thinking. Listen, learn, and lead.

And yes, let’s be kind.

Question: Do you have a story about someone taking the time to help you learn agile? How did someone in the community make an impression on you? You can leave a comment by clicking here.

Scrum: Velocity Measures Story Points, Not Productivity

Scrum teams rely on metrics to inspect and adapt. Taken too far, the metrics tend to lose value and in some cases cause harm.

Robert Donovan | Velocity | Flickr.com

Robert Donovan | Velocity | Flickr.com

Last week I wrote about 5 agile metrics to measure high-performance scrum teams. At the top of the list was the most controversial metric that scrum teams use: velocity. This seemingly simple metric is just a measurement of how much effort a scrum team can complete within a given sprint.

Velocity is – in its simplest form – the sum of the story points completed in a sprint.

The temptation that many organization face is to turn velocity in to a performance metric.

For instance, I was recently asked what I thought about setting an objective to increase the team’s velocity by 10% by the end of the year. My answer: It’s a terrible idea.

  1. Encourages gaming:  An intelligent scrum team will realize that if they gradually inflate their estimates over the course of a year they will hit their 10% objective – WITHOUT delivering more value to the organization.
  2. Increasing velocity is not the goal of scrum:  We are interested in delivering valuable, high quality software to our companies in a sustainable way. How does a 10% increase in velocity get the scrum team there?
  3. Quality suffers as a result:  A scrum team that is forced to increase velocity will have to make tradeoffs to complete the additional stories required to get the numbers higher. Quality inevitably suffers when these types of decisions are made.
  4. Lots of unknowns:  Scrum team members leave the company, they get sick, and go on vacation. An estimation can also be way off – it is an ESTIMATION. If the scrum team learns something new about a story, velocity can dramatically go up or down.

Another idea that managers try is to compare the velocity of one scrum team with another. This is usually an attempt to normalize velocity across multiple scrum teams. It’s a meaningless comparison as scrum teams have different skills, goals, tools, and approaches to estimating work.

Flame wars often flare up over questions like: “Does a scrum team get credit for the story points related to bug during a sprint?”

Some scrum team members say, “Yes! We did the work and it should show on our velocity.” Others say, “No way, you already got credit for that story and are now cleaning it up. No double dipping!”

Mike Cohn did a great job of answering the question here. Essentially, he says pick whichever way makes sense to your team and be consistent. Easy, right?

Questions like these come up regularly and show a general lack of understanding of how velocity should be used.

Velocity is a limited metric that can only tell you what you achieved in the past and could possibly do in the future. During sprint planning it can help a team avoid over committing. During a sprint retrospective an up or down trend in velocity could lead to a discussion about the team’s definition of done or other team practices.

And there is the value that comes from tracking velocity. It is in the conversations that it causes the scrum team to have. These discussions are opportunities for the team to inspect and adapt their practices. The new insights will hopefully lead to more valuable, working software being delivered to the organization.

Which is important because according to the Agile Manifesto, “Working software is the primary measure of progress.”

Question: Which metrics do you use to drive conversations on your scrum team? You can leave a comment by clicking here.

How Do We Get Back to the Values and Principles of Agile?

Unfortunately, I was not able to attend Agile 2014 in Orlando this year. Fortunately, the agile community loves to share. While reading the many blogs and tweets from the conference, I spotted a trend:   Scrum co-creator, Ken Schwaber, wants the word “agile” back.

Ged Carroll | Pow | Flickr

Ged Carroll | Pow | Flickr

 “What is Agile?”

After returning home from Agile 2014, Mr. Schwaber offered an answer on his blog.

Any software activity that conforms or attempts to conform to the values and principles of the Agile Manifesto for Software Development.

For those of you that are new to agile and scrum, The Agile Manifesto for Software Development has 4 value statements that drive the activities and behaviors of agile teams.

  1. Individuals and interactions OVER process and tools.
  2. Working software OVER comprehensive documentation.
  3. Customer collaboration OVER contract negotiation.
  4. Responding to change OVER following a plan.

That is, while there is value in the items on the right, we value the items on the left more.

The second question that Mr. Schwaber addressed in his post is:  “If you could add another value to the Agile Manifesto, could you state it?

His answer is excellent.

We value practices, tools, consulting, coaching, and software organizational work that continuously improve their adherence to the Agile Manifesto OVER Tools, products, methodologies, processes, practices that only use the word Agile to market themselves to make money and whose correlation to the Agile Manifesto is coincidental.

The latest scaling trends in the agile community feel like nothing more than money grabs. In fact, according to posts on Twitter, Mr. Schwaber said just as much during his talk:

So where do we go from here?

There are upcoming events that have embraced the sentiments that Mr. Schwaber shared. These groups are working hard to get agile coaches and agile teams to put the spot light back where it belongs – on the values!

On September 26th – 28th the Agile Coach Camp is taking place in Indianapolis, Indiana. This “un-conference” seeks to push the limits in guiding software development teams, managers, leaders and beyond, while staying true to the values and principles at the core of the Agile movement.

The ideal attendee is a passionate agile practitioner who is active in the field and excited about sharing what they’ve learned.

Agile Coach Camp is a peer to peer learning experience in an OpenSpace setting with Deborah Hartmann-Preuss  facilitating this year.

If you also feel that the agile community has drifted away from the core values, this Agile Coach Camp is an excellent opportunity to connect with agile coaches who share your concerns. The conference tickets start at $89.00 USD.

You can find more information about the conference here:  Agile Coach Camp | Indianapolis, IN | September 26th – 28th