|
|
Hi all,
Wow. I see a lot of new — and returning — readers have been checking out the site at www.implementingscrum.com.
I’d like to say a sincere “thank you” to each of you who both read the site and pass it on to your friends and colleagues.
One of the areas of the site that has been growing (slowly) is the Forum area. As a test, I wanted to let that part of the site grow organically without any input from me. I have found that is a bad decision on my part, and I apologize for that. In the future, I will be reviewing any postings as they are ummmm… posted (smile) and will offer my input.
As a member of the community, if you have something to say… PLEASE feel free to add to the discussions. I have found that these forums work best when the entire community participates!
If you are interested, please check out www.implementingscrum.com/forum
Have a great day and thanks again!
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
Race to the Finish Line.
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
Really. Please remember this as you read this entry!
With some clients and projects, I get called in a little after Scrum has been adopted. Sometimes the team has gone through one or two iterations and Scrum does not seem to be working.
Or so it seems. To the Chickens. And the team usually is getting frustrated at all the change surrounding them.
Here is one of the symptoms to the problem.
In heavy waterfall environments (corporate cultures), a lot of the time people are still working in silo styles (mini-waterfalls) and then some have tried to form multiple Scrum teams when one does not even work to its potential.
The reasoning behind the formation of multiple Scrum Teams is because some work “requires specialists” that only a few people — or just one person — on the team can fill. And they are perceived as slowing things down (or opposite — this Scrum stuff getting in the way of moving forward).
Teams — or should I say management — looks to the type of people who do this as “heroes” that can always pull a project out of trouble.
OK… I may piss some people off here; however, a lot of the “heroes” I have met (and tried to work with) are not worth what you are paying them. They may be hiding behind a process or claim to be the only person who knows a critical piece of code. Ug. Usually that code is crap. But I digress… sorry.
People implementing Scrum this way do not get it.
In these situations, sometimes the teams start competing with each other and the blame games start. Competition for resources starts to occur. All of the sudden, Scrum starts looking like the old waterfall environment of
the past.
All within only a few iterations gone bad.
How can you avoid this?
Look around and see what is happening with your team.
Is there a “hero” on your team?
Are you that person (smile)?
Are you doing the “basics” of Scrum?
Really?
Make sure.
And.
Get it right with ONE team before breaking out to new teams.
If the Chickens want to interfere… tell them to back off.
Or have your ScrumMaster do that.
That is one of the roles that the ScrumMaster must play…. helping to shield the team.
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
May 28, 2007
 |
 |
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
Today my friend Ed and I still talk to each other; albeit most of the time via email and occasionally over the phone. We rarely see each other face-to-face, as our lives have diverged into different areas of specialties and different areas of the world. I think the cool thing though is that if either of us called upon one or the other for help, we would “be there” for each other in an instant.
So what does this trip down memory lane actually bring to this blog entry?
Think about some of the most highly effective teams you have worked with.
Now think about the world today. I bet there are some still very high effective teams working together today (using Scrum of course!).
And to me this is great to see.
Here is where I see a failing — or a significant challenge today. In addition to me seeing it and living it on almost a daily basis, I realize it is being written about ad-nauseam in some forums and other areas of the net (including books I am sure!).
The topic is collocation — or the lack thereof — of teams today.
It is a fact that many many many Scrum teams are struggling with this topic today. And, while I hope people are coming up with creative answers, I’d like to make some recommendations that I have seen work — in the real world — today. Along with some miserable failures.
This may seem obvious, but I always always always always recommend any Scrum team collocate together during a Sprint.
This cannot always happen.
However…. strive for the ideal.
Really.
If this truly cannot happen, strive to make the part of the team which is not collocated with the main team feel a very close connection as to what is happening with the entire team today.
Huh?
Think about it. Yes, even people in large enterprises with “risk officers” who may shred my advice.
Open a communication line between the two rooms. Have more than two rooms? The same advice applies.
Realy.
It is that damn simple.
It may not be cheap, but it is simple.
Male it as simple and effective as possible.
This does not mean throwing a 56K ISDN line into a PolyComm Speaker Phone over to India to talk. Um. This is almost as bad as the string between the two tin cans. Don’t believe me? Try it. And come up with a better solution.
Team.
Do this.
And do not accept mediocrity.
Sure, the bean counters and other Chickens may say that getting the entire team together for even a Sprint Review, Retrospective, and Planning session may be too costly.
Hmmmm.
Look at what the team is burning each Sprint.
What percentage of the team burn will REALLY increase if you got people together once a Sprint.
And… on the flip side…. what would the team GAIN in productivity (as measured by the velocity) for the overall project?
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
May 21, 2007
RIP Scrum.
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
As regular readers of this blog can hopefully tell by now, I am not a religious zealot about Scrum and do not subscribe to the thought of a Scrum Police Force. I regularly push the edge on some topics (I am finding this gets your attention!) but do not think Scrum is a Silver Bullet nor should it be applied to every Software Development Project on the Planet.
Really.
However.
And I think you know this was coming (smile).
If you are going to use Scrum as one of the many available Agile Software Development frameworks on your project, please please please please please please please understand what you are getting yourself into.
When I teach Scrum (as a Certified Scrum Trainer), I teach things “by the book” and then talk about the differences I see sometimes in reality (you know, the real world you and I both live and work in!). At conferences around the world, I receive great feedback from a session I present named, “Scrum in the Real World.”
I know what “the book” says and what Scrum talks about as “best practices.”
So…. Why should I care (you may be asking yourself)?
The idea of, “Death by a thousand copies” is not something new to Scrum. It was taught to me by a gentleman named Michael Spayd (a great Organizational Change person!) and I do not know its true origin(s).
What does this mean?
Let’s say you are on a team which uses Scrum today. It really works for you and your current team. The team is so successful that the project is finally shut down (you have delivered enough value to the business — congratulations!).
You move to a brand new team.
Starting from scratch. Some people on the new team have been watching your “old team” and may be resentful at its progress. Now… someone is telling them, “You should use this Scrum thing because it worked so great for such-and-such a project.” You are excited coming off a great team that was high performing.
You are the only person with any experience using Scrum on the new team. And, you are telling everyone on the team how great it is and how, “On the old team, we did it this way….”
“This way.”
Hmmm… maybe the old “this way” included the team skipping doing a Burn Down Chart to track velocity. Maybe your stand-ups used to take 30-45 minutes.
And… you “push” these “old” ideas of Scrum onto the new team.
But wait. The “new team” has just finished getting some initial training on Scrum and wow… they say… we really do need a Burn Down Chart and the meetings should really take 15 minutes.
You entice them to do things the “old way” you did things (no matter what the reason) with your old team. You reason, “It worked for us, it can work for them.”
Zoom ahead three projects if you will for a moment.
People from the current “new” team have seeded about nine other teams at this point. Scrum training is a thing of the past since your organization now “knows what it is doing” and has this Scrum thing down pat.
Things start going wrong.
Way wrong.
People start looking at Scrum and calling it useless.
You are no longer delivering working software at the end of each iteration. Your iterations are now eight to ten weeks long. Retrospectives? What are they? The stand-ups have devolved into three meetings per day to get “input” from senior management on your team. Managers are parachuting in on a daily basis with “solutions” for the team. They start throwing bodies at the project, because, don’t you know, adding people and resources to a late project helps.
Not.
Stop.
Look around.
Is this happening today?
So what does this have to do with, “Death by a thousand copies?”
Hmmm.
I get called in (pretty regularly these days, yikes) by managers and teams who may have been using Scrum in their organization for a while.
I start asking the basics about Scrum.
“Sure Mike, of course we are using Scrum here. We are the experts on it,” they say to me.
So.
I look around.
Whatever framework they are using today — as a result of people cutting corners and skipping basic principles and practices of Scrum — looks nothing like Scrum anymore.
But.
People are running around saying, “Scrum is killing our organization.”
Are you in this situation today?
Are you headed that way?
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
May 14, 2007
What’s for Dinner?
|
|
*** Interested in becoming a Certified Scrum Master? Come to my next workshop! ***
And, it stresses the importance of an agile practice (not talked about directly in Scrum) called “pairing.”
This blog entry could take a dozen different tangents on this topic; however, I promise to try to stay on point about what I am trying to get across. Yes, O people who know Scrum… Scrum does not talk about “engineering practices” (this is by design).
So why am I even breaking out of the “World of Scrum” to talk about pairing? Because, my friend, Scrum must play in a big bad world of Software Development and well, people need to realize this.
So… what is pairing and why is it important?
I am going to tell you my definition from experience.
My idea of pairing is NOT having two people sit together for 8 (or more) hours a day at a computer banging away at code code code and not focusing on anything else. Nor does my definition of this include sitting by the computer together (as a pair… getting this??) for 3 hours a day joking around, surfing the Net, or playing online games. As cool as that may be to get paid for (and yes, some gamers who use Scrum in their development shop may have this opportunity and not even realize it!), neither of these two things describe pairing for me.
Here is an example we can use that is “outside” the Software Development world.
This site is developed using Scrum as a framework.
Do we do it perfectly? Nope.
Do we continue to strive to improve? Sure.
Now… please stick with me through this. There is a point. I promise.
Right now, remember… the site is developed and maintained by only two people (Myself and Tony). And, this is the process we go through to get you the comic strip and blog on a weekly basis:
Usually by Thursday evening, I get a rough idea about what I want to write about the following week (to be published on Monday evenings). I email the idea over to Tony. On Friday, Tony and I answer any clarifying questions about what we will try to get across… and by Saturday mornings Tony has a rough idea of the text and format of the panels in the comic to me. That’s usually the last we talk about anything until Monday afternoon when — pop — in comes the latest comic strip for the weekly blog. I’ll go back to my original outline for the idea (that I emailed him the previous week) and then — after the kids go to bed on Monday nights — I refine (as much as possible) the bog entry for the week.
Publish. Rinse. And Repeat.
I usually am totally shocked at the results. In a good way. And, most of the times, the comic strips that go along with this bog entry write-up take things to an extreme (with a lot of references to pop-culture and humor in ways I could never think about).
Over the time of working on this site together, Tony and I have come to a balance and understanding that he provides the [awesome] comics and I will provide the text and writings behind them.
This is an example of pairing.
Is it the classic example? Nope.
Does it cost me more than doing it alone? No.
Is the product better?
Does it work? You tell me (please!!!!).
Another interested fact on the idea of pairing.
Most people think you need to collocate in the same room and computer in order to do this. I will let you in on another secret, and think about this for teams that are not collocated today — Tony and I live in different states (not of confusion, but locations) and we have yet to meet face-to-face. If I passed him on the street, I would not even be able to say “hi” to him.
We will meet someday, I am sure. However, as with many Software Development projects these days, Scrum teams are using offshore resources on a more regular basis (I will not go into this topic on this entry, really!). The point here is that, in reality, we are all going to have to work with people we may never meet face-to-face. And it somehow needs to work.
Does this increase the chances of failure?
Absolutely.
Another factoid…. I had the idea for this site in early 2006. It took me almost eight months of speaking to my personal network of contacts — and then to networks of people and their networks — to “find” what both an artist and I considered a good fit.
Could I have launched the site earlier than September 11, 2006?
Sure.
Would it have had the same tone and impact it is having today?
No.
However, once we figured out that we could get started… we did.
And, weekly — come hell or high water — we deliver on a consistent basis. Sometimes the results vary widely.
As for Software Development projects using Scrum, realize that you are dealing with people — human beings (not Resources!) and you cannot do everything by yourself. And, with all the constraints that are out there for not getting things done or delivered…. remember that Scrum talks about the “Art of the Possible” and try to keep that in mind as you get mired down in your day-to-day work.
I hope the current blog entry was helpful to you. Share it with others, as I see happening quite a bit now (and thank you for that!). And hopefully you enjoyed this week’s guest artist!
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here.
You can also enter The Forum to discuss this entry and other Scrum topics. Thank you!
May 7, 2007