This can be a fun and exciting time because sometimes you may work with a team long enough that coaching the same team may get boring, especially if the team is just moving along and being productive (smile).
One of the things I like to chat about with an existing ScrumMaster is the concept of being able to move from “zero to sixty” within and among Scrum Teams.
What does this mean?
Scrum is a change.
Some may consider it an organizational change (a topic for the future!).
As a ScrumMaster, you are an agent of change.
When you are working on a Scrum Team, the team goes through the normal team “stuff” that teams go through to become a cohesive unit. Things and people mesh. Inside jokes prevail. Little things become normal, and sometimes people can start finishing another team members sentences or thoughts.
Then.
The team finishes a project and those people may go on to start new teams (or join existing teams). Some team members go back to traditional waterfall projects while others may have the opportunity to go to a new Scrum Team.
This story really apples to any role, be it a ScrumMaster, Product Owner, or Team Member. I do want to point out here that as a ScrumMaster, it is your responsibility to know and understand what is happening.
So.
When you go to a new team, remember this: It is a new team.
And, when you start a new team, I remind folks that they need to “start over.”
As a ScrumMaster (possibly working on one or more teams, or even a serial ScrumMaster (hmmm)), you need to realize that each team you work with are in different places of their lifecycle as a team.
You need to recognize “where” the team you are working with “is” on the team formation cycle, and be able to walk into the current situation to help them along.
Team A is not Team B is not Team C.
ScrumMaster must work with all different Scrum Teams — A,B, and C.
ScrumMaster must mold and treat each team differently.
Including when you play the role of ScrumMaster and how you perform that role on each of the various teams.
And be able to go from “0 to 60″ on a daily basis if needed.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!
March 19, 2007
Last week I must have hit a nerve with some of my readers. I received a ton of email responses (both positive and negative) and thank everyone for their comments. Keep them coming as I try to respond to everyone who takes the time to send their comments, thoughts, and suggestions.
Last week a common theme began occurring in conversations all around me. So I thought I’d better listen and actually write about it more.
Questions I ran into (or should I say, ran into me) last week included the following:
“Can a team max out their velocity using Scrum?”
“Is there such thing as a “ceiling” to the amount of work that can be done in a Sprint?”
“What is the terminal velocity of a Scrum Team?”
These questions [and answers that were discussed] interested me. They occurred in small one-person hallway conversations, online via email, and a topic at an Open Space {LINK} APLN-Richmond Meeting (facilitated by Joe Little (and his wiki) last Wednesday evening.
First, I had to go to our friends at wikipedia to remind myself of the definition of terminal velocity (kept thinking back to high school and 9.8 meters/second/second):
“The terminal velocity of an object falling towards the earth, in non-vacuum is the speed at which the weight of an object and the air resistance, or drag, balance, thus giving it a final,or end, velocity also known as Terminal Velocity.”
For someone sky-diving with (or I guess, without) an un-opened parachute, it is about 120 miles per hour (195 km/hour). Fast. So this is the interesting thing… there IS a limit to how fast one can fall.
How does this relate to the topic of a velocity for a Scrum Team?
I have been challenged in the past to defend my idea that a Scrum Team truly does have an upper limit, or ceiling, that they can work within. I usually take the side of, “If a team is highly functional and coherent, there really is no limit of the velocity they can reach by working together.”
I found out that sometimes, as the saying goes, “Them’s fighten words.”
In Scrum, the velocity of a team can be viewed on the burndown chart. Usually, this can be tracked by figuring out what User Stories are complete.
So what if a Scrum Team “finally” gets to a plateau (or ceiling) in its velocity? Or, the question should be, “When they plateau?”
Let’s say the team started using Scrum three months ago. After a few rough beginning Sprints, their velocity was computed to be 28 points per sprint. And, they have held steady since then.
They are producing and humming along as a real team. They have a regular “heartbeat” of the Scrum lifecycle.
Now… The Chickens step in and start demanding more.
Two ways I have seen (and was reminded last week at the APLN meeting) a team respond included:
- The team allowed the Chickens to add new team members or allow them to be pushed into working longer hours. We all know this is not sustainable and can lead to team burnout.
Always.
- The team started to figure out on their own how they could become better. Hmmm… they thought… what about amping up our engineering practices (such as pair programming)? Other ideas come out of the team and they keep getting better!
Does this mean the team must make a jump from working 40 hours a week to 80 hours a week?
No.
No.
No.
It means they — as a team — figure out for themselves what works for THEM. And this is where the power of Scrum can be seen (heck, don’t even worry about Scrum at this point, you are in the realm of working with a truly high-performing team!).
Circle back to the original question.
Is there a limit to what a team can do to increase their velocity?
I submit the answer is still a solid “No.”
If you are hesitating about taking that stance, I challenge you to go back to your team (not as a Chicken!) and figure out what you can do to make things better.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!
March 12, 2007
We have our first offer for translating this site from friends in the Ukraine!
If you are interested in helping with this specific translation effort, Max Pendyschtschuk and Roman Muntyanu are coordinating the effort.
You can send your info directly to GotischeRose@yahoo.de with subject “ImplementingScrum into the Ukrainian”.
If you are interested in translating any portion of the site into another language, please contact me and we can get the process started (I see a lot of traffic with the following languages: French, German, Spanish, Portuguese, Dutch, Italian, Swedish, Russian, Norwegian, and Chinese.)
in addition to this great news, I will also let the readers of this blog (you!) know that I am planning on offering two Certified ScrumMaster Workshops in Ukraine, Kiev (Kyiv), this June. The first will be 14-15 June and the second will be held 21-22 June. In between the two workshops I will hold there, we are also working on getting me up to Moscow to teach a workshop there.
More details (pricing, location) will follow and also keep an eye on the following pages (for translated information about the workshop and logistical information):
http://www.krivitsky.com/2007/02/scrum-trainings-and-other-events-in.html
http://www.agileukraine.org/
Thanks for the interest and let’s see where the site continues to evolve….
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Scrum Community to discuss this entry and other Scrum topics. Thank you!
March 6, 2007
Feel free to ignore me (as usual!). This is just my opinion. Like the rest of this site (smile).
[Full Disclosure ON]
I am not affiliated with any of the tool vendors mentioned in this blog entry. I have used some of the tools at various client sites and have worked with demos from some of the companies. I am not receiving any financial gain (or loss) from the companies mentioned. I know the main people at each of the companies and have spoken with them in the past about tool usage for agile and Scrum teams. They are nice people (smile).
[Full Disclosure OFF]
The “Software” Scrum tools out there include Version One (versionone.com), Rally Software (http://rallysoftwaredevelopment.com), Scrumworks Pro(http:/danube.com/scrumworks/pro) as commercial products.
There are more. And there are write-ups about the different tools (for example, “Fear and Loathing (http://weblogs.asp.net/bsimser/archive/2006/10/21/Scrum-Tools-Roundup.aspx or Dave Froslie – Microsoft Development on the Prairie http://blogs.msdn.com/dave_froslie/archive/2005/12/15/504251.aspx)
Open Source tools include XPlanner (http://xplanner.org/) and others that pop up on a regular basis (for instance, I heard about a new tool just last week called Project Dune (http://sourceforge.net/forum/forum.php?forum_id=671252).
There is always Microsoft Excel for the die-hard MS fans.
Microsoft Project is one tool I would not even consider using on a Scrum Team.
So, those are the “Software” tools that are available today.
Are there more?
Sure.
Will there be more in the future?
Of course. Geeks like to create tools. And marketing folks like to sell seats (licenses) for them.
“So Mike,” you may be asking me at this point, “Clearly the market has shown a need for these software tools, and people are buying them (or at least trying their demos!). You must be smoking something if you think software tools provide zero value to Scrum teams.”
First, I am not smoking anything. Or snorting. Or injecting. Or swallowing. Gulp.
The software tool mainly provides value to the software vendor. Remember, their goal is to sell “seats” or “follow-on” consulting services. Heh… remembering also that this statement comes from a consultant (who does not sell software tools).
And, wow, I work with teams that actually use these software tools; some clients even go as far as growing their own internal versions (so they can print cards nicely or bla bla bla).
Congratulations.
And what value does that bring to your team?
Think about this.
And then…
Here are some conversations I start hearing when software tools start getting involved / used on Scrum teams:
“Please make sure you update tool X so that we can report our burndown to [someone who is not even in the room].”
“Holy Shit. Our tool is down. What do we DO now?” [mad scramble ensues]
“I love this tool. It keeps me from having to be in the room all the time…..”
“I love this tool. I do not have to talk to anyone about what I am working on anymore. I can just enter my tasks and user stories in and just worry about the stuff I am working on.”
“Look at these cool graphs.”
“Wow. Our estimated time for a task was off my 37.5%, how do we ‘fix’ that delta so we don’t get dinged for giving bad estimates.”
“Oh, we do not have a bundown because our software tool admin is out of the country for a few weeks. And we do not show task cards or user stories anymore.”
And… I could continue for hours (really… and this makes me sad… barfy sad sigh).
I discourage the use of tools at any point in the project, but teams almost always want to use them 
. Geeks.
Are you seeing where this can have a reallllllllllly negative impact on the team and how the team works together?
The scary thing is, when teams get started using tools, it can be perceived as crack cocaine.
The first one is “free” (demo).
Then… The tool starts taking grip on the team. And starts growing to other teams within the organization.
Hmmm… now internal compliance people (at an enterprise level, these people say what applications “can” and “cannot” run on your machine) get wind of it.
Bad things start to happen.
So an internal software tool starts getting developed. This takes resources — or usually one poor schmoe who winds up doing it off the side-of-desk — away from the main goal of the team.
The compliance people may get involved again because hey, you are running some internal tool that is not supported by the enterprise and gulp, you are running it using a non-standard database (i.e. Microsoft Access etc.).
And then, and this is the really scary part, Chickens get this great idea that they can start comparing team velocities and setting up a control center or dashboard of some type to magically report what is happening in their kingdom. [Bad idea — here is why.
Throughout all of this, the comments I made above — REAL comments I have heard from teams using software tools — take place and start eroding the real purpose of why a team started using Scrum in the first place.
“So Mike,” you may be thinking. “What are the alternatives?”
My advice.
Keep it simple.
Really.
The alternatives include index cards, some markers, large post-it notes, and whiteboards.
I know, whiteboards can sometimes be harder to get than ordering new software for the team. Do not use that as an excuse to start using software tools.
And yes, whiteboards can get erased. It’s OK. Life goes on. And, since your team is actually using a whiteboard on a daily basis to discuss stuff, it may not be all that bad to refactor the board once in a while anyway (smile).
Remember the goal of setting up your team implementing Scrum?
Did you have one?
Was it to actually develop working software?
Think about it.
Delivering working software does not include “software tools” to get your there.
All the “stuff” I wrote about above regarding the use of “software tools” takes the team away from the primary goal.
I have actually seen teams burn more than 50% or their available velocity in trying to maintain a software tool.
Yikes.
50%???
Or more???
For WHAT????
Huh? Where the heck is the Product Owner in all of this?
Hopefully not the one saying, “I love this tool because I do not have to be in the room to answer questions anymore.” Unfortunately, I have heard this during a Sprint Review in the past.
Uggggggggggggggggg.
Just because you have a hammer does not mean it is the right tool for everyone. Or every team. Sometimes you can use a small screwdriver to finesse something together instead of whipping out THE big hammer and causing more collateral damage than good.
As software professionals, we should all carry a toolbox of things we can use. Sometimes, a “software tool” makes sense (hammer) while others it makes sense to use manual techniques.
And not lose site of your Sprint Goal.
Really.
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!
March 5, 2007
« Newer Articles
