In my previous post
in this series, I shared some thoughts on team building. It feels like a natural progression to write about how teams organize themselves to work together. When it comes to methodology, I'm always going to talk more about Scrum
than anything else. My experience with non-Scrum methodologies consists of a whole lot of cowboy
, and some picking and choosing from evolutionary prototyping
No two organizations should use exactly the same methodology, and that is one of the things that makes Scrum great. It is more of a framework for building your own methodology and process, than a detailed definition of either. In laying out relatively few steadfast rules, Scrum enforces a particular style of operation and leaves many of the details up to the team. Unlike waterfall, for instance, the only written artifacts required by scrum are related to project management – not development. Requirements, design, and architecture documentation rules are left entirely to the team to decide for themselves.
The real beauty in Scrum, if you ask me, is how it engages the organization as a whole. Everyone, from executives to the sales team, product management to engineers, has a role to play in the Scrum game. And everyone has visibility over all of the project artifacts.
I'm biased. I drank the Scrum Kool-Aid. I think that it is unique in its ability to empower the team members, who, when empowered, bring the best of themselves and their skills to building the product.