The Agile Monster
A developer once came up to me, and asked me, what is agile for you? This developer was not a junior. This was a guy that was in the field for at least 10 years working with various big corporations. I related the question to his sense of unbelief that agile exists. This hunted me for a few days. Once you work in a company where you live agile values, you see it; you get it, it’s an experience.
I worked in the same place as he did and recognized his pain.
Story or Requirement?
Most teams I met use scrum, within a scrum sprint, engineering teams often use the concept of a user story. A user story should be a short, simple description of an end user’s need. I noticed that it’s often a requirement that came from somewhere and had nothing to do with stories.
The engineering team discusses requirements to understand and break them up. If the requirement is unclear, the product owner[1] goes back into the organization and gets the new questions answered. The engineering team plans the requirements in sprints and commits to finishing them at the end of a sprint.
But where do these requirements come from?
Product managers.
Product managers handle the product roadmap, product vision, product strategy, and way more, but I’ve noticed that product managers define an extensive list of features to work on. I’ve seen this list being generated by top management as a quarterly plan.
Quarterly plan
Figuring out which ideas are valuable and which should be prioritized makes defining a quarterly plan hard. In order to achieve this, business cases are often formulated from those ideas. They want to know how much money or value a business case will make, versus how much money/time a business case will cost. This makes prioritization “easier”.
Business case
In order to calculate the business case cost, you have to know exactly what to build. This is where product managers/owners come back into the picture. They run around the organization to figure out what the idea entails and gather requirements from “the business”. Write them down and communicate with the engineering teams. Engineering teams plan sprints and cost is calculated.
Boom! Approved!
Management will approve business cases, prioritize and define quarterly planning, and set deadlines. Product owners prioritize their backlog, and engineering teams start work.
The plan is the goal!
The entire organization is now aligned to follow the quarterly plan. The business case is created, costs defined, and requirements set. In this stage, any change is unwelcome and any change will deviate from the quarterly plan. And we expect engineering teams to meet the promised quarterly plan.
This makes the plan the goal. Thus, it is now impossible to live the agile value:
Responding to change over following a plan
On schedule?
Agile with a schedule is not agile, it’s waterfall in disguise.
In the end, I don’t think that the developer that came up to me ever experienced any agile environment. A place where collaboration is top priority, where changes are welcome, and where hypotheses are tested consistently.
That’s agile the monster.
1. The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.
