There is much to love about Scrum and Agile. Yet, there are still some naysayers. Most of the time, when I talk to people with negative experiences, the issue is more about the team they are on than the method they are using. Sometimes, though, Scrum is just not a great fit for a project. Here are three barriers to using Scrum on business projects.
Sometimes Scrum is just not a great fit for a project. Here are three examples. Click To Tweet
The speed at which the project work is to be done is inconsistent.
In business projects, there are often situations where people are working on multiple projects. The work ebbs and flows, depending on where things stand on the project. You may have just met a critical deadline and it’s time to take a break and let your client spend some time with the work that you have delivered. Or, your project involves multiple presentations, a rush to get things ready for a presentation, and then, the need to slow down and intellectually process recommendations. When you are working on a merger or acquisition, you simply cannot force people into change.
One premise behind Scrum is a focus on reducing waste – by improving velocity, a statistic that measures the work that is accomplished in each sprint. This premise assumes that everyone is working the same number of hours each week. When team members come and go, or when the work is inconsistent from week to week, the statistics will simply not be comparable, or particularly meaningful.
User stories may distract us from the objective.
Let’s start with an understanding of what a user story is. Typically, Scrum teams begin a project by creating a list of user stories (usually on sticky notes). The objective is to describe the feature that is needed, why it is needed, and who needs it. Here are some examples of user stories:
- As a new software user, I want an easy sign-up process so that I can pay by credit card or PayPal.
- As an executive with oversight over the marketing department, I want a dashboard that will show me where things stand with all my projects so that I can better manage cash flow.
When this is done well, the user stories have a certain set of characteristics, defined in the acronym – INVEST. All of the user stories are: independent, negotiable (can be changed), valuable, estimable, small, and testable. This concept works quite well in some software development projects.
In business projects, the activities on the project are not always independent or negotiable. The value of the entire project is often much more than the aggregate value of all of the individual activities. I agree that there is great value in understanding the ‘who, what, and why’ for each activity, but ranking the activities in the order of business value ignores dependencies.
I sometimes see user stories as a distraction from the overall project objective. In established software development projects, ranking features makes sense. In new software, are we sacrificing a solid well-designed architecture, for a handful of loosely related features? Will our approach result in software that works seamlessly from beginning to end?
On business projects, the situation is often muddier. Suppose you are developing an on-boarding process for new hires. Do you create an objective that ensures that new hires are able to provide meaningful work to the organization within two days? Or, do you aim for a process that ensures that new hires are fully trained on all necessary organizational processes within two months? These are vastly different objectives, and there are many permutations and combinations of possible objectives. I’m a huge fan of agility, but in this example, it makes more sense to me to determine your objective and move forward.
Self-managed teams may not be a great objective for all projects.
I believe that businesses need to be capitalizing on the benefits of highly functioning teams by using them over and over again. However, the reality is that many businesses don’t. And if an organization is going to pull a team together for one four-month project, there is hardly time to get the benefits from having a team learn how to manage itself.
There is no question that it takes time for people to get to know each other, and for teams to bond. The investment in self-managed teams can reap rewards in the long-term, but in the short-term, it can be bloody. Furthermore, when team members come and go on a project, it can wreak havoc with the sense of community that has developed on the team.
Here are some examples of situations where it may not make sense to opt for a self-managed team:
- An organization that forms a team for a one-off project with no anticipation of using the team again;
- A consultant who engages a group of subject matter experts to respond to a winning project bid;
- A non-profit, working on an annual community project, where the people involved change each year.
Have you experienced barriers to using Scrum on business projects? Let’s talk about it. Make a comment, or give me a call.
