Operating Dev

Blurring the line between software development and operations

Operating Dev - Blurring the line between software development and operations

Agile as a humane way of software development – the road from cooperation to collaboration

A photo taken from a Scrum retrospective meetingOpenness to ideas, collaboration, communication. These are some of the things one of the agile teams I am coaching values and likes to keep doing. They’re valued equally as tracking issue in Github, regular refactoring of their application framework throughout the sprints or fixing bad coding practices.

I have been thinking a lot lately about the real value of Agile and Lean practices. Clearly people like the idea of efficient handling of changes and reducing waste, but there is a side of Agile and Lean that appeals to me more – their human side. What these practices are capable in doing is inspire teams to work harder, better and more efficiently, while maintaining an environment filled with respect, willingness to step out of each individual’s comfort zone and help others, and thirst for learning and improving.

If you are serious about Agile, you likely care about or even measure your team’s performance through the value added to their product with each sprint. You may count the number of new features added each sprint. You may care about delivering improved user workflows and count the number of steps or the time it takes for a user to complete a task. Some of you may want to reduce the maintenance effort and count the number of bugs found in production and the number of hotfixes and patches issued between releases.

These are all valuable metrics and you should continue to track them. However, I would argue they alone are lacking the ability to inspire true team collaboration and get stuck on simple cooperation — and the difference is not just semantic.

It is possible for the members of a team to merely cooperate and never collaborate. A cooperation simply means that everyone works on their own selfish goals but those goals are aligned and common and thus they’re able to create a semblance of a team and increase the overall productivity. In this sense, cooperation is limited in its capacity as the team performance is the sum of all individual performances.

Collaboration on the other end makes people to work together on a single shared goal. The individual selfish goals get pushed in the background and people collectively strive to achieve the same target as a group. It is an emergent property of empowered, self-organizing teams. When collaboration emerges, the overall team performance can often surpass any maximum efficiency a team cooperating well can ever achieve, i.e. it is not limited by the performance of any single individual on the team.

Collaboration is the drive behind the amazing orchestra performances where over 100 people are able to produce a harmonic melody that can’t simply be created by recording each individual instrument and then synchronizing the result. Each individual performer is already tuned into the group and the conductor simply provides cues when they need to adjust to stay in sync.

I would like to propose that you should measure how far is your Agile team from achieving collaboration and adjust your behaviour to achieve that. Agile provides you with the tools that allow you to improve on the go – the built-in and regular retrospective and focus on learning with each sprint are key to the success. Try measuring some of these next time:

  • How quickly the items that show up on your team’s “things to start doing” list during the retrospective move to “things we like to keep doing each sprint”,
  • How often the same items show up on the “things we should stop doing” list sprint after each sprint and if they keep cropping up after seemingly being eradicated in the past,
  • How many new ideas your team comes up with for the “things to start doing” list with each completed sprint,
  • How many user stores in each sprint are added to improve (and sustain) quality, architecture, and similar compared to simply new features or bug fixes.

I am very proud my agile team I quoted above realized the value of collaboration only after few months (the photo was taken during a retrospective meeting at the end of sprint 4 and I am posting this in the middle of sprint 6). Granted, they didn’t have to fight with existing waterfall practices and their management was very supportive and open to implementing Agile practices, but the team figured out themselves what is important to them.

I enjoy the sprint retrospective meetings and the creative conflict that arises when people openly point to flaws and deficiencies and discuss how can each of them help improve. They may still have ways to go to hit that threshold when collaboration emerges but they’re well on their way to achieve that.

Great job guys!

Category: Agile Projects

Your email address will not be published. Required fields are marked *