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.

Using the Agile Principles to improve your leadership - Part 1

How do the Agile principles relate to leadership? How can leaders use them to be better at leadership? 

I have been on various leadership courses, workshops, seminars and conferences over the years. They have provided me with a range of different tools and approaches. These have helped me become a better leader, coach and mentor. But I work in an Agile environment and one of the best guides to my leadership are the Agile principles themselves.

I think it’s important to understand that Agile is a mindset not a framework, methodology or tool, see Embracing Agile. The manifesto and the principles are a set of guiding statements on what is valued by Agile teams. It provides guidelines for everyone to be mindful of as they perform their role, aiming to quickly deliver value to customers. For Agile to be as effective as it can be, I believe that everyone in the organisation must demonstrate the principles in their work. Only then can your organisation be truly Agile. As leaders you need to foster and grow this mindset in others but also use it as your own guide in your leadership practices.

This is the first in a series of posts, looking at how I feel the Agile principles can be used by leaders to guide them in their leadership. In this post I will be taking a look at the following principle:

"Build projects around motivated individuals. 

Give them the environment and support they need, 

and trust them to get the job done."

Motivation, trust and support are all behaviours leaders can provide to teams and that you can encourage between team members. They are common topics that any leadership course would discuss. Yet they can be so hard to get right. 

Motivation can come in many forms. It will vary from individuals and teams, as a leader you role is to find out what people need to be motivated. I have found to motivate a team, they need a common shared goal. This can include a clear organisation vision, clear product mission, sprint goals, daily goals and personal goals. I believe teams require feedback from the customers and recognition of delivering value to customers. Everyone wants to be working on something they can be proud of. Individuals need to learn and grow, become masters of their craft and controllers of their own destiny. They need recognition and sense of how they contribute to the bigger picture. Renumeration and career growth will be important to many. Finally people should want to come to work, the culture and values of your organisation must match theirs. Remembering everyone is different, your job is to find what motivates them.  

Using tools such as Moving Motivators from Management 3.0 or the SCARF model to help find this out. I also suggest watching Dan Pink’s TED talk on motivation.

Here are some other questions that may be helpful and you should ask yourself.

• How are you bringing customer satisfaction and their feedback back to the teams?
• Are you asking questions about the goal for the week or iteration at stand up, are you helping to stretch them?
• Are you providing recognition when goals are met?
• How are you showing that people are contributing to the wider organisation mission?
• Do you give people time to grow and develop their craft?
• Can people demonstrate their mastery of their craft by mentoring and coaching others?
• How much autonomy do you give them, or do you delegate tasks to individuals on a daily basis?
• Does your organisation or team have values or discuss behaviours?
• Do team members get frustrated at the health of the codebase?
• What can you do improve the culture? Keep it simple, such as regular team cake!
• Is the work or technology exciting? If not how can you make it more interesting?
• Are you aware of your own behaviours and attitude? It will strongly influence the people you lead.
• Are you coaching people to come up with their own goals or just telling them what to they need to achieve?

Trust goes with out saying, with out it there is no respect, communication is crippled, no one speaks up or asks for help. As a leader you need to trust in people to get the job done, you’ve hired (or the organisation) has hired these people to do a job, so get out of the way and let them get it done. I believe providing an environment where is safe to fail is essential for continuous improvement and growth. 

 

• Do your team feel safe to fail?
• Can they speak up with out fear of being judged by leadership or peers?
• Do people get blamed for mistakes?
• Do you give people problems to solve or delegate solutions to be delivered?
• Can people speak up in front of you, when they have done something wrong, to get help from others on how to fix or improve the situation?
• Are you mindful of your emotions and how you react to negative news?
• Do you foster empathy and understanding of different viewpoints?
• Do you address bad behaviours early?

Environment and support, as a leader you need to do what ever is needed for your teams to work as efficiently and sustainably as possible. So you need remove anchors and roadblocks that may be holding the team back. Providing the environment from physical, skills, resources, technology and cultural. Support in all aspects to make sure they have what they need to get the job done.

• Does your team, working daily together, sit co-located?
• If they are remote teams do they have the right tools for communication?
• Does the team have the right skills and people to get the job done?
• Are there personal issues that could be affecting people? What can you do to help?
• Can you bridge the gap with essential people outside of the team? Can your networks help remove roadblocks?
• Are you available and accessible to the people you lead?

There is a lot to this first principle. To sum it up I believe that my job as a leader is to make sure that the people I lead are excited each and every day to come to work.

When diversity goes wrong

Diversity brings different opinions, ideas, thoughts and view points to tackle problems. But what happens when those differing views are so strong and are in conflict? When diversity goes wrong it cripples agreement, destroys team alignment and stalls decision making.

Successful diverse teams have a common goal. They know what they are trying to achieve and share their differing views on how to achieve it. They avoid group think but still have alignment on what makes them a team. They share common values. As leaders we need to encourage and recruit for diversity to have successful teams but make sure they know what they are hired to do.

The best teams are those that are aware of the diversity and understand that people have different view points. Team members listen to learn rather than listen to reply with their own agenda. They have open minds and can empathise with each other. They also understand in a team of differing views they may not always get exactly what they want. They are open minded and realise there is more than one way. Leaders need to help team members be aware of the viewpoints of others, build emotional intelligence and listen to learn.

Leaders need to be mindful that diversity will bring tension; healthy tension that will provide debates and discussions. But if team members have no respect for the views of others, this tension becomes unhealthy. It becomes conflict. Respect is a behaviour that is essential, without it trust fails. Diversity is so important in your teams, but without the right behaviours it can go wrong.

Diversity needs respect and a common purpose to succeed. It needs compromise and an open mind. Diversity without respect ends in arguments, disagreements and it can make a team dysfunctional.  

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?