Stephen Doyle said yesterday...
"Once upon a time we convinced the boss to allow us to use Scrum as part of our development process. Since its introduction in our team, there have been a number of successful projects and iterations that have used it and the boss thinks its the best thing since sliced bread...Over time our team size has increased from about 4-5 to a whopping 15...I find it hard to keep tuned in to what everybody is saying. Unfortunately, the boss is adamant that we stick to a single Scrum for the entire team and not split into sub-teams."
I'm sorry to have to break this to you, Stephen, but your organization is not practicing Scrum. If your team was truly self-managed, your team alone would be able to make the decision to split a large team into smaller more-productive teams.
Our experience at Decade, was much like Chris Spagnuolo described his...
"Success is a funny thing. When we started Scrum, I think we got the go ahead because management didn't think it would work. They cut us some slack to try something new, but we'd be back to waterfall before we knew it. Now that we're using Scrum and producing quality, valuable software on time and under budget, everyone wants to know how we did it."
Because of the success of Scrum, the management team not only allows my department to manage itself, but it is also experimenting with Scrum within the management team and throughout the organization.
In his article, 10 Ways to Ensure Project Failure, J. Frank Carr addressed pains that my team once coped with routinely—pains Scrum eventually alleviated.
Remember, Scrum is a management methodology—not a development methodology. The best way to get management to see the benefits is to (first) prove it can be successful, and (second) get the management team using Scrum. Once management has embraced truth, trust, and transparency, you won't have to convince them of the process inefficiencies. They will see it for themselves.
No comments:
Post a Comment