Using the Agile Principles to improve your leadership - Part 2

This is the 2nd post in a series on how I believe the Agile Principles can be used as a guide in your leadership. Previously I discussed that Agile is a mindset. Leaders should have the principles in mind and demonstrate them in the way they go about their work. The last post covered motivating, supporting and trusting individuals and teams. Once you have motivated individuals, you have built trust and you are always on hand to provide the support for your teams they need. Then the next step is to make sure they and you can continue being as productive as possible over time.

"Agile processes promote sustainable development. 

The sponsors, developers, and users should be able 

to maintain a constant pace indefinitely."

Avoid burn out with sustainable and constant pace. A team that is driven faster than the pace they can comfortably work, may be able to cope for short time. But it won’t take long for cracks to appear in the health of individuals, their work and your product. But a team at a pace slower than their capacity will also struggle. Boredom and feeling unvalued are extremely stressful.

To maintain a constant pace, teams need to first understand their pace. For delivery teams, velocity or throughput are a good way to measure it. The unit of measure most commonly used in Agile is stories or story points. How much work a story involves will depend on the team. For that reason be careful in comparing velocity across different teams. Once you are aware of the pace it makes it easier to understand if goals are too easy, a little stretch or unrealistic. You can also watch for change in the pace which may indicate possible issues. Looking at pace, and the variation in it (predictability), can help you as leader in your planning.

Getting the balance right with goals, is part of your role as a leader. Goals need to motivate and stretch but not load up too much pressure. Ownership of the goal comes when the team or individuals create and set it themselves. Neuroscience and neuroleadership tells us that people are more likely to complete a goal if they set it, rather than be given it by someone else. Coach your team in to coming up with a goal aligned to your priorities, rather than giving them a task and a deadline.

If you don’t lead delivery teams using stories or some other unit of measure, then pace may be a little trickier to determine. You may not have an easy metric such as velocity to hand and the unit of measure is just too varied. In this case catching up with your team and ask them about their pace and how they feel about it can go a long way to understanding if the pace is right for them.

Healthy teams are productive and sustainable. You can be aware of your team’s health with regular check ins. Using a health check tool such as this one suggested by Spotify is a really great way to cover a range of subjects and make the team aware of their health. Using timelines and asking team members to show their level of happiness and unhappiness is another good tool to start the conversation on health. A colleague of mine recently ran stay interviews, asking people why they continue to work at our organisation. Another great way to get an insight in to how people are feeling.

Happiness Graph

Support individuals to be self aware of the emotions and the effect they are having on others. Introduce mindfulness techniques to help in this. When individuals are more aware of their own emotions, they are better place to see emotions in others. This helps to build empathy and understanding of other people’s point of view. This is essential in all teams, especially so in diverse ones.

Watch out for change as well. Change if handled badly or frequent change can cause fatigue. In a growing organisation or with a continuously improving culture it can feel like constant change. As a leader managing change well is important. Giving space to people when needed, time to absorb and deal with the change. During large or difficult change you should increase checking in with people’s health.

A lot of these techniques require a safe and trusting environment. With out that you may not hear the truth. So it is important to build that trust, giving people a safe place to be vulnerable and a safe place to fail. If they need time to talk without their leader around then give them the space.

In conclusion I use this principle in my people leadership by understanding the pace of teams, helping teams be self aware of their health and be mindful of their emotions. If you have teams and individuals who are not working at sustainable pace or in an unhealthy state, you risk burning teams out. This will cause many issues for you, the individuals, your organisation and your customers. Unhealthy teams are unlikely to produce their best quality work and can be very infectious to other teams. It can be the start of downward spiral to the culture of your organisation.

And finally don't forget to watch your own health, how you are feeling as leader has a big impact on those you lead.

Is DevOps, just operation teams being fashionably late to the Agile party?

There is a talk about the DevOps movement being a new philosophy that is an evolutionary step from Agile. A change in mindset and different way of thinking. But is there really anything new in this philosophy that Agile manifesto and principles don't cover. Or is it just operation teams now catching up with Agile?

So what is causing the DevOps community to say they are the next step from Agile. Could it simply be that infrastructure and operations are not explicitly mentioned enough in the Agile principles?

Lets look at some of the Agile principles that I feel promote practices of DevOps.

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This principle talks about continuous delivery to satisfy the customer. The customer is not going to be satisfied if it is running on a developers machine so delivery here must be out in to the real world and therefore on suitable infrastructure. Should the term software be changed to software and infrastructure?

Business people and developers must work together daily throughout the project. This principle is about daily collaboration and just stating developers and business may be limiting. Testers, UX designers etc have had to live with this for a while and operations are certainly not included. May be changing the term developers to "delivery teams" to be more inclusive would help.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. It depends on your definition of "environment and support". For me this includes the right tools, dev and test infrastructure and necessary expertise to maintain and develop these. This is a key part of DevOps.

Working software is the primary measure of progress. As mentioned in the first principle the same applies here. If our measure of progress and therefore success is working software. The delivery team can not be progressing if they don't have delivered and working in front of the users. Therefore operations are needed to make this principle be fulfilled.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Again should this principle be more inclusive. As development teams ramp up without operations or DevOps practices, there is often pressure as they want to release much more frequently. This can become unsustainable for operation teams, in my experience this often one of the key drivers in an organisation that has been doing Agile to start talking about DevOps.

Agile and Lean should not just be about the development and QA team working with the business. To fulfil the principles it should be about getting all the necessary people working in a team with constant collaboration to deliver working software. That software can't be working unless it is deployed on suitable infrastructure and systems to support it. The Lean; build, measure and learn feedback loop can't be fulfilled unless you have the supporting infrastructure and skills in your team to collect the data. The business can't react to what they learn if they can't quickly release changes to the customer. To do that you need business, designers, developers, testers and operations. They need to be working collaboratively and all working together to deliver the software to the customer. They need to take on DevOps practices such as treating infrastructure as code, automated testing and automated releases to be able meet the Agile and Lean principles.

It may come down to your interpretation of the Agile principles and how you define terms such as "working software", "continuous delivery", "developers". Personally I don't feel there is anything particularly evolutionary about DevOps, depending on what definition you use. But it could be argued that the Agile principles could be tweaked to be more inclusive of operations when talking about developers and more explicit that working software also includes the underlying infrastructure and systems to support it.

What do you think? Could a some minor changes to the Agile principles show that DevOps practices are just part of the Agile principles or is there a fundamental mind shift from Agile to DevOps?

The power of cake...

Now that I have your attention with the mention of cake, I wanted to share my thoughts on how simple gestures that bring the team together out of their day to day work can really strengthen and improve your team. I know there is much literature out there on team building and activities away from the office but these don't have to involve being knee deep in freezing mud whilst being shot at by flying balls of paint.

I would like to share my experience on how stopping once a week for 10 minutes to share some cake can have a vast improvement on the collaboration (but not so much the waistline). 

Originally, when I was working in the UK our office had the rule, as I'm sure many do, that if it's your birthday you bring in some cake. When I moved to NZ and started working in a true agile team, I decided to continue the tradition. Other team members followed suit and, being the competitive bunch we are, it quickly sparked a who could bake the best cake, with increasingly outrageous attempts at baking. More and more people got involved from across different teams. Eventually this turned in to a weekly cake rota and as far as I know to this day the table we all stood around and ate cake is still affectionately called the cake table.

Little did I realise at the time the benefits this was having. Suddenly, communication barriers were being broken down, team members and members across teams were engaging in conversation and discussing what they were up to and problems they were having; both at work and out of it. Trust was built as team members got to know each other and felt able to have in depth and constructive conversations about those tricky design and coding decisions without the fear of upsetting someone. Once a team starts to communicate, people aren't scared to ask for help or grab people together for an informal discussion on the best way to design this piece of code or point out that perhaps a different approach could be better. Blockers are reduced and the team morale and motivation increases as the team is more productive.

In a new role, I tried the same trick on my birthday and although it hasn't quite turned in to the same level of baking competitiveness I believe it has certainly helped in building team communication and morale. Many a retrospective includes mentions of the amount of cake that week.

For those gluten free or not eating sugar it doesn't have to be just about cake, the point is that team building and building stronger team collaboration doesn't need to be a big ordeal.

I'm sure there are many similar stories in your teams. What goes on at your office that brings people together for a bit of fun?