DEV Community

Cover image for Setting proper Agile mission statement.
Dmitry Amelchenko
Dmitry Amelchenko

Posted on • Edited on

Setting proper Agile mission statement.

I once worked as a manager on an agile team, which seemed to have always struggled.

It's not that the team was not delivering -- quite the opposite. We built a lot of software and solved many engineering challenges. The engineers were highly proficient.

Somehow, the senior leadership of the company was never happy with us -- we often have heard complains like:

  • Why is it taking so long for my feature to be built?
  • Why can't the engineering team tell us exactly when they will deliver a feature?
  • Why do we keep accumulating tech debt and not able to innovate as much as our competitors do?

We (the engineering team) did everything by the book:

  • daily scrums
  • planning before the sprint start
  • demos and retros at the end of each sprint

Still, our business was unhappy and complaining. In response, the engineering team kept bringing up in the retros, that we are always changing mid sprint over and over again.

I, as a manager, was set to figure out the challenge.

Common agile practice is to define the sprint goals. General sense practice suggests, if you want to have something done -- have a goal.

So, I thought, I, as a leader, must define a mission statement -- problem solved.

Few hours before our next sprint planning, I wrote it down on the white board in our team room:

"To execute the sprint according to the plan".

I thought, this is exactly what the team needs -- this is got to be the way how to motivate the team.

When we all came into to the room for the planning session, here is what we saw on the white board:
Mission Statement

Some engineer added second bullet point on the bottom which read:

  • have a plan you can execute in a single sprint

This was an eye opener -- the lack of commitment was not the problem. The problem was -- unrealistic expectations that were set by the business.

In this organization, the agile transformation was initiated by the business as a way to optimize performance and deliver more. Before anyone realized, it turned into the tool for putting more pressure on the team while attaching a nice label to it -- hey we are doing "agile" so nothing is wrong with asking "when are you going to be done", right?

The reality was that by doing everything by the book and having all the scrum rituals in place was not making the org more agile. There was a huge cultural issue -- the business was so overpowering in their demands, which made the engineers afraid to speak up! And they also felt, that, even if they did, it would not make a difference.

What happened in that team room -- was a scream for "HELP"!

The team was trying to convey to me, the manager, please, listen to us, what we are doing is not agile, let us figure it out and let us become part of the solution.

My first inclination was to erase the second bullet (since I didn't put it on the board, and I already knew exactly what the team needs) and carry on with the planning session as nothing has happened.

Instead, I resisted the urge, and we (the team) accepted "have a plan we can execute in a single sprint" as our next goal.

And that was the best thing that ever happened in my leadership career.


Article was originally posted here.
The image came from wisaw

Top comments (0)