In my work as an independent agile consultant, senior or middle managers from companies large and small ask me to come in and assess their ways of working.
They know that something isn’t working, but they’re usually not quite sure what. Often folks speak of delivery teams being “slow” or “inefficient”, but have no data to back up their claims. Regardless, someone with enough authority in the company that their opinion matters has a perception that things could be far better. Perhaps the person bringing me in wants an external person with solid knowledge and experience of what they are facing, along with a good reputation in the market, to validate their own messages with the sceptical higher-ups.
Getting to the heart of the actual problem to solve, or objective desired from my tenure (the ROI), is usually a process of discovery. Untangling the complex web of politics and relationships to reveal the underlying roots of the negative perceptions, and opportunities for making some kind of step which is deemed — by the people who matter — as a forward one.
What am I looking for?
Putting cultural aspects of improvement engagements aside for one moment, there are always operational clues as to why people aren’t feeling any genuine sense of progress in their agile transition.
In this article I’d like to share what I am looking for both operationally and culturally when asked to assess what might be going on in a software delivery organisation from an agile perspective — and how effective such activities and behaviours are proving to be (aka “agile maturity”).
This then allows me to make recommendations which, if followed through, have a strong chance of making a real improvement to the business. A lot of agile coaching and training ends up being a rather aimless pursuit of sprinkling agile fairy dust all over the place and “making the teams more agile”. This is something I refuse to do — it’s not good for me and it’s certainly not good for the paying customer.
OK, so here are 8 broad patterns of operation I am looking for:
1. How much emphasis is put on early and often delivery of value for the customer
The first principle in the Manifesto for Agile Software Development reads:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Thus a focus on delivery of customer value is absolutely fundamental to what agile is all about, and at the heart of the benefits it can bring.
Accordingly, I am looking for customer-centricity in 4 key areas:
- The way work is described
e.g. Customer outcome-based capabilities such as user stories, Jobs-To-Be-Done (JTBD), etc. - The way work is prioritised
- By value to the customer (balancing short term and longer term customer needs and strategic value);
- Simplest, quickest path to delivering something useful to a customer
- Welcoming changing requirements (for the customer’s competitive advantage);
- Frequent and adaptive goal-based planning over static schedules and plans - The way teams are organised and managed
- Cross-functional feature teams pointing at customer-centric goals (including daily interactions with sales, support, marketing and other business functions) vs functional component teams working out of concert with surrounding business functions and pointing at technical/business-centric goals;
- Existence or otherwise of team and management continuous improvement champions (e.g. Scrum Masters), and whether they are part of the formal leadership and authority structures - Other processes, practices and ways of working
- Frequent feedback from real customers;
- Collaborating with customers, teammates and stakeholders;
- Acceptance test (behaviour) driven development (ATDD / BDD)
2. Frequency of working software
More explicitly, how often working software is:
- Ready to be released (aka shippable)
Every month? Every sprint/iteration? At all times? - Actually released to real customers of the software (aka shipped)
Release frequency, lead time (time from customer request to delivery)
3. How useful (valuable) the released software is to those customers
- How often features are used
Daily? Once a week? Once a month? Never? - How satisfied customers are with features, releases and products in general
CSAT, transactional NPS, product NPS
4. How much emphasis there is on direct face-to-face communication and transparency of information
5. Whether teams (and managers) are continually “uncovering better ways”
- Learning is treated as a 1st class citizen
Expected during working hours, and opportunities provided - Continuous improvement experiments are ongoing to improve products, processes and the surrounding environment for better outcomes
6. Whether management and teams are focused on technical excellence and quality
- Zero defect attitude and culture
- Stop-the-line for build pipeline, test failures and production incidents
- Prevailing message of quality over “get it out the door”
- Code reviews, pair or mob programming, swarming, TDD
- Clean code, simple and easy to delete or extend
- Easily extensible architecture
- Quality built in with practices such as evolving Definition of Done, ATDD, BDD, continuous exploratory testing
- CI / CD / DevOps automation tools, practices and culture
- Sustainable pace
7. Whether accountability is being put on teams for the above things, or for something else
The teams should be accountable for:
- Customer satisfaction
- Delivery of customer and business outcomes
- Being shippable at all times
- Releasing valuable software frequently
- Technical excellence
- High quality software / zero defects / zero failure demand
- Transparency of artefacts, information and communication
NOT delivering e.g. x, y and z stories or features by June 14th.
8. Whether management is focused on creating an effective environment for software delivery through supporting and trusting the teams
- Transparency of information over micro-management and status reporting
- Self-organisation and team ownership of process and decisions
- Safety to experiment, learn and get things wrong in the pursuit of excellence
- Setting teams and individuals up for success with the tools, people, coaching, training, working environment, autonomy, mastery and purpose they need
How will I discover these patterns?
- Embedding with teams and groups as required, both in day-to-day activities as well as regular and ad-hoc meetings
- Observation of people’s behaviour and interactions, both with their peers and those with more or less authority in the organisation
- Observation of established and evolving work processes, practices and tools
- Formal conversations (interviews, meetings)
- Informal conversations (“water cooler”, go for coffee)
What will I need from the client?
Coaching and training is largely ineffective if people are having it done to them rather than initiating it themselves. Also, it is very likely that being observed, however subtly I go about it, will change folks’ behaviour from what it would have been had I not been observing, and in unpredictable ways.
It is therefore imperative that an expectation is set with teams, surrounding stakeholders, managers and other individuals involved in the end-to-end software development lifecycle of:
- Why I have been engaged by the company
Note — If I discover that the reason for this is simply to “get the developers working faster”, rather than a genuine desire from leadership to find ways (including changing their own behaviour) to make a more effective working environment, then I will not continue with the engagement - What I am there to do and accomplish
There needs to be transparency about what I am doing (partly the reason why I am publicly sharing this right now!) in order for people to buy into it and participate, or at least to understand it. And the whole thing must be driven by the people bringing me in, not me. Otherwise it’s just “the bloody agile guy trying to convert everyone”. No one knows me from Adam, and I am not part of the company and thus lack influence and skin in the game. - The need for a lot of their time, energy and goodwill during the engagement so they can share in detail how they do things, their pain points and opinions on what can be improved
I am usually there largely because everyone is “too busy to improve”. That situation is not suddenly going to change when I arrive. Hence if people have been explicitly afforded the time and space by management for learning and improvement activities with me, it makes for a far more effective engagement.
I hope this article has given you an idea of what kind of behaviours and activities make for a productive agile environment, and what to expect if you bring me in to help your own organisation.