As we discussed last week, when it comes to project portfolio management, the best approach is to get rid of the project governance process entirely. How? By eliminating projects as a class of activity altogether.
Instead, next-generation IT organizations should manage all activities as an ongoing stream of releases, doing so by embracing the agile variant scrum (last week's topic) -- with additional wrinkles (this week's topic).
[ Find out the 10 business skills every IT pro must master, beware the 9 warning signs of bad IT architecture, and steer clear of the 12 "best practices" IT should avoid at all costs. | For more of Bob Lewis' continuing IT management wisdom, check out his Advice Line newsletter. ]
And by "embrace," I mean adapt scrum to deliver business change, not just software that "meets requirements." Because as regular Advice Line readers know, everything is about improving the business, or there's simply no point. But how do you go about it? That's where Goldratt's theory of constraints (TOC) comes in. Eventually.
Delivering business change with scrum
Scrum works as a project-management alternative to the extent that you can break down software design into a collection of more or less independent features (now called "user stories"). Once you've done this, they are added to the enhancements queue -- renamed "the backlog" -- and are incorporated into releases (sprints) according to business-established priorities.
Business change, however, involves more than just dumping a new piece of software into the system and hoping everyone figures out how to use it to improve the business. It involves additional tasks such as designing improvements to business processes and practices, training, communication, making accounting changes, redefining performance metrics, and a bunch of other stuff.
Organizations that want to use scrum to manage business change will have to add all these tasks to the backlog, right alongside software features. This is a perfectly reasonable thing to do. In many cases, it will mean that user stories -- use cases with almost all the detail left out -- will become, well, use cases with almost all the detail left out.
Remember: Use cases are more than just descriptions of how software is supposed to behave. Done well, they describe how work gets done using the new software, which is just what the doctor ordered.
When the time comes to work on a user story, aspects that have nothing to do with software will be assigned to appropriately qualified business staff, who, in addition to working directly with the developer assigned to the user story, will have responsibilities of their own.