Agile is more than just tools

It's been a challenging yet rewarding journey since joining Afiniti back in October, 2020. As a first-time Agile Coach, I was overwhelmed with the amount of information the AIDI teams were dealing with, building complex solutions for fortune 500 companies worldwide. But I was ready to be vulnerable and act for the betterment of my colleagues, clients, and organisation. Working closely with knowledge workers from different regions and cultures, I learned about the impact of unconscious biases on business deliveries. My journey to becoming a practicing Agile Coach is now available for those who want to build and sustain high-performing software delivery teams.

Agile Adoption is about "what we do?" and Agile transformation is about "who we are?" To find long-term success as an Agile Coach /or Software Delivery Lead /or Manger /or Director /or VP, you need to find the right balance between the two.

(a) Know your super power

I have an ability to connect with people at emotional level so, they feel safe to bring their whole authentic self to work and add value to the product/organisation. This is my super power, what's yours?

Tools: Introspection, StrongSuits, Personality Pallet, 16 PF, etc.

(b) Learn about level of your skills and expertise

You should always keep an eye on what you're good at and, where you need you to improve? Reflecting on yourself will not help you grow as an individual but also as a team coach. You should be constantly thinking about how you can improve.

Tools: Reflective Journaling, Goal setting, Capability Model, 4 DX

(c) Build a toolbox for your teams

Here's a sample of my personalised kit to teach, coach and mentor teams to be more agile.

1. Know your teams at personal level e.g. their personalities, background, experiences, working styles, aspirations, strengths, weakness, controllers, influencers, fears, motivators, demotivators.
2. Apart from facilitating the Scrum events, pay attention to individuals and interactions by observing, actively listening , asking open-ended questions (especially What and How questions instead of Why questions) and jotting down notes (separating facts from meaning).
3. Focus on verbal or non-verbal cues that come up more than once and try to identify, fix and improve your team's ability to deliver/deploy as fast as possible.
4. Ensure psychological safety in your teams as it helps in promoting accountability, not blame.
5. Help your teams surface the strong emotions that may hinder their ability to work together.
6. Do not only focus on milestones, targets and quarterly goal; also gather data to illustrate your teams’ leading and lagging measures to track, measure and showcase their growth e.g. How predictable your team is? How many resources were added/removed in a quarter? How sustainable your team is? How many value-addition features were delivered ? How many non-value addition features were built and never went to production? How often the backlog was changing ? What wastage was removed in terms of resources, inventory, and performance of your system? What no .of outsider events lead your team towards distraction? How many commits were made after reviews or making code part of master? What's the quality of your code? What's the code coverage? What's the rate of fixed vs not-a-bugs ? How many bugs were identified internally? How many production bugs were raised by the client? What's your team’s engagement score? What're the team days? How many dependent items were raised and when? What no of experiments were done in an iteration or quarter? etc.
7. Have a reflective journal for yourself and your teams. It's like holding a mirror that would help them with their self-discovery and growth.

Tools: Personal Maps, Capability Matrix, Team's Growth Matrix, etc.

(d) Know how to use OODA Loop

1. Observe? Find the current reality
2. Orient? Recognise any barriers
3. Decide:? Since you're done with homework in first two steps so now, you can make informed decisions
4. Act:?Just do it and see how good or bad it was and once you've have enough information; go to Step one

Tools: Pi-charts, Heatmaps, Scaling maps, Discovery Calls, CPM, OKRs/KPIs, etc.

(e) Customise your growth model around People, Process and Structure

Every team is different; so is the process. Know their dynamics e.g. needs, demands, expectations, challenges. Know your team well before introducing change and get buy-in from all the stakeholders involved.

There were the attributes I considered while defining the structure of my teams:

People:

Behaviours: Culture, mindset, values, norms, needs, demands, communication

Capabilities: Number of people, competence, skillset, training, mentoring, unleashed potential, workshops, sponsorship

Process:

Practices, Tools, Habits, Patterns, Experiments, Reflection, Feedback

Structure:

Organisational design (offsite, onsite, onshore, offshore, departments, divisions, squads, tribes), Personal transformation, Role Modelling, Governance, Goal Setting, Networks, Recruitment/hiring, Performance Reviews, Reward, Compensation

(f) Opt for Lean Thinking

Lean thinking is an approach to improvement developed at Toyota in the 1950s to create the Toyota Production System. It is a strategic approach that focuses on dramatically improving flow in the value stream and eliminating waste. I am summarising some of the key highlights I used within my teams I worked with:

1. Long-term philosophy with short-term financial goals
2. Right process will produce right results
3. Use Pull system to avoid over-proudction and level the work
4. Follow standardised tasks and processes
5. Use thoroughly tested technology
6. Develop exceptional people and develop partners
7. Continuously solve root problems to drive organisational learning

Here's a sample of the lean model I used with my AIDI squad in Afiniti:

Values:?

1. Respect for people’s opinions, ideas, time and working style
2. Continuous improvement (document mistakes and lessons learned each sprint.

Principles:?

1. Pull JIT (only produce what's needed) items in the sprint and do not over-commit. Enable your teams to make evidence based decisions e.g. Growth Matrix.
2. JIDOKA- Create a clear and visible picture to identify and fix problems e.g. whenever we see a problem, we stop, we talk about it, document it and improve in the next sprint/iteration.

Methods:

Standardise the management of product, people and processes mentioned in (e).

Tools: Visual Planning Boards

Make sure that everything is visual and easily accessible to the related stakeholders:

A few examples are:

• Product Vision Board
• Story Mapping
• Roadmapping
• Release Plan
• Impediments Chart
• Feature Dependency Map
• ProductPlan
• Monday.com
• Miro
• Mural
• Jira/Confluence