By Gonzalo Amuchástegui Mayoral
For the past years we’ve been seeing some scary statistics. In late 2020, BCG estimated that 70% of digital transformation projects didn’t meet desired outcomes.
Most software projects fail. Why? There’s a variety of reasons but between these, I can mention:
- Lack of transparency regarding the real progress and status of the project.
- Expectations not aligned between the owners of the project and the development team
- Teams with no clear strategy and focus
- Launching a product that was not the product users wanted or needed
- And so on…
The agile manifesto has 4 values.
Among these, there’s the value of having working software over comprehensive documentation. This relates to the fact of having features in market fast, in order to test them, learn and improve instead of spending months working on documenting what you will do.
We need to know where we want to go. We have to plan short iterations, define what we want the team to deliver in such iteration (or after certain iterations), test with users, learn and continue developing with more and better information.
To achieve this, it’s key to deliver functionalities that can be tested.
What does usually happen?
It’s really common for teams to work, and after a period of time, to show “progress”, and describe the situation as if everything is OK and as planned. Product owners, project managers or product managers just review that progress, and believe they are in the right path and closer to launch the product into the market.
Once the release date is getting near, let’s say 1 month before, the Product Owner asks the team to start closing up and testing in order to be sure everything is working as expected. That is the moment where they face a serious problem: progress does not mean nothing itself. When they want to close 100% the different functionalities, many things that were not contemplated previously start arising.
Teams have a hard time understanding which is the real progress and status of the project they are working on. Generally, when they are asked how much they’ve progressed, they answer with % which are based only on perceptions or feelings.
Why does this happen?
On the one hand, because we don’t really know how much is pending or how far we are from the goal (basically the team’s expectations are not aligned with the client’s expectations). A clear cause of this problem is the lack of definition of the different functionalities at the moment of their execution. As consequence, we end up having teams delivering products of poor quality and teams working more hours than expected, all just to deliver what was promised. In other words, dissatisfaction for all.
On the other hand, because teams do not have a clear focus and do not work in short iterations. One of the goals of agile teams is being able to test and learn from what is done each sprint (iteration of 1–4 weeks). The team should be capable of launching something that works and adds value to users; and of course improves our product.
How to SCRUM?
If we want to have a product that is “launchable” once the sprint is concluded, it’s necessary to focus, to avoid working in 10 things at a time, and to, as a team, have a mindset of closing functionalities (with the correct prioritization). It is much better to have 1 functionality finished, that will allow us to test the product with users, than having 3 in “progress”.
The issue with progress is that it is hard to really understand when the functionality is finished. This is handled with the acceptance criteria.
As a challenge, SCRUM teams need to have the “increment” mindset and work in order to achieve it sprint after sprint. Finish and close up things, not starting over finishing.
It is really common to start many things, but not so common to finish them. To avoid this, SCRUM relies on Dailies (15 minute meetings for teams to know what each of the members is working on), and on Kanban boards (To Do, Doing, Done) which each team adjusts according to their needs and preferences.
Let’s imagine we are the owners of the product. We manage to achieve the first version, and then start learning from users and continue adding functionalities. To keep on learning, it’s necessary to add value to the product, that is to say, add new functionalities (or certain changes).
Once a sprint is concluded, the development team wants to show us how much they progressed. That is when I ask them: “Can we upload them?”, to which they answer they can’t, because there are some details missing. Therefore, none of the functionalities were really completed, there’s no increment. I can imagine the feeling (and even some memories) of what this causes.
To conclude
¿What’s the point of progressing in many things at a time? ¿Isn’t it better to focus on finishing (as a team) one thing at a time, and be able to have certain functionalities ready to launch once the sprint is finished, in order to build and grow our product, and keep on learning?
It’s usual to lose focus, over commit, and do many things at the same time. A SCRUM team, through the different ceremonies that the framework suggests, seeks transparency and communication.
Both Scrum and Kanban encourage the mindset of finishing things over starting new ones. Scrum refers to it through one of it’s artifacts: increment — it’s the sprint focus: being able to deliver value at the end of each sprint. On the other side, Kanban does it with WIP (work in progress); which suggests this to be as small as possible, and to avoid starting something new before completing whatever is in progress.
It is key to fully incorporate this mindset in the team and understand it will take many retrospectives to achieve it. Through these, the team will, iteration after iteration, continuously improve, learn, and build quality products adding more value to our users.
By Gonzalo Amuchástegui Mayoral
If you have an idea or are working on a project you could use some help with, feel free to contact us! We’d be happy to help you… or who knows? Maybe be your new partner in crime.
You enjoyed this post and want to read more?