Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
These are two principles of the Agile Manifesto. In this blogpost, I’ll write about some of my experiences with aiming for a constant pace by using the empirical freedom of the agile mindset.
Have you ever been in a situation where the development team needs to rush to make the sprint? Maybe you were even a member of the team. Among heaps of reasons, this sprint could have been unintentionally underestimated or maybe impediments affected the development efforts.
Under pressure of different origin, the team will start cutting corners which introduces technical debt or bugs. They will also have a lot of stress in order to try to make the sprint. I even saw teams cancelling their reviews, simply because of the fact that they didn’t finish the sprint. Which in turn has a negative impact on the relationship with the stakeholders.
There might even be another negative consequence; overestimating the next sprint or manipulating the estimations. Team members might do so, so they could relax or even chill at the end of a sprint. This affects the teams pace and doesn’t support the continuous delivery process at all.
During retrospectives teams spend a lot of time figuring out why the sprint wasn’t completed, why the estimates were off, how to increase the velocity, sometimes even questioning their own ability of creating software. Based on these long discussions the team will tune its behavior and starts experimenting.
Common changes or experiments that many teams try are:
- Spend more time on estimates
- Spend more time on planning a sprint
- Spend more time on refinements
And did those experiments pay off? Do the extra time and effort weigh up to any positive effect?
In our case, no. The results of the experiments only took up more valuable time.
When working with Scrum, we already have an agreement with the stakeholders about working agile. The stakeholders are happy with having the ability to adjust their plans and priorities.
Why not take the approach a step further and provide the stakeholders, the Product Owner and the development team even more agility? Get rid of the extensive planning sessions, rushing or relaxing at the end of sprint, using the retrospectives to solve this and creating tech debt?
Let’s aim for that constant pace! For the rhythm, we can endure forever.
Let me start with the fact that we operated in an organization with people who were advocates for the empirical process. So, we experimented a lot!
We learned from every step we took and every failure along the road. And yes, we failed many times, that’s the only way to really grasp the consequences of the experiments.
But in the end, we had something we were pretty proud of and I’ll write down our best practices.
The most important thing that we have introduced looks like an element from Kanban.
In a short planning session, the content of the sprint is determined. During the sprint, the team can pick up stories from the prioritized backlog when they finished the stories. There is no formal commitment on what is delivered in the upcoming sprint, but instead there is a continuous pace in delivering features. And there for a commitment to the end goal. Every sprint we delivered features and this is how we gained even more trust from the users and stakeholders.
This is a first step towards a more kanban-style environment, which in my opinion is a nice and appropriate approach for products built by mature teams. We even called it Scrumban.
We turned sprints in a marathon with the usual Scrum events and artifacts, but with that very important continuous pace.
In order to use this kanbanish method, the top of the backlog needs to be ready for development and prioritized at all times. That’s why we refined a lot. In fact, we refined constantly. We didn’t wait for the refinement or planning session. We kept our stakeholders, users and other teams very close and talked to them on a daily basis. Whenever necessary, they are part of our refinements. Even external companies we relied on for certain API’s, we kept really close and involved them on a regularly basis.
Similar size stories
As a Product Owner, I need to write small, clear user stories and discuss the priority of the stories with the stakeholders and change it accordingly. Therefor the top of the backlog is always up to date. Please have a look at one of my other blogposts about User Stories.
We stopped estimating stories. The reason people are estimating is trying to predict how long a certain story, epic or feature will take. Most of our estimations didn’t result in this goal. Estimating takes a lot of time and in all honesty, it causes hassle and disturbs the continuous development process.
A positive thing about estimation sessions, is the discussion when there are different views on how to create this piece of software. The discussion adds value to the story, because developers, designers and the PO are talking about the story and ventilating their opinion, view or experience. So the positive effect of the discussion is the fact that the user story becomes clearer to everyone.
There are a lot of blogposts about using different methods for gaining predictability and stopping the estimations. Look at the #NoEstimates discussion on the interwebs. I happily refer Neil Killick or Vasco Duarte.
So, no estimates, what then?
I wrote stories that were approximately of the same size, so we could use the story count mechanism. As a PO I really listened to my teams, in order for me to learn about development effort, challenges, architectural dependencies, etc. Everything that has to d
o with the amount of sweat and tears developers and designer put in their daily work. And of course, the team and stakeholders helped slicing the stories until they were fine-grained enough. With this precious knowledge and help I
could write same-sized stories.
Benefits of our way of work:
- Constant and sustainable development we could keep up indefinitely. My so-called marathon.
- Short planning sessions; 30 minutes tops. More time left for refinement and development!
- Estimating can be reduced drastically. Or in our case even discarded in total.
- The retrospective is not only about failing a sprint or terrible estimates and how to solve that.
- There will always be a review.
- Constant communication with team, stakeholders, users and Product Owner, which a positive effect on transparency, expectations and the end result.
- Fits in a scaled agile environment, because it is still using the standard scrum events and artifacts.
Together with the team we experimented a lot and it finally evolved into this approach. We used our method for 6 months and I’ve seen happier team members, being more productive and delivering product increments more often. And all of this has a positive effect on the stakeholders and the end users.
The take-away should be: experiment a lot and aim for that constant pace in everything. Your product, team members, stakeholders and you will benefit from it.
It is not easy, you will fail at first, but it is worth a shot. Or two. Or three. :)