Question: Explaining Impediments to the Sprint Goal that happen

I received this Email with a Question:

Hi Joe,
I wanted to follow up and let you know how much I enjoyed the agile class and how much I've enjoyed implementing it at my office.

The team has really seen the improvement with their own eyes, and they are getting more and more brought in each day. We are already on our second release plan since the class. Our start velocity with 7 developers the first sprint was only 18, but by the last sprint we were getting close to 50 points. This current release plant we are averaging right under 60 points per sprint. It's been amazing the turnaround in such a short time.

Now to my question, how do you relate loss of staff time to your stakeholders, due to sickness? For example, we had a user story planned for a sprint, but the staff person who needed to be involved in it's design has been sick. I've let the stakeholders know that it may not be finished in the sprint due to illness, but beyond that, I'm not sure what else I can do.

Just reaching out for advice, thanks Joe!  Regards, Tony [...]

ANSWER:

In the title, I use the words '...that happen...'  By this I mean, an impediment that was unexpected that arises during the sprint.  If it were a different situation, I might give a different answer.

First, we want the velocity to be meaningful.  Remind them there is no value in fudging the numbers.  It is good and useful to be honest.  If you all do things 'according to the book' it is actually hard to fudge the numbers.  But not everyone explains enough so that it can be seen that they are (or are not) playing 'by the book.'

Second: Great!  Very good improvement.

Third: These things happen.  People get sick.  And, of course, to some degree every decent human being understands.

You say that 'you let the stakeholders know.'  To me, depending on exactly how you did it, it is a potential weak point, or area for improvement.  For example, if you 'just' sent an email, and they never read emails, then this is not very good.

Here's what I suggest.  The PO should sit down with the business stakeholder (and any key managers) and discuss the project.  Help them understand that we expect to make progress every sprint, but that  the long-term success is key, not that we 'hit or exceed' each and every sprint.  Stuff will happen, and we will have ups and downs.

You want to keep them informed.  When and how should I inform you about impediments in the sprint that mean (or might mean) that a given story may not get done (done, done) in that Sprint?

There are lots of situations.  Sometimes they will say: 'Don't bother to tell us until the Sprint Review.'  They might say 'text me immediately.'  Or other variations.

Discuss the business purpose or impact of informing them, or inform them sooner or later.  For example, if you are lacking something and those people might get that 'lack' fixed (maybe knowledge, maybe a screw, whatever), then informing them quickly could be very helpful.  But, if they cannot do anything with the information, why bother?  So, discuss this.

Discuss also how much detail they need on some sample impediments like this that have happened.  Sometimes they want to know, but without much detail.  Sometimes they may want more detail, and having the detail would actually help.

Let's say you agree to inform them by email asap, with a special subject line (so it sticks out in the inbox).  And usually in not more than 30 words.

Now, also talk about how these impediments will be discussed in the Sprint Review.

Probably agree that the PO should not assume that the business stakeholders or managers read the emails.  Likely they did not read them, or forgot about them.  So, to some degree (ask how much), these impediments need to be mentioned and (lightly?) discussed in the Sprint Review.

As you see, I am proposing a working (living, changing) collaborative relationship between the Team (PO) and the business stakeholders (and/or managers).

The key goal is to make that relationship more effective.  This 'inform about impediments' issue is just one discussion point in that relationship.

Put another way, the answer to your question partly depends on where that relationship is and can be about now.

One more thing.  The Team (the whole Scrum Team) is always expected to work together and overcome impediments (in priority order) where possible.  So, at some point you might need a discussion of other impediments, of what the Team (SM?? Others?) did about them, etc.  After some trust is developed, maybe all of this does not need to be explained every time.  But the key idea is: you can't just say 'I have an impediment, sorry!'  The Team has to always be trying to overcome the top impediments.

In this case, what might that mean?  Well, maybe someone in the Team could help out with the design.  Or the Team borrows a 'chicken' or another chicken to help out with the design.  Or at least went to a manager and asked for advice on this one.  Depending on the situation, this might need to be discussed.  At least there needs to be a discussion of 'ok, but what happens now?  What do you recommend?  Is he well now?  Or 'next man up!'  Or what?'

Long enough answer for today.

Please tell me if you want to give more information and/or ask it a different way.

BTW, I am fairly confident that you (Tony) did the right things.  In part my answer was for others..., others less experienced and successful with Scrum, you might reach the wrong conclusions if I had not explained more.

Executive Action Team

Jeff Sutherland has defined an Executive Action Team.  This is similar to the Management Scrum idea that I discussed. You will also notice that Ken Schwaber and Mike Cohn have described roughly similar ideas to what Jeff is describing.  (I will look up later the names they gave to those teams.) Jeff Sutherland's idea is similar to what I (and some others) call an IRT.  An Impediment Removal Team.  That is, a higher level team that looks at all the impediments and works on the 'best' ones.  Best is either highest (best bang for the buck?) or the ones that IRT are best at fixing. For Jeff's discussion of the Executive Action Team, see the video and the slides here.  It is part 3 of his Scrum at Scale series.  You will notice that in addition to working on 'impediments', it implies that they work on 'transition issues' (as they are aka as a 'transition team'). Enjoy!  

Automate Testing!

Dear Joe,

In the course you emphasized how important it is to do may things….seemingly from the start.  One of the ones was automated testing.  This will be very hard for us to do, I think, at my company.  Were you really serious that we must have automated testing immediately?!?!?

Thanks, Janet

****

Dear Janet,

[First, I must confess that I made up this email or letter.  I did have a student who I think had this question, but she did not phrase it to me this way.]

Glad you asked.

First, in many places it is almost impossible to do all of Scrum on Day One.  So, I am not upset and you are not terrible (if you thought you might be) if you do not do all of Scrum on Day One.

We do expect you to implement change continuously, so that eventually you can do al of Scrum with you team.  Never never give up on that.  And do not think that you have done Scrum until you have done all of it (all of the bare framework) with the right attitude.  This is important, we think, because it will give you better results (almost every time).

Then, automated testing is beyond the bare framework of Scrum (as are many other great agile ideas).

Again, we are not upset that you cannot get ‘full’ automated testing to happen on Day One.  Again, that is not possible for many people in many situations.

And, again, we expect you to change things at your place, and start implementing some automated testing soon.  As I said, you are not really agile in software development without automated testing (and continuous integration, etc).

How long will it take you to do that?  Well, that depends on many factors.  But, mainly, you have to start something now.  Something perhaps very basic.  Such as, have the coders or developers automated (or more fully automate) their unit tests.  Get a good unit test tool for your situation (eg, JUnit) and start building.

It may take a long while before your automated testing is truly professional. You can do Scrum before you get there, but the real power of Scrum expands significantly as you automate the testing.

You may have to convince managers to spend money  This may take time.  You may need to access the Scrum community to get evidence to convince the manager(s).  But you will get there eventually.

Hope that helps.

***

Comments please.

Aggressively Attach the Impediments

We can look at impediments or continuous improvement many ways.

For us, in Scrum, we usually look at impediments as continuous improvement for one [Scrum] team at a time.

Note: Of course, we can think of impediments also for a scaled group of teams or for the agile adoption, and for other kinds of things. Not for today, though.

I wanted to reiterate a few key points that I make in my course.

• Anything can be an impediment.

There are many types of impediments.  Blockers ( meaning an impediment that causes a full stop to one User story in the current sprint) are one type of impediment.  Usually we define impediments as anything that ‘slows’ down a team.  Once an impediment is fixed, we can expect an improvement in velocity (without any increased time or effort for the Team).

Impediments, though, are anything that is keeping the Team from being the best Team in the world.  Best in every way with the most business value, highest quality, most fun, highest productivity, etc, etc.

• Attack every day

Every day the SM should be getting someone to work on the top impediment.

• Incremental improvement every Sprint

Of course, we could have said ‘continuous improvement’ but we want to relate the concept to getting a small improvement in velocity (usually that is the metric) every sprint.  Now, this may not always happen (we are human, etc), and this may not always be possible.  But I strongly prefer to do things incrementally.

• SM plus the whole Team

The SM leads on this ‘getting better’.  The whole team must contribute.  For example, the Team must decide which is the biggest impediment (at some reasonable period), and the SM must get the Team to decide quickly.  And the Team’s motivation will change as they see their top impediment get fixed, over and over again.

I think dedicating about 1/7 of your Team’s time to getting better (especially when the payback of getting better is so great) is about right.  Ck Stephen Covey’s 7 Habits book, especially ‘sharpening the saw.’

• Get the Managers to help!!!

Of course the managers can and must help in removing the impediments.  And the Team must get the managers engaged.  I recommend making a business case (every other sprint?) to a manager, to get approval for $, for people, or for just approval to change things (often required).

It may take the Team some time to learn how to make these business cases (mostly benefits versus costs).  The Managers should take time to teach them how to do it better.

• It never ends

Be patient.  The path to becoming perfect never has an end point.  But it is also good to become better.

Never, never, never, never surrender to complacency.

Never surrender to the lie; ‘we can’t get any better’, or the more sophisticated lie that ‘the cost of any more improvements is greater than the benefit.’  The potential power of the Team is virtually immeasurable. Even the best Team has only tapped a small fraction of the potential of the Team.  Even champion sports teams are still far from ‘perfect’.  Records in every sport, expected to stand ‘forever’, are broken every day.

OK.  Once you gather the metrics and write the paper that shows how your Team became and is currently the best Team in Scrum ever, then you can take a day off from removing impediments.  Heck, take two days off. And then start getting better again.  As you know, once we get really good it is hard to stay at that level.  Very hard.

A few more concepts that I think are so obvious that I did not explain them today:

• A public impediment list will help. EX: It is hard for the SM to fix the impediments she does not know about.
• I recommend telling the truth to everyone.  Hence, a Public impediment list.  Yes, I know that’s ‘impossible’.  Mark Twain: “When in doubt tell the truth. It will confound your enemies and astound your friends.”
• Focus
• Work in priority order
• Plan a bit (adaptively)
• Use cost-benefit analysis
• KISS
• Single piece continuous flow (in this case: one impediment at a time)
• Aggressively attacking impediments is fundamental to Scrum, and key to its success
• Use metrics (with judgment)
• Culture is one of the key impediments; a ‘not good enough yet’ PO is a very common impediment; poor flow of business information (value and details) into the Team is a Universal impediment; better Continuous Integration and better automation of the testing is (are?) a near universal impediment(s)
• Yogi Berra: “Little things are big.”  If you improve 5% per Sprint, it will not take long to double your Team’s productivity.
• Of course, the world is so incredibly mucked up, that making huge improvements is easy. (I could cry or laugh, and I choose to laugh.)
• Convert normal human bitching to action.  Shakespeare: “Take arms against a sea of troubles, and by opposing end them.”
• Use the transparency that Scrum provides to help identify the top impediment to work on now. (Yes, the top one could change every hour.)

***

I hope these reminders helps a Team or two.

Feedback welcome!

Toronto – Impediment List

Here is what the Toronto course identified as impediments.  Not in any order (although understood that it must be ordered).

1. Overlooking risks
2. Big scope
3. Team competence
4. Too many defects
5. Team changes
6. Processes not clear
7. Product owner involvement
8. Under estimated
9. Requirements not clear
10. Requirement change not being communicated
11. Not what client expected
12. Finance
13. Resource (probably mot the right people or not enough people)
14. Schedule (too tight)
15. Poor communication plan
16. Stakeholder (poor, missing, etc.)
17. Knowledge (lack of)
18. Training (lack of)
19. QA (test)
20. Lack of focus
21. Buy-in
22. Scope creep
23. Bad Req
24. Too many opinions

Some of these should say ‘(lack of)’.
We recommend a public impediment list. Of course, the list itself is not the point.  But rather AGGRESSIVELY attacking the impediments and fixing all the impediments is.
We like to have one list for ALL the improvements we need to be made (for the Team). From people issues to Blockers, to tech issues and changing culture.

Managers : Impediments

It should not be confusing how to manage in Scrum (agile) Let's put a scope of this. We are talking about the management of innovation, using Teams. Not the management of BAU or regular production or whatever your firm calls that. I am less sure these principles apply in those cases. First, you have a Team that should be a real Team. And they (the full Team) should mostly self-manage. Second: ask a few questions as a manager. Ask the Team things like this:

1. How is it going?

Then listen carefully. Don't 'talk', listen.

2. Am I (or is 'management') an impediment to the Team?

It is remarkable how often, in trying to help, we managers actually get in the way. We distract, we interrupt, we just don't help them. OTOH, sometimes things that actually are helpful are not understood that way. But if the Team does not understand (in your opinion), at least listen carefully to their opinion. They might actually be correct. Always recognize that management is 'overhead' and by definition is in some way 'getting in the way' of doing the real work of innovation.

3. Where is your public impediment list?

Review it with them, especially the top items. And you might suggest impediments that they should consider. You want to see a good, current list of the top 20 ways they think they can improve.

4. Let's discuss the impediments you have fixed lately (in the last sprint) and how much impact that has had.

Comment favorably on the progress they have made. Reward that behavior. Ask them: having done that, 20-20 hindsight, how might you (or you all) have done that better (the next time)?

5. Are there any impediments you would like me to help you with?

This is THE essential question. In fact, the answer always must be 'yes', and the only real question is deciding which one. It probably will be one where the manager is competent to help. And then, more competent than the Team itself to fix.

6. Is the Team spending enough time 'sharpening the saw'? What percentage is that?

"Sharpening the saw' is from that famous story in Covey's Seven Habits book. Human beings 'naturally' never spend enough time sharpening the saw. They seem to be thinking that it is 'better' to just do the work with brute force. Perhaps in the middle of a battle, hand-to-hand combat, that is the right thing to do. But not with our knowledge work. I recommend that the Team spend about 1/7th of the 'power' on getting better (aka fixing impediments). *** Some notes: The public impediment list will be prioritized, and the priorities could change with time. The order should include cost-benefit analysis, at least to the degree they can do it. You might need to help them think that through. Often they have little or no experience in doing that. Political cost is among the costs to consider. But we do expect managers (and teams) to take political risks, in a measured way. You might not agree with the priorities, especially at first. Discuss that with them, without using your power. Don't worry about the priorities too much. Even if you do them 'out of order', a significant part of the benefit of fixing impediments is that you did what they wanted you to do. It has a huge motivational impact. You are saying via action their work is important. Now, I am not saying spend tons of money just to have them 'feel good'. But do not ignore the motivational factor. There are many many more things to say about impediments. But I hope for many of you managers, these notes are a good start. I think if your encourage 'removing impediments' in these ways, I think you will be surprised how much better the Team becomes. *** Please comment....

Public Impediments - Charleston Oct 2014

Until you are perfect, you have impediments to fix.

Here are the ones identified quickly in the course in Charleston.

From an Agile point of view, I am not sure I would agree all are impediments.

1. Team member looking for other work
2. Lone wolf attitude with some team members
3. Changing technology
4. Lack of specific skills
5. Uncontrollable outsiders' influence
6. Team churn
7. No success criteria
8. Poor communication
9. Different areas/teams not working together
10. Micro-management
11. Unrealistic expectations
12. Project uncertainty
13. Lack of QA
14. Lack of Development [people]
15. Not enough teammates or do not have all skill sets needed
16. No contact with end users
17. Scope creep
18. Scope changes
19. Funding - money was cut
20. Not understanding what the customer really wanted
21. No direction or poor plan
22. Unclear requirements
23. Lack of formal or clear requirements
24. Customer not trained properly in agile
25. Intractable customer

Not sure I understand what each person meant by every one of these.  But I feel strongly we start with a rough public list. And then we aggressively work on fixing the most important problem first.

Maybe this list helps your people identify a better list for your team.

Impediments – Charlotte Sept 2014

The following impediments were identified:

1. Egos
2. No proper test environment
3. Bad data
4. Process failure
5. external market
6. Lack of coordination
7. Unrealistic timeframe
8. Change Mgmt
9. Org changes
10. Changes in technology
11. Budget
12. Customer communication (lack of)
13. Too many defects
14. Waterfall “hangover”
15. No accountability
16. Management interference
17. Bad product owner
18. Lack of structure
19. Lack timeline
20. Ru out of money
21. Unclear scope & vision
22. Change of strategy
23. Testing
24. Lack of buy-in
25. No proper acceptance criteria
26. Planning (lack of)
27. Not following agile practices
28. New technologies
29. Lack of skill sets
30. Poor requirements
31. Scope creep
32. Lack of clear goals
33. Story (stories) not well defined
34. Changing priorities
35. Requirements change
36. Bad arch

Some maybe redundant, but they were from several firms.
I am a strong advocate of a public impediment list.  And working the list, one item at a time.

Impediments - Charlotte Course July 2014

In the Charlotte course, the following impediments were identified.  These came from different people and were expressed in different ways.  I just copied what they said.  So, for example, sometimes a "..., lack of" is implied, I think.

1. No one knows what done looks like
2. Missed stakeholders
3. Poor or non-existent planning
4. One release per year (mentality)
5. Technology
6. Undefined critical risks
7. Gold-plating requirements
8. Goals that are not measureable
9. Modeling for the sake of modeling
10. Lack of knowledge share
11. Not a clear defined deliverable
12. No client involvment
13. Multitasking
14. No capability to deliver
15. Lack of collaboration
16. Dependent on other projects
17. Decreased motivation to change
18. Adversarial position with S/W vendor
19. Lack of S/W vendor participation
20. Leadership
21. Interruptions
22. Technology change
23. Unrealistic expectations
24. Not enough money
25. Lack of commitment
26. Unrealistic timeline
27. Management override
28. Requirements not defined
29. Low morale
30. Budget
31. Communication
32. Not enough resources [He might have meant people.]
33. Single point of failure
34. Scope creep
35. Changing requirements
36. Wrong people
37. Lack of teamwork
38. Not enough people assigned
39. Missed requirements
40. Lack of communication
41. Did not plan budget properly

So, that is what they listed.  Many duplicates were not listed twice.  The number do NOT indicate a priority order (numbers are just added to add reference). Some of them were what each attendee felt was his team's biggest impediment today. Let me make a few quick recommendations on impediments.

1. Impediments can be anything that slows down the team.  Anything.
2. All the impediments go into one public list.  The one impediment that is slowing the Team down now the most goes to the top of the list.  Consider benefit-cost analysis in prioritizing, etc.
3. Some impediments can't be fixed, but any impediment can at least be mitigated (have the impact reduced).
4. The Team should prioritize them, but often will not agree.
5. Fix the top one, one at a time.  See Theory of Constraints, for example.
6. Slice your fixes into small things, so that noticeable improvement can be measured each Sprint.
7. Although the Team has become numb to many old impediments, re-awaken their senses to the 'we have always done it this way' kind of impediments.
8. Give the Team a challenge, to identify impediments we can fix that will double the Team's productivity.
9. Never, never, never, never stop getting better.
10. Recognize the value of a SM who aggressively attacks the impediments.
11. Impediments can be fixed by the SM, by the Team (or team members), and by people outside the Team (including people outside the company).

Impediments - Charlotte

These are the impediment the group identified today.

1. Culture, company politics
2. Missed requirements
3. Team motivation
4. Competing priorities
5. Lack of mgmt support
6. Insufficient expertise
7. Not enough senior support
8. Budget constraints
9. Lack of funding
10. Undefined requirements
11. Poor planning
12. Missed stakeholders
13. Poor training
14. Resources not allowed to focus
15. Requirement clarity
16. Lack of planning
17. Change controls (lack of)
18. Team not on the same page
19. Skill set
20. Lack of resources
21. Planning
22. No fun
23. Sponsorship
24. Not clear communication
25. Scope not right sized
26. Compressed testing
27. Lack of teamwork
28. Budget
29. Lack of management
30. Lack of testing
31. Documentation not defined
32. Non-agile team member
33. Unproductive meetings
34. Too many meetings
35. No collaboration, no feedback
36. Unreasonable expectations
37. Market changes
38. Over confidence
39. Changes identified but not communicated
40. Late change requests
41. Incorrect requirements
42. Compressed timeline
43. Disagreement on "process"
44. Incorrect estimates
45. Poor communicating team members
46. Unclear acceptance criteria
47. Unclear vision of customer

As stated many other places on this blog, we hope these lists encourage you and your team and your company to aggressive identify and aggressvely attack the impediments, one at a time.  And make life better for yourself, your team and the customers.

Impediment List: Toronto

We just completed a CSM course in Toronto.

Here are the impediments they identified, although some are phrased in a positive way (but implying the lack of the positive).

This list, as with others here, supports the idea of a public impediment list.  Of course, the real issue is 'fixing impediments regularly and aggressively."  But we find that that starts with a good prioritized list of impediments.  And we attack them one impediment at a time.

Here's their list (not in order):

1. Small teams (<5 7.="" a="" amp="" and="" are="" better="" closer="" first="" for="" i="" is="" li="" notion="" person="" right="" scrum="" size="" small="" team="" teams="" that="" the="" them="" think="" this="" timelines="" to="" too="" will="" with="" work="">
2. Making time to meet
3. Changing requirements
4. Task breakdown (poor)
5. Being in the office at the same time (not)
6. Compressed timeline
7. Admitting we need agile or a Proj Mgmt solution
8. Tight timelines
9. Technical challenges
10. Lack of people with diverse and required skills
11. Waterfall/Agile hybrid
12. Lack of people for given schedule
13. Delays (outside the team that mean the team will 'fail')
14. Lack of flexibility
15. Poor communication
16. Too much planning, not enough execution
17. Old fashioned tech
18. Lack of people
19. Over budget
20. Lack of proper planning
21. Lack of approach
22. Lack customer feedback
23. Incorrect requirements delivered
24. Lack feedback
25. Lack of detail in scope or requirements
26. Lack skills
27. Too ambitious feature list
28. High level design
29. Lack of collaboration between teams
30. Poor scheduling
31. Too complex
32. Inadequate testing
33. Lack of leadership

Impediment List - Inhouse Course May 15

I am a strong supporter of identifying small things that we can take action on, one at a time, to get better.  In Scrum, we call this an impediment list.  This week, the class identified these impediments. I think I have it right....

1. Lack of governance
2. 0% transparency
3. Actively disengaged team members
4. Competing goals
5. Adversarial sponsors
6. Poorly understood technology
7. Losing people mid-project
8. Too many cooks
9. No change management
10. No requirements
11. Individual contributions [not team contributions]
12. Finger-pointing
13. Lack of support
14. Ill-defined teams / structure
15. Lack of team collaboration (incl vendor-client)
16. Unrealistic estimates
17. Exit criteria [lack of??]
18. Too high expectations
19. Insufficient funding
20. Silos
21. Changing scope without adjusting (R or T or B).
22. Poor communication
23. Lack of Buy-in
24. Absences from meetings
25. People availability
26. Poor estimates of time
27. Poorly defined tasks
28. No direction
29. No / lack of leadership
30. No understanding of benefits
31. Personal agendas
32. Command and conquer
33. Constant distractions
34. Unrealistic expectations
35. Business ownership / partnership
36. Lack of communication
37. Lack of buy0in / ownership
38. Disengaged team
39. Unrealistic value
40. Skillsets
41. Lack of coordination
42. Hidden assumptions
43. Complete assumptions
44. Just get 'it' done - don't know what
45. Unhealthy communication
46. Confusion
47. Lack of involvement from customer
48. Unclear purpose
49. Poor definition
50. Poor team dynamics
51. Single points of failure

There is some duplication, I think, for many reasons.  But perhaps useful in suggesting relative priorities.

A couple of key points:

• We have a list to prioritize and act on the most useful stuff first
• Prioritize mainly by 'how much is it slowing down the team'
• Use cost-benefit analysis to some degree (maybe only intuitive)
• Drive one to completion at a time
• Make them small.  No bigger than one sprint.
• Get the managers to help you (and the Team as well)
• Show results

Charlotte APR 2014: Public Impediments

The following impediments were identified by the Charlotte CSM class this week.  Again, we may have dups, although that probably is an indicator of relatively higher occurrence.

1. Business – IT not aligned
2. Poor test practices
3. Set date before project begins
4. Over documentation
5. Poor communication
6. Unclear roles
7. Lack of resources
8. Disengaged customer
9. Uncontrolled team member egos
10. Lack of accountability
11. Funding cut
12. Cutting corners on testing
13. Lack of risk management
14. Changed mind about what you wanted
15. External factors
16. Hidden agenda from stakeholders
17. Not understand critical path
18. Too many managers
19. Change in environment
20. Stakeholder awareness & involvement
21. No process
22. No teamwork
23. Clarity (lack of)
24. Revert ways
25. Process disagreements
26. Missed requirements
27. Over commitment — under achieving
28. Lack of leadership
29. Inflexibility // dates
30. Unrealistic deadlines
31. Market / customer
32. Urgency, speed
33. Unclear requirements
34. Lack of communication
35. No documentation
36. Analysis paralysis
37. Skills

I am not sure I fully understand (now) what each of these meant.  Also, maybe if I explored some, I might disagree that they are really impediments.  For example, if something just must get done by X date, that can just be reality (assuming it is indeed true that we *must get it done by that date).  Calling reality an impediment is just not helpful.

More generally, though, we have impediments until the team is the best Scrum team in the whole world.  Once you can accurately declare your team is the best, then by all means, please stop improving.

Question: Advice to a beginning ScrumMaster

Virginia asks: “I am a beginning ScrumMaster in a tough situation.  I have some ideas, but I am unsure what to do.  And unsure what to do first.  What can you suggest?”

Answer:  I think this is a common problem.

But, in reality, there is no end of things that a ScrumMaster can do to help the team.

First, take what you already know about Scrum, and remind the Team what Scrum is.  And why….what the values and principles are.

This can be done in a thousand ways.  One example: Post the Agile Manifesto and the Agile
Principles in the Team room.  After each Daily Scrum, ask each member of the Team to take two minutes to explain something about one line or one item from the list.

You will be impressed how well they explain the agile ideas to each other.  And then, you can add an additional insight. Maybe something you think they could improve on.

Read or re-read Agile Project Management with Scrum by Schwaber to get lots of stories and ideas about how Scrum should work.

Second, get a better list of impediments.  Ok, let’s be honest — START a list, a public list.  Yes, of course collect the ones they tell you in the Daily Scrum and in the Retrospective.  Add the ones that you see.  Read this blog, and steal some impediments that apply to you and your team.

You want a list of the top 20 things to improve, broken down into actionable things, where you could see, smell, notice improvement in 2 weeks or less.  Yes, you often start with some epic impediments…but just start there…

An impediment is anything, ANYTHING, that is slowing down the Team. Example: Anything that stops a story, slows down the Team. People issues, technical issues, organizational issues, the weather, I need coffee, I need a dentist, we need a different culture, whatever. Whatever.

Ok, we have to discuss two things that happen universally in the Daily Scrum, at least at first.  They don’t divide the tasks into small pieces, and they talk vaguely about what they worked on, and do not focus on what was DONE (completed).  The tasks must be mostly in the 2-4 hour range.  And they must say whether or not it was completed. If a 4 hour task is not completed in one day, clearly there is some kind of ‘impediment’ (eg, I cannot estimate very well).

Then, they must give their biggest impediment. (What slowed them down the most.)  Time itself is not an impediment.

It might be: “I don’t know this area that well.”  Or: “The servers were down.”  Or: “Well, if the tests were automated, then I could have found the bad code faster.”  Or lots of other things.  Saying:

“None” is not an option.  Implying that ‘things are so good around here, that there is no way it could possibly get better’ is also not an option.  Things can always be better.

Also, you must give them a challenge.  Tell them: “We have to double the velocity, in a way that we believe, and not by working any harder.  So, what do we have to change to do that?  And imagine that anything could change. Anything. And that the managers will approve anything, if we can make a good case for it.”

For the Retrospective, see also Agile Retrospectives by Derby and Larsen for more ideas to uncover the real impediments. They have forgotten lots of impediments because they have become used to them, or they can’t imagine that it could be changed.

Third, aggressively attack the impediments.  Every day. Every hour.  Take the top one, and go after it. If you can’t fix it yourself, that is fine.  But get someone to.

I do not mean go crazy. Use some common sense. If the cost is greater than the benefit, than do solve it that way.  Sometimes you can only mitigate the impact. Etc, etc.  But still, every day and every hour, attack the top impediment.

Fourth, tell them.  Tell the right people what you will do, what you are doing, and what you have done.

Mostly, you tell the Team.

How?  In the Daily Scrum (you answer the questions, and tell them).  In the Retrospective.  And in other ways that make sense.

Why?  Well, not to brag as such.  But you need to know they care.  They want the ‘fix’ that you will give, are giving, did give them.  Also, once they know things are getting fixed, they will get more creative about talking about things you could fix.

Fifth, keep a list of ‘fixes installed.’  All the things you did, or got done, to make their lives better.
Why? So, when you are discouraged, you can look at the list and get some encouragement.  So, so when the wonder why you are not doing ‘real work’, you can remind them of your value.  So you can justify the managers why you deserve a raise.

Track the list, and make a reasonable guess as to how much of the improved velocity of the team is attributable to the fixed or mitigated impediments. Typically 100% is effectively attributable to you.

Yes, Scrum itself did some (but you still take credit). Yes, the Team did some things, but honestly probably would have done very little without you, or would have done it very much later.  It does not matter that you did not do it ‘with your own hands’.  You made it happen, you were the key.  It does not matter than some improvements cost ‘extra’ money. The benefits were huge, and mostly would never have happened without you.

Do not slack for even one day.

The Team and the customers deserve everything you have to give.  And you too will be rewarded in ways hard to explain but very clear…by all the good things you make happen.

Sixth, to help you become a better ScrumMaster faster, start a ScrumMasters club with other SMs in your area.

Learn from each other. Maybe have a brown bag once a week, and present ideas and experiences to each other once per week over lunch.

That’s a start. There are many places and ways to learn.  As you act, you will discover more ways to learn, and more things to learn about.

Does that help?

Halifax: Public Impediment List

As some of you know, I am a strong proponent of aggressively attacking the impediments. And I think it starts with a good public impediment list.

So, as examples, here are the impediments identified by the class in Halifax.

1. Team is working on too many things
2. No prioritized backlog
3. Uninvolved PO
4. Keeping everyone in the loop (not)
5. Complexity
6. Lack of management attentiveness
7. Acting on retrospective improvements
8. PO not involved
9. Lack of understanding
10. Silo workers
11. Lack of impediment list
12. Lack of retrospective
13. Increasing Tech Debt
14. Not having vision from PO
15. Managing people instead of work
16. Lack of team spirit
17. Managing interference
18. Unmotivated
19. Bottom down planning
20. Too much useless chatter (from Mgmt, I think)
21. Lack of early feedback
22. No ending [to] project
23. Not following process
24. Conflicts (too much)
25. Keeping Top 20 impediments
26. Distributed team
27. Lack of process
28. Lack of management
29. Communication
30. Too many cooks
31. Product knowledge gap
32. Scope creep
33. Not defining DOD
34. Lack Buy-in
35. Lack of process for Development Tasks
36. Technology group (IT) support infrastructure
37. Testing Time
38. Bug fixing time
39. Not having all Scrum activities
40. Management available
41. Lack of communication
42. Poor planning
43. No estimates (no velocity)

Public Impediments – Toronto March 2014

Here are the issues this group thought were important.  Many are ‘issues’ in a waterfall model.  Not necessarily in priority order. Not necessarily impediments in an Agile model.  Some are vague here (stated in few words), but I think they knew what they really meant.

1. Management apathy
2. Unclear goals
3. Too much process
4. Changing requirements
5. Insufficient people
6. Work overloaded
7. Large team
8. Redundant skillset
9. Internal compertition
10. Single out individuals
11. Late request
12. Project cancelled
13. Newly formed team
14. Distributed
15. More layers (different teams)
16. Too many scope creeps
17. Not enough executive engagement
18. Not good leadership
19. Delays from vendor
20. Not enough knowledge in team to solve issues
21. Tasks not properly assigned to team members
22. Didn’t allocate enough time for unknowns
23. Team was told what / when
24. Management and Execs painting a different picture
25. Blame / “steamrolling”
26. Forced to “report” waterfall way
27. No clear product owner

Public Impediments - Charlotte March 2014

The group came up with these impediments.

1. People issues
2. Distractions (multitasking)
3. Lack of resources
4. Arbitrary long time estimates
5. Lack of feedback
6. Black box projects
7. Dishonesty
8. Management constraints
9. Team too big or too small
10. No clear roles
11. No funding
12. Unrealistic expectations, time or $
13. Team improperly formed
14. Too many impediments (main cause of failure)
15. Inexperience (wrong skills)
16. EGO
17. Poor listening
18. Unchesiveness
19. (lack of) localization support
20. No direction
21. Stubborn people not aligned with Team
22. Budgeting not clear
23. Shareholders having diverse interests
24. Lack leadership
25. Teams not talking to associated teams
26. Lack of resources dedicated to Team
27. People turnover
28. Performance not measured - no data
29. Real product owner is not identified
30. No clear process / product owner
31. Cross-purposed stakeholders
32. Lack of stakeholder buy-in / support
33. Upstream / downstream dependencies

We hope this list helps your team get more creative about the impediments.
We are a strong advocate of a public impediment list.

Public Impediment List - Charleston Mar 2014

I am a big advocate of each team having a public impediment list.  Elsewhere I describe that in more detail, and some issues with it.  The key thing: the main purpose of the list is to enable us to fix the 'best' impediment faster.  We don't just have a list to assure we do NOTHING.

In the recent course in Charleston they identified these impediments.  You may or may not agree.  There may be duplicates (maybe a rough indicator of greater impact).  Maybe some are not clear to the reader, but only to the writer or that Team.  The order is random.

We hope this list makes your Team more creative in identifying its 'best' impediments.

1. Small group supporting sustaining work
2. Lack of experience (skill set)
3. Knowledge transfer
4. Automated build-test / quality
5. Requirements traceability
6. Loading radios [To test the functionality of the software in the radios]
7. Schedule tight
8. Undefined goals
9. Inexperienced people
10. Shifting priorities
11. Hiring people
12. Establishing a team
13. Unresponsive vendors (external)
14. Issue with external system not in our control
15. Moving timeline, target date
16. Lack of ownership from product owner
17. Changing scope
18. Team concept
19. Work distribution
20. Lack of knowledge
21. Inaccurate information
22. No mitigation strategy [for risks, I think]
23. Lack of buy-in
24. No planning
25. Inexperienced people
26. Insufficient client management
27. Not understanding client's true needs
28. Inadequate skills
29. Inefficiency
30. Changing personnel
31. Over-committed [given too much work, I think]
32. Don't understand process
33. Team not on same page
34. Lack of pre-plan
35. Lack of ownership [by team, I think]
36. Adequate training (lack of)
37. Weak company management
38. Failure to commit
39. Weak PM [in Scrum terms, I might say weak SM -- depends what he/she meant by PM]
40. Changing goals, moving target
41. Lack of resources, HW, SW
42. Weak IT
43. Risk mis-management
44. Failure to communicate
45. Do not understand goals
46. Lack of teamwork
47. No support
48. Time Zones
49. Change of vision
50. Org not ready for change
51. Budget
52. Scope creep
53. Unrealistic deadlines
54. Mean team members
55. Moving timetable
56. Disorganized
57. Lack of experience
58. Under budget
59. Poor stakeholder management
60. Over budget
61. Lack of leadership
62. Unavailable team members
63. Inconsistency
64. No requirements
65. Changing requirements
66. Ins budget [Insufficient budget, I think]
67. Bad estimates
68. Lack ofparticipation
69. Missed deliverables
70. Poor attitudes
71. Not enough tech knowledge
72. Poor communication
73. Product failure [one might need to identify the root causes here]
74. Non compliant
75. No gate reviews [In Scrum, each Sprint is a kind of 'gate review' -- but not sure this would be enough for the person who raised this concern]
76. Unrealistic scope
77. Lack of commit
78. Employee no shows
79. Insufficient time allotment
80. No leadership [person started with 'A lack...' and crossed that out]
81. Creeping scope
82. Change of scope
83. Team incompetent [for this work??]
84. No enough people
85. Inadequate schedule
86. Lack of planning

***
To get this list, I asked two questions, one early and one later:
1. What are the root causes of failure in most projects?
2. We need to double velocity in 6 months, and we have to change radically.  What do we have to change to get the velocity (productivity) to double?
This may explain some of the duplicates.

Impediments - Raleigh-Durham Feb 2014

I really want to advocate again that we must make the impediments visible in a public impediment list.  And never stop aggressively attacking them.  If you prefer to call it 'our list of things to improve on', I won't arrest you.

Here's the list the group made in this class.  They are not on order, they are not framed the same way, there will probably be some redundancies. These are in random order.

1. Team commitment to Scrum
2. Singular voice from PO
3. Team commitment to project
4. Unqualified Team members
5. Quality agile process training (Gee, I hope they were not talking about me? (smile))
6. (lack of) collocation
7. Finalizing sprint work / goals
8. Communication / collaboration
9. Definition of Done / of Ready
10. Replacing communication with documents
11. Non-value process for process' sake
12. Unclear requirements
13. Unrealistic or undefined scope
14. Clear definition of done (lack of)
15. Misunderstood requirements
16. Well defined sprint - days
17. Lack of team commitment
18. No vision or backlog of work
19. Unrealistic expectations
20. No support of team
21. Clear goal each sprint (lack of)
22. No unified team or stakeholders
23. (No) realistic expectations
24. Lack of senior leadership commitment
25. Actual list of impediments
26. Overall goal / delivery
27. Scope creep
28. No idea of what 'done' means
29. Self goals over project / team goals
30. Poor leadership
31. Resource constraints
32. No single voice (I think it was of requirements to team, eg, PO was not really there)
33. Expanded teams skills (need training)
34. No shared vision

Impediments – Charlotte Class Jan 2-3

Here are some impediments that were identified

1. Lack of awareness of other projects
2. Unwillingness to say ‘no’
3. Clearing plate of current projects
4. Poorly prioritized projects by management
5. Pulled off project
6. Poorly defined reqs
7. Access to stakeholder / SME
8. Reaction to rapid market changes / demands
9. Budget ?
10. People –> Teams

In addition, these impediments were identified:

1. Unexpected changes
2. Lack of management support
3. Removal of Time, Dollars, People
4. No or little understanding of core requirements
5. Wrong or not enough stakeholders
6. Too many chiefs, no indians
7. SME not available
8. One person doing work
9. Wrong skill set
10. Lack of Communication
11. Unrealistic timelines
12. Resources shortage
13. No resource commitment
14. No defined deadlines (we need them)
15. Mixed expectations
16. Un (not good in various ways) Requirements
17. Budget (lack of)
18. Not enough Scotch
19. Scope Creep

Hopefully these help your team.