Some people like to ask: “What happened before the big bang?“. Being a geeko-nerd, I like to ask: “What happened before the first product backlog?”.
Regarding agile framework definitions, IMO, Scrum has the most well-documented and coherent definition of the bunch. However, since it remains silent on the issue, I still wonder: “WTF happens before the first product backlog?”.
For innately complex systems requiring a large amount of coordinated effort, here’s what I think should happen:
- A small group of senior domain analysts and system architects should spend a fair amount of un-pressured time to develop and document the high level, technical blueprints (structures + behaviors) for what needs to be built.
- The authoring group should disseminate and educate the rest of the development team on the technical vision.
- The team should populate and iterate on the first version of the product backlog.
- The team should decide on, and put in place, the development toolset and infrastructure that will be used to develop and test the system throughout the effort.
- The team, including the technical authors, should start incrementally and iteratively building the system – revisiting/updating the plans/product backlog frequently when new knowledge is discovered as the project moves forward.
What do YOU think should happen before the first product backlog?
Looky here at what someone I know sent me:
This person is working on a project in which management requires time tracking in .25 hour increments. On some days, that poor sap and her teammates spend at least that much time at the end of the day aggregating and entering their time into their formal timesheets.
Humorously, those in charge of running the project have no qualms about promoting their process as “agile“.
I can’t know for sure, but I speculate that the practice of micromanagement cloaked under the veil of “agile” is pervasive throughout the software development industry.
Quick, quick! What role is missing from the classic Scrum 1.0 team configuration of developers, product owner, and scrum master?
Ooh, ooh, I know what’s missing….
Me thinks version 2.0 of the Scrum guide should include, and formally recognize, the glorious role of Agile Coach, no?
Since the Scrum Master has waaaaaaay to much to do already (running the daily 15 minute meeting and removing all those bazillions of impediments that the whiny developers willingly disclose every day), she can’t possibly fulfill the crucial role of agile coach. In addition to formal recognition, the Scrum Alliance should create a program where aspiring coaches can dole out some $$$$ to get certified.
To promote their infallible expertise, fathead consultants love to present apples-to-oranges comparisons as though they were apples-to-apples comparisons. One such prominent consultant (hint: a famous Forbes columnist) recently gushed over the success of music provider Spotify.com; contrasting its success to the team that built the buggy, slow, initial, version of the healthcare.gov web site.
As is almost always the case, these clever dudes leave out the oft-hidden, process-independent, contextual, forces that relentlessly work against success:
To imply that the Healthcare.gov team would have been successful if they simply employed agile practices (like Spotify.com) is to either be naive, disingenuous, or both.
Have you noticed that the press isn’t clamoring over the inadequacy of the healthcare.gov site anymore? Obviously, the development team must have righted the ship by morphing into a high performing juggernaut under the tutelage of a cadre of agile process consultant(s) – regardless of whether they did or they didn’t.