Bill turned to me, the Agile Coach he was looking to hire to “fix engineering”, and said “I am tired of the laziness and non-delivery of the engineers. If they want to be Agile, that is fine with me, but I do not want this stuff bothering the rest of the company. I just want Engineering fixed! I want them to understand this is a business and they need to deliver!”
I didn’t know where to start. As with many organizations that have abused engineers for years, he (the CEO) just did not understand this was a company problem, not just an engineering problem. The engineers were not bad employees, they actually worked harder than almost anyone in the company. The problem was that the decision process in the company was loaded to make the engineers fail and the whole company was complicit in the poor track record of delivery. After thinking about this I told him a story of a company I had worked with a long time ago.
“Bill”, I said, “A few years ago I accepted this assignment where the CEO believed as you do that it was only engineering that were the cause of poor product delivery. We trained the Engineers in Scrum and started a 4 weeks Sprint. At first, the engineers were skeptical of this new process and balked at participation. However, a few days into the Sprint they began to see the power it had for them. They liked the team nature of the experience. They also liked the help they could get from the others. Best of all, they liked the fact that the work they were asked to do would not change for the entire Sprint.
Unfortunately, this did not last long, as old habits die-hard. Everyone in the company had different habits of getting the engineers to change priorities. Sales folks either sweet talked people into accepting new features, or would threaten the loss of a key customer or a big sale. Operations people would declare a problem to be Severity 1, and in need of immediate fixing. Product Management would change their mind about what was asked or what the priorities were. Customers would call in and convince support to declare their problem Severity 1, as they would leave the company if the problem was not fixed immediatly. It just did not stop.
After much discussion we got all of the engineers to say to each requestor, “I will write it up and give it to Pete, the Product Owner.” If makes it a high priority, I will work on it. Pete was instructed to only allow real (not pretend) Severity 1’s through. This reduced the interruptions by about 90% and the team became really productive.
When Pete said “No” to people they went ballistic. They were used to getting their way and suddenly being told that they had to get in line and do a real justification was not acceptable. They escalated their issues to their bosses. These bosses would argue with Pete, his boss and eventually the CTO. The CEO soon found himself trying to make priority decision that he thought belonged to engineering, and was furious. Why was he making these low level decisions?
But these decisions were not engineering decisions. They were Business Decisions to be made by the business people in charge, not the engineers. Deciding between saving a sale, a customer, or engering a new market with some new capabilities are the heart of the business and need to be made by business leaders. The engineers should not be choosing between a new feature and closing a sale. That decision belongs to a business manager, and now those decisions were being pushed to the right people, who did not want to take the responsibility or accountability for these decisions. There was also no decision process to make these trade-offs in a timely manner.
Agile is for the whole company. Agile is a team sport and the Company is the team
© 2011-18 Westerly Consulting LLC, all rights reserved