Picture credit: Unsplash

Since the first programmable computers hit the market and software developers started working in teams, organizations have been looking for the holy grail of methodologies for delivering quality software. And while the software development industry as a whole has improved, many organizations still struggle with delivering quality software that meets the needs of their stakeholders. As it turns out, delivering quality software that provides value consistently is hard. 

Strong Teams Create Great Software

Developing good software is not just about writing good code. It is also about creating a development team that can connect with each other and becomes bigger than the sum of their parts. This includes all members of the team, from the developers to QA to the product owner. In fact, everyone who contributes to the delivered product must come together and be committed to delivering something of value. This coming together, this human connectedness, was not one of the anticipated benefits at the start of the digital age but whether by accident or not, it has led to a social realization that teamwork is critical to developing quality software. 

Creating amazing teams, or beautiful teams as I have written about before is key to building quality software that provides value. Many software developers use Agile as a framework for their software development life cycle. The first line of the 12 Principles Behind the Agile Manifesto states “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software’.

Developers, testers, customers, and stakeholders are all mentioned in the manifesto which makes it clear that Agile is not an intellectual set of rules for creating software but a system that brings people, or what the manifesto calls “motivated individuals” together to create that value. Agile puts supreme faith in individuals and their teams, with the conviction that as these teams work together they will self-organize, and from that “the best architectures, requirements and designs” will emerge.

Continuous Improvement

The last line of the manifesto says “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Note that “at regular intervals” is not specifically defined. It doesn’t say how frequently this should take place, although many of us have gotten into a cadence where our reflections are time-boxed, usually to coincide with our sprints. A team reflects, not the individual but the team. It’s not only the scrum master or the project leader, or the developers. It’s each member of the team that reflects, with each member being a valuable, and equal, contributor. 

A few years ago I was running software development for a consulting company and we were implementing a new SDLC. We had printed out large, 4’ high flow charts describing the new process and hung them throughout the office. I would often stand in front of one of the flowcharts and use a marker to make changes or write questions for the other team members on the printout. I would also invite one of the team members to stand with me and we would discuss the new process together. When the team member asked a question, I would give them the marker so that they could write their question on the flow chart. As I modeled this behavior, eventually the team started to do this themselves, without the “manager” asking them. They came up with their own definition of what a “regular interval” was. And as the process grew and matured, it became theirs and they became the model of a self-organizing team.

With most of the world now sheltering in place due to the COVID-19 pandemic, how do teams continue to reflect when they are no longer co-located? How do teams continue to come together and continuously improve? For some, this will be easy as they have already been working with non-collocated team members. For others though, it will be a challenge to keep the team together, connected, and self-organizing. This means that now is the perfect time to reflect on how connected your team was before we had to shelter in place and how you can improve those connections now. 

The Retrospective

The retrospective is the perfect Agile ceremony for building, or re-building, your team’s connectedness, and now is the perfect time to reinvigorate your retrospectives. If you’re already doing regular retros, spice them up with a virtual game. You can use the InspireMe card deck by Lyssa Adkins or have a desk photo competition. Desk photo competition works well because even though we are connecting with virtual meetings, most of our desks are not in the video. Have the team vote on who has the most interesting desk or the most organized desk. Desks show the personality of the person so seeing a person’s desk is another way to connect with them. These are just two of the many different kinds of virtual games that you can play with your team. Try one at your next retro. 

If you’re not doing retros, now is a great time to start. Schedule it now, you don’t have to wait for the end of your sprint. And be creative; add another column to your retro board called “How am I Doing?” and make it the first column. This will give everyone on the team a chance to share how they are personally doing. As sheltering in place continues, many on your team will welcome the chance to talk about something not related to work. Once you are done with “How am I Doing?”, you can bring the focus back with an explanation of the importance of retros and remind the team why you need to be doing them on a regular basis. 

Action Items, usually the last column on the retro board, are a built-in continuous improvement component. As the group discusses what went well and what did not, action items that will improve the way the team works will naturally be revealed. Add these items to the column and before the retro is finished, make sure that each action item has been assigned to a team member with a due date (usually by the end of the next sprint). Tracking action items is key in order to make sure they get done and using spikes is a great way to track them. As action items are done, the team will build confidence in the retrospective and realize that it is a valuable role in their continuous improvement. 

As I said above, retros don’t have to be done only at the end of a sprint. I would suggest that while we are sheltering in place, schedule them once a week or every other week. It is not the formality of the retro but using that time to come together as a team, reflect on how you are doing your work and how you can improve it, and how your teammates are doing emotionally. Value is created when teams come together and connect so that “the best architectures, requirements, and designs” will emerge. Not only will your team create great works of value but they will become a truly self-organized team. 

How Nisum Can Help

If you need help jumpstarting your retros or any part of your Agile process, contact us. Large organizations have found that Nisum gives them a competitive edge through Lean and Agile coaching. They’re using Nisum to build change management systems that address key organizational challenges related to team efficiency.