Two things destroy productivity and torpedo customer expectation on an agile team.
1. Unnecessary rework
2. External dependencies
We’ll discuss how to minimize unnecessary rework in this article as we focus on Agile Manifesto Principle #4.
There are two types of rework that agile teams do: necessary and unnecessary.
What’s the difference?
Unnecessary Rework
When product details are ambiguous assumptions will be made to fill in the lack of definition. The “assumptions” made by the developer or the team will result in extra work that may take the product in the wrong direction.
Unnecessary work also occurs when teams build out too much infrastructure ahead of the customer’s needs because of an urgency to be ready for a big production system.
Teams can be tempted to extrapolate and create a system that supports much more functionality or infrastructure than the customer needs or wants. Sometimes managers call this ‘Gold Plating.’ In LEAN this is simply called waste.
Alternatively, developers and system engineers might attempt to minimize rework by asking for a large discovery period in which they think and write information in textual format or illustrations. This has the illusion of removing unnecessary rework, however, it doesn’t effect the rework curve dramatically on highly innovative product development. It can reduce some of the unnecessary rework but typically results in too much up-front work for prototype products and too little learning directly from the customer.
Necessary Rework
Some rework is to be expected. Once the customer gets a working product based on their initial request they’re going to see things they want to change. From the resulting software, they learn they want something totally different or see areas of improvement based on their hands-on use of the application. This is a healthy cycle where you quickly give a customer what they want and they can critique the product they just requested.
To visualize the cost of unnecessary work, I’ve called on the higher power of mathematics to simulate the increasing unnecessary work that occurs as the communications between team and PO or team and customer is delayed.
Note the graph above shows days on the x-axis and effort on the y-axis. The equation is a parabolic curve starting at some fixed point on Y-axis (0,Y0), where Y0 is the quantity of work that will remain untouched in a product. The graph shows a plot of the parabolic function f(x) = (x – h)^2 + k, where the vertex of the parabola is (h,k) = (0,Y0). I don’t have actual data to validate the curve, but my 20 years in software development comparing short releases versus long release cycles is enough validation for me to make a bold statement.
Long release cycle snowball with effort due to rebasing code after weeks or months of development and attempting to merge into an active release branch with lots of bug fixes and small features. In addition, long releases enable you to create too many features that won’t ever be used or must be re-worked to be useful.
The blue area under the curve represents the work a team does that results in virtually no rework. For each day of effort the team puts in, it’s assumed that some of that work will remain unchanged for the future.
Assuming 2-week sprints (10 working day), if a release is made to the customer after the first sprint, the green area under the rework curve is small.
If a release is made to the customer after the second sprint (20 working days), the rework effort grows more dramatically as shown by the orange area.
After the third sprint, without talking to a customer, the rework is fairly large as shown by the red shading.
This curve of this graph is exaggerated for sure, but the rework equation holds true for nearly every project. Rework grows bigger as you build more software without having regular conversations.
Minimize the Communication Lag
- Frequent deliveries (See the article about agile principle #3, “How to Accelerate Agile Software Delivery“)
- Daily communications with the product owner
Daily Communication Reduces Rework
As an agile leader you can reduce unnecessary rework and close the communication gap by following these product owner practices:
- Have a product owner.
- The product owner is active in grooming.
- The product owner is available to the team pretty much any time the team has questions.
There are no substitutes for a dedicated product owner. I’ve tried part-time product owners, proxy product owners, and executives with great ideas but no time to participate in backlog creation. The greatest success I’ve had is in product development is working with a full-time product owner.
How to Locate a Product Owner
If your team is really cranking through the backlog and the backlog is not getting refilled fast enough, continually go to the business unit with an obvious request–“Can I get a product owner?”
If you’ve got a budget and no product owner, there’s no reason to hold back. If you don’t locate a product owner, you will face a lot of unnecessary rework.
In the event you cannot locate a qualified product owner, the scrum master will have to step up. As a scrum master, I have facilitated the role of a PO many times for small or medium sized projects.
Not having a dedicated PO causes extra rework, but it will keep the team going. Perhaps this is the best you can do if you are a scrum master and the organization has not decided to identify a Product Owner for your team or project.
Make Sure to Get a Product Owner Involved
Product owners need to be present daily at standup. It’s sometimes considered optional, but I’ve found that my high-performance teams are going so fast that they can’t do without a PO at the daily standup.
And sprint reviews go awesomely fast when you’ve talked every day with your PO over the past week. If additional stakeholders show up to the review and the product owner accurate conveyed the desired features, the team will likely receive kudos.
What About Remote Teams?
Remote teams are not as efficient, but, in a world that increasingly embraces remote work, you will need to find the ways to become efficient. It’s best if there are at least two people in a single location so they can collaborate. Every remote team I’ve ever worked with has had at least two locations and sometimes three or more. Some team members have work-from-home days, which increases staff distribution significantly.
Tools like HipChat and Slack can help with fluid communications within the team. When integrated with an agile project management tool like JIRA everyone can more easily stay on the same page. Everyone is made aware when a submission is being made to the code repository.
If the product owner stays plugged into the HipChat group, the communication about product definition keeps the team delivering spot on functionality.
Digital chat room tools are not as good as turning to a colleague and saying, “I’m going to submit this change, can you please review it,” but it’s probably the next best thing.
When your PO is remote, it’s also harder. In my company, 2 out of 6 POs are remote so team members spend a lot of time on the phone. Interestingly, everyone has gotten pretty good at communicating over time, even though we have a highly visual web product.
The most productive and successful team with remote POs and remote co-workings are plugged into HipChat and on the phone for many minutes a day (dare I say hours).
Make it a priority to remove the communication barriers between the people who know what they want to be built and the people who build it and you will be effective in killing off unwanted unnecessary rework.
What is the biggest communication issue that you face between your team and customer or business leader or product owner?