I am about to possibly rock your world — or the organizations around you.
Welcome back to yet another week at www.implementingscrum.com. I appreciate all the comments from the last posting and comic strip, and it feels good for me to get back into posting the comics and new thoughts.
It seems like you enjoy them too (thank you).
If you ARE in this situation, start the difficult conversations today about how to fix it… and SHARE this posting within your organization.
If you are NOT in this situation, well… count yourself lucky and SHARE this posting with your friends who might be in the following situation!
Is your organization struggling to come up with an “Enterprise Plan” for rolling out Agile [and Scrum in particular]?
I am working with clients today that have a similar problem. I have worked with many many many large [and small] enterprises over the years and have seen many patterns that work. I have also been personally involved with ideas that have failed (and yeah, some were even my ideas).
Here is the number one reason I have seen that “Enterprise Rollouts” of Agile and Scrum FAIL:
They try to implement it too fast and furious.
Does this sound familiar?
Here is some great advice (and I know most people will ignore it AND possibly even disagree with me) for successfully rolling out Agile and Scrum projects:
Start with ONE project.
That’s it. Sound too easy? Hmm… Remember that the easiest and obvious answer may be that way for a reason!
“But Mike,” people say to me.
“WE are different.”
“WE need to get our entire portfolio up and running using Agile and Scrum across the worldwide distributed enterprise so that we can get metrics and tools in place to increase our time to market, lower costs, and make everyone feel like it is a party coming to work every day.”
OK… so the “party” part in that last statement was made up by me (smile). Just making sure you are with me.
The idea that, “We are different” and “we need to do bla bla bla bla” ALL RIGHT NOW will kill your Agile and Scrum implementation.
Don’t believe me?
OK… try it and get back to me. Or… continue down this thread with me….
If you are jumping on the Agile Bandwagon and using Scrum to transform your entire enterprise because “everyone else is now doing it” (yeah… Agile and Scrum have hit mainstream!) here is another word of advice.
STOP.
Right now.
Please.
Remember it took your organization years (and maybe decades) to paint yourself into the corner you are in today. Your organization has probably spent years coming up with incredibly complicated frameworks, processes, or methodologies to get things done. People have been promoted and rewarded for building empires and silos of expertise.
You also know that if you keep doing this, you are screwed.
Because your competitors are now all “Agile” and a lot are using this thing called “Scrum.”
There is still a major failure rate out there using Scrum (and the other Agile techniques).
Why is this?
Organizations — made up of really smart people (usually) — are making one of the greatest and most common mistakes in history… trying to inject too much change at one time.
Remember what happens when you try to do this (on a regular basis even)?
The organization will always always always go back to the way it was.
Dysfunctional.
Comfortable, but Dysfunctional.
AND… just as screwed as before you wanted to start this Enterprise Rollout of Agile and Scrum.
So.
Listen.
PLEASE.
If you are just getting started (or have already been down the path to where now “Scrum” or “Agile” is a bad and forbidden word in your organization) with a Scrum and Agile change management process….
Start with ONE Scrum project.
Get Executive Sponsorship as high up into the organization as possible (they need to take the fire cover for you and will be burning political favors).
Worry about scaling it later.
Otherwise, you’ll be just as comfortably dysfunctional and screwed at the end of the day.
Don’t believe me?
That’s OK.
Your competitors do.
Let me know your thoughts.
I am listening!
Hi all.
Well I have done quite a bit of traveling around this great planet of ours, and a lot of time spent in the clouds (thinking of course while I fly to destinations afar).
So, tomorrow you are going to see something that I did not think I’d ever see.
We’ll start with the cartoon and try to turn a story around it related to Scrum — something you all know I am good at doing.
And the next night I will send you the inspiration for the cartoon this week.
Wow.
Inspirational?
I hope so LOL.
Thank you,
- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com
Welcome back to yet another week at www.implementingscrum.com.
I sincerely apologize for the lack of a new posting last week. Sometimes even I need to remind myself that I am human.
And.
The cartoon for this week really says it all.
Keep IT Simple Stupid.
In the past, I have seen the “KISS” stuff look like: “Keep it simple stupid” or “Keep it super simple” or many other variations.
Note the capitalization of “IT”?
That’s where you and I come in a lot of the times.
So.
Really.
Keep IT Simple Stupid.
I am not calling you stupid. If anything, this is a great reminder for “me” to not get stupid.
A few weeks ago I was with a client (actually doing the work thing, which I doooo actually “do”!) and they have been spending a lot of time planning for their agile rollout.
What is a lot of time?
This will vary.
Let’s just say it looked very much like a waterfall process — nothing near agile.
And I had to tell them this.
Will “they” listen?
Who knows.
But.
It was a great reminder to me that taking months and months planning for an agile rollout of more than ten teams at one time is not a good idea for people starting agile stuff.
What is my recommendation?
Get ready for “Captain Obvious.”
Start with one project.
Today.
Now.
And stop the planning game.
Really.
Get good at what you do.
And the only way to do this is to get started.
One project at a time.
Don’t worry about the enterprise rollout today when you have not started even one project.
Scary thought?
Yes.
Reality?
It does work.
Worry about the “enterprise” stuff later.
Start producing working software.
Today.
Think about it and challenge the way you currently do things today.
Results will vary, but all will surprise you.
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!
May 6, 2008 An updated blog posting using this comic strip is available at: http://www.implementingscrum.com/2012/01/18/modifying-scrum-you-think-you-know-better/
Today I am addressing something that has been bothering me — and others in the industry too — and maybe even you, my great reader!
Scrum talks about having having working software at the end of every Sprint (or iteration).
Wow.
Not a Requirements Document. Working Software.
Not a Design Specification. Working Software.
Not a great Architecture PowerPoint Presentation. Working Software.
Not Compiled Code. Working Software.
Not an incredible Test Plan with Automated Testing and complete coverage. Working Software.
Yikes.
Get the point here?
Not too preachy I hope (smile).
That is awesome, right?
“Working Software” then became recast or known a, “Potentially Shippable Product.”
Huh?
Is there a difference?
Yes.
There is a difference.
Think about it.
In your Scrum Teams today, do you have someone from your Production and Support areas involved with your Sprint on a daily basis? How about the Daily Scrum (or Daily Stand-up meeting)? What about in your Sprint Planning? Planning Poker?
Any planning?
At all?
Hmmm.
Now OK.
We may have different definitions of Production and Support people. You can look at them as one separate team, two separate teams, or actually part of your Scrum Team.
In Agile and Scrum, I’d argue that the Production and Support people should be an integral part of the Scrum Team.
In the end, it is the Scrum Team agreeing on the definition of, “Done” for the Sprint (or iteration).
And where does Working Software actually spend most of its usable life?
Say it with me now… “In Production and Support.”
Wow.
What a paradigm shift in the way you are working today.
Or is it?
And.
Think about this.
If your Scrum Team does not include the Production and Support people into your Scrum Team, you may be creating more “Working Software” than the rest of organization can handle.
What? You may be asking yourself?
Are you kidding me?
Nope.
I see this.
Often.
And.
One way I advise clients about handling this situation is to include the Production and Support people into the Scrum Team.
Do they always listen?
Nah.
And then they have a big dump truck full of stuff (waste…. work in process…. inventory….).
What does this cost an organization?
What is this costing your organization today?
Do you care?
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!
February 11, 2008
Hi,
Thanks for the positive feedback I have received so far on the idea for this week. It is good to hear and see that people are interested and some are learning about the forum for the first time!
One of the most viewed threads on this forum is called, “Understanding Velocity“. It has some great information and questions / answers that help clear up (I think) the usage of story points for measuring velocity within a Sprint and for Product Backlog Planning purposes.
You may also want to check out the following blog postings and comments related to this topic:
Whiskey Tango Foxtrot. Over.
Scrum = Communication.
Ya Got to Know When to Fold ‘Em.
Burn Baby Burn.
Hope this is helpful and please feel free to add to this or other threads located at the forum.
Get involved!
Have a great day and thank you for your time.
- mike vizdos
www.implementingscrum.com
www.michaelvizdos.com
PS –> Want to join the Forum? Click here!
Older Articles »
