One of the ways a Scrum Team tracks their progress is through the use of a burn-down chart.
It is used to tell you how much work is left to do in a Sprint. Right or wrong, this is the purpose. Now, keep this in mind as we move forward on this one…
I’d like to focus on some of the ways it should not be used….
If a burn-down approaches zero only at the end of the Sprint, it is not�being utilized by the team.
If a burn-down uses an “ideal line” to help trending (something I tell teams NOT to use), and the actual burn-down is tracking exactly, something is wrong.� Really.
If a Chicken walks into a room and wants to know why the team is not tracking to the “ideal” line, and proceeds to tell the team what to do to get there, something is wrong.� Really.
If there is no burn-down chart displayed in the room, or it is out of date, something is wrong.
OK…
Now I will review each of the statements above and backup the reasons for why I said them like I did. You may disagree. And that is OK.
If a burn-down approaches zero only at the end of the Sprint, it is not�being utilized by the team.
I have worked with many Scrum Teams that have thought the main purpose of the burn-down chart is to “report their status to Mike.” Ug.
Um. No. This is one of the signs of a dysfunctional team. I guess if some of the teams I work with are dysfunctional, this will keep me busy — but that is for another topic.
When a burn-down chart approaches zero only at the end of the Sprint (or at all), it tells me that the team is not effectively using the simple tools available to them. Mainly, these “tools” include user stories and task cards. Nothing high tech.
The burn-down should show movement — up OR down — on a daily basis. Remember the purpose of a visible burn-down chart is to help show the team how much work is left in the Sprint. That is all. It needs to move some direction each day. If I see a flat-line most of the Sprint…. it tells me the team is spinning and probably dead in the water. And they are only going through the motions of updating the burn-down chart. Sad.
If a burn-down uses an “ideal line” to help trending (something I tell teams NOT to use), and the actual burn-down is tracking exactly, something is wrong.� Really.
OK, any burn-down I see that uses an “ideal line” usually signals something is wrong with a Scrum Team. The “ideal line” is usually drawn in red (or some other color) at a nice perfect angle.
Um.
Think about this.
Life is never perfect.
A “perfect” burn-down in my mind is one that goes up, down, up, down, and eventually takes a dive toward zero. This shows active communication between the Product Owner and the team.
If it is perfect, someone is gaming the system. Nothing is life is perfect. Nothing.
Reality is real.
If a Chicken walks into a room and wants to know why the team is not tracking to the “ideal” line, and proceeds to tell the team what to do to get there, something is wrong.� Really.
Oye. A Chicken wants to become a Pig. Ug. Remember the PigKin?
Hopefully enough said on this topic. Really.
I know I know I know… Chickens want to help. They see a chart with that darn “ideal” line and…. what has their old training taught them…. go into command and control mode to and give the team answers for their problems. “Add more people to the team.” “Work overtime.” “Work weekends.”
No. No. No. No.
The correct answer is for the team to have a conversation with the Product Owner. Reduce scope for the Sprint if you need to do that. Read that last sentence again.
Remember… when using Scrum…. imagine the Iron Triangle with three edges — Scope, Budget, and Resources. In Scrum, only Scope is negotiable. Think about it…. Your budget per Sprint is pretty much fixed (resources*hours*length of Sprint). Adding Resources — we all know this — does not work. You cannot make a baby in a month by dividing it into nine women. Really. Duh.
So… have that [tough] conversation with your Product Owner about Scope. Even if people say, “Scope cannot be changed.” Guess what. Reality sometime sucks. And reality deems the discussion of Scope something that must happen. A good ScrumMaster will facilitate those discussions.
If there is no burn-down chart displayed in the room, or it is out of date, something is wrong.
If no burn-down chart is displayed in the room, this is a sign that a lot of things are wrong. If the burn-down is from Sprint #2 and the team is in Sprint #5. Um…. Think about it.
Look at the other artifacts — or information radiators — in the room. Are they also stale?
Time to bring in someone else to facilitate a retrospective. The ScrumMaster has lot his or her objectiveness (is that a word?) and has become part of the problem. Bring in another ScrumMaster to help turn things around. IF that is possible.
So, I think that is a good amount of information for now. I am sure to re-visit this topic.
For now…
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
December 26, 2006
Mark Pushinsky and I (Michael Vizdos) will be hosting a Public Scrum Certification Workshop on January 29-30, 2007. If you are interested, please visit www.michaelvizdos.com/scrum for more information about the workshop.If you already know you’d like to go, visit www.michaelvizdos.com/enroll to sign-up now!
While Tony (our artist) and I realize the next few weeks may be “downtime” for a lot of teams — including Scrum Teams — we have decided to keep publishing a new weekly comic strip (for those of you reading this in January after your “break” — welcome back!).
This new comic strip addresses a common theme I hear about both Scrum and other Agile processes (shall I say finally XP or Agile Modeling, possible agile engineering practices) — Collocation.
Collocation is spelled with two “l”’s.� At least my spell checker says so LOL (laughing out loud).
I work with many “offshore” agile teams (is this an agile misnomer?).
One of the comments I have started hearing over the years of working with international teams is the term “Agile” being pronounced “A Jail” instead of “Agile.”
This pronunciation is being used on purpose by some members of Scrum Teams. Wow. Shock and amazement hit me.
I asked one of my teams why this is the perception….
They stated that “agile” — or Scrum — requires people to be collocated as a team.� Working together. Sometimes it seems like “A Jail”.
Ummm… my response is, “Yes.� It does require collocation. If it feels like a jail, something else is wrong.”
Scrum requires collocation.� All for one and one for all.
If you are taking a waiver from that stance, you are making an exception to Scrum and Agile in general.
Is this OK?� Well, there is not a Scrum Police Agency that will come out of the clouds and strike you with a bolt of lightening.� That is the good news.
Now.
For the bad news.
If you are doing off-shore work, you are making an exception using time-zones as an excuse.
Hmmm… Can a 10.5 – 11 hour time difference make a huge difference in the overall output of a team?� Of course it can.� And it does.� There. I said it. Again, realize the obvious!
Off-shoring (or Outsourcing) is not the end-all-be-all-answer to cutting costs (hmm… neither is Scrum — see the article about “Scrum is NOT a Silver Bullet“).� Large enterprises will realize this one day. And I will cover this more in the future. They can be on opposite ends of the spectrum for goals and objectives within a company. This can confuse teams. And does.
But.
This is reality today in a large number of organizations (if this is not happening in your organization, consider yourself one of the few and proud!).
Until they figure out which way they want to go (off-shore or agile), the off-shore (or, shall I say “OutSourced”) teams will need to figure out how to work with teams in an agile environment.
Is this hard.� Or tough?
Sure.
Impossible?
Not. I work with agile teams who utilize off-shore components with a lot of success (again, I also see teams royally screw up on this component of Scrum).
Do not use the time difference (even if you are in the same time zone) as an excuse for not collocating.
Sure, it takes work.
Just like working with any team members on a Scrum team.� Be wary and understanding of their personal situations.� If someone needs to leave at 4:00 to pick up their kid at day care, work with it.� If that means someone “offshore” needing to “leave” at midnight their time — be understanding of that. Don’t make your priorities the same for someone else — they are all personal decisions.
The world does not revolve around your time zone. Or you. You are not two years old anymore and it is time to learn that is reality.
Welcome to 2006… almost 2007.
Wow.
The other totally wimpy excuses I hear about collocation — outside of off-shoring — include:
” Well Mike. Really. Collocation is REALLY not needed in Scrum. That is optional.”
OK… so do not do Scrum. You need to collocate. Really. Ug…. just recently I heard one guy tell me I talked about too many reasons NOT to do Scrum… sounds like a good conference topic for me in the future!
“Well Mike. Really. We have two teams spread across multiple buildings (sometimes on the same darn campus). We could not possibly work in one room together.”
OK… so do not do Scrum. You need to collocate. Really.
There are a myriad of excuses for people to NOT collocate as a team and work together. From time-zone differences (which we can do nothing about) to what I would consider corporate laziness at the other spectrum. If I could control time, trust me, I would not be doing this Scrum stuff for a living (smile). And I know I cannot change corporate cultures… only keep pointing out to them the inefficiencies they are hitting by being — and staying — lazy. Laziness is a poor excuse. Easy. But poor.
So, is “Agile” or “Scrum” really “A Jail.”
Only if you let it be.
Really.� Think about it.
And then do something about it.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Scrum Community to discuss this cartoon and other Scrum topics. Thank you!
December 18, 2006
The following items will be covered in the Certified ScrumMaster training (effective November 2006 per Ken Schwaber):
1. Scrum is a framework for iterative, incremental development using cross-functional, self-managing teams. It is built on industry best practices, lean thinking, and empirical process control.
2. Scrum is optimized for high yield product management and product development. Scrum is particularly appropriate for high risk, complex, large projects and can be used when other parts of the endeavor are hardware or even waterfall development.
3. If waterfall suits current needs, continue using it.
4. An enterprise can use Scrum as a tool to become the best product development and management organization in its market. Scrum will highlight every deficiency and impediment that the enterprise has so the enterprise can fix them and change into such an organization.
5. Whenever an enterprise modifies or only partially implements Scrum, it is hiding or obscuring one or more dysfunctionalities that restrict its competence in product development and management.
6. The iterative, incremental nature of Scrum puts stress on the product development organization to improve its engineering skills and on the product management organization to optimize the return on investment of every release and project. The phrase, �That can�t be done here� really means that it will be very difficult to do so. The gap between current practices and target practices is a measure of incompetence and competitive risk.
7. The use of Scrum to become an optimized product development and management organization is a change process that must be led from the top and requires change by everyone within the enterprise. Change is extremely difficult and fraught with conflict, and may take many years of sustained effort. Turnover of staff and management can be expected.
8. The most serious impediments to using Scrum are habits of waterfall, predictive thinking over the last twenty to thirty years; these have spawned command and control management, belief that demanding something will make it happen, and the willingness of development to cut quality to meet dates. These are inbred habits that we aren�t even aware of anymore.
9. The focus of using Scrum is the change from old habits to new ways of doing business. Scrum is not implemented or rolled-out as a process; it is used to foment change.
10. Scrum is not a methodology that needs enhancing. That is how we got in trouble in the first place, thinking that the problem was not having a perfect methodology. Effort centers on the changes in the enterprise that is needed.
11. Iterative, incremental development is much harder than waterfall development; everything that was hard in waterfall engineering practices now has to be done every iteration, and this is incredibly hard. It is not impossible, but has to be worked toward over time.
12. Managing a release or project to deliver only the highest value functionality and not deliver the rest optimizes value is the job of product management and customers.
13. Self-managing teams are extremely productive. When they work closely with the customer to derive the best solution to a need, they and the customer are even more productive.
14. A team consists of people under pressure to do their best. Conflict is natural and the team needs to know how to deal with the conflict and have resources to draw on when needed.
15. The role of an enterprises management changes from telling people what to do to leading and helping everyone do their best to achieve goals. People aren�t resources and managers aren�t bosses.
The following cartoon was put up last month and Ken Schwaber liked it.
Today, I have found out that I am banned from a yahoo group that I frequented — for basically pointing out that there were some dysfunctional things happening on the list.
I have started a new thread to discuss the job of a ScrumMaster as a Facilitator. Please join me in this discussion and others.
Forum Entry — December 12, 2006
Older Articles »
