Westerly Consulting

Homehome.html
Due DiligenceDue_Diligence.html
ProductProduct.html
Management AdvisoryManagement_Advisory.html
BlogBlog.html
AboutAbout.html
Contact UsContact_Us.html
 

Agile is a team sport

Stop blaming the engineers


Fred Engel

Westerly Consulting

www.westerlyconsulting.com


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 don’t 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 was 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 immediately. 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 Pete 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, and engineering a new market with some new capabilities is the heart of the business and needs 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.”


The traditional problem of all requestors coming into engineering and negotiating for time has created a set of habits that are bad for the business. The engineers, in the midst of trying to build very complex software (and building software is extremely complex!) are also being asked to make trade-offs between Sales, Operations, Key Customers, and new markets.  This is an upside down business model that Agile stops cold.  Agile tells the engineers to stop playing this game and bring actual facts and reality to bear on the decision-making.


Agile stops this old habit cold because in Agile the engineers only work on those things that are Business Priorities as decided by the Product Owner, who gets direction from other business people.  The engineers are now saying “no” instead of saying “yes”, not delivering and being everyone’s scapegoat.  Agile stops the “yes” delusion that has gone on far too long in the Waterfall world.  It stops the delusion that engineering can do A and B and C and D, when in fact it may only be able to do A or B or C or D (or some combination depending on complexity).  It forces the business leaders to move off the righteous position of “those engineers are failing” to a more realistic position of “I need to make trade-offs and decide on priorities to allow us to deliver regularly to our commitments.”


In Agile, the priority for Business decisions moves to the business leaders and is ongoing. That is, the cadence of these decisions needs to be frequent and timely enough to cause the business to stay just far enough ahead of the engineers to allow them to just focus on building creative working tested software. It also needs to be defined in time to allow the setting of sales and customers’ expectations.


Agile is a team sport.