I’m assuming we all know the choice phrase: “Assumption is the mother of all fuck-ups.” If you don’t, well there is the problem with assumptions right there.
In my previous article I listed 8 behaviours that contribute to a high performing team. The first on that list is:
Test assumptions and inferences.
It’s first for a reason. Humans have evolved advanced behavioural traits to ensure survival on the wild plains of Africa. We are great at pattern recognition, until we’re not. Our assumptions and inferences are examples of our application of pattern recognition. When we see someone behaving in a certain way, we review our memory for events that match that behaviour, then we infer the reason behind the current behaviour from the reasoning behind the historical behaviour. Many times our assumptions are correct, (After all, we did manage to survive this long!) however that’s not always the case. In our modern world, cause and effect can be a lot more complex than: “see a rustle in the bush – must be a lion! – run away and climb tree immediately!” In a business team context we are faced with people from many walks of life, cultural backgrounds and personal experiences. We also have the issue that language doesn’t fully express the nuances of what’s really going on in our thoughts, and that’s not even taking into consideration that many people in our teams are not even communicating in their native language. Put this all together and it becomes obvious why working in a corporate environment can often resemble a war zone.
But it doesn’t have to be. A lot of conflict can easily be avoided by making sure that the initial messages exchanged between people are understood properly. This is where the behaviour of testing assumptions comes into play.
Practically, there are 2 steps to this process:
Becoming aware of the assumptions and inferences you’re making; and
Testing these assumptions with the other party in a way to minimise defensiveness.
Becoming aware is the most difficult. We’re remarkable good at seeing when others are making assumptions but not so good at observing it in ourselves. Understanding the Ladder of Inference makes this process a lot easier. If you understand the steps you go through to come to a decision based on the data that has been supplied, you can stop and question yourself at any point on the ladder.
Testing these assumptions with the other party then becomes easier. You first replay what you’ve seen or heard and ask whether they see it differently. Then you play back the assumptions or inferences you’ve made based on that data. If they see it the same way, you are at least seeing or understanding the situation in the same way. If it’s different, you have the opportunity to clarify the situation.
This technique helps both parties realise they’re at least looking at the same hymn-sheet. Whether or not everyone wants to sing that particular hymn is another issue. You may still need to have a difficult conversation.
We are each on personal journeys of mastery, learning and growing continuously.
We take every opportunity to learn and practice our crafts.
We congregate regularly with others on similar paths to share our learnings.
We all know what the company’s purpose is.
We understand how the company’s purpose aligns to our individual purpose.
We can articulate how our actions contribute to the purpose.
We are constantly looking for new ways to contribute this purpose.
When we see colleagues struggling to understand their contribution to the company’s purpose, we get involved and try to help them understand.
When we see colleagues not living the purpose, we get involved in a respectful and caring way in the full knowledge that we are all human and sometimes need help from others to remind us of our purpose.
However, if a colleagues’s purpose is different from the company’s, we agree to part ways.
We are passionate about the work we do and are intrinsically motivated to do it.
We don’t need and certainly don’t appreciated either the ‘carrot’ or the ‘stick’.
We can control the work we do, when we do it and who we do it with.
If we have the same purpose and are intrinsically motivated, we will do the right thing.
We understand that we all have our strengths and weaknesses so we form teams that amplify these strengths and minimize the weaknesses.
We know that to thrive as a modern organisation we need the freedom, space and time to innovate and think creatively.
We will not always agree with each other. This is normal and gives us opportunities to understand each other’s points of view and thereby grow from them.
We endeavour to approach disagreements with respect and trust.
We understand and acknowledge that we are part of a larger, complex system and as such cause and effect patterns are often not as simple as we may assume.
We therefore prefer to test our assumptions regularly.
Because we value testing our assumptions, we prefer doing small bits of work and testing the outcomes so that we can pivot or change quickly to ensure we’re doing the right things.
We understand that even this manifesto will adapt and change and we are ok with that.
One of the most common rebuttals I often hear during an Agile transformation is “Oh, we’re already doing all this stuff. We just don’t call it Agile.” When I hear this, I try to stay as open-minded as possible, so I nod and find the first chance to observe. Usually my observations confirm very quickly that there’s an awful lot of cargo culting going on.
You see, the ceremonies and practises of a framework like Scrum aren’t difficult to explain or understand, at least at face value. No-one would argue that a stand-up every morning is a complicated affair. No-one grapples with the concept of putting the whole team in the same co-located space. Doing work in short increments or sprints seems to get nods of agreement from most people.
The ceremonies and practises are valuable and they work – Scrum wouldn’t be such a successful framework if they didn’t – but they are just some of the operational manifestations of an underlying way of thinking that is fundamentally different from the waterfall or project-based way of thinking. Waterfall is the ‘chalk’, Agile is the ‘cheese’.
Probably the most fundamental difference is that
Waterfall strives for certainty, Agile embraces uncertainty.
The implications of this are profound but are generally not understood very well. Let me try to explain by highlighting 3 comparisons that people make.
1) “A Feature Release Roadmap (Release Plan) is just another name for a project plan.”
The Waterfall mindset is rooted in Industrialism – we’re all resources building a machine and all we need to do to get it right is a detailed blueprint and a clear plan. It may be complicated, but it’s not complex. As long as we follow the plan we’ll be ok
The Agile mindset accepts that we are part of a larger complex system and we cannot be sure of the impact our actions and therefore our software will have on the overall system. So instead of planning to the nth degree, we create a rough order of features that we think might work and then release work into the wild as often as possible, gathering as much regular feedback as we can from our real customers to see if we’re on the right track. The Feature Release Roadmap changes based on the feedback and other inputs, such as changing market trends.
“Our Waterfall teams are cross-functional too!”
Co-locating everyone needed to achieve the business outcome is a good thing. Keeping working in silos inside the team is not. The whole team needs to get involved in all parts of the process. If the members of the team are still handing off work to each other and only focusing on their function, all that’s happening is mini-Waterfall over a 2 week period, which I must admit is better than Waterfall over multiple months or years! The hand-off is another example of the flawed notion of certainty – that the work can first be clearly and completely documented, then designed and developed based on the specifications, then tested according to the same specification.
Agile teams understand how powerful face-to-face communication can be and instead use documentation only as a supporting act to facilitate discussions during the process. This means that team members interact with each other throughout the course of the Sprint and gain a good appreciation for the input and skills of the other team members.
2) “Isn’t a User Story just another phrase for functional specification?”
No. A functional specification is again about certainty, about believing that a single document can detail exactly how a system should function. The reality of this fallacy starts hitting home as soon as development starts and the first change needs to be made. Keeping a document up to date with the code becomes completely unmanageable, as well as extremely costly and it invariably drifts out of sync.
A User Story, on the other hand, doesn’t try to be the definitive truth of anything. It is simply a narrative that is used to facilitate the discussions that happen during the development of the code. If it turns out that the Story didn’t deliver the value it intended, a new Story could easily be created to change the implementation. Seen this way, it’s clear that a list of all the Stories will not provide the details of exactly how the system should function – it was never intended to do so. That honour is left to the code and the test suite.
A Story is also framed from the perspective of the value that is provided to a User of the system rather than from the perspective of the system, an important point to remember.
3) “We have daily stand-ups too!”
This is often the first ceremony that is adopted by teams wanting to “go agile” and, let’s face it, it’s better to have the team gathering daily, rather than weekly, or (perish the thought!) monthly! When a Waterfall project adopts a daily stand-up, the Project Manager will usually be running it and requesting status updates from everyone in the team, usually marking off the responses on a project plan against the planned deliverables. The Project Manager will usually also allocate work to the team members if someone is finished with their previous task. If they have a visual radiator (aka a kanban board), it is usually either just a replica of the project plan, or a kanban board with a column for each phase: analysis, design, development, testing and deployment. The goal is usually not to get the work through the entire pipeline in one Sprint but rather through a specific functional area, for example, this Sprint will involve getting the design finished so that next Sprint the developers can start coding.
Contrast this with a high-functioning agile team, where anyone in the team may facilitate the stand-up, or indeed, no-one needs to facilitates at all! The team focuses on getting the work on the board through to done and in priority order. They use the stand-up to recalibrate and plan the day ahead, taking into account anything that may have changed. When there is an issue, they don’t try to solve it in the stand-up, rather planning a quick huddle afterwards, fully aware that others need to continue with their work to keep the flow happening. Optimising the flow of work through the pipeline is key to improvement.
Not so different
There are a number of other examples that abound but I think you get the point. On the surface there are similarities but when you probe a bit deeper you will find that they’re fundamentally different. You can’t effectively superimpose Agile on Waterfall. If your mindset doesn’t change, your way of working won’t, and this is when people usually proclaim “We tried Agile and it didn’t work for us.” They may have put a few ceremonies in place and changed the name of a few documents, but they certainly didn’t change.
One of the main tenets of agile is working in cross-functional teams. This means that individuals in the team each have their own functional expertise,together working towards a combined goal. Having different functions working together increases the chances of creating a great solution; one team member will be able to highlight issues that the others didn’t think about. A person’s blind spots are usually compensated for by others in the team.
But cross-functionality often doesn’t go far enough. Bottlenecks can still manifest. If the next stories on the backlog need some serious analysis, you will find that the BA becomes the bottleneck and the development slows down. Similarly, if the developers have finished the development of a story and that story needs a lot of manual testing, you’ll find that stories start backing up and can’t be marked as “Done”. Sometimes the Scrum Master needs to spend a lot of time dealing with external stakeholders dealing with dependencies and the team may lose focus without the Scrum Master on the floor. Too often a project involving many technology layers may need a specialist in a certain technology who is supporting a few teams and the velocity of the team slows down while they wait for that specialist to complete their tasks.
In these cases it helps to have poly-skilled team members. Testers could perhaps pair up with the BA to do some of the analysis, as they usually understand the underlying systems very well. Developers could lean in and help the testers with some of the manual test cases (We all know it’s more important to get a story through to “Done” rather than have multiple stories in progress, don’t we?) BAs often stand in for the Scrum Master when the Scrum Master isn’t on the floor, as the BA is intimately aware of the business priorities and can help keep the team focussed.
Developers can pair with the technology specialist to help transfer the skills and become more “full-stack” in their capabilities.
So instead of a team comprised of specific roles with one person performing a role, we end up with a team of people, each with a variety of skills, picking up any tasks that they can do, and learning more skills as they go along. That’s when things really start to groove.