Leadership Agility

Here is a link to the PDF version with the formatting intact –> Leadership Agility

Leadership Agility

Bill Joiner

Why do we need Agile Leaders?

  • Implement Agile adoptions and sustain it
  • Develop organizational agility

Agile leaders currently conceived as

  • Upholding Agile principles and values
  • Using and supporting Agile practices
  • Not being traditional manager

Agility is the ability to achieve sustained success in an environment or accelerating change and increasing interdependencies [due to global economy, new technologies etc] According to a survey by the Economist, 90% of the executives believe that agility is essential for business success and growth and the primary obstacle is organizational culture What is Leadership Agility? Agility comes from the world of sports and it includes being

  • Receptive to change
  • Adapting to changing environment
  • Faster capability in people
  • Faster feedback loops
  • Being responsive rather than being reactive
  • Self organized teams – delegation
  • Embrace change

The essence of Leadership Agility is

  • Focus
  • Step back
  • Gain a broader deeper vision
  • Re-engage and take action

The levels of Leadership Agility correlate with established stages of personal development. Synergist Co Creator                                                                                                                                                              Catalyst Achiever Expert Conformer Operator Enthusiast Explorer The first four stages(Explorer, Enthusiast, Operator, Conformer) correspond to the Childhood stages and the others to the Adult stages of development Expert

  • Holds expertise
  • Acts in a tactical manner
  • Address people as they come up


  • Have a strategy
  • Adapt to change
  • What can I do to make that change
  • How can I make my team more motivated


  • Do everything done at previous levels
  • Vision – not just to reach the top
  • Have everyone on the team super engaged
  • Have every one become leaders in their own right

  Expert level leadership

Key assumptions Leaders are respected and followed because of authority and expertise  
Leadership style Tactical, problem solving orientation. Leader’s power depends on expertise and positional authority
Organizational change  Focus on incremental improvements within one’s unit with minimal stakeholder engagement
Team Leadership More a supervisor than a manager Focus on one to one Supervision vs management/leadership of direct reports as a person
Pivotal conversations low tolerance for conflict –  either strongly assert opinions or hold back to accommodate others.  May swing from one style to the other.

   Achiever level leadership

Key assumptions  Motivate others by making it challenging and satisfying to contribute to larger objectives
Leadership style Strategic outcome orientation, believes power comes not only from power and authority but also by motivating others
Organizational change Initiatives include analysis of industry environment strategies to gain stakeholder buy in – ranges from one way communication to soliciting input
Team Leadership Treats direct reports as a system to be orchestrated as a team
Pivotal conversations Moderate tolerance for conflict Primarily assertive / accommodative with some ability to compensate using other systems Will often accept feedback if helpful in achieving desired outcome

Catalyst level leadership

Key assumptions  Articulate an inspiring vision and empower and develop others to make it a reality
Leadership style Visionary, facilitative orientation
Organizational change Organizational initiatives often include development of a culture that promotes team work, participation and empowerment, proactive engagement with diverse stakeholders – reflects belief that their input increases the quality of decisions
Team Leadership Create a highly participate empowered team that leads change together Welcome exchange of views on difficult issues
Pivotal conversations Greater tolerance to conflict Adept at balancing assertive and accommodative tendencies as needed Proactive in seeking feedback – genuinely interested in learning from diverse new points

  The Co-creator level leadership

Key assumptions Oriented towards shared purpose and collaboration
Leadership style Believes leadership is ultimately a service to others
Organizational change Develops key stakeholder relationships characterized by deep levels of mutual influence and genuine dedication to the common good. May create companies or units where corporate responsibility is an integral practice
Team Leadership Develops collaborative leadership styles where members feel fully responsible not only to their own areas but also to the organization they collectively manage
Pivotal conversations Style reflects an integration of assertive and accommodative tendencies Able to process and seriously consider negative feedback even when highly charged emotionally

The Synergist level of leadership

Key assumptions Wholistic orientation
Leadership style Experiences leadership as a participation in a palpable sense of purpose that benefits others while serving as a vehicle for personal transformation
Organizational change Maintains a deep empathetic awareness of conflicting stakeholder interests including their own. Able to access synergistic intuitions that transforms seemingly intractable conflicts into solutions beneficial for all
Team Leadership Capable of moving fluidly between various team leadership styles Can amplify or shape group energy dynamics to bring about mutually beneficial results
Pivotal conversations Creating a present centered awareness that augments external feedback and supports strong style connection with others even during challenging conversations

    Heroic and Post Heroic Leadership Heroic Leadership

  • Heroic leaders can be highly effective in certain situations.
  • However in complex rapidly changing organization environments heroic leadership over controls and under utilizes subordinates.
  • It discourages people for feeling responsible for anything beyond their assigned area
  • Inhibits team work and implicitly encourages subordinates to use their heroic approach with their own units

Post Heroic Leadership Post Heroic leaders retain ultimate accountability and authority that comes with their role yet they create work environments characterized by high involvement and shared responsibility. 4 types of Leadership Agility   Context Setting Agility

  • Scoping initiatives / Self Direction
  • Leaders use Context Setting Agility to
    • scan their environment
    • anticipate change
    • decide what initiatives they need to take
  • It also includes the ability to determine the optimal scope of an initiative and the outcomes it needs to achieve
  • They have the ability to undertake visionary initiatives that are personally meaningful and beneficial for the organization and its key stakeholders

Stakeholder Agility

  • Understanding stakeholders / resolving differences
  • Leaders use Stakeholder Agility to
    • Identify the key stakeholders of an initiative
    • Understand what they have stake
    • Asses the extent to which their views and objectives are aligned with their own
  • Includes the ability to engage with stakeholders in ways that lead to more optimal alignment
  • They seek input from key stakeholders not simply to gain buy in, but because they feel that genuine dialogue will improve the quality and effectiveness of their initiatives

Creative Agility

  • Creating solutions / analyzing problems
  • Leaders use Creative Agility to transform complex novel issues to deliver results
  • Catalyst leaders begin their initiatives with a keen appreciation of the novelty inherent in the situation they are addressing
  • They conduct their initiatives in a manner that encourages the expression of multiple views and the questioning of underlying assumptions
  • Where they encounter apparent opposites, their willingness to experience the tension between them increases their ability to discover creative solutions

Self Learning Agility

  • Developing new skills / seeking feedback
  • They develop a strong interest in becoming aware of behaviours, feelings and assumptions that would normally escape their conscious attention
  • They are motivated to increase their self awareness and more fully align their behaviour with their values and aspirations
  • For them personal growth fuels professional development

Repeatedly engaging in these competencies allows one to use leadership initiatives to develop all four leadership agility competencies.  Each of these competencies involves stepping back from yoru current focus in a way that generates new insights and helps you make better decisions that reengaging in what needs to be done next.

  • Context Setting Agility – re-examine current priorities in the light of changes taking place in your large environment
  • Stakeholder Agility – consider the needs and perspectives of those who are influenced by your initiatives
  • Creative Agility – develop optimal solutions to the often novel and complex issues you face
  • Self learning Agility – reflecting you yourself and experimenting with new and more effective behaviours

Agile books recommendations

This is a list of Agile books recommended from experts.  This will be updated as and when new lists are published.

My top 10 books on Agile are :

1. Succeeding with Agile – Mike Cohn
2. Essential Scrum: A Practical Guide to the Most Popular Agile Process, by K. Rubin
3. Coaching Agile Teams – Lyssa Adkins
4. Agile Estimating and Planning – Mike Cohn
5. Agile Testing – Lisa Crispin and Janet Gregory
6. Scrum and XP from the Trenches – Henrik Kniberg
7. Agile Retrospectives – Making Good Teams Great   Esther Derby   and Diana Larsen
8.Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition –  Lyssa Adkins
9.Agile Coaching – Rachel Davis
10. The Art of Agile Development  –  Jim Shore




Toyota Kata – the Improvement Kata and Coaching Kata

Happened to see this nice article on Toyota Kata.


Kata means  pattern, routine, habits or way of doing things. It is about creating a fast “muscle memory”  (Systems 1 thinking) of how to take action instantaneously in situations without having to go through a slower logical procedure. A Kata is practiced over and over again and strives for perfection

Mike Rother in his book “Toyota Kata” talks of 2 main Katas – the Improvement Kata and the Coaching Kata. The Improvement Kata consists of 4 steps  –

1. Understand the direction

2. Grasp the current condition

3. Establish the next target condition

4. PDCA to the target condition

The Coaching Kata supports the Improvement Kata by focussing on learning, improving, and pointing in the right direction. The Coaching Kata itself primarily supports the fourth step of the Improvement Kata, PDCA toward the Target Condition.

Brief summary of LiftOff – Launching Agile Projects and Teams

Lift Off

 Diane Larsen and Ainsley Nies

  1. In a project Lift Off, everyone associated with the project come together to define the initial intentions, approach, and plans and begin team building
  2. We give attention to lift off because
    1. It is hard to recover when teams don’t start well
    2. Uniting strategy and execution keeps everyone focussed on what the customer needs
    3. Business and development team move in alignment creating a shared understanding of what is involved
    4. Group of people gets the opportunity to begin building themselves into a team before the pressure of development work begins
    5. Attention to starting well helps everyone to express what the project can or should accomplish and begins the collaborative effort
    6. Everyone learns about the broader project community and what each group of stakeholders needs as a deliverable or wants from their involvement
  3. Project liftoffs typically start with an initial session to clarify the broad outlines and intentions for the project.
  4. Liftoffs follow a variety of formats including Agile Chartering sessions, Agile practise boot camps and other forms.
  5. An effective project lift off
    1. Achieves alignment by establishing a clear, shared understanding of what the project involves and why it exists
    2. Builds momentum by getting into the project community and core team to start the project
    3. Clarifies roles and develops working relationships among project community, core team and sponsors
  1. Typical goals of a kickoff workshop
    1. Brief team members about the project history and current planning status
    2. Coordinate of role assignment, work packages and interfaces
    3. Inform about processes tools and reporting structures
    4. Clarify codes of conduct for customer contact
    5. Collect of input for risk management purposes
    6. Get to know one another and taking first steps towards becoming one team

Planning a Liftoff

  1. Are we really ready to start the project – a discovery process
    1. Does the deliverable have a committed sponsor and identified product manager?
    2. Can the business case be articulated?
    3. Does the project have a budget?
    4. Do we have a clear intention for what we want the project to accomplish?

Designing a liftoff

  1. Every liftoff needs a sponsor or executive introduction
  2. Only include activities in the liftoff that have real work purpose
  3. The best liftoffs create a sense of ownership of the outcomes
  4. Every work group and project team needs agile chartering
  5. Take time to include participants in design decisions

Agile Chartering

  1. Agile chartering means taking the time to ground everyone in a common understanding of what you want to accomplish
  2. 3 critical elements of a charter – Purpose, Alignment and Context
  3. Agile chartering is a lightweight minimum documentation approach to creating initial understandings, agreements and alignment about the work and how it will be accomplished.
  4. Agile chartering catalyses the interactions needed to accomplish the work, facilitates a quick start on delivering software, accelerates collaboration within the team and across the project community and sets the context for replanning when new information becomes available
  5. Chartering is a discovery and negotiating activity that transforms bright ideas into valid and manageable work efforts. The charter balances the interests of the project gold owners with the capabilities of the development team
  6. Agile chartering builds project unity from 3 primary elements
    1. Purpose – provides inspiration and conveys the meaning of the project. Purpose includes the product vision, project mission and mission tests
    2. Alignment – helps the project team create an alliance to achieve the mission. Alignment includes shared values and principles, core team forming and cohesion and working agreements
    3. Context – reinforces and extends alignment agreements. Context includes the boundaries and project community interactions, resources commited to the project and prospective analysis.

Chartering purpose

  1. The purpose provides inspiration and meaning for the project.
  2. Product vision describes the desired future your project will help to bring about, while the project mission describes how your project contributes to creating that future.
  3. A product vision illustrates the ultimate expression of customer value, the reason for the project to exist, the big picture, the overarching outcome you want to manifest. It is your guidepost to the desired future.
  4. A strong product vision inspires a team to put in the effort to make it a reality
  5. The project mission describes your team’s unique contribution towards achieving the product vision.
  6. A mission demonstrates four characteristics
    1. Description of the project’s customers
    2. Actions the team will take to deliver the product
    3. The product or service the team will deliver
    4. Differentiating and compelling value of the product to the customer
  7. The project mission clarifies the boundaries of the work for the team and everyone associated with the project
  8. Mission tests delineate the indicators for successful project outcome. By writing mission tests you itemize the qualitative and quantitative intentions that define “done” for the overall project
  9. As a core team, you use the mission tests to know what the project will be measured against and as decision filters
  10. Working agreements are a set of operational guidelines to help your team accomplish a mission. By defining working agreements, your team members forge a pact how they will interact,  behave and produce
  11. Working agreements may include topics like
    1. Practices to give special attention
    2. How communication / conversation takes place
    3. How the team makes decisions
    4. How to deal with conflicts
    5. How to handle design decisions and coding standards
    6. Definitions of done
    7. Meeting times ,frequency, attendance and agenda
    8. How facilitation and other maintenance roles are handled
    9. Agreements around distractions
  1. Context includes project boundaries, interactions with project community, committed resources and prospective analysis to anticipate opportunities for risk and benefit
  2. Boundaries define the relative responsibilities of the core team and others in the project community. The purpose of defining project boundaries in chartering is to enable smooth flow.
  3. Prospective analysis is a method of looking ahead and checking assumptions about a project – taking into consideration the risks and the benefits. One of the ways of doing prospective analysis is to come out with an Impact Probability chart which lists out the impact to the project (on a scale of -3 to +3) and the likelihood of it occurring on a continuum scale.  This is pretty similar to “Give yourself an A” from the Art of Possibility and “Remember the Future” from Innovation games
  4. From moving to liftoff to flight – 3 points to consider – Metaphor, Charter  components and Team Development
  5. A metaphor often emerges during liftoff – project metaphors can provide powerful connections and shorthand for project team and community
  6. Use Purpose, Alignment and Context  as decision filters / course correctors to clarify project dynamics throughout the project

User Story Mapping – brief summary in bullet points

User Story mapping

This is a brief summary of the book User Story mapping by Jeff Patton – in bullet points.


  1. The real goal of using user stories is shared understanding
  2. Shared documents are not shared understanding. Shared understanding is when both understand what the other person is imagining and why.
  3. Good documents are like vacation photos – the details in having that photo taken are not available – hence you won’t get the whole picture.
  4. There is always more to build that we have time or resources to build – always
  5. Minimize output and maximize outcome and impact
  6. Stories aren’t a written form of requirements, telling stories through collaboration with words and pictures is a mechanism that builds shared understanding
  7. Stories are not the requirements, they are discussions about solving problems for our organizations, our customers, and users that lead to agreements on what to build

Chapter 1 – The Big Picture

  1. Stories get their name from how they should be used, not what should be written
  2. Story maps are for breaking down big stories as you tell them
  3. Talk and doc – write cards or sticky notes to externalize your thinking as you tell stories.
  4. Reorganizing cards together allows you to communicate without saying a word
  5. Mapping your story helps you find holes in your thinking
  6. Focus on the breadth of the story before diving into the depth

Chapter 2 – Plan to Build Less

  1. Mapping helps big groups build shared understanding
  2. Map for a product release across multiple teams to visualize dependencies
  3. Scope doesn’t creep – understanding grows
  4. Focus on what you hope will happen outside the system to make decisions about what’s inside the system
  5. Focus on outcomes – what users need to do and see when the system comes out – and slice out those releases that will get you those outcomes.
  6. Focusing on specific target outcomes is the secret to prioritizing development work
  7. A simple prioritization model has 4 aspects
    1. Differentiator – a feature that set them apart from their competition
    2. Spoiler – a feature that is moving in on someone else’s differentiator
    3. Cost reducer – a feature that reduces the organization costs
    4. Table stakes – a feature necessary to compete in the market place
  8. The Minimum Viable Product is the smallest product release that successfully achieves its desired outcomes
  9. The Minimum Viable solution is the smallest solution release that successfully achieves its desired outcomes
  10. A Minimum Viable Product is also the smallest thing you could create or do to prove or disprove an assumption

Chapter 3 – Plan to learn faster

  1. Validate that the problems you are solving actually exist
  2. Sketch and prototype so you can envision your solution
  3. Prototype and test with users to learn whether your solution is valuable and usable
  4. Treat every release as an experiment and be mindful of what you want to learn
  5. The goal is not to get something built, rather it is to learn if we are building the right thing

Chapter 4 – Plan to finish on time

  1. Map only what you need to support the conversation
  2. The best estimates come from developers who really understand what they are estimating
  3. Use iterative thinking to evaluate and make changes to what you have already made
  4. Use incremental thinking to make additions

Chapter 5 – You already know how

  1. Write out your story a step at a time
    1. User tasks are the basic building blocks of a story map
    2. Use goal level concept to help you aggregate small tasks or decompose large tasks
  2. Organize your story
    1. Maps are organized left to right using a narrative flow, the order in which you would tell the story
  3. Explore alternative stories
    1. Details, alternatives, variations and exceptions fill in the body of the map
  4. Distil your map to make a backbone
    1. Activities aggregate tasks directed at a goal
    2. Activities and high level tasks form the backbone of a story map
  5.  Slice out tasks that help you reach a specific outcome
    1. Use slices to identify all the tasks and details relevant to a specific outcome
  • Tasks are short verb phrases that describe what people do
  • Tasks have different goal levels
  • Tasks in a map are arranged in left to right narrative flow
  • The depth of a map contains variations and alternative tasks
  • Tasks are organized by activities across the top of themap
  • Activities form the backbone of the map
  • You can slice the map to identify the tasks you will need to reach a specific outcome.

Six Steps to Story Mapping

  1. Frame the problem – who is it for and why are we building it
  2. Map the big picture – focus on the breadth, not the depth.
  3. Explore – go deep and talk about other types of users and people, how else they might do things and the kind of things that can go wrong
  4. Slice out a release strategy – focus on what you are trying to achieve for your business and on the people your product will serve
  5. Slice out a learning strategy – use the map and discussions to find your bigger risks, slice your map into minimum viable product experiments
  6. Slice out a developmental strategy – focus on building things early that help you learn to spot technical issues and development risks sooner

Chapter 6 – The real story about stories

  1. The best solutions come from collaboration between the people with the problems to solve and the people who can solve them
  2. Story conversations are about working together to arrive at a best solution to a problem we both understand
  3. Good story conversations have lots of words and pictures

Chapter 7 – Telling better stories

  1. Use simple story template to start conversations
  2. It doesn’t need to be written in a template to be considered a story
  3. Checklist of what to really talk about
    1. Really talk about who
    2. Really talk about what
    3. Really talk about why
    4. Talk about what’s going on outside the software
    5. Talk about what goes wrong
    6. Talk about questions and assumptions
    7. Talk about better solutions
    8. Talk about how
    9. Talk about how long

Chapter 8 – It is not all on the card

  1. There are many different kinds of conversations with different people for every story
  2. What should be on a story card
    1. Short title
    2. Description
    3. Story number
    4. Estimate, size or budget
    5. Value
    6. Metrics
    7. Dependencies
    8. Status
    9. Dates
  3. Use a document camera or a web camera during a video conference to let remote people see what is being created on the wall
  4. Use tools to post pictures, videos and text to help you retain and remember your conversations
  5. Use tools to sequence, analyze and track progress

Chapter 9 – the card is just the beginning

  1. Handling off all the details about the story to some one else to build doesn’t work
  2. Inspect the results of your work
    1. User experience quality
    2. Functional quality
    3. Code quality
  3. Try using stories to drive the making of anything whether it is software or not

Chapter 10 – Bake stories like a cake

  1. If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal
  2. If the story describes a solution that’s affordable but big, break it into smaller parts that will allow you to evaluate and see progress sooner
  3. Don’t break down big things into big plans. Break big things into small things with small plans
  4. Luke Hohman – “deliver half a baked cake, not a half baked cake”. Half a baked cake may not be enough to feed a wedding party, but it is enough to taste and leave everyone looking forward to the rest of the cake.

Chapter  11 – Rock breaking

  1. A right sized story from a user’s perspective is one that fulfils a need
  2. A right sized story from a development team’s perspective is one that just takes a few days to build and test
  3. A right size story from a business perspective is one that helps business achieve business outcome
  4. Conversations are one of the best tools for breaking down of big stories
  5. An epic is a story that we expect is large and know needs to be broken down
  6. Use opportunity discussions to agree the problem is worth solving – to make a go forward or trash decision
  7. Use discovery conversations and exploration to find a small viable solution
  8. During discovery you will dig deep into
    1. Who the customers and users are you believe will use your solution
    2. How they meet their needs today without your solution
    3. How the world would change for them with your solution
    4. How your solution might look and behave
    5. How long your solution might take to build
  9. Use deep dive story workshop s to discuss the details break down stories and really agree on specifically what you will build
  10. Frequently reflect on product quality, your plans and the way you work
  11. Learn by testing meaningful chunks of working software with customers and users
  12. Keep the progress and quality visible to stakeholders in the organization
  13. Use metrics and conversations with users to really learn if the target outcomes were met

Chapter  12 Rock breakers

  1. Requiring a single product owner to write all of the stories and be present for all story conversations does not work
  2. Valuable – Usable – Feasible – Marty Cagan describes the responsibility of the Product manager to identify a product that is valuable, usable and feasible.
  3. A small cross functional team led by product owner orchestrates product discovery work
  4. Support product owners with a core team that includes user experience, design expertise and technical expertise

Chapter 13 – Start with opportunities

  1. Have conversations about opportunities
    1. Who they are for
    2. What problems are we solving
    3. What we are imagining
    4. Why
    5. Size
  2. Product Canvas – Marty Cagan’s Opportunity assessment template
    1. Problems or solutions
    2. Users and customers
    3. Solutions today
    4. User value
    5. User metrics
    6. Adoption strategy
    7. Business problem
    8. Business metrics
    9. Budget

Chapter  14 – using Discovery to build Shared Understanding

  1. Discovery is not about building software – it is about building a deeper understanding of what we could build. It would mean asking questions like
    1. What problems are we really solving
    2. What solutions could be valuable to our organization and to customers buying or adopting the product
    3. What does a usable solution look like
    4. What’s feasible  to build given the time and the tools we have
  2. 4 essential steps to Discovery
    1. Frame the idea – to set the bounds for the work
    2. Understand customers and users – gain insight of the features and how it would benefit them, personas
    3. Envision your solution – envision how your target customers and users will make use of the solution – combine/brainstorm ideas, refine and come to a shared understanding of what the software should look like
    4. Minimize and plan – cut away more ideas that you keep, prioritize them

Chapter 15 – using discovery for validated learning

  1. Design thinking
    1. Empathize – understand how it really feels to be a user of your product, talk directly to them and experience their challenges
    2. Define (Focus) – build shared understanding – focus on one or a few problems
    3. Ideate  – come up with multiple possible solutions to customer and user problems
    4. Prototype  – build simple prototypes to help filter a lot of ideas that wont work
    5. Test – learn whether the solution could really solve someone’s problem – iterate and improve
  2. Short validated learning loops – Build Measure Learn
  3. How Lean Startup thinking changes Product design
    1. Start by guessing
    2. Identify your risky assumptions
    3. Design and build a small test
    4. Measure by running your test with customers and users
    5. Rethink your solution and assumptions

Chapter 16 – Refine, Define and Build

  1. Meeting is the word that has become a euphemism for unproductive collaboration
  2. Allow team members to participate in /opt in to the conversations. A Fishbowl collaboration (small effective group inside, interested members outside) pattern could also be used
  3. Use a map to visualize progress

Chapter 17 – Stories are actually like asteroids

  1. Break stories down progressively and just in time
  2. At each story discussion and splitting stage, you do so with a purpose in mind
    1. For opportunities, you discuss what they are for, what problems they solve.
    2. During discovery, you discuss who would use the product, why and how
    3. When planning a development strategy, you discuss what the risks are
    4. When planning for the next development cycle, you decide exactly what to build and make agreements on how you would check to confirm it is complete
  3. You could also look at bundling similar stories together to form a bigger story

Chapter 18 – Learn from everything you build

  1. Review as a team
  2. Review with others in the organization
  3. Learn from release to users – improvements made after release are most valuable
  4. Evaluate release readiness across the backbone of a map