Software development, both as an industry & craft, is still very young. We have a lot to learn and improve upon & there is no field guide yet. This is why most of the time we think our processes are broken, our tech choices are not up to the mark & why we have to figure out a lot of things as we go along. Healthy teams know this. This is why they reject the status quo & keep on tinkering and tweaking things. They experiment and they evolve. Every organization I have seen so far wants it and promotes it, many teams try it, but very few are successful.
When facing the unknown, it often helps to know what not to do when you don't know what to do. In that spirit, below are some common mistakes I have seen & some tips on how to avoid them.
Not defining what success should look like
Usually, frustration or some other kind of pain is the motivator to try something new. Oftentimes people also try out new things based on what they have read & want to explore the possibilities. In both cases, it is important to take some time out to define & refine what you are trying to achieve or solve. There needs to be a shared understanding of what an acceptable solution should look like.
This pause is very beneficial. Doing this will help you:
ensure that you are not just treating the symptoms but tackling the root cause
When we treat only the symptoms, the effort we put in does not bring in proportional gains. If this happens often enough, people & teams will get discouraged from trying out new things.
identify when you are straying down the wrong path
When we are looking at new things, we can get tunnel vision or fall into a rabbit hole. Defining the 'acceptance criteria' serves as the north start for us. It prevents one from spending more time than warranted.
break down the problem statement further
Pausing and reflecting on the problems can let us see them in a new light. More often than not, this simple act lets you break down a bigger problem into smaller pieces, making it easier to make progress.
Not keeping track of the experiments
Failed experiments are often discarded without any care. It did not work, into the trash bin it goes! There are many reasons experiments can fail. You could have looked at something at the wrong time. Perhaps you had not been exposed to the full extent of the problem statement yet. Or the solution was not that mature. Or simply, you did not have the right skill set or setup to execute it. It is fine to fail early & dropping it, but one should always try to learn from them.
Our attitude towards failed experiments should not be "Oh, we tried X, but it did not work". It should be "Last time we tried X it did not work because of Y. Let us see if that still applies"
Tip Document only the failed things & just adopt the successful ones. When you adopt new things, they continue to live on organically, but failures are quickly forgotten. For e.x. if you are introducing a new process, it can become a new habit for the team in a few weeks. It is ok to document the things you adopt too, but they can be lightweight & transient. No need to optimize them for reading and comprehension by people outside the team or their future selves.
Not evaluating them once accepted
Just because something worked when you introduced it, doesn't mean it was the right choice. Learn to let go, even if it was a labor of love. Keep an eye on it, and see if it still brings you value, else Marie Kondo that.
Not being aware of the barriers
Teams and organizations try to promote & create an engaging & inclusive atmosphere. This can sometimes blind us from seeing the barriers that are in front of the team members. Even if you consider your team to be a safe space, a newcomer will most likely need time to feel safe enough to express their opinions freely.
Not everyone is eloquent or comfortable presenting an idea. Just because someone is not able to present their thoughts convincingly doesn't mean the idea is not worth exploring. Ask probing questions, trust their judgment, and give them time to maybe create a small working solution
Quick tip for the leaders, do not over-democratize things, trust & encourage your people to try out things.
Not doing it continuously
Pains faced by the teams and people cannot be compared to a list. It is not a backlog to burn through. If you want to visualize it, think of pains as piles of dirty dishes that need to be done. If the pile grows too big, no one would like to touch them. If the pile needs to be tackled, you are most likely to reach for the most recent & relevant thing, even if the most valuable or correct thing is at the bottom. Don't let the pile get too high. Work on it continuously. Do not fill your iterations with tickets, leave some room & create a culture to tackle these pains. This also helps nip many problems in the bud, leading to a cheaper solution.
Limiting these activities to a strict time window
How many of us can have creative thoughts on command? I would bet almost none of us can do so consistently. Yet we expect teams to do so. Many organizations & even frameworks like SAFe® try to carve out dedicated time for experimenting, such as innovation sprints. I think innovation sprints or something in a regular/predictable cadence is a valid neccessity, however, they are not executed properly. This time window should be used for intensive or exploring the "out of the box" ideas. There is plenty that can & needs to be done in this period, but perhaps that is a topic for another post.
Comments: