Presently, I am working on a gigantic project. It is the replacement of a forty-year-old enterprise system. Teams reside over three continents, and conference calls have hundreds of participants. Projects like this require millions of dollars and the patience of Job. I exist as a product owner who intersects with the organization's remaining units. It is a tremendous amount of responsibility. Today, I want to discuss a vital work component on a gigantic agile project.
When working on a massive project, the biggest challenge is making sure the work is completed quickly and with sufficient quality. Teams hand off work to each other, and those are usually the pain points as one group takes over the work of another. It is why scaling frameworks like SAFe, LeSS, and Scrum at scale have become so popular in enterprise-scale projects. The additional artifacts and rituals of scaling frameworks are supposed to prevent botched handoffs and production environment problems.
Disagreements are going to happen. Large agile projects are strange because there is a tension between the need to manage hundreds of people to get a job done and the desire for those people to be empowered and autonomous to get the job done. How we handle those disagreements can make the difference between success and failure.
I received a directive from an executive to do something, contradicting over twenty years of my experience as a technology professional. I objected and said it violated both the letter and spirit of agile. The response was terse, "We are a SAFe project, not an agile project." At that point, I had some choices. I could be insubordinate and not carry out the order. My other choice is to follow the directive unquestionably. I chose a third path that agile coaches embrace called "disagree and commit." I explained the foolishness of estimating research spike and then said, "You are in charge of this project, so to save time, I am going to disagree with you but commit to this course of action." You are not being insubordinate, and you are pointing out a future complication or challenge which the team can resolve when deadline pressure is not severe.
Six years ago, Jeff Bezos, in his letter to shareholders, said the disagree and commit approach is how Amazon was able to create Amazon studios. It is also a decision that can easily be reversed. Any discussion about the merit of a process can get vetoed. Fortunately, you can change most decisions, so the quality of a decision is not what matters but the speed.
In my brief tenure on this project, I have delivered software and improved the process for the team. I believe that my approach will be vindicated, but for now, I will commit to the other one because it is easy to reverse when the time is correct.
The manifesto says working software is the accurate measure of the progress of an agile project. Disagreement is a natural part of creating working software. Saying you disagree with someone is not insubordinate; it is sticking up for your development team, quality of work, and professional ethics. Committing after disagreement means you want to get the working software into production sooner. It keeps the bills paid and ensures a massive project does not collapse into a big ball of mud.
Until next time.
No comments:
Post a Comment