Most of us are creatures of habit. We have favorite restaurants, favorite clothes, and favorite hangouts. If you doubt my statement, why are there Starbucks on every corner and McDonalds at every exit off of the interstate? Because, even when we are 2000 miles from home, we know what to expect at McDonalds or Starbucks. When I was traveling internationally, we would temporarily step back into America by getting a Big Mac or a Starbucks. So why am I rambling on about this? How does this apply to business? Why do you care?
Software organizations can’t be creatures of habit. Think of businesses that have continued to operate as they always had. Newspapers and magazines have been slow to move into the digital world, while websites like the Drudge Report have revolutionized how we get our news. Network news organizations have had similar issues. Digital Corporation, horse and buggy manufacturers, Studebaker, Packard, and Xerox are examples of businesses that didn’t adapt.
In software development organizations, most organizations continue to use a Waterfall approach. We have continue to use the Waterfall approach even though the evidence is mounting that there are other approaches that may be more efficient while delivering a better product to our clients. These approaches have names like Extreme, Scrum, and Crystal. Adoption of these new approaches has been slow in Indianapolis, though I can guess why.
My educated guess is that midwestern values continue to detour our thinking around new approaches to software development. Most of the business leaders and businesses in the Midwest have their roots in the manufacturing. Assembly line thinking dictates knowing exactly what you are buying, what the cost will be, and when you are going to get it. The fallacy is that most businesses don’t really know exactly what they want. If they do know what they want from a software system or a website, by the time the system is completed, the business environment and requirements have changed. If businesses did know what they wanted, we would never need a change request.
Software organizations in the Midwest complicate matters by not educating our clients on the new approaches. Projects are drawn up as fixed bid contracts. Sometimes, projects are executed as an “agile” project. To some development teams, an “agile” project means a project without documentation. Note: An “agile” project should only produce documentation that adds value. Documentation that doesn’t add value is not produced in an “agile” project.
Without an educated client, scope is allowed to change without CRs and the required corresponding approvals. When the project ends up over budget, clients respond with “we didn’t approve those changes”. Guess who gets stuck with the cost?
I have used Scrum in development projects without specifically labeling it Scrum. To avoid acting like a lunatic, software organizations need to do something different. Here are a few simple steps to take to start being “agile”:
1). Get some training. There are a number of companies that conduct CSM and CSPO on a regular basis. Choose a class that is being run by a Certified Scrum Trainer. Professional trainers are also usually Scrum coaches, and have real world experience.
2). Hire a Scrum coach to provide counsel and advice throughout the project. While this type of consulting is expensive when you consider the hourly rate, the impact of having a coach will save money and time across your teams. (See #1 above.)
3). Apply the principals of Scrum that you were taught in your training. The CSM should ensure that the Scrum team adheres to the principles. Include your Scrum coach occasionally in your daily Scrum meeting, providing guidance and coaching following.
4). Remember that your organization may have it’s own project reporting standards or best practices. Management may be used to those standard reports. In addition, they may not understand what Scrum is. To help your organization overcome the transition, Scrum information may need to be massaged and utilized into any standard reports.
As a creature of habit, you are probably uncomfortable right now. Taking a different approach like adopting Scrum seems as though it is a big step. In reality, it is a series of small steps (sprints), giving you more opportunities to take stock of where you are and correct as needed. Scrum also provides transparency by providing functionality that can be deployed sooner which can provide an Return On Investment sooner. Providing transparency and the ability to correct mistakes while they are small reduces the overall risk to the project. Reducing the risk across all of your projects will result in more projects on time and on budget.
So are you a creature of habit?
Thanks for coming in today.