Solution development today involves a lot of trial and error. This results in teams doing multiple iterations in order to figure out the best possible way to make things work. But how do you determine whether you are doing the ‘right thing’? How do you ascertain whether you are going down the right path? More importantly, when do you establish that it is the right time to stop?
Fail Fast, Learn Faster
One of the key principles in Agile is to ‘Fail fast & learn rapidly’. In simple terms, this means that teams should try things out, demonstrate to relevant stakeholders, get feedback and adopt the learning as early as possible. This is better identified as the ‘Plan-Execute-Inspect-Adapt’ cycle in Agile. Teams may end up doing this cycle for a particular feature or a task over and over again in an iterative manner. More often than not, this will make the solution stronger and seldom it will fail. But when do you call the feature ‘Done’? Even so, are these stories ‘Really Done’?
The definition of ‘Done’
An important concept in Agile is what we call the ‘Definition of Done (DoD)’. In simple terms, it includes the circumstances under which we determine that a story or feature is completed. It helps teams determine when to move a feature card to the ‘done’ state in an information radiator.
The definition of done is unique from project to project and from team to team. Before the start of the project, the team must sit together to determine the criteria that constitutes a definition of done. Below is an example of a well-crafted DoD.
We normally move the story to ‘Done’ state if all criteria are met. However, more often than not the feature requires changes or revisiting in the future. This may result in a new story being created in the backlog to do the necessary changes. So in reality, the story is not ‘done-done’.
Achieving the done-done state
Does the ‘done-done’ state really exist? Yes, it can happen. When the story doesn’t require any more changes and never crops up in the future then it really is ‘done-done’. The team may be required to do multiple iterations to get the solution to such a state.
Obviously, this process involves a cost. Cost to the sponsor in terms of resources (human and non-human) consumed, opportunity cost and the cost of waste in the form of mistakes, defects, and throwaways.
“That which does not kill us, makes us stronger”
Friedrich Nietzsche (German Philosopher)
So how long should you continue? This is like a situation where a rock climber tries to climb a perpendicular mountain. The climber will use his hands & legs, his climbing gear, and his willpower to propel him forward step by step. He will lose his grip, slip and lose ground multiple times. But he will get up and keep on climbing till he reaches the summit. But if it becomes too dangerous and if the risk is not worth it, he will bail out and stop climbing.
Know when to bail out
It is important for Agile teams to know when to quit. In Agile terms, we call it ‘Pivoting’. To pivot is to understand that you are doing something wrong, quit iterating and move on with another feature. There are multiple reasons as to when you may decide to pivot.
Read this article for examples of pivoting.
Agile teams are most probably ‘wrong’ when,
Above are just some reasons as to realize that you are most probably doing something wrong. Act fast to identify this and quit what you are doing. It may really be pointless for you to keep on iterating and more beneficial for you to invest your time and energy on something else.
So, act wise!! Fail fast, learn fast and most importantly pivot faster!!