CAIN (Continuous Attention to Individuals’ Needs) – An #AntimatterPrinciple approach to retrospectives

This is an idea for a series of focused retrospectives called CAIN (Continuous Attention to Individual’s Needs). It is inspired by, and based upon, Bob Marshall’s Antimatter Principle (Bob is @flowchainsensei on Twitter – you can find all related posts and tweets here).

The premise of the Antimatter Principle is simple – Attend to folks’ needs.

Think of CAIN as one example of a concrete implementation of this principle, or a method.

CAIN adapts the typical retrospective questions of “What’s working well?“, “What’s not working well?” and “How can we improve?” to directly address the needs of folks in a team in a systematic way.

The team is looked upon as a group of individuals with unique human needs rather than purely a homogeneous unit. Continuous improvement efforts are focused on the habitual attendance to each individual team member’s needs (hence the name CAIN) rather than trying to ascertain the needs of the team as a whole.

From a Toyota Kata perspective, the current condition is the number of unmet needs in the team. The target condition is zero unmet needs. The team as a whole will continuously endeavour to reduce the number of unmet needs of the individuals in the team via deliberate actions and experiments identified in the retrospective.

What’s working well for me? (needs being met)
What’s NOT working well for me? (needs NOT being met)

Each team member spends time individually reflecting on events since the last retrospective that directly addressed one or more of their innate needs, and those that did the opposite. They are also invited to highlight needs that feel unmet due to something that didn’t happen.

:) "I feel very valued this week, and that I am starting to form friendships in this team."
:( "I feel our work at the moment is quite mundane and uncreative."
:( "I did not receive recognition for my efforts this week, which leaves me feeling somewhat deflated."

For this exercise, the team might find it useful to refer to a model for representing human needs, such as Maslow’s Hierarchy of Needs.


Folks are invited to consider their emotional response to events rather than trying to be rational or scientific about what is working and not working. How they feel about what happened (or didn’t happen) rather than an objective assessment of what is effective or not.

For this to happen, it is more important than ever that the team feels they are in a safe environment, so the need for a safety check is paramount. Folks are being invited to share intimate thoughts and needs as human beings, so a high degree of trust is required. Consider that CAIN might also be used as an approach to build this required trust in the first place.

It’s also worth pointing out here that reflecting on one’s actual needs is not a simple task*. It is far easier for us to talk about what we want, or think we want, rather than what we actually need.

However, there is much inherent value in simply talking about needs – especially those of the deepest human kind – even if the “needs” that get identified are not truly the innate needs of the individuals. With practice, the team will become more effective at identifying genuine needs, and in the meantime they will at least be talking about them, building trust and perhaps making their work environment more joyful in small ways.

*This is also apparent in so-called requirements elicitation, where folks try and identify what the customer needs by asking them what they want. Actual needs are somewhat intangible in practice, and tend to emerge over time rather than be identifiable in the present.

How might we attend to my unmet needs?

Having celebrated the needs of its members that are being met, the team will turn its attention to addressing unmet needs. Folks are invited to spend time individually thinking of ideas that might reduce the unmet needs count.

All ideas are presented, and the group votes for the one they think might have the biggest impact.

An experiment is formed, and each team member goes back to her/his work routine, hopefully with an enriched view of her/his own needs as well as those of their colleagues.

What next?

My hypothesis is that CAIN might reap better results than other retrospective approaches because it reduces the risk of groupthink. No attempt is made to collate things identified as (not) working well into a team consensus. It is always the needs of the individuals that are focused on.

CAIN also might reap positive results because it focuses on the strongest lever for improving effectiveness, which is mindset. The conversations that arise when folks are unravelling their personal and professional needs will reveal differences in mindset – dissonance – which, left unaddressed, will result in a perpetuation of ineffective strategies for getting needs met, leading to conflict, competition, poor results from a team’s perspective and, ultimately, that of the entire organisation.

I invite you to give CAIN a try in your next team retrospective, and share your experience 🙂

8 signs of an agile organisation

1. Folks have shared goals with the organisation at a shared time

— i.e. they are synchronised with each other and the organisation’s goals

When we think about what makes Agile such an effective approach to software product development, we think about a single team, working toward a single product vision, happily iterating and incrementing toward a common goal.

As soon as you add just one more team or product in the mix (often referred to as “scale”), you have already added significant complexity to the situation in terms of product prioritisation, team processes, methods, estimation, relationships, dependencies and more. In short, keeping the magic of single team/single goal becomes increasingly difficult — seemingly impossible.

Well, It’s certainly not impossible. Agile organisations make principle-led decisions that allow them to keep the single team/product magic alive. They ensure that every person in the organisation has a clear goal at any given time — the same goal as that of the team they work with — which in turn is aligned to the correct organisational goal at that precise time.

Principles are one thing, but structurally this might sound too hard. Again, yes it’s hard, but it can be achieved via clear and ongoing prioritisation of initiatives (the things of [assumed] value that we want to achieve as an organisation), and forming autonomous teams/squads/tribes around them. If there are dependencies between teams, act to minimise them — remove them completely if possible — for your highest priority initiatives. Push the dependencies down the priority list.

It can also be achieved by forming teams around long-lived themes, such as customer capability. For example, MYOB builds accounting software. If I were to ask one of our SME customers “What does MYOB software enable you to do?“, the type of answer that would come back would be “banking“, “taxes“, “payroll“, “reporting“, etc.

These functions are all candidates for forming cross-functional squads around — squads that include all folks required to deliver end-to-end value within that area of capability for the customer. Suddenly, our business mission of “Making business life easier” is broken down into “Making banking easier“, “Making taxes easier“, “Making payroll  easier“, and so on.

As a side note – this kind of customer-centric approach is also a hallmark of a truly agile organisation.

2. Decisions are made quickly and daily by all

— via ubiquitous information, not based on rank

In knowledge work organisations, thousands of little decisions are made every day. If folks do not have good information with which to make those decisions — or they are not empowered to make them for some other reason — there can be a huge impact on the organisation, both culturally and economically.

For example, if I am asked to deliver two outcomes, and it becomes apparent it is only possible for me to deliver one of them, what should I do? Do I have the appropriate information (and authority) to choose which one to sacrifice? What about technology choices? How should I deal with this customer situation? Should I fix this bug? Should I ship this feature now or delay delivery for a week?

If I cannot make these decisions quickly — in a way that is consistent with how others would decide (because we all have access to the same information), and without fear of being punished for making the wrong decision — the organisation might effectively grind to a halt.

An agile organisation makes decisions quickly — based on clear decision frameworks that enable everyone from the CEO to the cleaner to fearlessly make good decisions every day.

3. “How the work works” is optimised for sustainable responsiveness to customer needs, not output nor strategic certainty

— i.e. responding to change over following a plan

An agile organisation is not [necessarily] one that can churn out masses of features every week. It is also not one that jumps around, shifting priorities from one week to the next. Instead, it is an organisation that can seize opportunities very quickly — opportunities that arise either via internal ideation or changes in the market.

An agile organisation should have a strategy, sure, but it recognises that the strategy might be misguided, or needs to change for some other reason, so it ensures that teams can adapt quickly to a change in strategy rather than require a painful restructure. It does not put all its eggs in one basket and optimise for delivery of the strategy. It actually embraces agility itself as a strategy.

Lead time is a common metric for lean/agile organisations to focus on, and rightly so – how quickly can we turn an idea or request into real value for a customer?

In theory, it is easy to turn that killer idea into a real thing for a customer quickly, even if your organisation does not yet have the necessary infrastructure for true agility. You can achieve it via an authority figure usurping other “priorities” and thus seeing their request expedited by a team swarming around it, doing what they are told to do as quickly as possible at the expense of everything else. Look how quickly critical production issues are resolved when all the key people are thrust together immediately with a single, shared focus and goal.

This is why organisational agility requires not just responsiveness but sustainable responsiveness. The expedite situation above can never be sustained. True agility is being able to turn on a sixpence due to work being done in small enough batches — and with enough slack in the system for folks to be quickly available when new and better opportunities arise than the ones we currently have.

4. Where rituals and practices are required in order to achieve 1-3, the preference is always for individuals and interactions over processes and tools

— and conveying information to and within a teams via face-to-face conversation.

Organisations typically default to processes and tools when trying to address improvements in performance. Truly agile organisations are full of folks who recognise that improving the quality and quantity of their interactions with other folks is the key to improved performance.

For example, frequent all-hands gatherings to plan together, celebrate and review achievements, learning and progress toward goals — over trying to get everyone to put all their tasks in Jira.

5. All hiring is for mindset over skills over experience, which allows for implicit trust that folks will always commit to doing their best

— i.e. build projects [sic] around motivated individuals – give them the environment and support they need, and trust them to get the job done

This one almost speaks for itself. If every hiring manager in the organisation hires other folks with a mindset aligned to the desired collective organisational mindset, they are [by design] hiring people they trust and who will be motivated to achieve the organisation’s goals.

There is no place — nor need — for hierarchical authority, carrots and sticks in effective agile organisations.

6. Organisational performance improvement is addressed via deliberate action toward systemic change (that is hypothesised to improve the organisation in the desired manner)

— not via the sum of collective individual performance appraisal

Managers and leaders who focus their efforts on trying to improve the performance of individuals in their teams are playing a low percentage game in terms of the likelihood of any significant effect on organisational performance. Managers are far better served addressing “the way the work works” — the system conditions — to achieve the kind of improvements they are being asked to make.

If you want your organisation to get better in a particular area (e.g. efficiency), fix the environment to support improved efficiency for the whole eco-system, not any one team or individual.

(I’ve referred in my talks to this systems approach to improvement as “building a network for high speed trains” rather than “trying to make trains faster“).

7. There is no delineation of “business” and “IT”

— technology folks work daily with other folks who share the primary concern of serving customer needs, thus the organisation operates as  one “we” rather than many “them’s”

As I’ve already alluded to, organisational agility requires high trust between individuals, teams and departments. Unfortunately, typically organisations are instead built around silos, which encourages and then perpetuates a low trust environment. This is why folks in, say, development teams, end up referring to folks in, say, sales or marketing teams as “the business”.

High level strategy and day-to-day task execution must be mutually respected in equal measure by the folks who are responsible for them. Everyone in an organisation is “the business”, and until folks recognise this and live it daily they cannot be part of a true agile organisation.

8. There is continuous attention to [technical] excellence, simplicity, learning and improvement

Organisational agility requires an embedded continuous learning and improvement culture. There are always better ways of doing things in complex environments (such as knowledge work organisations). “Best practice” and cookie-cutter processes will never achieve agility.

Instead, we must experiment with models, heuristics and methods that allow us to adapt, pro-act, react and enact with respect to what we’re building and how we’re building it.

What other signs are there of an agile organisation? I’m sure there are more — please share 🙂

#NoEstimates is neither the destination nor the journey

Being one of the early contributors to the #NoEstimates (NE) hashtag, and a regular blogger on the topic, I am understandably regarded as a “#NoEstimates advocate”. When I get introduced to folks at meetups and conferences, a typical exclamation is “Hey, you’re the #NoEstimates guy!”

Another consequence of my reputation as a pioneer of the “movement” is that I will often get asked questions that, when answered, are deemed to represent the views of all NE advocates or, more bizarrely, NE itself. It’s as if NE is a thing that can have an opinion, or is a single method/approach. “What does NE say about X?” or “Here’s what the NE’ers think“.

What some don’t realise is that there are wide and varied disagreements between so-called NE advocates. It’s similar to the variety of viewpoints that you would get within, say, a political party. The party represents a set of values and principles, but there will rarely be a situation where all the members agree with every policy proposed or pushed through in the party’s name. I guess the same could be said of Agile too.

Folks are naturally interested in the practicalities of what a #NoEstimates approach might look like. This is fantastic, and I welcome questions and discussion on this. I engage in such conversations often. But I do want to make a point about an underlying presumption behind most of the questions I receive. Here are some of the most typical ones:

“How do you prioritise at the portfolio level without estimates?”
“How can you make decisions in the presence of uncertainty without estimates?”
“How do you convince senior management to implement #NoEstimates?”
“How can we minimise the number of things we need to estimate?”

What these questions have in common is that “not estimating” at all levels of work is where we want to head. That the goal is to reduce our estimates across the portfolio, with zero estimates as utopia. That the premise of #NoEstimates is the less we estimate, the more effective we will be.

For me, DOING NO ESTIMATES, or even LESS ESTIMATES, has never been a destination from my point of view.

My focus has always been on improving the way we work such that estimating becomes redundant.

This means understanding our business better. Becoming more stable and predictable in our method of working. Building relationships based on high levels of trust and respect. Reducing dependencies between teams. And so on.

People ask “So, Neil, how do we get started with #NoEstimates? Should we simply stop estimating and see what happens?”

The answer to this is a categorical “NO“, at least from where I sit. There are a set of minimum conditions (or “barriers to entry”) before you can get anywhere near being in an environment where you do not need to estimate. Other NE’ers might not answer in the same way, but that has always been my stance. Read my earlier #NoEstimates posts if you don’t believe me!

My views have certainly evolved on the topic, and some of my early work might take a slightly more extreme stance. But I would never advise people to stop doing anything without knowing anything about their context. Even if I did know their context, I would be suggesting small experiments rather than simply stopping doing something that may be of value to that team and/or wider organisation.

Some people see #NoEstimates as meaning “NO ESTIMATES”, and can’t see beyond that.

To me, I see it more along the lines of:


If anyone wants to start tweeting to these hashtags, go ahead! I prefer to tweet to where the conversation actually is (and shorter hashtags :)), and trust that the reader does their own research and understands the nuances of the debate. You need to scratch well beneath the surface to find where the “NE’ers” agree and disagree.

The destination, in our jobs as software professionals, is becoming more effective at building great software for our customers. The journey is one of continuous improvement via experimentation. We can use Agile, Lean and Kanban principles to help us with that. We can use Scrum, XP, Kanban Method, SaFE, LeSS and other methods to help us with concrete implementations of the principles.

#NoEstimates started as just another Twitter hashtag. It has since become an enduring symbol of an industry that is unhappy with the prevailing way estimation is done, and the effect that has on what we’re trying to achieve professionally and personally. Some critics have cited “poor management” as the root cause of the dysfunctions we see around estimation. If that’s true, and estimates aren’t to blame, what next? How do we address a widespread problem with poor management?

Simply telling people how to do better estimations won’t do the trick. #ShouldWeDoNoEstimates? Perhaps, perhaps not. Either way, let’s at least have a bloody good debate about how we go about things in the workplace. Let’s put our heads together and “uncover better ways of working”.

Behind the NE hashtag is a world of opinion, ideas, principles and approaches that may be worth exploring and experimenting with on your journey to becoming more effective at software development. Many have done so. Many continue to do so.

I hope you do too 🙂

My presentations





The common ground of #Estimates and #NoEstimates

One of the criticisms of the #NoEstimates (NE) stance is the view that even contemplating not estimating is a non-starter – because estimates are “for those paying our salaries”, not those doing the work. That the business folk in our organisations need to know what will happen and when in order to run their company successfully.

OK, even if NE advocates could successfully argue against that assertion, perhaps it is time we started to acknowledge the “impediments” of the debate? The back and forth arguments that prevent us from moving forward to a more constructive place.

Perhaps it is time to find the common ground, and build on that.

A simple truth is that business wants (needs) both speed and predictability. I think we can all (mostly) agree on that 🙂

Some NE critics argue that we should learn better estimation skills such that our predictability improves. Yep, sure. Difficult to argue that learning to do something better is a bad thing.

Given that we have to do a lot of estimating as software practitioners, learning and using more effective estimation techniques seems a good idea.

However, in return for NE advocates acknowledging that we need to provide estimates for those asking, and get better at doing so, I think it’s time for the critics to acknowledge that arguing better estimation as the answer to all the dysfunctions surrounding software estimation is another impediment to the debate moving forward.

I see common ground in that we are all trying to create better predictability for our teams, customers and internal stakeholders. If we put aside “better estimation” as a way of doing that, how else might we do it?

Better predictability can be achieved in many other ways:

  • Stability and autonomy of teams
  • Limited WIP of initiatives (1 per team at any given time)
  • Frequency of delivery of “done” software
  • Cadence of collaboration – planning, building and reviewing together
  • High visibility and transparency of work and progress
  • Shared understanding of variability, its effects on long range planning and how/when to try to minimise it or leverage it to our advantage

to name but a few.

To take the NE debate forward, we need to find ways to provide “those paying our salaries” with the predictability they need, while at the same time moving away from the dysfunctional behaviours associated with holding teams accountable to estimates in highly unpredictable environments.

What is an unpredictable software development environment? One in which 1 or more of the things listed above are not being addressed. It might not be a stretch to suggest that’s pretty much every software shop on the planet.

There is common ground between critics and advocates in this debate. Let’s move on from “no estimates for anyone!” and “just learn better estimation techniques” – these arguments will perpetuate butting heads.

Instead, let’s explore – together – how we might create more predictable environments for our software teams, such that estimation becomes easier (and, in some cases, redundant).

“We are uncovering better ways of developing software by doing it and helping others do it.”

~ Agile Manifesto