There are some who believe that Scrum alone is sufficient to run complex, big, expensive, scary projects and/or programs. Some people think that Scrum instructs us how to code. It does not. It provides a framework and a set of principles (as does any sound agile methodology) on which to base our development and delivery practices and processes. The only way that Scrum is sufficient alone is if the teams are completely self-organizing, highly skilled and efficient, the business has a clear, sound vision that is clearly understood and communicated, and the management fully supports the efforts put forth by the team. I have never experienced nor have a heard of a company that attained this utopia.
Let's talk about the real world. Most developers are average at best, there are politics, hidden agendas, attitudes, kingdoms, and lots of other "stuff" that prevents this paradise. Since that's the case, you can't be done at Scrum.
The Scrum framework provides guidance regarding key roles (Scrum Master, Product Owner, Team), ceremonies (sprint planning, daily scrum, retrospective, sprint review) and artifacts (product backlog, sprint backlog). It provides no other guidance. In Scrum, "the team" decides how to handle things. How do we manage requirements? The team decides. How do we handle vendor relationships? Let the team decide. How do we make sure we are compliant? Let the team decide. I think you get the picture.
Below are some things that Scrum does not address.
- How to code
- How to test
- How to manage code
- How to manage risks
- How to document and manage requirements
- How to manage the budget
- How to estimate
- How to decide whether to build or buy
- How to deploy into production
- How to operationalize the product
- How to train new users on the product
- and the list goes on and on and on
My point is this...if you are successfully doing Scrum alone, good job. But it's not enough (unless you have achieved utopia). The team likely will not have the knowledge or experience necessary to decide how to do EVERYTHING. Now you need to take that next step. Bring in CI and TDD. Start measuring your productivity by bringing in some lean/six-sigma tools so you can better improve. Heck, I think there's even some stuff in the PMBOK that is pretty useful!
1 comment:
The reason I like the Omaha Agile Dev User Group is the format of the meetings. More practical stuff and less pre-prepared presentations. With that in mind, I think your post would a great topic for a meeting. How do companies using Scrum handle what Scrum does not address!
Post a Comment