Interested in becoming a Certified ScrumMaster? 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 Scrum Community to discuss this entry and other Scrum topics. Thank you!
February 11, 2008
2 Comments! to “Development is Ready. What about Production and Support?”
Leave a Reply
Comment moderation in full effect!
All comments at Implementing Scrum are moderated to help cut back on spam.
This only happens once (more if you are using multiple computers). Once you are in the system, everything is good to go after that.
February 11th, 2008 at 11:09 pm
Mike, you clearly describe the unhealthy outcome of having a special group be responsible for support and production, and suggest a good first step. Would you agree that in the longer term the support group should be dissolved and every single team member should be responsible for support and maintenance of the system?
It makes sense that if the whole team were responsible for maintaining their own code that there would be an increased focus on stability and robustness.
February 13th, 2008 at 12:48 am
Tobias,
A very thought provoking response and question.
This is one that I struggle with teams — especially in very large enterprise situations — because the “production and support” people a lot of time are in their own matrix / functional organization.
I do agree that the team that creates the working software should be responsible for maintaining it in the future.
This can — and does — lead to some very interesting team dynamics!
Is it possible to do this?
Of course.
It is easy?
Not always.
What works in your situation?
- mike vizdos
http://www.michaelvizdos.com
http://www.implementingscrum.com