To do or not to do ...

Foreward

I recently read an opinion which stated that in contexts where agile is “adapted” it has proven to be more successful than when it is “adopted”. What the author meant is that agile is not a collection of tools and processes that you can blindly adopt to be successful. It is a mindset, a framework using which you look for a solution that best fits your context. It is in the spirit of agile to experiment, learn and improve, i.e. adapt.

I was looking at my most recent team to see how we did in that context. There were some dark moments when the crowd was cheering to fallback to a more directive management style as some things did not go as planned. Anyway, here are some of the many experiments we did …

Sprint duration

The heart of Scrum is a Sprint, a time-box of one month or less ... - The Scrum Guide

This was a new team and team members had a variety of “lessons” from their previous work experience. They all had very strong feelings about the sprint duration – and all options from 1 week till 1 month was on the table. Everyone was convinced they were right and the others were wrong! It was important to get to a consensus and get a buy-in. The easy option was for “management” to decide the sprint length. But we choose to go a different route.

We realized that whatever duration we choose it will not make everyone happy. So first we all arrived at an agreement that whatever we choose now, if as a team it does not work for us, we have the option to change and try something else. This was important – everyone was happy that they were not tied for life and if a certain approach didn’t work they will get to voice their concern and action will be taken. They were happy that they will collectively decide how they work and not an “outsider”.

Then, instead of a black-and-white decision, we asked for people’s opinion on the different options – this is the best/that is too short/long , this is best but that will also work etc. Based on the primary choice and secondary choice we selected a sprint duration. Even those whose choice did not get selected put in their full support behind it – knowing that if in future we tried the option they proposed, they will also need the support of others. We can have different opinions, but once we take a decision – everyone gives it their best to make it work.

Estimation approach

It is funny how often when you put together a group with apparently similar talent/skills, how widely their opinions vary on such basic elements. Here again, we had all kinds of inputs – function points, story points, complexity points, man-days, T-shirt sizing and then variations e.g. will we use planning poker with a linear scale or Fibonacci series and will the T-shirt sizing have a 3-point or a 5-point scale.

"The Development Team is responsible for all estimates. ...  the people who will perform the work make the final estimate." - The Scrum Guide

Here again, we made the same commitment – we will try something that everyone can work with. If it didn’t work out, we will switch to other options. Surprisingly, when people realized that change is possible in future if the current approach didn’t work, co-operation and collaboration was easier to achieve.

Task granularity

A story is a high level container to trigger a discussion. Ultimately, the development team breaks down the work in a set of tasks which they can follow. There were strong feelings as to how detailed a task should be and how closely should it be tracked. Most of the team worked on projects that are broken down into milestones and further into smaller and smaller tasks each with a specific start/end and duration. Now, some of them were more comfortable with that level of granularity while some others had the strong opinion that breaking down a story (into many granular tasks) is not relevant – we all know what needs to be done for which story.

We almost came to a breaking point as we could not resolve the tie. What we opted for is to give everyone the choice of what they wanted to do provided … at any point, without needing to prepare a separate report or taking a special action/effort it was possible for anyone else in the team to know whether or not we would meet the sprint goal.

"At any point in time in a Sprint, the total work remaining in the Sprint Backlog can be summed. The Development Team tracks this total work remaining at least for every Daily Scrum to project the likelihood of achieving the Sprint Goal" - The Scrum Guide

Everyone anticipated it would be chaos – but soon, after a few energetic discussions between the team members, a common consensus developed. People started aligning to the goal – transparency of the state of play, rather than the specific question of task granularity. This was means to an end.

Product Increment

"The Increment is the sum of all the Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints" - The Scrum Guide

We started off with the plan to deliver a product increment every sprint. It wasn’t a smooth start, to say the least. But after a few sprints and retrospectives, we had mastered the estimation, planning and tracking process (it was new technology, new business domain) and we were “stable”. In a few months, our story slicing was clean – it had clear expectations of what the system/user will do, and how it can be verified (acceptance criteria) and – most importantly, they were independent. Soon the team realized that a story did not take a sprint to get “done” and holding “done” stories for review until end of the sprint was “waste”.

"Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback" - The Scrum Guide

So we switched to a shorter review cycle – instead of end-of-sprint reviews, we started doing weekly reviews with the product owner. We thought about it and we agreed (between the product owner and development team) that planning it more frequently may mean some of the meetings had to be called off for lack of new things to review. The next logical realization was that if a story was reviewed and accepted as done – why not deploy it. And logically, if we could bring a potentially releasable increment every week, why should that not be our sprint duration! So we eventually switched to sprints of 1 week.

It happened naturally – it happened with consensus, it happened as everyone was ready to take the next step. In retrospectives, team was always looking for how can we be better at what we do – how can we challenge each other.

Framework

Most teams that claim to be “doing Agile” follows the Scrum framework. That’s how we started as well. As our development items became operational, we didn’t just have new stories to work on – we had defects and operational tasks to take care of as well. Some of these tasks had two different elements as compared to developing a new feature as a story: some of them were small (hours instead of days) and some of them were time sensitive (do it as-soon-as-possible rather than wait for the weekly deployment cycle). It soon became apparent that Kanban was better for this type of work.

So now we had two worklists – a Scrum board with weekly list of things and a Kanban board with ad hoc items. While from a management perspective it made sense to segregate the two lists (run vs change), it soon started becoming irritating for the team as sometimes it meant unplanned task switching – you do not see all your work together.

This was the moment of truth – we had the need for some degree of predictability (what is the scope that will be delivered in this sprint) while we had to deal with an element of unpredictability. As anyone with data science experience will tell you – the shorter the time slice that you look at, the probability of deviating from average is higher than when you look at a longer time slice.

We agreed to launch an experiment on a software tool. We created two lists – a Scrum board with all the new features to build and a Kanban board with a list of all adhoc items that come in. On top of this we built a Kanban view that combined the two underlying lists. Some stakeholders were only interested in the sprint scope and looked at the Scrum board. Others who were only interested in the operational items looked at the Kanban board. The team looked at and managed the high level Kanban view.

Was it the best solution? I don’t know. In the beginning it was tricky to align everyone as to what was going on – we had to also make assumptions about unplanned work. But today, after a few cycles of improvement, this works like a charm for us.

In conclusion ...

These are just some examples of experiments which many other teams can relate to. Trying out things, and knowing that the only consequence of failure is to try differently with more knowledge, knowing that the cost of failure is low made us open and creative. We did not have to have rules set in stone on day one. By agreeing to experiment with the rules and changing when changes seemed to make sense, we are improving faster.

What experiments did you run and how did it go?