I am currently working on a gigantic project with over twenty software development teams. It isn't straightforward and contains numerous surprises for everyone involved. Projects like this are emotionally exhausting and require focus and attention to detail which can humble the best professionals. Along the way, I have learned a few things about myself and the SAFe scaling framework. Additionally, I have discovered an anti-pattern which I need to expose to my fellow coaches and scrum masters.
One of the base requirements of any project is to have a source control system to manage code and a kanban board to track user stories and defects. The board can be as simple as post-it notes on a whiteboard or as complicated as an elaborate software package. Like many organizations, our project uses Jira. The company uses the tool to keep track of the numerous teams and the thousands of product backlog items completed each iteration. I will not waste my readers' time critiquing the merits of Atlantasan's project management software. You can find better discussions about the subject elsewhere on the web.
What I have noticed is an ugly anti-pattern that is taking place on this large project. One of the technical leads called it "Jira-fishing," and if you want to deliver value quicker to customers, it needs to stop. Jira can help an organization or transform it into a bureaucratic cesspool of evil like any software development tool. If software developers or product owners engage in Jira-fishing, you are fighting corruption.
Jira has a powerful feature known as linking product backlog items. It allows a developer or product owner to connect other product backlog items to the original story. So if you are building out a web service and the front-end developer will use it, you can link your story to the front-end developer's story and say they are either dependant on each other or related. The feature makes it easy to track dependencies and establish relationships between different pieces of work. Things become evil when multiple teams in the same repository create defects and "analysis" tickets that block other work. A product owner or developer is "fishing" around multiple tickets to understand dependencies and stopping a work item.
For example, we have a team building APIs, but another team is working on the database, and a third-team is constructing the UX/UI for the customer. The front-end developer on the UX/UI team has a story to edit a record, and they rely on an API to work correctly. For the API to work, the developer on the API team needs to have someone on the data team properly update the database. During testing, the front-end developer discovers the data is not updating correctly. Naturally, the developer or the quality person on the team creates a defect, links it to the front-end development team, and then assigns it. The Product Owner on the development team is then aware of the fault and assigns a developer to fix it. During debugging, the API developer discovered a database problem and raised a defect to the database team, and the process repeats. For the Product Owner of the UX/UI team to understand what is happening, they have to go fishing through a minimum of three Jira tickets. Each defect can have a different priority for each group, and the original story for the UX/UI team will not get completed during the sprint because of those dependant defects. Timelines slip, and the customer does not see any business value.
The previous example is a simple illustration of the problem. I see stories that have taken sixty days to resolve because of numerous dependencies between teams. Deadlines are out of the team's control, and work is held hostage by another team that does not have the same priorities. To anyone who works in the agile or SAFe world, it is a prescription for anxiety.
The easy answer to this problem is organizing the development team, so a front-end developer, API author, and database person work on the same team to address the original ticket. Dependencies vanish, and work moves through the system in a smoother fashion. The practical reality is that splitting up teams and reorganizing them in the middle of a massive project guarantees the project will go over budget and be late. The team's reorganization won't work because it violates Brook's law which says, "adding staffing to a late software project makes it later. If adding a new person to a late project makes it later, I will expand that postulate and say reorganizing a software development team on a late project will obliterate any reasonable deadline. I call it "Wisniowski's First Theorem of Project Management."
What is a coach to do when confronted with Jira fishing and dependencies which resemble a series of Russian nested dolls? I always return to the notions of empiricism and transparency, which are central to agile. The Product Owner must explain each link or dependency in the story along with the acceptance criteria. It should look something like this below.
This story is dependant on story 123 from the database team >> which depends on story 345 from the API team >> which requires a change request 678 from the claims team.
The point is that the Product Owner and the team can clearly see the dependencies and mitigate them.
Each day I have a standing meeting with product owners who have dependencies with my team. Next, it will become apparent where the dependencies are happening. It is then up to the Product Owners or scrum masters to create a steering committee or scrum of scrums to address these situations. Finally, when all else fails, get executives and stakeholders involved. Often these individuals get in the way of progress with micro-management, but when priorities do not align and work is stalled, they can step in to clear out a blockage. In most organizations, the Executive Vice President of Development has more authority than a product owner, so when the Executive Vice President asks why something is lingering for sixty days, it becomes a priority for the organization.
Jira fishing is an ugly by-product of a large project with numerous dependencies. It is also a symptom of agile teams which are not cross-functional. To mitigate these challenges, make sure all dependencies are linked to stories and are explicit. Next, create a scrum of scrums or steering committee to deal with those dependencies. Finally, have executives and stakeholders get involved to break down obstructions to work. I enjoy going fishing. I don't want to do it in Jira.
No comments:
Post a Comment