Many teams transitioning to Agile struggle with delivering a potentially shippable product every sprint. Producing a piece of software that provides a business value to a client every 2 weeks seems impossible. Usually, teams say that they can deliver either front-end, or backend, or architecture design for a given feature, but not all these together.
It’s a common problem for many teams that are new to Agile, but my experience shows that it’s also a problem for more mature teams that prevents them from advancing to the next level of agility.
Why is that? IMHO it’s because many teams struggle with a concept of delivering software incrementally and they are much more focused on an iterative part of Agile paradigm. They struggle with understanding that larger features don’t have to be implemented in one chunk and that they can be built in several steps. It usually means that a given feature won’t be perfect from the very beginning, but it doesn’t have to be! It’s one of the key concepts of Agile – deliver value incrementally, wait for client’s feedback and adapt accordingly (if need be).
Many developers say that they can’t split a given feature into smaller chunks not because they are not capable of doing so, but because from their perspective something less than a whole feature is imperfect, non-functional and not worth presenting to any stakeholder.
It may be a huge problem because it influences planning and tracking & monitoring, and therefore impacts transparency and works counter short feedback loops. Improving it requires changing the mindset and adjusting way of thinking which is never an easy process.
The good news is that teams are not doomed to fail here. First, they learn how to split larger features into smaller chunks as they progress with Agile and gain more experience. In addition, Agile itself forces them to do so because there is nothing more embarrassing than holding a sprint review and having to explain to stakeholders that there is nothing to present and discuss.
In addition, it’s possible to encourage the right approach by doing some exercises with the teams. One of them is called “Elephant Carpaccio” which I hope you’ll find useful. It was originally proposed by Alistair Cockburn and you can find more details about it here.
I executed this exercise with my teams and I must say that the results are quite promising. Of course, there were a lot of discussions and complaining, but overall people liked the idea and said they learnt something from doing it. Pretty much everyone agrees it was a challenge to split an application they would deliver in 1 hr into 20 small user stories, each of them of a meaningful value to a client.
If your teams struggle with splitting large features into smaller stories I recommend doing this exercise with them. It’s bit “artificial” but should result in some fun and good discussions afterwards.
