|
|
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
 |
 |
Interested in becoming a Certified Scrum Master?
Come to my next workshop!
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 Forum to discuss this entry and other Scrum topics. Thank you!
May 6, 2008
|
|
Interested in becoming a Certified Scrum Master?
Come to my next workshop!
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 Forum 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!
The cartoon this week may seem very “Thanksgiving-ish” at first glance. However, the lesson today is that one of the jobs (notice here I said this is a job, not a role!) of the Product Owner is to provide the Scrum Team with lots and lots of continuous food. Good food.
“What do you mean Mike,” you may be asking yourself?
Product Owner — Find the budget for food. It is miniscule at the amount this team is saving you. And remember, they are happily delivering stuff where you actually may have forgotton people could. For you.
During the first Sprint (or iteration), the project usually has enough in the budget for the Product Owner to actually tell the team they can have some food. As any geek knows, food can be a great motivator. The usual pattern for the first time a Scrum Team can actually order food is like receving manna from heaven to a six-year-old. Twizzlers abound. Milk-duds appear as often as a simple Costco run. Potato Chips — the good ones — Pringles — appear to prove that yes in fact, you cannot just eat one.
A great Product Owner funds food. Say it withe me now. Repeat this oftern. Past the first Sprint.
However, as the first Sprint is over, the Scrum Team realizes that — yikes — their belts are getting a little tighter. The six-year-old mentality then starts to turn back to adults around the end of Sprint 3. All of the sudden, instead of Twizzlers and Milk-duds, the team is asking for “healthier” stuff. Trips to the grocery store begin and all the sudden fruit appears, along with veggie trays (with lots of high-fat dips!) and the “low carb” crappy chocolate.
Now, usually by the third or fourth Sprint, the Product Owner starts to take budgetary heat from the outside noise. Man, stakeholders have short memories. Corporate cards have been known to disappear like Brittney and her marraiges. This means food becomes scarce for the team. Let the scrounging begin.
O Product Owners — who, by the way are on the outside of this strip egging on Chicken and Pig to eat — unfortunately show how incredibly cheap they can become when a team is actually producing. Bad things can happen here, as food is now expected by the Scrum Team but nothing shows up to provide for said team. If the food flow stops now, expect the Scrum Team to start seeing dead people. Really. It is that damn scary.
I have a question to you cheap-ass-Product-Owners. Have you ever seen the movie where the plane crashed and people were eaten? I am pretty damn sure those inconsciounable people who actually ate the others were those very tasty Product-Owners. And the rest of the team survived (OK, maybe with a toe missing, but c’mon!). Scary. Think about that.
I do work with teams that, during each Sprint Review and Sprint Planning Session, the Product Owner steps up and makes sure a celebration is had. This can be something as simple as bringing in burgers to something as cheesy as the CheeseCake factory. With Desserts. And know that the two “ss”’s in Dessert is a huge difference than leaving your team out in the desert by not giving them jack.
Product Owners. Be responsible and stay alive. Otherwise Darwin will prove its existence. Comprende?
And guess what…. because I have personally seen this…. the Product Owners that keep their teams well fed see a performance increase many time what the actual “food” cost for the team.
What’s my closing message this week?
Product Owners…. talk to the team members and see what motivates them. Food is an easy kill and also easier to be pound-wise then penny-foolish. You make the call though, and, as Product Owner, hope you are not taking a plane trip across the Andes with them anytime soon. As others found out (in a tasty way from the team), your role as Product Owner can easily be replaced with another who brings food.
I want to thank Mark P. for the metric analogy this week… as well deserved as it was to start, I take responsibility to where it ended!
Gotta run…
Please send comments, questions, criticisms, ideas, or whatever here. You can also enter The Forum to discuss this cartoon and other Scrum topics. Thank you!
November 20, 2006