Embrace mistakes

I started my career in the 90’s working in the metal industry where the culture was extremely hierarchical and mistakes were swept under the carpet. For some reason I never acquired the talent of hiding problems, instead I admitted the mistakes I had made even though I knew it was frown upon – I have always had the notion that the sooner you admit a mistake the less severe the consequences are when the ugly truth gets out.

Now that I am working in software industry the culture is much more relaxed and it seems quite rare that a mistake is deliberately hidden, instead there seems to be a need to find out who made the mistake.

I have always found the hunt annoying so I started to volunteer as the perpetrator in a hope that once the hunt is over we can focus on the real issue; how to prevent the same mistake from hapening again. Now I must admit that this kind of man hunt is quite rare but it does happen.

I am trying to get rid of the last bits of the man hunt culture by advocating the celebration of mistakes, more glorious the mistake the better the party should be. I don’t think mistakes should be taken lightly but adding some humor into the situation relieves people from the initial shock and encourages them to come forward with the problems as soon as they are discovered – knowing that the only thing that is going to happen is that we learn an important lesson and perhaps I’m going to have to wear a funny hat for a while. In any case, everybody knows how bad the whole team feels if the mistake has caused serious problems.

We once had a situation where we needed to perform a database wipe for our quality assurance server but there was a problem with communication and we assumed we could do it in the morning when infact our customer had a demo ongoing. As soon as we dropped the database, phone started ringing – I don’t need to tell what kind of panic that caused. We tried to restore the system but in the heat of the moment we failed that also. There was little we could do at this point so the demo went bust and we got a reclamation – rightfully so.

We cried internally but had a good laugh as that was some glorious stumble – no man hunt needed, it was a team effort after all. When we analyzed what had gone wrong we noticed that we did not have a calendar for customer demo events and that our database restore process needed improvements. We implemented the calendar and rechecked the restore procedures and so far we have managed to avoid similar problems – lesson learned.

So the next time your team makes a mistake, embrace it as the valuable learning experience it is – and should you notice a man hunt commencing, raise your hand and yell: “I am Spartacus”, hopefully the hunt ends there and the party can begin.

Advertisements
Embrace mistakes

From chaos to managed chaos

There are projects that claim to use some agile method but fail to grow beyond it, instead they just keep on going with the same routine year after year regardless of the outcome. Retrospectives are seen as a time to complain and the actual problems go without attention due to excuses such as lack of time.

I recently worked in a scrum project that started this way with a fixed scope and schedule, requirements in Jira backlog and attitude that all that was missing was the implementation for the features.

In the beginning planning meetings were just like a scene from a weird nerd version of the movie Fight Club, where managers and scrum team fought over how much can be done in a sprint. Meetings took several hours with room full of people resulting in sprints doomed to fail. And fail we did.

Estimation was seen important at that point, so we decided to use story points to reflect the relative sizes of the features compared to each other in order to gain some baseline for team velocity to support the planning meetings. We used a lot of time to think about how we can implement the features so we could have some idea how many story points each feature had.

Even though the stories were extremely technical the approach helped us a lot, and over time the sprints started to succeed. This caused an overdrive in the team and we started to think about more ways to streamline our work. Then we encountered the #NoEstimates movement via twitter: We were intrigued.

We looked at our past couple of sprints and realized that on average our stories had 3 story points, so we did an experiment: we gave each story 3 story points without thinking. This worked like magic, sprints succeeded just as well as before and we did not have to use any time thinking if a story was worth 2 or 8 points.

A few sprints later we revealed our new method to the project stakeholders and suggested that we would move away from story points completely and start tracking the count of stories instead.

Next we focused on the stories themselves: we started to experiment with stories written from user perspective instead of developers perspective; “as a developer I want to write stories from user perspective so I can better understand why I am implementing a feature”. The new stories soon started to bear fruit as we did not need to think each and every technical detail beforehand, customer communication got better and the stories were really fast to write.

Before moving to the new story format, we also switched backlog management from Jira to Wiki. Using Wiki as the backlog gave us much cleaner Jira environment to work with – no unnecessary items were added to Jira. In grooming meetings we would reorder the backlog items and in sprint planning select the top items from backlog to sprint wiki page.

We soon realized that most of our time was spent reordering low priority features and decided to change things a bit. We started to add written goal for a sprint along with a list of high and low priority tasks. Low priority tasks would only be worked on after the high priority tasks were completed. In grooming meetings we would check which of the secondary tasks were not completed and the secondary task list was transferred to the next sprint as high priority tasks, along with new items from backlog as low priority tasks.

The sprint Wiki page had a huge impact on the meetings. Focus got much better as there were no future tasks visible and the grooming meetings shortened from one hour to 15-30min. Now we consider giving up on the planning meeting as it seems just a rubber stamp for the output of grooming sessions.

We have also given up on tracking the story counts for the sprints and the only fail condition for sprint is implementing wrong features. We no longer consider sprint a failure if we encounter something unexpected and cannot implement all the features from first priority list.

I have gained a lot from this experience and I can say from my heart that this has been the only project were I have seen scrum used in a meaningful way. So much so that I feel we can now move past scrum altogether.

I thank you scrum and bid you farewell.

From chaos to managed chaos