A while back I was contracted to help in a huge (100+ Developers), prestigious and expensive high tech project. It was supposed to be a scaled agile setup, but unfortunately a lot of fundamental errors had been made already. Thats why the team that I was assigned to was the reddest (farther behind the timelines than any other team), with low quality code, almost unmaintainable, every bugfix introduced regressions and the product demos werent working most of the time. It was almost perfectly academically wrong. Until this project I had only read about this kind of projects in the books.
Of course this situation was reported by the development team many times, with suggestions on how to improve, but as you can imagine, not much had changed (apart from instructions to work overtime and excessive pushing of people into the project…).
About two years before the launch date, the project was reevaluated. The resulting estimations (time + money) looked rather grim. When the management team asked for more money and time, as you can imagine, the sponsors started panicing. Trust to the management team was gone! After the project was finished I found out that they havn’t been aware of the real situation at that time, since the project progress reported to them almost allways looked on track with only minor problems.
Luckily, the project was to important for the sponsors to give up on it. It was the next big thing, introducing new disruptive technology to secure the market leadership for the years to come. So what would you do, if your money and future was at stake? Well here is how it was managed in this case: The sponsors hired two huge consulting companies. The first one evaluated our techology/architecture, development speed and the costs generated. The results where good news, because compared to other projects around the world with similar complexity we were slightly faster and just as good/bad technologically. Surprise, surprise though, we were just ALOT more expensive! Why was that good news? Well, on this news only the dishonest management team got replaced, the development team got a second chance.
The second consulting company (lets call them TopConsult) was to help execute the plan and deliver on time. Of course they were put in charge almost everywhere. But what do you expect when you lie to your sponsors and they figure it out? Obviously it will destroy the trust. You never want this to happen between you and your customer! But this I will display in another story.
In this article I show you the fastest way to destroy the trust of the development team to the management team. My team was the only one TopConsult wasn’t fully in charge/control, mainly because of the lack of domain know how and some under the radar improvements my team did without approval of the management so that at the time they were hired we were not the most critical team anymore.
As we were going down the road, fixing bugs and implementing new ones…I mean implementing new features…my team was asked at the end of a sprint whether it was OK for two high ranking officers of TopConsult to join our retrospective meeting. They said their goal was to see if there was anything they could do, to help us “improve”. Since the retro should be a “fear-free-zone” to also be able to adress critical and personal problems we denied and suggested to setup another meeting. They seemed to agree-but when we went to our retro-room, the officers were already sitting there and waiting for us!
We didn’t like that at all, and our ScrumMaster supported the team. He pointed out that under this circumstances it wasn’t possible to have a sincere retro. It would be a waste and if they insisted on staying we would have to cancel the retro. “Just cancel the retro, and you will see what happens then!” was the reaction. Our ScrumMaster then asked the team what to do; continue or cancel?
The team decided to cancel and so we did. The next day something to me unbelievable happened: our ScrumMaster got fired and an officer of TopConsult took his place. From that moment on, management lost all trust from all development teams, and the teams went into “Clock-Watchers-Mode”.
To this day I have not found a faster way to undermine your teams loyalty, trust and engagement. Well, in the following weeks, more and more impediments that were blocking progress became visible. Many of these were handled before by our ScrumMaster and the team never got blocked because of them in the past. It took management over one year to get these issues under control (and another team of 5 developers).
Why am I telling you this story? Today I am obviously wiser than back in the days. Today I would realize, that it was VERY important for the management to “observe” our retro. We should have obeyed (I mean played along, acted if you so wish), and then have “the real” retro at a different time, different place (worst case, after work in a pub for instance). After all, what good is the best Sheppard (ScrumMaster) if he is a dead Sheppard (also check Ken Schwabers book Agile Project Management with Scrum)? He can no longer help the team. In “agile” after all, everything that doesn’t get you fired or put into jail is allowed!
So what do you think? Have you ever been in a similar situation? If so, how did you handle it? If not, how would you have handled it being in our ScrumMasters shoes?
I am excited to read your comments!