In the last five parts of this series we focused on:
After the last ingredient some things might be off now, and in a non-tasty way. How do you get back on target?
The easy thing to say here is to do the opposite, or to follow the previous recipe to correct any issues. But depending on what was bent this might be to open ended. You may also have new issues to deal with depending on what has been bent in the process. Maybe there isn’t anything to fix, maybe there is just a new process now. First we need to assess our current state.
Part of continually improving is reflecting back on how things have gone. In these articles I have avoided being prescriptive about meetings, artifacts, or other agile software development processes. One thing all teams should do is have some kind of standing retrospective meeting.
There is a need to reflect on what has gone well and what may need improvement with input from everyone on the team that is doing the work. Whether this happens weekly, monthly, or at whatever cadence is appropriate for your team, they should happen and happen at a consistent day and time.
There are many articles out there on how to run a good retrospective. The most important factor is the meeting should be a safe place where everyone is free to bring up anything that is constructive for the team. This kind of trusting environment is key to enable real positive change to occur.
Coming out of the retrospective there should be actions that need to be taken. If your team continually says everything is great, then I would challenge that it isn’t a safe space. There are always ways to improve the process or product.
Here is a short, non-comprehensive list of things to look out for:
A lack of engagement shows team members that are apathetic or worse afraid. If this happens make sure everyone is being pulled into the conversation (but not forcefully). Maybe go around the room when something is brought up. Maybe mix up who is managing the conversation.
It could be easy for these to become complaint sessions. If left unchecked, it will become toxic. Steering the conversation back to ideas on how to improve or getting ideas from others is a good way to combat. Before a toxic/negative retrospective happens it would be better to establish these meetings as a place for positive feedback and constructive criticism. At one point we had a system where we would state our issue and then how it could be addressed.
Great ideas can come from anywhere. Once there is a safe space and people are engaging in positive contributions, keep an ear out for new ideas. So many great ideas have come from the newest people on the team. They have a fresh way of looking at things that long term team members do not.
Another thing to promote or listen for are successes. Celebrate what has gone well. Team members should encourage each other with shout-outs when they do something great. This will help keep the mood positive and everyone engaged.
Technical debt is when the implementation is allowed to make implementing future features more difficult. This can happen from moving too fast or from decisions made that are no longer valid. It is easy for technical debt to build up over time. Make sure you are listening for issues from the team and fight for the time to resolve them.
The largest problem with getting time to resolve technical debt is selling it to the business side of things. Using quality views, proposed by Michael Feathers and Colin Breck, is a very good solution to this problem.
Marie Kondo has made tidying up world famous. And much like keeping your home/office clean, the projects, designs, code, tests, etc. should also be clean and a joy to work on.
This is a little bit of a repeat from part 2, where we should always be introducing positive change. But taking it a step further in that everyone on the team should be striving for this. Need to add a button? Make sure you include design. Need to add a similar feature somewhere else? Make sure you don’t duplicate the code.
The review of these kinds of things should be explored by all team members to make sure a tidy product is maintained. This will in turn make it a joy to work on because you don’t have to be worried that there isn’t enough time or it won’t be appreciated. If everyone on the team is working towards the same goal of a joy filled product, it will show in all places.
On top of having a tidy project be part of the daily work cycle, having dedicated time to explore larger improvements will allow for experimentation that may catapult future features. Not only that, it is a great way to inject a morale boost directly into the team. Here are some things to dedicate team time on:
The most important way to fix what has gone wrong is to reflect on what has been done, both the positives and the things that could be improved. Regular retrospectives are the best way to enable the team to create a culture of positive change that everyone will find joy in working on.
This wraps the 6 part series on a software development recipe. Hopefully there was a good nugget or two in there for you to enjoy.
Photo by Slashio Photography on Unsplash
Are you ready to build something brilliant? We're ready to help.
.jpg)
