Welcome back to another week at www.implementingscrum.com.
I hope you enjoyed last weeks posting and are looking forward to learning something new this week with me. This is an important concept — we learn together (thank you!). Please post comments below or tweet about this (or whatever other social media thing you use today!).
One of the big problems I see people talking about (and talking and talking — NOT DOING) is the concept of planning in Scrum.
Bottom line. Instead of talking about it (and becoming stuck in analysis paralysis and NOT DELIVERING), do it.
How much time?
Enough to get started.
Really. Get started on Delivering Working Software.
The original posting for this comic strip was about 2.5 years ago and um… wow… it was pretty politically incorrect. Oh well… Blogs are timeless (smile). That original posting talked about the rules for planning poker, about being on Fantasy Island (you may or may not be old enough to remember that show — google it), and quickly devolved into possible sexual innuendo. Oops. Or you are welcome (smile). You can take a look at the original posting here.
So what really is “enough” to get started?
When you look at Scrum, there are so many opportunities to plan. And execute. And Deliver.
Remember the reason for using Scrum — DELIVER something of value to your customer and end users. Reduce Risk. Whatever. Deliver. Inspect and adapt. Really. Hmm… Seems like I may be over using the words DELIVER and REALLY. Wonder Why? It needs repeating. Really (smile).
You can do long range Release planning at the Product Backlog level.
You can do short term Sprint Planning at the Sprint Backlog level.
You can do Daily Planning and adjusting at the Daily Standup level.
You can track all this planning on different Burn Down Charts.
Plan plan plan.
Bla bla bla.
What does your customer really want?
Really?
Really?
ASK.
You can get stuck PLANNING for a long time.
DELIVER. Get to DONE.
Yeah… you still need to PLAN in Scrum.
But what is REALLY important to your end users and customers.
Do they really care about the plan?
Hmmm… not if you keep missing deadlines and deliveries. Plans then become a CYA (cover-your-ass) thing that opens the gulf of distrust even more between the team, the customers, and other stake holders. Traditional Project Managers then use it to beat people over the head about missing dates. You know the cycle.
So.
Stop it.
Plan enough.
This is one of the *tough* conversations you need to have with your stakeholders at all different levels.
I can promise you (from experience) — these conversations SUCK at the beginning. Mostly because a traditional Project Manager has been making excuses for the team about missing dates (and using the Project Manager Whammy Stick to do strange things to the team).
As a ScrumMaster though — remember — who is REALLY responsible for delivering on a Scrum Team?
The Team.
Yeah, as a Scrum Master you are responsible for facilitating the process (or framework or whatever you want to call Scrum) AND making sure the Scrum Team understands their roles. Oh… and also working with the Product Owner. And Oh… the outside Stakeholders. Welcome to reality.
This is real world stuff.
So how can you keep it from sucking?
Deliver. Team — do you hear this? DELIVER.
And guess what… once you are delivering on your commitments the conversations shift to AWESOMEness. Really. This is not just my dream fantasy world. It happens. Daily.
It will suck wind at the beginning.
Plan.
Enough.
Execute.
Deliver.
Inspect and adapt.
That’s enough planning in Scrum. Yes… DO IT.
AND.
Deliver!
Scrum is not a Silver Bullet.
Delivering builds confidence.
Try it.
Hi.
Sorry I went “dark” here for a week. Eeek… I am in India through the end of this month (and yeah.. I’ll blog about the experience so far WOW!).
Just wanted to let you know I am getting great comments about the latest Scrum Challenge #2 regarding “An Awesome Product Owner on a Scrum Team will…”
So.
Today.
Go and talk to your Product Owner or Scrum Team Members about this.
Start some conversations!
Please use twitter to complete this statement or contact me or comment here (or on the original blog entry). [heh... no excuse for you NOT to answer!]
Thank you!
- mike vizdos
Hi.
Wow, the responses last week from my first “Random Thought Scrum Challenge” were awesome.
Thank you for all who participated. Let’s try another one for the week.
Same rules: You’ll have just about 24 hours to respond, so please post this on twitter and anywhere else (your own blog?) where you think interest may be around this one.
I’ll then post a synopsis of the results like I did for the first Scrum Challenge — Scrum Is…
So… this weeks Random Thought Scrum Challenge #2 is:
“An awesome Product Owner on a Scrum Team will…”
OK… finish that statement via Twitter (@mvizdos) or below in the comments.
Thank you!
- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com
Hi all,
Today is our first try at a new format (in addition to the cartoons) at www.implementingscrum.com.
It is called, “ImplementingScrum – UnScripted” and will feature audio and/or video in different formats along the way. By the time this goes out, it should be out on youtube and here is a link to the “.mov” format (uses quicktime and is just under 17MB — for some reason this is MUCH clearer — any recommendations???).
Using FeedBurner, it should also find it’s way out to iTunes as a podcast… let’s see together how it all works and continue to inspect and adapt.
Fair? (smile)
This first version of this is with a guy “Down Under” who had some spectacular patience with me this morning (in addition to the fifteen hour time difference!).
His name is James Brett and he maintains a site at www.scrummaster.com.au and recently (with a LOT of help with the people there!) published a survey, where you can see the results at www.scrummaster.com.au/Article.mvc/Detail/43 or download the PDF file from www.scrummaster.com.au/Content/download/ScrumSurveyResultsJan09.pdf.
The video of this is about eight minutes long and goes into the survey a bit and introduces the topic. It is not meant to be exhaustive — right now it is a test of the technology convergence(s) and as usual we want to keep these things short and to the point.
A few other references made in the video included a retrospective formats article and retrospective why.
You can also check out a few cartoons about retropectives on this site (there is a three part series here:
www.implementingscrum.com/2007/09/04/scary-team-retrospectives-part-one/
www.implementingscrum.com/2007/09/10/retrospectives-not-just-reading-a-book-part-two/
www.implementingscrum.com/2007/09/17/walk-into-the-light-retrospectives-part-3-of-3/
As usual, any errors anywhere on the video or my site — I accept that responsibility.
Take a look at the video and the links above for the survey and other stuff and PLEASE comment about it below.
Inspect and Adapt.
Let’s see where we go.
As usual!
Thank you.
www.implementingscrum.com
www.michaelvizdos.com
Welcome back to a new week and first cartoon of 2009 at www.implementingscrum.com.
Thank you for continuing to follow and spread the word about this blog and our cartoons.
Get ready for a blast this coming year.
The last cartoon of 2008 covered the topic of how to handle questions from outside stakeholders during a Scrum (or iteration).
Remember that even familiar chickens can be dangerous to derailing an iteration.
Eek.
Does that sound too dogmatic?
Hmmm.
Let’s think.
Who calls an iteration “Done?”
That would be the Product Owner (look back at this old comic strip from the early days for a refresher on that).
And, the “old way” of doing this — in a waterfall environment — was to bow to the pressure. That leads to very funny cult-movies; however, in reality it sucks for everyone involved.
Especially if you bow to it while using Scrum.
So.
If you are a Team Member on a Scrum team and you get asked to do something that is outside the Sprint Backlog, you’ve GOTTA turn it over to the Product Owner to deal with.
So, this comic strip shows that.
Our intrepid character Pig did the right thing.
And.
What is the Product Owner now supposed to do with this information?
This is not a blame game.
But.
Someone needs to be responsible for the decisions.
How does this sit with you?
And where does the ScrumMaster play in this situation?
Comments, as usual, are requested and will help guide where we take this in the future (smile).
Thank you,
- mike vizdos
www.michaelvizdos.com
www.implementingscrum.com
Older Articles »
