Project Methodologies

Picking a project management methodology drives the entire project -- the tempo, the tenor, the way people working the project interact with one another.  Because software projects are strange, unpredictable beasts who like to wander into the thickets by themselves -- what we quote from Donald Rumsfeld as the unknown unknowns -- an entire industry of blogs, training, books, consultants, contractors, more blogs, and certifications have popped up around the software engineering process.

In the old days, the wise older masters locked themselves in a room for a few months, wrung their hands, and tried to cook up a requirements document filled with, presumably, all the requirements for the project for delivery.  This was handed off to some architects in their high towers to design and figure out the hard stuff and then hand this off to project managers and software engineers for implementation.  PMs would busy themselves over MS Project* and software engineers would diligently crank out what ultimately would be the wrong or incomplete features because the original requirements document was unclear or scope had crept or scope had changed or the customer wanted something else entirely.  This was called Waterfall and it was how it was done and it lead to endless costly overruns and missed dates.

Smart people wandered off to find a better way and discovered a core truth. Engineers can build a little bit at a time, stakeholders can sign off on little bits at a time, and the project can wind its way inexorably to completion on time with plenty of time to course correct.  In fact, no one needs to wait for the wise masters to cough up requirements.  They just need to iterate just enough business requirements in small chunks to keep the project on track.  This is called Agile and the adherents to Agile declared architecture as a discipline dead.

Agile also has... some problems.  But as the CTO of Project Butterfly, I decide that the teams will do Agile with SCRUM as the team organizing philosophy because it's better that Waterfall for this particular project.  If we were building a building or a bridge, a physical thing, well, one cannot iterate on a building (or a datacenter buildout) but Project Butterfly is a perfect candidate.

Here's a big dense page on Agile with SCRUM.  Don't read that.

* MS Project has its uses as a tool because some things work better as Kanban than SCRUM.  MS Project can be fought to the ground to be used as an okay Kanban boards but better Kanban boards are available.