Agile Indy 2015 Notes

The Agile community in Indianapolis is a vibrant and flourishing group of passionate agilists and lean thinkers. They put together an amazing conference that should be on your radar for next year.

Agile Indy 2015 - Hala Saleh Stage Talk

Agile Indy 2015 – Hala Saleh Stage Talk

The highlight of the event for me was Hala Saleh’s stage talk: “My Agile is Better Than Your Agile“.

She spoke about the dangers of extremism when promoting ideas. She also made a great case for dropping the judgment and negative connotations that come along with certain “trigger” words in the agile community such as: agile project manager, PMP, #NoEstimates, management, and PM’s.

We state “People over Process”, then turn around and put people in boxes because they have the wrong letters following their name, or because they use the word “hybrid”. 

It’s a message that I needed to hear and that I very much appreciated. It’s inspired me to inspect the way that I engage with others and adapt where needed.

Agile Indy 2015 was also a special event for me professionally. I presented a talk for the first time to the sell out crowd, and had a great time in the process.

I should have been nervous, but the excellent staff of conference volunteers, the venue, and the overall vibe of the event made it a great place to debut my talk:  Help!!! The Scrum Master *IS* the Impediment!

The change in mindset necessary to become a servant leader is incredibly hard for a scrum master who comes from command and control background. As a newly minted Professional Scrum Master (PSM I), I returned to my team excited and ready to get underway with a scrum adoption. Unfortunately, I had not fully grasped the concept of servant leadership. Instead of being a change agent, I was an impediment.

I also really appreciated one of the nicest – and most humbling – compliments that hit my Twitter feed immediately after the talk.

Comments like this are why I enjoy writing, blogging, and speaking. Becoming a scrum master is a difficult journey. I struggled with it. Given the feedback I’ve been getting, so have many other people.

Below are related posts if you would like more information about this topic:

Scrum Master Heroics Can Hurt Agile Teams

Scrum teams work on complex problems. Solutions emerge during these type of projects; over time and after many sprints. When a scrum master becomes the “hero” and mandates solutions, he/she can cause lasting damage to the scrum team.

Scrum Master Heroics

Uplifting Hero – JD Hancock – Flickr

All nighters, caffeine fueled coding marathons, and last minute deployment heroics happen regularly on projects death marching to a forced conclusion. That behavior manifests on agile teams as well. But the “hero scrum master” anti-pattern surprised me during a recent exchange on LinkedIn.

A scrum master explained his role as follows:

“I would prefer to be considered as someone who managed to make the team get past the hurdles and obstacles and make it to the “Miller Time” to chuckle and laugh about how silly they behaved in reflection.”

Not exactly the model statement for self-organization and self-management.

My own struggles with dropping the command and control habit are here and here. During those episodes I thought I acted in the best interest of the team and with best intentions. And I believe that this scrum master feels the same about his actions.

With that said, the consequences of directing instead of coaching can be significant and long lasting:

  • No Ability to Experiment: When a scrum master “solves” all of the teams problems, the scrum team will not learn how to experiment. We constantly inspect and adapt our practices. Some changes work; others don’t. Dictating answers robs the team of these possible improvements and lessons.
  • Scrum Team Members Withdraw: Apathy sets in when scrum masters mandate solutions. A disengaged team can lead to silos of knowledge and individual actors as opposed to a gelled and cohesive scrum team.
  • Whole Team Concept Compromised: Every member of the scrum team contributes to and owns the project. If a hero scrum master is solving all of the problems, the scrum team can become dependent on this hero behavior. Coaching others to solve issues and impediments can help make sure that teams grow, mature, and find success together.


As the LinkedIn exchange progressed, it became clear that a bad system/environment drove the scrum master’s behavior:

  • Job Security: When I asked why the heroics were needed, he replied “Either one is a passionately participating and involved scrum master or he is someone that can be replaced tomorrow and no one may notice any difference.” Understandable, but not in the spirit of servant leadership.
  • Carrot and Stick Mentality: He also added, “Sounds to me more like letting people succeed or fail but suffer so they can change out of necessity at the cost of damaging the team’s image/pride and team spirit. This to me is something a villain would resort to.” Experiments do not appear to be valued at his company. Neither does failure.
  • Bad Scrum: The scrum master’s environment “smelled” toxic. The scrum team does not have a Product Owner. The QA team works in India and gets code nightly from U.S. based developers. The list goes on. Perhaps, without the heroics of the scrum master, nothing truly would get done at his company.

The scrum master heroics can appear to help in the short term, but over time the negative impacts – especially the loss of continuous improvement – amplify. The sprint retrospective can help uncover these issues. But once these items make the impediment list, the scrum master still has the difficult task of addressing these system issues up the organizational structure.

Being a servant leader is hard, but as the consequences above indicate, we should coach our teams to be empowered and self-sufficient and remove system impediments…even if it makes us a bit uncomfortable.

[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] How Do You Pass the Professional Scrum Master I (PSM I) Assessment?

A former co-worker reached out to me and wanted to know how to pass’s Professional Scrum Master I (PSM I) assessment. Below I describe my path to certification and how to get the most out of the PSM I assessment experience.

PSM I Assessment Certificate | Scrum.Org

PSM I Assessment Certificate | Scrum.Org

The PSM I assessment is an 80 question examination with a 60-minute time box. The questions are a mix of multiple choice and true false. To pass you must score at minimum an 85%, which means you need to get 68 questions right or better to become certified. made the interesting decision to not require a class in order to take their assessments. This means that anyone who wants to try to gain the Professional Scrum Master I credential only needs to pay the $150 fee and pass the exam.

There are many paths that people have taken to get a passing score. Here’s my path to obtaining this certification followed by the steps that I think are valuable to people trying to pass this assessment.

Before pursuing the certification path I had been working in an agile way for the previous 10 years. I started as a java developer, later moved in to project management and finally people management.

Even with 10 years of experience with agile and scrum, I decided to take the Professional Scrum Master course. I am fortunate to live close to Professional Scrum Trainer Dr. Chuck Suscheck and got a lot out of his class and subsequent mentoring on scrum and agile.

His class is excellent and gives the participants a solid basis for understanding scrum and the practices that support delivering value to your organization. He starts with values and principles and takes a deep dive in to how scrum works and how to implement scrum in real world situations.

I took the exam a few days after the class and managed to pass with a good score.

Clearly, I recommend the Professional Scrum Master course. It’s a great opportunity to learn about scrum in a group setting. The learning that takes place is valuable not only for understanding scrum, but for also creating relationships with other agile practitioners.

However, the class is expensive ($1,200+) and as mentioned earlier, it is not required to get certified. For those of you who plan on taking the PSM I assessment without taking the class, these 4 practices will help make sure you are successful:

  1. Read the Scrum Guide…Often:  I read the scrum guide 2-3 times per week. This not only keeps the scrum framework fresh in my mind, I often find myself gaining new insights in to scrum the more I read about and inspect the roles, artifacts, and practices outlined in the scrum guide.
  2. Take the Open Assessment…Often:  I don’t recommend taking the PSM I assessment until you are consistently scoring 100% on the open assessment. There is some overlap between questions on the PSM I assessment and the open assessment so you can get a few right answers for “free”. More importantly, the open assessment gives you a feel for how the real exam is administered.
  3. Favor Empowering the Team:  If you are unsure about an answer, try asking yourself which of the available options empower the team. Scrum calls for teams to self-organize and self-manage. Answers that violate these practices will likely not be right.
  4. Read and Understand the Agile Manifesto:  The values and principles of the agile manifesto are at the core of scrum. You must understand the manifesto to truly understand the “why” behind the scrum roles, artifacts, and practices.

I wish you luck as you prepare for the PSM I assessment. If you follow the advice I’ve laid out, you should have a great chance of understanding scrum at an intermediate level and passing the exam.

I’m looking forward to hearing how all of you do!

Question: What are your experiences with the PSM I? What are your best tips to help others successfully pass the assessment? You can leave a comment by clicking here.

I’m excited about being a presenter at Agile Indy 2015. This conference has a great line-up of speakers including:  Mike Cottmeyer, Maria Matarelli, Aaron Kopel, and Jason Dukes.

Date: April 17, 2015
Time: 8:00am-5:00pm
Event: Agile Indy 2015
Topic: Help! The Scrum Master IS the Impediment!
Sponsor: Click to view the full list of sponsors
Venue: NCAA Conference Center
(317) 916-4255
Location: 700 West Washington Street
Indianapolis, IN 46204
United States
Public: Public
Registration: Click here to register.
More Info: Click here for more information.

Agile Does Not Scale

The Agile Manifesto defines “agile” using 4 values and 12 principles. People embrace values and principles and act on them. Therefore, people are the practitioners…and people do not scale.



This is has been my thought process on scaling agile for a while, but I’ve often struggled to fully articulate this idea. Then I saw Gunther Verheyen’s recent post – “Agile and Scrum, actually”.

As a side note, I’m a big fan of Gunther Verheyen. I’ve mentioned his excellent book – Scrum: A Pocket Guide – many times on this blog. I follow him on twitter (@Ullizee). And his latest series of “actually” scrum posts on his blog site are fantastic.

Verheyen hit a beautiful note in the previously mentioned “actually” post that struck a chord with me.

“Values and principles are agnostic of scale.”

Awesome. He’s absolutely right. The scrum tactics, strategies, and practices are modified to align multiple teams working off of a single product backlog. But the principles and values stay the same and they apply the same way whether dealing with one team or many.

When adopting agile, the question really becomes:  How do the values and principles impact our organization?

The answer is important because when organizations try to “scale agile” they are really scaling their software development systems – their processes, structures, relationships, and practices used to deliver their products and services.

If they have not dealt with these impacts, their scaling efforts cannot possibly go well.

Question: What are your thoughts about scaling? Can teams successfully scale their systems and stay consistent with agile? You can leave a comment by clicking here.

[QUESTION] Should Scrum Teams Use Hardening Sprints?

The Scrum Guide says that at the end of each sprint a “potentially shippable” increment of software should be delivered by the scrum team. But what happens when system dependencies and other release constraints make shipping impossible? Enter the “hardening sprint”.

All done |

All done |

A hardening sprint is a specialized sprint where scrum teams work on things such as: integration testing, performance tuning, security reviews, and localization.

It is not a catchall for new features, sloppy code, bug fixes, and other work that signals poor craftsmanship. Be on alert for some of these common misuses:

  • We ran out of time and didn’t full test this feature, we’ll finish testing during the hardening sprint
  • User documentation didn’t quite get done for this feature. I’ll finish that up during the hardening sprint
  • No need to engage support | security | infrastructure now, we’ll bring them up to speed during the hardening sprint

These abuses are why many of the scrum gurus will tell you that hardening sprints are an “anti-pattern” or just flat out bad. A quick google search reveals past flame wars and pointed blog post demeaning the use of hardening sprints. This volatile territory. You’ve been warned.

However, I do not agree that scrum teams who use hardening sprints have lost their way.

It is true that by using a hardening sprint, the scrum team is admitting that they did not deliver “done” software during their preceding sprints. This is an indication that their definition of done is lacking. This could be an impediment to the team’s future success.

But this could also be an intentional decision by the organization. A pristine definition of done is expensive. Continuous integration, high test coverage, and strong devops organizations take time to build and implement. Along with a lot of money. During the early stages of an agile transformation, hardening sprints may be mandatory due to some or all of these practices not being in place. This is ok, but please keep these 3 important ideas in mind when deciding to use a hardening sprint:

  1. Be transparent with the Product Owner about what “done” means:  If “done” isn’t true until after the hardening sprint, the Product Owner has the right to know. Being open about why the hardening sprint is necessary will allow the PO to make better decisions about releases and ensure that their forecasts and product planning are more meaningful.
  2. Don’t abuse the practice:  A hardening sprint isn’t a free pass to be lazy. Keep the work within the hardening sprint to a minimum and continually be on the lookout to reduce the work that is necessary to complete in hardening sprints.
  3. Reduce the reliance on hardening sprints over time:  Your goal should be to eventually eliminate the use of hardening sprints. In some organizations this will not be possible due to various constraints, however, continually inspecting the reason for sprints and looking for ways to reduce their frequency and duration can help the scrum team get value delivered faster to their customers.

The bonus idea to wrap things up is to make sure that your decision to use a hardening sprint is intentional. By that I mean that scrum teams should have a plan for conducting hardening sprints and a long-term goal to eliminate them to the extent possible. If left to chance, many of the bad practice mentioned earlier can and will creep in to your hardening sprints.

Question: I’d love to hear your thoughts and experiences on hardening sprints. Do you use them? If not, why not? If so, how have they helped your team? You can leave a comment by clicking here.


Help!!! My Sprint Review is Out of Control!

A past co-worker reach out distressed about their Sprint Review meetings running amuck. Too many participants, topics, and tangents dropped the value of the meeting down to zero. Clearly, the Scrum Master must get the meeting refocused, but what’s the best way to do that?

National Library of Ireland - Flickr

National Library of Ireland – Flickr

This team operates in a plan, build, and run model. In other words, there are people responsible for planning, people responsible for development, and people responsible for support. A problem with this model is the cost of transitioning work between the 3 teams.

In an attempt to lower the cost of the handoff, the build team (scrum team) decided to incorporate the transfer to the support team (run) during their Sprint Review meeting.

Not surprisingly, the participants in the Sprint Review meeting increased and the build team now struggles to complete the support transition in the 4 hour time box (4 week Sprints), let alone the actual activities that are supposed to be completed during a Sprint Review meeting.

From the Scrum Guide:

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This means that the build team is not properly reviewing the current increment of software. They are not adjusting the product backlog to optimize the potential value of the next Sprint. And they are not collaborating with the product owner to get aligned for the next Sprint Planning session.

To solve this problem, the build team should add transitioning support of the new feature/story/bug fix to their Definition of Done. There are 3 clear benefits to moving the cost of this activity from the Sprint Review Meeting to the overall Sprint.

  1. Impact of the requirement will show in the team’s velocity. The build team should estimate their work knowing that transitioning the feature to the support team is part of the effort. This ensure that the cost of the process is known and can be discussed in real terms.
  2. Impact of the requirement will show in the value delivered. Similar to the value benefit, knowing the impact to amount of value a team can deliver in a sprint is another metric that can help guide better decision making and operational practices.
  3. The value of the requirement can be discussed in terms of impact to the organization. Having metrics replaces emotional conversations. Rather than argue that a transition meeting has zero value, the team can discuss the merits of the system in terms of value.

Perhaps most important of all is that the build team gets their Sprint Review meeting back. This meeting is critical for getting the team ready for the next Sprint and to ensure that product backlog is optimized and ready to be used in the next Sprint Planning meeting.

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