By now you've heard the word scrum in the hallways of any company that builds software. In many cases, mid-sized companies managing multiple projects have embraced the term and have launched numerous projects under scrum management. Many technology leaders are befuddled when projects under scrum management false start or they see the utter confusion on everyone's face. Why is a system developed to be more simple and productive so hard?
It is simple right? Everyone knows that Scrum is a skeleton process with predefined rules anchored around the ever present "ScrumMaster." This product owner runs sprints, lasting 2-4 weeks, with a goal of creating incremental usable software. Ideally the business stakeholders see usable software at the end of a sprint and the big kicker is the developers produce testable code in nice bite sized chunks. Let us not forget that a product person chips in by owning a product backlog comprised of "user stories." The value of a user story can not be understated. In the simplest terms a user story defines the product/feature in layman's terms so that everyone is on the same page. This loose process is supposed to be a recipe for productivity.
A scrum purist will tell you that by definition scrum accepts that products and/or solutions cannot not be created in a predictive manner. Change is inevitable. Scrum embraces change and focuses on quick deliverables traversing a common vector.
So what's the problem?
Ironically Scrum is typically explained to the masses from a technical person's perspective. I've personally seen insane productivity numbers once scrum is underway. Despite measurable impact, the business stakeholders can be left with a stale taste in their mouths. As anyone in software knows, you can deliver on time and to the specification and still fail!
Scrums fail for two primary reasons: poor presentation and lack of focus on users stories.
Technologists often forget that they must sell the process. Proper expectations must be set in the language of the business stakeholders. One common mistake is to fall in love with burn down charts produced by scrum management tools and show them to the business team. Think about it! You show a chart that shows how far ahead you are or how far behind you are. Both have downsides. If you are ahead more features are required. If you are behind, in their minds you might as well revert back to old faithful- the Water Fall method.
The reality is the schedule doesn't matter!
How do you sell it?
- Sell the business team on productivity and what they will get and not how well the project will run.
- Speak to the transparency of scrum. Everyone is involved sooner, thus identifying potential problems earlier saving time and money.
- Scrum is a methodology the company should use, not just an engineering process.
- Products/features are delivered sooner thus contributing to revenue sooner.
As the business changes, scrum adapts. It's like turning a speed boat versus the Titantic. The other common mistake is to build features that sound like the following : "Build SQL scripts to archive old table data" or "Upgrade source code to use LINQ." Neither of the two mean anything to the business team or better yet the sales team. While they maybe tasks that are necessary, completing the tasks yields nothing. A better approach is to develop crystal clear user stories such as "As a user of Acme site, I can search for data for up to 12 years in the past" or "When a user is in the process of registering, if he clicks back and then forward his progress is saved."
Concise user stories will level the playing field for the business and development teams and give them a common language.
Give it a try.