Over the years I have worked with a lot of software engineering processes and; generally speaking; I like them all. Here are a few well known processes I have worked with:
In my experience no one process is "best", although any one can be better than the next for any number of reasons. Just like your trousers, you have to the buy-in to the correct size, style, colour, level of affordability, etc... and as your size changes or styles change you may have to buy a new; and different; version. To use more practical terms here are a few things that may drive your choice:
- The type of development being undertaken (Ex. Web Sites, Monolithic clients, Enterprise Services)
- Team(s) structure and experience (Ex. Developers, Testers, Designers, Architects)
- Degree of fidelity in engineering artifacts or required artifact deliverables
- Organizational process maturity
For the past several years I have been working in the SCRUM process and have really come to appreciate what it has to offer. Things like focus on responsibility, team momentum, time-boxing activities, and more. While each of the aforementioned processes address these in one form or another, none seem to do it like SCRUM.
From my perspective, its genius lies in its simplicity. If you do a little reading it won't take long to realize the process focuses on simply bringing the right people together at regular intervals to ensure everyone is moving with a common vision, and that real (tangible) progress is being achieved. Lets look at just a few aspects to the process:
SCRUM doesn't really define at what fidelity any one work product should achieve such as requirements, design, storyboards, etc... It simply structures a conversation between those that define requirements/expectations/vision and those that need to understand it well enough to implement solutions. If you want to use an SRS, BRD, User Story, Storyboard, or even a yellow sticky on a wall, the choice is yours. Compare this to approaches like CMM/CMMI which strive to produce more high-fidelity artifacts, sometimes to the point where the artifacts become the product. In their defense, higher degrees of fidelity are needed for some projects especially when human safety is concerned.
SCRUM defines very broad roles such as Product Owners and The Team and leaves the rest for you to define. Product Owners define what's needed, and the relative priority to meet business demands, while The Team are those that provide solutions for business needs. Compared to the aforementioned processes this is very straight-forward, and provides any organization the flexibility to fill these two groups in a manner that best suites their needs.
Sometimes it is amazing just how much time can be spent (or wasted) in meetings and while in a meeting you cannot possibly be working towards the creation of a product. SCRUM tries to balance the need to communicate on a regular basis, the need to keep momentum by not spending all your time in meetings, and to set a real deadline with a product commitment. My favorite bit is the notion that you can't keep changing requirements daily, rather, you set a target based on what you know now and let The Team get there. Once there, reassess and go again. For those of you who are Agile aficionados you recognize the Iteration.
It doesn't stop here. Do some reading and you will see similar themes in other areas. With all that said, I do not intend to completely regurgitate the details of this or any process, but I have decided to do a series of SCRUM-focused blog Posts to identify some really simple practices that just might make things more successful for your SCRUM team or teams that are just getting started with the process. Check back next SCRUM-tastic Tuesday.