Showing posts with label Principles. Show all posts
Showing posts with label Principles. Show all posts

Friday, 30 September 2016

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.

Tuesday, 24 November 2015

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?