Two main errors your agile project may have right now and how to solve them
Doing agile for software development is way beyond leaving the heavy documentation behind and produce more. According to an HBR study of 2018, 25% of enterprise companies are already using agile and 55% are in the process of doing the same. The data doesn’t lie: the masters of DevOps and Agile grow and are 60% more profitable than the rest. Agile brings many benefits, but it also brings new challenges built-in. The single point of adopting agile is already a major challenge. But after them, new challenges are still there and you might not have noted them.
1st — Involuntary blindness from POs
A day in the skin of a PO (Product Owner) is tough. They own the product! And are responsible for its evolution. Basically they are responsible for translating the company’s macro strategy for that product into the actual final product. It sounds pretty simple, but this process is where commonly things get fuzzy. A PO also:
- Solves questions from the development team on their tasks;
- Keeps feeding the backlog;
- Helps the Scrum masters with decisions for prioritization;
- Eventually, changes prioritization and delivery plans because of special requests from the management;
- Monitors metrics of the product;
- Is responsible for meetings with high management to discuss the metrics she’s been monitoring;
Many of the items above would require a person full time working to fulfill it successfully. But given this load of work, the PO often leaves behind one important thing: hearing what the market is saying and still staying aligned with the macro strategy. By that I mean the PO frequently doesn’t have time to think, judge and decide appropriately after a new demand came from a BA (Business Analyst) or high management. Due to lack of time, she leaves behind the most important task of his job, which is enhancing the product. Let’s go over one example to better illustrate:
A page never used in a hotel website
Years ago I was the SM (Scrum Master) leading a team developing a hotel website. I remember as if it was today. We had a big deliver at the end of 3 months and in the last week, my PO brought me the news that we missed one important page to showcase the hotel’s partnership with an entertainment channel. Guess what? We worked several hours more than planned and delivered just a small part of that page. Also kept working on the same page even after the deadline. We released the final page a few weeks later, and I was checking Google Analytics. I found out that that page had less than 5 percent of the website visits.
The summary: we spent at least one entire month of work on a page that less than 5% of our target public was actually interested in. We wasted one month of money for a team with 4 dedicated people. There was no regulatory thing and no contract binding forcing them to have that page live. It was just a request from a board member. In that situation, the PO SHOULD have argued about not doing that and going for the e-commerce system as a priority. This was actually something the users were asking strongly.
But why did the PO let it stay that way? The answer: she didn’t know that page was about so few accesses. She was so dived into the deadline and reports and monitors and tests that she just accepted the request without questioning it. If she had had time to think about it, with the appropriate information from her BAs, she would have taken a better decision.
2nd — Deficient hands-off of tasks from the PO/BAs to the delivery team
The second thing that often breaks plans is when the planning meeting is already going on and the technical team finds out a task is much bigger than the PO/BAs thought at first. When the PO is defining the next tasks for the backlog, she must be well aligned with the software architects. When a major feature (an epic) comes to the table, the technical team has to adapt the software to develop that new task accordingly. Let’s go over one more example:
The “just one more report”
This one happened during a project for one company in the manufacturing industry. The software had been running for months and was stable. We were in a phase of acting over bugs, security and small features. We were also generating some reports for gathering new metrics. When the planning started, our PO explained about the task of adding more columns and creating a new report with charts. The charts were fine, but those new columns were stored in other systems which we didn’t have control over. We had to talk to people on the other software to create an API for us to consume the data, and the simple report took more than a month to be finished.
The interesting part of this example is that the report was promised to be delivered after one week and took almost 2 months. The management had to wait for the new report to take new decisions because of the important information. The change from 1 week to ~2 months created an unneeded discussion between the project team and the management. All of that wouldn’t have happened if somebody with a brief technical vision of the project was involved during the grooming/prioritization of the backlog and had properly communicated with management.
If a task much bigger comes with no previous preparation, it generates delay. The way to solve it is to have technical senior people checking the backlog periodically and being closer to strategic decisions. This way they will be able to anticipate such moves and tackle big tasks little by little.
At last
Agile is not exact sciences. You will have to find your own set of practices that will create your own agile. These are the two main challenges I found are often hidden and people don’t actively tackle them because they don’t hurt at first, but yes have side effects that can turn into a big mess. And what are your main challenges?