Last week I wrote a blog on the barriers to using Scrum on business projects. While there are a lot of barriers when it comes to using it for business projects there are many parts of Scrum that I love. Here are six Scrum practices that you can easily implement to ultimately reduce your costs. It’s simple. The more effective you can make your project teams, the more that effectiveness translates into cost savings.
Ask who, what, and why.
One of the activities that a Scrum team does when beginning a new project is to develop a set of user stories. I referred to this and gave some examples in last week’s blog. Regardless of whether you adopt the practice of writing user stories, you can begin to focus more on the “W” questions – who, what, and why – especially why.
It’s clear that you have to know who will do an activity, but don’t forget the other people who are involved. Who actually needs this work product? Who will be approving the quality of the work and who is responsible for managing the budget?
Before you can make clear progress on any activity, you have to understand what you are going to do, and why. Understanding the ‘what’ can be hard in creative projects where the path is not clearly understood in the beginning. Ask questions. Focus on the why.
Before you can make clear progress on any activity, you have to understand what you are going to… Click To Tweet
Use time blocking to focus completely on a subset of activities.
One basic principle of Scrum is the notion of working in “Sprints” – typically, two-week blocks of time where a team focuses on a limited piece of work and moves it all the way to finished. The goal in Scrum is to be able to deliver incremental functionality by the end of each Sprint. According to Jeff Sutherland, one of the co-founders of Scrum, “if something is half done at the end of the Sprint, you’re worse off than if you hadn’t started at all.”[i]
In the business world, it is often the case that there are activities that are simply too big to be done in a two-week Sprint. You can still plan the project so that you regularly deliver value to the client. And you can align your delivery of activities that have real value to the client so that they coincide with the billing periods. At the least, try to avoid invoicing the client for large amounts of work that is half-done.
Focus on delivering value
When we are working on non-IT business projects, there will not be software that can be delivered. That doesn’t mean that we don’t think about how we can periodically deliver something of value. What will help the customer? What can you do next that would be of the greatest value to the customer?
One of the big differences that we often find in IT Scrum projects and business projects is that the activities on business projects are not independent. Often, activities are related, perhaps through dependencies, or because they all are relying on a particular subject matter expert. On non-IT projects, you may have to think harder about how you are going to deliver value.
Involve the customer regularly.
In classic Scrum, there is real functionality delivered to the customer at the end of each Sprint. There is typically a face-to-face demo of the software that has been built. It may not happen every two weeks, but that’s generally the goal. During these sessions, and at other times, there is a real focus on talking to the customer and getting feedback.
It doesn’t matter whether you are developing something for a customer or developing something for management, the team has an obligation to another entity, typically one who is providing the funding. There should be a focus on involving that person(s) regularly. In a fast-paced world, we cannot trust that the objective and scope that were developed at the outset will remain useful indefinitely. We need to meet with the customer and ask good questions, regularly.
Review the past to improve the future.
Scrum offers several times during which teams think about the past and try to plan for better outcomes in the future. The Sprint Retrospective is held after each Sprint to focus on what went well and what didn’t. Planning meetings are held before each Sprint to decide what work will be done in the Sprint. Typically, the lessons learned in the Retrospective factor into the decisions in the Planning meeting.
Regardless of how you structure your meetings, take advantage of opportunities to learn from the past and improve the future. Have a lessons learned database that is indexed and useful. Don’t make the same mistakes every year.
Use standing meetings to build accountability.
As much as people may complain about time spent in meetings, I rarely hear people complain about well-run standing meetings. They are just useful. Those short moments ensure that everyone is on the same page and hold everyone accountable to work promises.
In the business world, with disbursed teams, I sometimes see these meetings as being a valuable time to check in about project issues that need solutions. I understand that those conversations violate the official definition of a standing meeting, but if the conversation is short, focused, and solves a problem quickly, it is time well spent. I typically save them until the end and let the unaffected team members peel off.
Are your teams adopting any of these Scrum practices on your business projects? Share your experiences in the comments.
[i] Sutherland, Jeff; Sutherland JJ; Scrum: The Art of Doing Twice the Work in Half the Time; p. 96; ©2014; The Crown Publishing Group. Kindle Edition.
