The Starfish and the Spider: the unstoppable power of leaderless organisations - by Orid Brafman and Rod A. Beckstrom.

The Starfish and the Spider looks at the rise and fall of organisations due to their structural differences, and how the choice of different leadership styles play a part in an organisations longevity. Authors, Orid Brafman and Rod A. Beckstrom have done an incredible job at exploring centralised and decentralised organisations and not just from a modern day perspective, in fact the book kicks-off with a rather interesting tale involving MCM entertainment company, Spanish conquistadors and the Apaches.

One question it looks at answering is ‘What happens when organisations with different structures go head to head?’ - for example, the revolutionary change of how the vast majority of the music market share was once dominated by just a handful of big organisations, then in 2001 we saw the arrival of Napster which was based on using peer 2 peer software to share music on MP3 format. No longer were there people queuing up to buy the latest CD from music shops, instead they started to simply download music straight from the internet. This revolutionised how music was created and made available, driving the big organisations to revise their business models and in some cases, they went bankrupt as a result of them not being able to adapt in time to such a sudden change in the market - as one of the principles described in the book, when it comes to decentralisation ‘as industries become decentralised overall profits decrease’.

When you first look into what makes a successful and powerful organisation, you might immediately think that such organisations have a well-disciplined hierarchy with strong traditional leadership. I mean, what happens when there is no traditional leadership, no command and control within an organisation? Surely, magnitudes of chaos and disorder would inevitable prevail and getting work done would just run amok, right? Not necessarily - some organisations can thrive and even flourish due to their, let’s say, opposing centralised formation.

After reading this book, it has made me wonder more about how organisations are structured and if there are any signs of major disruption for these organisations on the horizon. It seems to me that there is room for modern-day organisations to explore and consider taking on a starfish-like structure, especially if it involves technology. You only have to look at the rise of blockchain and the capabilities of this technology, and not just blockchain, but technology in general and the many alternative ways in which work can be carried out. I think we’re now at the frontier of reshaping how modern-day organisations form and operate, thus introducing a whole new, interesting world of social and economic innovation.

• The Starfish and the Spider: the unstoppable power of leaderless organisations - by Orid Brafman and Rod A. Beckstrom

Making the right turns at the right time. The literal translation of the word agile – ‘able to move quickly and easily’, doesn’t exactly encompass the essence of everything that an agile team building software is about. There is a case for business agility for sure, but I don’t think an agile team should necessarily be trying to work faster as their primary aim. What about the needs of the people, the individuals of the teams, people in the organisation, people that use the software? There will be, of course, times when being able to move easily and fast as a team will pay off. However, you need to be heading in the right direction - in most cases, teams are better off going at a slower pace making the right turns, then running flat out in the wrong direction.

‘Agile processes promote sustainable development. The sponsors, developers, and users should be to be able to maintain a constant pace indefinitely’ – Agile Manifesto

Development teams should be able to maintain a pace of working that doesn’t cause any of them to become too overloaded with work, not to the point that they get stressed and burn out as a result of it anyway. Pressure can build up and the sense to do things quickly can easily appear if there aren’t processes in place promoting sustainable development. This will bring a halt to value being delivered, potentially impacting quality and innovation on the work that does get done. And not to mention the health and well-being of the individuals on the team.

Autonomy & Slack

Freedom within set boundaries and the flexibility to be able to change direction if necessary. This can become difficult when we strive for each team member to be 100% utilised, after all, we can’t possibly have people just sitting around doing nothing now can we …or can we? Some would say that there are situations where being able to just lean back in your chair, gaze out the window or up at the ceiling and daydream can be beneficial, this is probably true. The challenge arises when teams move at a pace that’s not sustainable for them. If there hasn’t been enough slack created, they become overloaded with work and if they then get blocked and pick up something else in the meantime, then that ‘something’ remains not done and in progress. Work in progress (WIP) is a leading indicator and can help expose bottlenecks to the team, so they can do something about it while there is still time. Having information relating to the Sprint progress visible, enables conversations to flow more easily amongst the team, allowing them to get alignment around how they may need to adjust things to still meet their commitment to the Sprint goal.

Quality of Performance

This ties in with sustainable development. When a team are under pressure to deliver something quickly, and they fall behind, then they can be tempted to cut corners. Teams that feel that they have the heat under their feet and don’t have enough time they need when it comes to them choosing between a safe route or a more experimental route, they play it safe almost every time. This can potentially hinder innovation and can produce less than desirable results, it can be seen when a team’s Sprint length is too short. Plus, there is also a good argument that maintaining a sustainable pace is a sensible approach when it comes to doing complex work, such as software development. As well as pacing being an important consideration for the well-being of the people on a team, it also plays a part in the quality of their performance - studies around the quality of performance suggest that there is be a sweet spot to be found when working with complex work.

Yerkes–Dodson law

Robert Yerkes and John Dillingham Dodson, perhaps best known for describing Yerkes–Dodson law. Their study is based on observation and experience and it maps the relationship between the quality of performance of an individual, and their physiological or mental arousal. The results from the study suggest that the quality of performance increases with arousal, but only up to a point, then performance decreases as levels of arousal become too much for the individual to handle. It seems that this typically occurs when working on complex tasks, such as those found in software development. Teams should work at a pace that’s suitable for them given their abilities and context - being able to work at a sustainable pace helps ensure that a team has enough time to plan, think and rest, to deliver a constant steady flow of value to the users.

Sponsors should be able to move and keep a pace that’s aligned with the teams so that they can continue to help provide support, steer and feedback on the work as it gets ‘done’ by the development team. What about the users, where do they come into this? The obvious answer might be to say that users, should continue in adopting and using the software as it’s released. To keep the organisation in business and to help shape the product. In an ideal world, the users should be giving feedback on the product increments as there are marked as done - it doesn’t get any better than that. If we released software frequently, but it took users months to pick any of it up and use it, then the lag in getting their prolonged feedback wouldn’t lend itself to be too useful to our sense and respond approach of delivering value - which essentially is what ‘agile’ is about. If users aren’t using the software frequently, then there is that question ‘Do they even find the software particularly useful at all?’ - it’s worth finding out!

‘Rule of thumb: Never space your releases out for longer than you can afford to absorb in wasted development time.’

Conclusion

Since software development is complex work, find the sweet spot that sits between full utilisation and slack, a point that allows flexibility and freedom within the team to be able to pick up and deal with unforeseen events and issues that can crop up during development. In the interest of team member’s well-being and the quality of their performance, development should move at a pace that makes sense for the team, organisation and the users. Closing the communication gap between an organisation and its customers seems to be a key aspect to the success and longevity of an organisation. It can certainly help an organisation understand their customers better, so they can discover useful and valuable solutions together. Developing without this type of relationship overtime will not likely prove itself to be a successful formula for delivering software. Not inspecting and adapting regularly, can end up costing a lot more than just the time and effort it took working on the design, test and build of the software. Since now you’ll have the added burden of maintaining that software and potentially created an unnecessary dependency to understand the additional complexity that has been introduced into the codebase. There is a high percentage of features rarely get used or yield the expected ROI / business value – the success of software isn’t ascertained whether or not a development team get all their requirements delivered. It’s determined by the outcome and impact the software has once it’s been released and put in the hands of users. It has to meet their needs and be valuable to the market - the market is the market; users are the users.

Links below if you’re after more information on this subject:

• Sustainable Software Development: An Agile Perspective - by Kevin Tate
• Agile Development & Business Goals- Agile Development & Business Goals
• Productive Conversations - Agile Manifesto

The ability to effectively facilitate groups of individuals that are all fully engaged for making decisions collaboratively, is commonly recognised as being a fundamental skill for any Scrum Master and is a key element to the success of building a functional, high performing Scrum team - Why is facilitation considered to be so important for a Scrum Master? What are some of the challenges found in facilitating? What might help with these challenges? These are some of the questions that I’ll be exploring. There are many parts to facilitation so I’ll cover parts that I think are worth mentioning. If you’re after more information about the topic of facilitation, then there are links at the bottom that will hopefully, be as useful to you as they have been for me.

I can’t emphasise enough on the importance of facilitation and if you’re a Scrum Master or an Agile Coach, you’ll only know too well. If you’re just starting out as a Scrum Master or considering it? Then I’d highly recommend engaging within the Scrum community for more information on this topic (or indeed for most Scrum related topics). Generally, the Scrum community are a nice bunch to mix with and they like sharing experiences and knowledge, these practical perspectives can be extremely useful.

Facilitation Isn’t Easy

No doubt, you’ve seen great facilitation outside of the world of Agile. If you have ever been in a meeting, workshop, or any kind of group gathering that went smoothly with a successful outcome, perhaps even thought to yourself afterwards ‘Well, that was easy’. If so, then there is a good chance that it had a good facilitator that made it feel easy. After all, the word ‘facil’ in Spanish translates to ‘easy’, deriving from the Latin word ‘facilis’. That’s not to say facilitation is easy- it’s not. One of the things I’ve discovered since being a Scrum Master is that the journey towards becoming a good facilitator- is one of the biggest challenges found in communication and collaboration.

Collaboration Is Nothing New

You’ll often hear the word ‘collaborate’, being said in software development. But what does ‘collaborate’ mean? I think, in the bluntest sense it just means ‘work together’. Which is nothing new of course, since we’ve been working collectively in groups since the beginning of our existence, and to a large extent our ability to collaborate has contributed towards our success as a species.

‘Only by working together are we able to fully account for the emergence and timing of unique features of Homo sapiens and how humans, evolved through natural processes, resulted in a spectacular anomaly among living species.’ - Kim Hill (professor anthropologist)

It may seem obvious to have groups of people working together in a team to accomplish something that would be otherwise difficult if everyone acted as separate individuals, and it might also seem logical for a team to practice as a team so that they can improve working together over time. Take sports teams, for example, they all typically spend hours of their time practising together to improve how they work as a team. In the British Army (and most likely all armies), small teams of soldiers (sections) practically collaborate constantly, to accomplish their objectives. They use terms such as ‘mucking in’, instead of ‘collaborating’, and often refer to someone as ‘jacking’, when they’re not collaborating. But essentially, they’re working together and typically improve how they work together over time.

One of the main reasons why, I think, collaboration is heard and echoed so much in software development today is that the success of software is usually based on the outcome that occurs after it’s been shipped. This means that it becomes paramount, not only for individuals on a team to collaborate but also for those at the team level to collaborate with their organisations higher strategic objectives, as well as with customers and users to understand their needs and challenges. Generally speaking, any Agile team that collaborates well, keep their work transparent and has effective facilitation so that they can take advantage of making effective decisions that are driven by the collective knowledge of the team. By collaborating they can make decisions about their work and their commitment that is based on their abilities. This type of transparency coupled with good communication and effective facilitation, helps each individual on the team align collectively to focus their efforts on a single point, for example, building a valuable solution for users, or completing a Sprint goal.

Good Communication Is Essential

My overall view is that collaborating depends heavily on trust, but also good communication amongst a team, having a free flow of meaning in conversations allows for a better understanding of each other’s perspectives, ideas and opinions. If individuals of a team find it difficult to communicate with one another, then that’s when the wheels start falling off and it’s very likely, that it will impact their agility and effectiveness as a team.

‘Most Conversations Are Simply Monologues Delivered in the Presence of a Witness’- Margaret Millar (perhaps, Mark Twain?!)

The need for good communication and collaboration are clear. Being a facilitator can help with promoting and nurturing a safe environment for communication, which is a must for any type of Agile team. This probably all sounds obvious and straight forward. However, what isn’t always obvious, are the types of obstacles (impediments) that prevent communication from working effectively and how facilitation can help, which I’ll come back to in a minute.

Scrum Master Facilitation Is Not..

I recently read an interesting article by Tobias Mayer, that explores the topic of collaboration. In this article (Collaboration: the art of letting go), Tobias explores this topic and doesn’t start with an explanation to what he thinks collaboration is- instead, he starts by offering specific examples of what collaboration is NOT. Perhaps, when it comes to exploring something that is commonly misunderstood or misused, then it might be better for us to start with first, defining what that ‘something’ isn’t. After all, we’re probably more likely to understand and resonate with something that we already recognise.

‘It is far from easy, and there is a great deal of mind-trickery that tells us we are collaborating when in fact we are coercing, manipulating, managing, shaping, colluding, controlling, seeking compliance and perhaps even sulking to get our own way. True collaboration is a rare bird of paradise, seldom seen, and when discovered often shot.’- Tobias Mayer

Starting my Scrum Master journey from being a Project Manager in software development and a Paratrooper before that, I have had to adjust quite a bit in terms of my mindset and what I originally thought a good facilitator should be doing. In the journey of me transitioning, I have learnt that facilitation for a Scrum Master is NOT:

• Typing and updating tickets in JIRA, Pivotal Tracker, or any other kind of software tool.
• Solely about facilitating at the team level, but also the Product Owner and those at the wider Organisation level.
• Telling a Scrum team what tools, techniques, methodologies and practices they should be using (suggestions for a team new to Scrum is fine).
• Being the one standing at the front and demonstrating the completed work during a Sprint Review.
• Creating a list of actions for a Scrum team based on your own interpretation of collected data from a Sprint during a Retrospective.
• Preaching about what it says in ‘The Scrum Guide’.
• Assigning tasks to members of the Scrum team.
• Being known as the note taker for the Scrum team.
• Just chit-chatting about the teams’ feelings during a Retrospective.
• Running Daily Scrums as if there were report meetings.
• Telling the Scrum team what their plan should be for improving.
• Have I mentioned what it says in the ‘The Scrum Guide?’

The ‘Scrum Master facilitation’ is NOT preaching about what it says in ‘The Scrum Guide’, I’d go as far in saying that I’d avoid dropping the words ‘The Scrum Guide’ or even ‘Agile’, from most interactions at work. Particularly when you’re trying to get a point across or explain something. That goes for the Scrum team, Product Owner or someone within the organisation and especially stakeholders. In my experience, nothing falls quicker on deaf ears than a preaching Scrum Master reciting words from a 19-page guide book. Instead, I’d recommend using a real-life example, some kind of story, a form of metaphor or analogy.

Neutral Position

Being a good facilitator is the bread and butter for any Scrum Master, part of the role is to service the Product Owner and Development Team by ‘Facilitating Scrum events as requested or needed’. Which sounds straight forward and in theory, it is since the outcomes from each of Scrum event in the Scrum Guide are clear. However, what I find interesting about the ‘Scrum Master facilitation is NOT solely about facilitating at the team level, but also the Product Owner and those at the wider Organisation level’, is that there are many circumstances when a Scrum Master might want to experiment and facilitate in a slightly different way (not just in the Scrum events), perhaps to incorporate a new, different activity or method to help reach a wider audience or to achieve a better outcome. I don’t see there being anything wrong in getting feedback on this either. I mean, in the spirit of modelling positive behaviour shouldn’t the act of experimentation be recognised as being part of a pragmatic approach to your efforts in becoming better in your role, isn’t that what you’d expect from a team too?

Scrum Masters shouldn’t just be facilitating the Scrum events, occasionally they will get asked to help facilitate something for the organisation, which could entail considerations such as:

• What are the desired outcomes?
• Who will be attending (C-Levels, Stakeholders, Investors)?
• Will any attendees be attending remotely?
• What are the attendees’ expectations?
• Who needs to know the results of the outcome?
• Where will it be held?
• What is the expected duration?

In addition to the Scrum events, what I think facilitation for a Scrum Master SHOULD be about:

• Ice-breaking activities for new teams or members.
• Integrating multiple frames of references.
• Nurturing relationships between team members, Product Owner and others within the organisation.
• Guiding structured discussions about product and processes.
• Assisting the team in divergent and convergent thinking.
• Aiding with conflict resolution.
• Group decision-making.
• Internal and external collaboration meetings.
• Applying basic ground rules in facilitation.
• Integrating Scrum into the organisation.

For me, facilitating as a Scrum Master is about staying in a neutral position, understanding the desired outcome of each event and being able to smoothly transition the team from A to B whilst keeping things on track, encouraging conversations to flow without letting things deviate too much from the desired outcome.

Facilitating Scrum Events

Some great examples of the type of characteristics that each Scrum event should have, I like what ‘Barry Overeem’ offers in his post The Scrum Master As A Facilitator. He describes the characteristics of well-facilitated Scrum events:

• The Daily Scrum contains an atmosphere where healthy peer pressure occurs on delivery quality, commitment and addressing impediments;
• The Sprint Planning is all about collaboration between the Product Owner and the Development team and has a strong focus on delivering business value. All team members understand the work and jointly agree to achieve the sprint goal;
• The Sprint Review is an energising event in which the Scrum team, sponsors and stakeholders together inspect the product increment and backlog. But also retrospect their collaboration and how this can be improved. They act as one team with the same purpose, there are no barriers between ‘client’ and ‘supplier’;
• The Retrospective is done in a safe atmosphere in which ‘the elephant in the room’ is addressed, discussed and turned into actionable improvements that the team members agree upon realising in the next sprint.

Psychological Environment

Coming back to ‘what isn’t always obvious are the types of obstacles (impediments) that prevent communication from working effectively and how facilitation can help’- one of the main challenges is usually the environment from a psychological perspective, it has to be psychologically safe. Not just that, if the culture of the organisation suffers from dysfunctions that diminish the levels of trust and respect needed for truthful conversations, then it is likely that part of this will have trickled down into the team layer level and could be embedded within the Scrum team. If that’s the case, then team members might not want to risk communicating what they think. I mean, who wants to suggest an idea and get laughed at, or not be taken seriously? Is it easier for team members to just to succumb to the HIPPO (highest paid person’s opinion) in the room, or conform to the most dominant member of the team for the sake of ease and conflict avoidance?

‘Positive emotions like trust, curiosity, confidence, and inspiration broaden the mind and help us build psychological, social, and physical resources. We become more open-minded, resilient, motivated, and persistent when we feel safe. Humour increases, as does solution-finding and divergent thinking — the cognitive process underlying creativity’.- Barbara L. Fredrickson

Physical Environment

Another impediment that could be preventing effective communication might be physically related, for example, air conditioning of the rooms, room size, lack of natural daylight, external noises and interferences, etc. Having distributed team members can also present challenges, although this might work well for some, others (probably most) find this difficult due to differences in time zones, lag time between responses and loss of information that usually gets subtly conveyed when speaking with someone face to face.

Biases & Negative Attitudes

Other impediments might be found more in the context of conversations, for example, the surfacing of preconceived notions, negative attitudes, assumptions, inferences and biases can all make achieving the desired outcome as a team difficult. I try and ‘spot the biases’, almost like a game that I play in my head. I consciously try and make an effort to be more attentive and aware of any judgements being made that are based on personal points of view (including my own). I observe and listen out for biases in conversations and in the decisions that are being made. To do this has meant that I have had to constantly remind myself, to be quiet and listen more, sometimes resist breaking silence (usually at the very point at which I want to speak up or intervene). For anyone who has ever met me, will know, that this is an achievement of itself. Here are a few biases that I typically come across or have otherwise just found interesting:

• Status quo bias The tendency to like things to stay relatively the same.
• The empathy gap The tendency to underestimate the influence or strength of feelings, in either oneself or others.
• Confirmation bias The tendency to search for, interpret, favour, and recall information in a way that confirms one’s pre-existing beliefs or hypotheses.
• IKEA effect The tendency for people to place a disproportionately high value on objects that they partially assembled themselves, such as furniture from IKEA, regardless of the quality of the end result.
• Irrational escalation The tendency to refer to a situation in which people can make irrational decisions based upon rational decisions in the past or to justify actions already taken.
• Dunning–Kruger effect The tendency for unskilled individuals to overestimate their own ability and the tendency for experts to underestimate their own ability.
• Focusing effect The tendency to place too much importance on one aspect of an event.
• Framing effect The tendency to react to a particular choice in different ways depending on how it is presented.
• Social desirability The tendency of survey respondents to answer questions in a manner that will be viewed favourably by others.
• Courtesy bias The tendency to give an opinion that is more socially correct than one’s true opinion, to avoid offending anyone.
• Knowledge bias The tendency to unknowingly assume that the others have the background to understand.
• The illusion of control The tendency to overestimate one’s degree of influence over other external events.
• Planning fallacy The tendency to underestimate task-completion times.

Not to worry too much about biases. I mean, we all have them at times and the science on this is clear- if you’re a human, then your brain operates through biases. Being aware and making the team aware of biases, assumptions (taking for granted things that are true, that have not yet been verified) and inferences (making a conclusions about things that are not known, based on something that is known), can help towards making sure that ‘value’ stays defined by the customer and that pointless, expensive, full-on features that are built just because we all assumed that we knew what the customer wanted. As a rule of thumb, in software development- customers don’t know what they want, they know what they want once you show to them.

Team Dysfunctions

By being that somebody (the facilitator) that’s in a neutral position, you’re in a far better position to be able to; observe the behaviours and interactions of the team, notice how each member communicates and whether they’re collaborating. Working on identifying and rectifying team dysfunctions based on Patrick Lencioni’s - The Five Dysfunctions of a Team, if you’re not already doing so, I’ve found that it’s a good place to start:

• Absence of Trust
• Fear of Conflict
• Lack of Commitment
• Avoidance of Accountability
• Inattention to Results

Language Difficulties (言語の問題)

There can be impediments associated with languages difficulties, regional dialects or proficiency in a certain language. Using jargon or slang words can sometimes be confusing for some people due to generation gaps. Not having enough common experiences can also limit somebody’s understanding of a discussion, especially if there are a lot of stories or examples that are frequently being used to convey information.

Conclusion

Being able to work as a team successfully will often come down to how well individuals on that team respond to the methods that the team are using to work together- these methods ideally should be reviewed and evaluated by the team regularly. To avoid biases and encourage engagement from everyone on the team to make effective group decisions, having someone in a neutral position to effectively facilitate this, helps ensure a smooth process and generally a much better outcome.

Having some basic ground rules when it comes to facilitating can help promote positive behaviours that should improve overall group discussions. These basic ground rules can act as a modelling tool to exhibit desired group behaviour, they can also help with knowing when to intervene as a facilitator, as you’re able to identify negative behaviours and general unhelpful group behaviour within the team- examples of some basic ground rules include:

• Test assumptions and Inferences.
• Keeps things transparent.
• Be specific.
• Explain reasoning and intent.
• Focus on the interests rather than positions (solutions).
• Combining advocacy and inquiry.
• Decisions should be made by the team.
• Agree to address (if necessary) any uncomfortable issues.
• Always strive to improve your facilitation skills.

Remember to get feedback on your facilitation, why not? Much like how a good agile team operates through the transparency of their work, inspecting product feedback and their processes regularly, then adapting to make improvements over time.

As usual, I’ve stumbled across a whole heap of great material whilst writing this, so if you’re after more information on the subject of facilitation, then I’d recommend checking these out:

• The Skilled Facilitator Field book - by Roger Schwarz
• Productive Conversations - Systems Thinker
• Tobias Mayer, untangler- Tobias Mayer
• The Five Dysfunctions of a Team - by Patrick Lencioni
• The Liberators- Barry Overeem
• Early Humans Used Brain Power, Innovation and Teamwork to Dominate the Planet - Scientific American
• Scrum Clinics - Tobias Mayer, Scrum Clinics

Like it or not, there is a lot of data that get’s generated throughout software development lifecycles. The metrics that an agile team chooses to use should help them shed some light on what might be happening, it can be an interesting way for a team to learn more about their systems and performance, and it forms part of an important aspect of experimentation.

Experimenting

As Jeff Sutherland may have once said ‘Reduced mental capacity caused by multitasking makes us erroneously think that we are crushin’ it, when we are actually losing focus and productivity.’- which may well be true. However, being solely focused on one thing, a ‘sprint goal’ for example, can without question contribute towards the success of that sprint goal. The price that’s paid for that specific, focused attention, even when there is flexibility in the implementation of functionality, it can still, at times cause blindness to everything else, as it can be too easy for us to get blinded by our desires which can end up hindering our ability to see things as they truly are.

Experimenting whilst things are going well might not seem all that necessary to most people. Imagine if our focus was solely that ‘sprint goal’ and nothing else matters, and that goal was being accomplished by the team at the end of each sprint- what would be the problem with that? Well, always getting what we set out to achieve could be blinding us to perhaps an even higher possible accomplishment? Also, if we’re getting nothing else but what we have set out to achieve, then what have we learnt? Can growing and learning be just as important as winning (accomplishing a sprint goal)? Isn’t there value in knowledge acquisition? It is during retrospectives where the results from experiments and recent performance can be analysed and discussed.

‘If you adopt only one agile practice, let it be retrospectives. Everything else will follow.’- Woody Zuill

For a software company that has teams with the odd certified ScrumMaster, Product Owner or a few Developers that are familiar with Kanban, Scrum, XP, Lean-Software.. a so called ‘agile’ team is far less valuable than a team of actual agile thinkers- ones that have an understanding of the principles behind agile and lean, that are empowered to question everything, and have the ability to experiment without the fear of failing.

Who Wants To Be Measured?

The thought of being watched by someone or measured in some way, I think, it’s safe to say that a certain amount fear, or at least the feeling of slight apprehension can be found in all of us. Perhaps this derives from our childhood when our parents or primary care givers first start looking over us, observing us and our behaviour and teaching us right from wrong. As children in school we are measured by our grades, job searching involves us being measured against our competition and keeping a job involves us having our performance measured and reviewed over time, at least in some way or another. Does this help explain why there is rarely anyone on an agile team that ever gets excited about the thought of them or their work being measured? Well, in this post I’ll be exploring team level metrics, metrics that should be chosen by the team and analysed by the team based on what they think is relevant and useful.

Metrics can help us make better sense of what has happened or what is actually going on right now, particularly if you’re looking at a metric that’s a leading indicator like the work in progress (WIP). And a lot can be said about having a sense of understanding. I mean, there is nothing simple and straight forward in software development, it seems it’s a complex environment with a default setting of chaos. Therefore, we have to try to make sense of things that we think are important, being stressed at work or because of work can be a serious problem. Failing to come to grips with (someone or something) could cause us to suffer from all sorts of psychological effects overtime by provoking anxiety and depression.

‘The way in which we’re constructed neurophysiologically, we don’t experience any positive emotion unless, we have an aim, and we can see ourselves progressing towards that aim, and it isn’t obtaining the aim that makes us happy, it’s pursuing it.’- Jordan B Peterson

What Are Useful Metrics?

The right choice of metrics to use depends on the team and context, so not all metrics are necessarily going to be useful- in fact, sometimes they can be dangerous. In terms of metrics at a team level, they can be used to measure anything that the team think is relevant in helping them identify improvements, as it can provide them with additional information on; their experiments, results from adjustments made in their behaviour, track their progress towards goals and can even help prepare for the future- it should really come down to what the team find out to be useful.

‘Individuals can make a difference, but it takes a team to really mess things up.’

Typical Agile Metrics

It’s safe to say that most of the time, when you mention the words ‘Agile Metrics’, people tend to think of the following:

• Team Velocity
• Sprint Burndown
• Epic and Release Burndown
• Cumulative Flow
• Control Chart
• Lead Time
• Cycle time
• Work in Progress (WIP)

The data from an agile team will generally come from multiple different locations depending on the context of the team and how they are working. For example, they may use a project tracking tool such as: ‘JIRA’, ‘Pivotal Tracker’, ‘Rally’, ‘Asana’, or they might just be writing requirements on ‘Post-it Notes’, then plastering the notes on a wall. One of the best things about agile practices, I think, is that teams can move quickly within their own context, and utilise what is useful for them. If a team find it beneficial to use Post-it Notes on a wall for their product backlog items or requirements, then great, let’s get decorating. A team might even find that what they want to measure can’t be done with any of their system tools that they’re using, so they have to get creative, maybe some sort of mood board is required that they update manually to track their mood during a sprint?

Generally speaking there will be a whole list of different systems that are used by a team. Here are a few examples of systems that a team might use.

• Project Tracking (JIRA, Pivotal Tracker, Asana, Trello, Post-it Notes)
• Source Control (Github, Bitbucket, Subversion, Microsoft Team Foundation Server, Mercurial)
• Continuous Integration (Jenkins, Bamboo, Travis, Github, Circle CI)
• Deployment Tools (CodeDeploy, Capistrano, AWS CodeDeploy, Octopus Deploy, Distelli)
• Business Intelligence/Application Monitoring (NewRelic, LogicMonitor, Datadog, AppsDynamics, BMC Software)

Questions Based On Outputs:

• How often are we getting working software to our target environment?
• How many known bugs are there?
• What is our current velocity?
• Are we meeting our commitments?

Data from each of these systems, on their own can answer simple questions around specific outputs.

Questions Based On Outcomes:

• Are we making our process better?
• Are we delivering the right things?
• Are we making our product/service better?
• How good are our requirements?

As a whole, having all these systems and the data they produce forms the team’s system data collection. Having this collection of data allows the team to group together certain data group samples, enabling them to then have conversations around some of the bigger types of questions that are based on outcomes, rather than just outputs.

Effective Metrics

Defining effective and useful metrics can be tricky, and what metrics that might be useful for a team might not necessarily always stay useful overtime. Here are a few important aspects that are probably worth considering when it comes to choosing and defining a metric.

Contrast

We tend to understand things better when we can compare it to something that we already understand, this helps us form concepts in our mind based on our existing knowledge. An effective metric is one that is comparable to itself overtime, it wouldn’t be a good idea for example to compare team velocity from one team with another team.

Simplicity

Using too many metrics will quickly over complicate things. Less can often be more when it comes to maximising metrics, the easier it is for the team to understand what behavioural changes they can do to help influence that metric the better.

Affordable

What are the associated costs in gathering metrics? It may be difficult to answer this exactly without measuring it, as we could be referring to ‘costs’, in terms of the amount work effort spent on gathering metric data, or ‘costs’, could also derive from paid software tools, like the software that is actually gathering the data for us. Therefore, as a rule of thumb- would it be sensible to say that, the possible value of improvement that can be gained from a metric shouldn’t exceed the costs of collecting it.

Team Level

Meaning that the metrics used should be chosen by the team for team, and if additional metrics on a organisation level are required, then there should be a separation, or at least an agreement in what that is exactly. I mean, nothing wrong with showing off your metrics externally, who knows- the team and other people in the organisation might even start mingling, sharing ideas and having deeper conversations around each others metrics?! Just be cautious of any stakeholders wanting to utilise any of the team metrics without fully understanding the context behind them.

‘Managers who don’t know how to measure what they want settle for wanting what they can measure.’- Russell L. Ackoff

Actionable

An effective metric should be specific enough and not just document the current state of the existing product or service, but offer insights into understanding where the team are, so that they can have conversations around where or what to do next, I mean, why else measure things that you can’t do anything about?

Truthful

There wouldn’t be much point in relying on data output from a system, if the input data wasn’t true or accurate. I’ve found that it can be useful for a team to discuss and agree on how exactly they intend to input data into each of their systems, and then make it part of their team working agreements. That way they can hold each other accountable for any deviation. Sometimes you can’t always measure what you want (true metric), so you settle for what you can measure (proxy metric), the important thing is to understand the two. Imagine an organisation that wanted to increase their online presence and be popular across all their social media channels. One metric could be to measure how many followers they get. But it wouldn’t be a true metric if a click farm was used to obtain all those followers. The take away from this is to be aware of what is it exactly that you’re measuring, and the impact of what might occur as a result of choosing it as a metric.

‘Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.’- Charles Goodhart, or in other words and more simply put by Marilyn Strathern ‘When a measure becomes a target, it ceases to be a good measure.’

Conclusion

I think for any agile team, it is essential to spend time in not only establishing the metrics that matter most to the team, but also to always ask questions and not to hold back when it comes to experimenting, particularly if the evaluated effort involved in running the experiment doesn’t out way the potential reward. Accept that each team will vary in what metrics are beneficial for them, for example, some teams in a certain situation might just need to focus on a leading indicator metric like their WIP. By limiting their work in progress might free them up enough so that they can start looking at other areas.

As usual I’ve stumbled across some great material whilst writing this, so if you’re after more information on the subject of agile metrics, how to focus on value, human behaviour from a psychological perspective and chaos in general, then I’d recommend checking these out:

• Chaos: Making a New Science - by ‘James Gleick’
• Practical Kanban: From Team Focus to Creating Value - by ‘Klaus Leopold’
• Lean Organization: from the Tools of the Toyota Production System to Lean Office - by ‘Andrea Chiarini’
• jordanbpeterson.com- Dr Jordan B Perterson
• robertsapolskyrocks.com - ‘Robert Morris Sapolsky’

If behavioural diversity can cause conflict, then does that mean ‘conflict’ is bad? Do ‘behaviour’ and ‘personality type’ assessments really help us gauge an understanding of ourselves and others? And can human social behaviour even be straight forward to understand?

Is ‘conflict’ all that bad?

Almost all teams will experience some form of conflict sooner or later, and in some cases, particularly in a scrum team conflict amongst the team can even be desirable, so long as the conflicts that occur have a positive outcome. If the individuals on team are aware of their team members behavioural differences, and they all use a style to communicate that allows them to fully express their opinion without causing others to get stressed or take offence, then there should be some positive outcomes, some of which might include:  

• Concerns are raised sooner rather than later
• Improvement to the quality of how decisions are made
• Create an environment suitable for the free flow of meaning (conversation)
• Broaden the discussions to a wider audience by effectively engaging others
• Enhance team cohesiveness
• Consideration of a broader range of ideas
• Surfacing of assumptions that might not be correct

Most conflicts that occur in an agile team tend to be resolved with a positive outcome, but there is a chance that conflict has a negative outcome. Some examples of negative outcomes might lead to:

• Lack of engagement with each other
• Hesitation in suggesting new ideas
• Delay in informing others of information
• Dips in productivity
• Increase in stress and anxiety

Assessing Behaviour & Personality Types

There are many models that can be used to identify behaviour and personality types, organisations as well as some agile teams, often utilise these models for recruitment, team member/employee evaluations, and even for further career development purposes. Some of the most commonly used models include:

MBTI Myer-Briggs Type Indicator

MBTI is definitely one of the most popular personality assessments. Created by ‘Katherine Briggs’ and daughter ‘Isabel Myers’. It’s based on Carl Jung’s idea that people understood the world through: sensation, intuition, feeling and thinking.

DISC Assessment

This one is based on the ideas of ‘William Marston’ and ‘Walter Clarke’, it evaluates behaviour. Identifying the traits of: dominance, inducement, submission, and compliance.

Holtzman Inkblot Technique

Assesses the personalities with the use of ink blots, and specific criteria such as: rejection, reaction time, place, and space.

PCM Process Communication Model

Originally developed by NASA, utilised to assess and screen their astronauts. It identifies personal strengths by grouping people into six personality types: harmonisers, thinkers, rebels, imagineers, persisters, or promoters.

When people participant in a behaviour or personality assessment, in most cases, they will admit that they are intrigued to see their results. What I find interesting is that we use these types of models to help us understand, we often like the ‘cause and effect’ paradigm way of thinking, after all, we like it when things make sense. But how much do these models really tell us about ourselves, others and human social behaviour in general?

“We are in a far better position to observe instincts in animals or in primitives than in ourselves. This is due to the fact that we have grown accustomed to scrutinising our own actions and to seeking rational explanations for them.” Carl Jung

It’s Not Complicated

When entering the realm of understanding human social behaviour, most people would argue that it is a complex subject. If it was complicated, for example: like a watch, the components could be dismantled, but we’d know that the sum total of all those components would be equal to that watch. Therefore, if the components were to be reassembled correctly, then it would become that same functioning watch that we dismantled in the first place. Instead, human social behaviour doesn’t always seem to be that straight forward, and can, at times appear to be totally unpredictable, resembling that of a complex system, a bit like the financial markets, or the rain forest.

Why Did The Chicken Cross The Road?

What makes the subject of human social behaviour even more difficult to simplify, is that it has a lot to do with how we think, for example asking, “why did the chicken cross the road?” The amount of different responses to this question alone demonstrates, that there can be many answers, some of them quite plausible, some even funny?! The answers given tend to be based on the perspective and understanding of the person providing the answer, but is that not how we approach and answer every question we are asked?

According to American neuroendocrinologist, and Stanford university professor ‘Robert Sapolsky’, he explains, that we tend to think categorically and he uses the term ‘thinking in buckets’, meaning that we get a better understanding of something if we can compare, or reference it to something that we already know. He continues to explain: ‘Suppose there’s a rooster standing next to you, and there’s a chicken across the street. The rooster gives a sexual gesture that is hot by chicken standards, and she promptly runs over to mate with him (I haven’t a clue if this is how it works, but let’s just suppose). And thus we have a key behavioural biological question-why did the chicken cross the road? And if you’re a psychoneuroendocrinologist, your answer would be “Because circulating estrogen levels in that chicken worked in a certain part of her brain to make her responsive to this male signalling,” and if you’re a bio-engineer, the answer would be “Because the long bone in the leg of the chicken forms a fulcrum for her pelvis (or some such thing), allowing her to move forward rapidly,” and if you’re an evolutionary biologist, you’d say, “Because over the course of millions of years, chickens that responded to such gestures at a time that they were fertile left more copies of their genes, and thus this is now an innate behaviour in chickens,”. I asked my 3 year old niece why she thought the chicken crossed the road?, she replied ‘because the lollypop lady said it was ok’. It goes to show, that thinking in categories, even across different scientific disciplines, can result in there being many alternative, acceptable explanations.

Conclusion

I think for any agile team, it is definitely worthwhile spending time in, not only establishing the most appropriate communication framework for your team, but also spending time to evaluate and gain insights into the behavioural differences of each of the team members. Accept that the human social behaviour is a complex subject, and there can always be times where actions of others may appear to be unexpected, or even out of character. But when team members understand and accept the behavioural differences in themselves, as well as others, then an increase of team performance and communication can be achieved. I stumbled across some great material whilst writing this, so if you’re after more information on this subject, then I’d recommend checking these out:

• The Oxford Handbook of Sport and Performance Psychology - by ‘Shane M. Murphy’
• Individuals and Interactions, An Agile Guide - by ‘Ken Howard’ & ‘Barry Rogers’
• Chaos, Making a New Science - by ‘James Gleick’
• Behave, The Biology of Humans at Our Best and Worst - by ‘Robert M Sapolsky’
• robertsapolskyrocks.com - ‘Robert Morris Sapolsky’

The single biggest assumption made when building software is that the requirements (features) that get created are the right ones. Here are some things to consider that I think can help counteract this problem. First of all, always ask and understand ‘Where are the requirements (features) actually coming from?’, ‘What will be the cost of delay?’’, What might be the impact of delivering a useless feature?, and be mindful of ‘Confirmation Bias’.

The word itself ‘requirement’, implies that it is something that is needed. I mentioned this in a previous post, that there are many cases where the customer comes first, but when it comes to ideas about product functionality, I’m afraid the ‘customer’ isn’t always right. In fact, their ideas are often bad ones. They may ask for AI shooting drones with lasers, but users don’t know what they want, they know what they want once you’ve built it for them. If the requirements (features) are coming from someone within the organisation, then how has it been decided that these are actual requirements (features)? As ‘Kent Beck’ (the founder of Extreme Programming) puts it ‘Software development has been steered wrong by the word ‘requirement’ defined in the dictionary as “Something mandatory or obligatory”. The word carries a connotation of absolution and permanence, inhibitors to embracing change. And the word ‘requirement’ is just plain wrong’. Based on the research shown in the 2015 CHOAS report, it suggests that even if projects were considered successful (delivered on time, in scope and within budget), only two thirds of the features provide value. Considering that the success of software is determined by the actual outcomes, and impact the software has after it has been delivered, then to me, it’s all the more reason to use an experimental approach in product delivery. Agile in the short sense of the word, just means fast, so delivery wants to be fast in this case because, the requirements (features) need to be validated to a certain degree first in order to make sure that they are, in fact providing value. Then investing more time and effort can be rightly justified.

Confirmation Bias

Confirmation Bias is something to be mindful of, an example of this could be: Imagine you send a message to someone you know, a few days go by, and you haven’t heard a response from them. Without meaning to, you may start to find yourself jumping to conclusions in thinking that this person is deliberately ignoring you. The problem with this, is that after a while you can start to convince yourself that this is in fact true. Confirmation Bias occurs from the direct influence of desire on beliefs. When we want a certain hypothesis to be true, or we believe a certain feature will bring x amount of value, we can end up believing it to be true before it’s actually been proven. This error leads to us to stop gathering information when the evidence gathered so far confirms the views one would like to be true.

Cost Of Delay & Delivering Useless Features

Precious time can be lost when analysing a proposed requirement, this tends to be a common problem found when scaling agile with the organisation having a heavy governance that want to spend their time and focus on estimating costs before any work starts. Although estimated costs are important factor to consider, I think it is far more important to understand if whatever it is that is being built, is in fact even going to be used by the end user. As far as costs are concerned, what about the often overlooked cost of delay, and the cost associated with delivering features that provides 0 value, or worse, a negative value! Cost of delay combines urgency and value, these are generally two things that we are not very good at distinguishing between. To help make better decisions, we need to understand not just how valuable something is, but how urgent it is. I think it’s worth considering this: Every time a feature (valuable or not) is implemented it adds complexity, this then requires time and effort to test and maintain. The more complexity that is added to a system, then the harder it becomes to add more features. Loss of opportunity costs from not delivering a feature that could have actually brought value. Reputation costs from delivering a feature with negative value

Conclusions

When it comes to defining requirements (features), I think it works best when you’re able to involve the entire team, they should be aware of the big picture and desired outcomes. A popular template used for writing story titles is: ‘As a [persona], I want [to perform some action], so that I get [some benefit]’, and an interesting alternative to this is an idea by ‘Jeff Gothelf’ who has a great template for writing tactical hypothesis statements in his book Lean UX: ‘We believe that we will achieve [KPI] if [persona] will attain [user goal] with [feature].’ If you’re going to make assumptions, then assume that the chances are high that the requirements (features) being built are wrong. Consider the consequences of delivering useless requirements (features). An interesting article by ‘David Mierke’ 3 Reasons You Can’t Just Ask Customers What They Want Agile in the short sense of the word, just means fast. It has to be quick and economical to deliver small vertical slices of work frequently, so that we can learn how we can improve, not just in the way we work, but to create feedback loops so that it can help us validate what is being built.

Food for thought for your next retrospective.

Better Questions

Progress usually starts with asking questions, questions that lead to a better understanding: ‘What went well in the last Sprint?’, ‘Was the expected work completed, if not why?’ or if the Sprint goal(s) weren’t met the team will be keen to ask ‘How did this happen?’, ‘How can we stop this from happening again?’, ‘How can we improve?’. All these types of questions play a key part in convincing ourselves, and others to consider change. They say it’s important to review quantitative and qualitative data, I think Agile metrics deserves it’s own post so I’ll stay focused on the non-numerical data for now. I believe the best place to start and first thing to consider, is be genuinely interested and listen to others when they respond to a question, as this shows mutual respect, and can help towards creating a safe environment for conversation.

Assumptions Holding Us Back

I’d also be mindful of the fact that sometimes when it comes to generating insights and ideas for change, people can often hold back because of their assumptions. Examples of this can be seen when people works within a big organisation and they assume that because they are just one of many other employees, that their ideas and opinions won’t make a difference. Another example, could be when people assume that if an idea of theirs is considered a bad one, then they might get laughed at. People sometimes hold back on putting forward an idea, simply because they assume that they’ll just be creating additional work effort for themselves, and will be made responsible of making that idea work. All of the above examples probably go unnoticed more so in larger organisations, especially when there can be a lot of employees that have been there for a long time. They may of course be those employees that want to just show up at work, do their job (or at least what they are used to doing), get paid, then go home. In a Scrum team, due to the nature of the team working so cohesively, constantly inspecting and adapting the way they work to improve. It ends being noticeable straight away if a team member doesn’t share the same mindset as everyone else on the team. Scrum teams should feel empowered to contribute towards ideas for change without any negative assumptions, it should be in their vested interest to succeed, since they all share the responsibility for improvement.

Avoid ‘Dumb’ Incentives

Setting commitments and reviewing previous commitments are often overlooked, but are an important aspect of the retrospective. When we set commitments that are exciting to us and we believe that they are attainable, then it can become extremely motivating for us to want to take action towards that desired commitment. However, I don’t think it is a good idea to attempt to incentivise members of any Agile team by way of offering financial reward, or any reward in fact, just for carrying out what is expected from them in terms of their job duties. Overtime, this will contribute towards them only producing what is needed in order to obtain that reward. If incentives of any kind are to be rewarded, then I think they should be based on the successful achievements of the team or organisation, and not the individual.

It Has Always Been Done That Way

Rules and procedures are often in place to help us, they help us they stop us from having to think. But in some cases they can help stop disasters from happening. Providing the rules are stuck to, and procedures are followed, then a fairly consistent output can be expected, which decreases the risk of disasters from happening. However, they can also contribute towards shaping the culture of an organisation. On occasion, when rules and procedures get in the way and prevent possible improvements from happening, then they should be challenged and evaluated. Understandably some rules may need to be in place due to legislation or compliance. But have you ever questioned ‘why’ something is done within an organisation a particular way because you don’t fully understand why it is done that way? Only to get a response like ‘I’m not entirely sure, we’ve just always done it that way’. When an idea for improvement is challenged by something that has always been done a certain way, you might just want to check to see if it is actually required? Does it need to be performed as it is, or can there be room for negotiating a better solution?

Conclusion

Ask better questions, challenge rules and procedures that prohibit improvements, experiment and avoid dumb incentives. For more reading on agile retrospectives I’d highly recommend checking out Agile Retrospectives - Making Good Teams Great’ by ‘Esther Derby’ and ‘Diana Larsen’

Software development, is not just about developing software, or at least it shouldn’t be. Software development tends to have a lot of focus on output, and when I say the word ‘output’, I’m talking about ‘velocity’ (the amount of work getting done over time), deliverables, requirements etc. All of the outputs from development. And you may hear things like delivering shippable software fast is good, and that having a consistent velocity is great. But be careful, you don’t want to start thinking that the sole aim is to just get requirements from the end user, so that the quicker you can design, build, test and ship those requirements. Unfortunately, there is (or at least there should be) a little more to it than that. It’s the feedback that is useful, not just collecting requirements for the sake of it. Successful software is ultimately determined not by outputs, or how quickly requirements can be delivered, but by the actual outcomes and impact the software has after it has been delivered.

It All Starts With People and Ideas

When It comes to building software products or services it all starts with people and ideas, ideas about how people are going to use the product or service to get some form of benefit. There are many cases where the customer comes first, but when it comes to ideas about product functionality, I’m afraid the ‘customer’ isn’t always right. In fact, their ideas are often bad ones. Here’s an Example: Let’s say there is a software product (system) that is being used by a company to help them take stock of their inventory. Each time a new stock item arrives the employees type the stocks details into the system. The employees of the company start to complain to management that when they are making data entries into the system, it’s laborious and annoying for them because the system is old and slow. When asking the employees or even management for suggestions on possible solutions for this problem, their ideas are often just based on having a better version of that current product, which might not necessarily be the best viable solution. If a company is using software as a tool, then overtime it can play a big part in influencing or shaping the way in which they work. Resulting in them getting stuck into thinking that the way in which they work, has to match that of the existing technology and capabilities of the product that they’re already using. In this example the problem is being framed as ‘the system is old and slow’, therefore the suggested solution might be to ‘update the system to make it faster’. However, by reframing the problem to ‘when updating the system with new inventory data, it’s laborious and annoying’ then it generates alternative solutions, like ‘make new data entries automated’. This may explain why (not always), but it is often the software developers that come up with the best viable solutions, since they are aware of the technical possibilities.

Sorting The Good Ideas From The Bad Ones

It is not just customers or end users that have ideas about desired product functionality, ideas can come from stakeholders, developers, testers, business analysts, shareholders, etc. the list goes on. How to establish what should be built, this task often falls on the shoulders of the product owner, it is their responsibility to have a vision of what it is to be build, and convey that vision to the team building it. More importantly they need to sort the good ideas, from the bad ideas. This is done by them finding a sweet spot that sits in the middle between what is ‘Valuable’, ‘Usable’, and ‘Feasible’. For example it isn’t much use having a great idea for an amazing solution, if it’s too expensive, or a solution that solves the problem, but is too complex for anyone to use. Therefore, messing this ratio up to get too much of one, and not enough of the other, then there is high chance of failure. This is why it pays to to keep a regular, short feedback loop from the customers and end users, so that the solutions (or part of them) that are being built can be validated. Remember it’s only really after seeing the outcomes that you’ll understand the actual value.

That’s Not What We Were Expecting

In software development it is often expected (certainly by the teams building them) that the features or ideas about product functionality can frequently change. Which might explain why ‘Accommodate changing requirements throughout the development process’ is one of the twelve Agile Manifesto Principles. That being said, there are cases where we would deliberately want to introduce uncertainty into estimating on features that we’re not 100% sure of. And the reason for this is, that we simply need validation on the parts that we have done so far before going any further. But it can be a common mistake to fall into thinking that because there is a high chance of change, then there is isn’t much point in listing all the requirements for a feature. As a result, this can produce a less than desirable outcome, a low quality version of what was expected, and introduce potential rework. When writing the acceptance criteria for a feature, I’d suggest to always base them on all of the information that you have at that time, and ensure that the expectancy levels are always clear, to the team, to stakeholders and to the customers.

Conclusion

To help avoid a lot of these types of problems and build better software, then the time should be spent focusing on solving or providing the right solution. It’s not just a case of delivering requirements fast or even failing fast, it should be more about learning fast. Try and better understand the end users behaviours and patterns of working. When it comes to defining the requirements, if there is ambiguity when writing an acceptance criteria for a feature, then perhaps a better understanding of that feature is needed. The acceptance criteria for a feature should be based on the information that you have at that time, but make sure those expectancy levels are always clear. Another way to help get better solutions is to get the team using user stories as a way to describe product functionality, user stories are by far the most popular method used within software development to describe desired functionality, and a great way to understand the who, what and why. They help with being able to stay in the mindsets of the end users, but how ‘user stories’ are used can be easily misunderstood. The real benefit of using them comes from how they are created by using conversations, rather than how they are actually written. For more reading on ‘User Stories & User Story Mapping’, check out ‘User Stories and User Story Examples’ by Mike Cohn, and even though Mike and Jeff may not see eye to eye, another good recommendation would be ‘User Story Mapping’ by Jeff Patton.

Firstly, the journey in building a high performing agile team relies on many things, and isn’t something that turns out well when it is rushed. It depends on many influencing factors, some of those being: Skills and abilities, attitudes and mindsets, good processes coupled with the right guidance etc. And there can often be outside influences that can act as opposing factors too, such as: Company culture, other areas of the business that may not be aligned with agile methods. There may also be a strong PMO, or governance in place that impacts on how agile is being adopted. This is especially noticeable if an organisation works within a regulated industry, as there may be many bureaucracy hoops that need to be jumped through in order to maintain compliance.

Before going any further, I’d like to briefly explain what I’m referring to when I say ‘high performing agile team’ I like the definition that Keith Cerny’s has used on his blog post which is: “A high performance Agile team is a committed team that has the right people, has been effectively empowered, has established trust, adheres to an effective process, works at a sustainable pace to deliver quality software of a quantity that reflects a consistent high velocity and factors in influences like capacity and support.” Let’s jump straight in, here are just some thoughts and suggestions on what can help contribute towards establishing a high performing agile team, and where I think is a good place to start, and it is based on what has worked well for me, and for the teams that I’ve worked with.

Where to Start

Whatever the opposing factors might be that are getting in your way to achieving a high performing agile team, I think the best place to start is with what you can influence, and what better place than us, the people. Agile teams require constant improvement along the way, working alongside each team member during this process is a must. Although people are notorious for being the biggest problem in most things, let alone an agile team. In fact, I’m convinced that anywhere where there are people, there will be problems! ‘Let’s get rid of them?’ ‘wrong!’ People are essential and they’re also the most valuable asset! Therefore, they need to be treated as such, be appreciated for their skills, including whatever else they’re able to bring to the table as an individual, and as a team member. In order to assist and help build agile teams to reach their full potential, they’ll need to be monitored and be provided with feedback in a way that works best for them, so they can see where they can improve. I think it’s important to note that, the better you understand each team members level of expertise, who they are as a person, and the more you listen to their ideas on how they think they can grow and improve, then the more successful you’ll be at this.

Downside of Collaboration

Yes, the title of this paragraph is correct! There is a strong emphasis on collaboration with agile, and for good reason as it forms an essential part of adopting agile successfully. One of main benefits is that it saves a lot of time, and provides an overall smoother process. However, it does have a downside, which is that conflicting views and options tend to flare up a lot quicker than they normally would do. This can be problematic if the communication is being done in an environment that isn’t safe. Let me explain, in order to have a ‘safe’ environment that allows for healthy conversation (dialogue with the free flow of meaning), then it’s essential that it is safe to do so. When it becomes unsafe, then you’ll start seeing people show patterns of stress. These can be in the form of people raising their voice, shouting, interrupting others when they are speaking, etc. Or it can go the complete opposite side of the spectrum, whereby people start turning to silence and stop speaking all together. Conflicts between team members, or team members and other people within the organisation can really hold the team back.

Improve Collaboration with Better Communication

If regular conflicts is an issue, then I’d strongly suggest that you bring this awareness to the team, and/or organisation that so that a better communication strategy can be followed. I’d also start listening more, not just when being spoken to directly, but also how the team are speaking with each another, then you’ll start noticing signs of stress patterns when they occur. If it does happen, then the focus should be on who is speaking, evaluate the situation, see how they’re expressing themselves, and consider possible reasons as to why they’re showing signs of stress. It usually comes down to the context of the conversation with at least one of the three reasons below, or a combination of the three:

• High levels of emotional attachment

• Strong opposing opinions

• High level of risk involved

Pay attention to body language too and the tones of voices being used, are they uncomfortable, relaxed, angry, upset, excited? Just remember that before making any slight interventions, it’s important to get a good understanding of any differences before attempting to help get an agreeable solution. Again, focus on the person who’s speaking, and try to understand their needs and wants that are underlining what they’re saying without being biased. Ask clarifying questions or paraphrase what’s been said to help get a better understanding, this avoids you appearing to take sides.

There Should be Conversations

When it comes to listening to how the team are speaking with each other, I think there should always be some form of conversation flowing throughout the day. I feel reassured when I hear them in conversation, as it means that if/when there are problems then they’re more likely to tell each other about them. One of the best examples of this is during the daily Scrum (stand up), as it forces them to speak with one another. I’ve lost count how many times during a daily Scrum (stand up) that key dependencies have been identified, or problems have been brought up that other team members didn’t know about that should have, all because of a direct result of the team having a conversation. I mean if the team weren’t speaking with each other throughout the day, then I’d be worried, and concerned as this would be a strong indication that they’re not working as a team.

Conclusion

Being a good listener is a skill that you can learn (which I’m forever a student), but by listening respectfully it can show a level of care for the person that you’re talking and interacting with, this in turn can have an effect on how much they listen to you. When listing intently it can show that you actually care about their concerns, and that you’re generally interested in helping them, as a result when you provide any feedback to individuals or the team, then you’ll be much more influential and be in a far better position to make a positive, sustainable difference.

I think it’s quite evident that years ago in the 1940s and 50s, it was somewhat of a consumption economy driven period. Companies would build and produce products and services, and the customers would then purchase them. The products and services that were produced back then, in comparison to today’s world, seem basic and almost rudimentary in design. Fast forward 40-50 years, and customers levels of expectation have gone through the roof and still on a constant rise. Companies competing with one another, each trying to portray their product or services as being something more, something better. This time customers aren’t just purchasing a product or service, they’re getting the brand and the experience that comes with it. This experience driven world is very much among us, I mean we can see it everywhere we look as there are leading groups of brands in almost every industry. When we associate ourselves with brands, it can provide us with an experience and a sense of belonging - as customers and end users, are our levels of expectancy starting to outgrow the experience driven economy? Are the levels of expectancy growing to an extent that we now no longer just want a quality product with an experience, we want more, we want to be part of it and control it!

Listed below are just 5 ways that through using an agile approach to delivery, can help keep up with the high expectancy levels of today’s customers:

Delivering The Right Thing Fast

The benchmark for producing any quality software in today’s world is pretty high. It depends on being able to create and utilise a short feedback loop that is fed from various stakeholders, customers and end users. Implementing this feedback successfully will not only depend on having the right team in place, but also good guidance is required in order to form the development processes for the team to follow. Agile works best when there is flexibility coupled with lean processes, keeping what’s essential and get rid of anything else! Less time, less work effort, fewer costs, and the ability to deliver FAST without compromising on quality!

Taking Small Reversible Steps

Using engineering techniques such as ‘Test-driven Development’ (TDD), can be a great example. This is where the first test that is written fails, which is the expected result when using TDD since the tests for the code are written before the code itself. This helps in many ways, one of them is that it avoids a lot of potential regression issues, and can be used over time to help build a reliable test suite. ‘Pair Programming’ is another great example of a good engineering practice. This can be beneficial when there are new joiners to the team and they need to get up to speed. When delivering vertical slices (i.e. shippable software after each Sprint), it might be worth it to pair up back-end resources with the front end engineers to help ensure that full feature delivery is implemented correctly. Pair programming shouldn’t be thought of as the work effort of 2 people, but as the avoided rework of 4 people.

Increase Reliability

Customers and end users are becoming increasingly less tolerant of errors and crashes that can be found in software. Take mobile Apps for example, it’s often the case where if a user has downloaded an App but it keeps freezing, fails to work, or is just incredibly slow, then the user will just end up deleting the App and start searching for another alternative. Using agile frameworks such as ‘Scrum’, with its multiple cycles of building, testing and quality assurance, enables the App developers to build in more quality and reliability through planned repeated cycles of testing within each Sprint cycle.

Responsive to Technology Changes

Desktop and mobile technology such as, new operating systems, existing feature updates and enhancements all move at an extremely fast pace. Being agile can help keep up with this by welcoming changes to the project and in turn takes advantage of having frequent releases, with the added ability to pivot and change focus (if/when necessary) at the end of each Sprint. As a result, this makes it easier for new updates and enhancements to be introduced into a LIVE production environment, and can be much more responsive to these types of technology changes.

Iterating on Feedback

Combining the use of Sprints with the typical software update model of desktops and mobile Apps, means that comments about new features and enhancements gained from the feedback can be implemented easily. Agile enables the ability to keep a continuous process of iterating and updating, because the design, planning, development and testing (including against the compatibility of any old existing data) are all done within the Sprint cycle.

Conclusion

Just to end with a few thoughts about quality:

• Quality shouldn’t be an afterthought, think about quality from the get go. It should be getting baked in, not stuck on at the end.
• Never comprise on quality thinking it will save time, it always catches you up.
• Don’t just iterate on the feedback from the customers and end users, remember to keep the feedback loop short, regular and consistent. It’s no good providing the RIGHT solution at the WRONG time.

There are many contributing factors that need to go into to building great software, having reliable processes in place that support a consistent development pace is a good place to start. Working environments that encourage teams to improve their ways of working to get better results, can really help introduce quality and consistency into the products codebase. Seeing successful results from this sort of thing can be both positive and aesthetically pleasing. However, there is another important contributing factor that goes into to building great software - ‘ability to be able to recognise opportunities when they arise, and being agile enough to take advantage of them’.

Initial Investment of Time

The initial investment of time, cost and resources should be applied properly. Start by reviewing the requirements, then establish what the maximum amount of customer value that can be delivered using the minimum amount of work effort. This will produce quantifiable value immediately and will provide some early validation. The quickest way to do this is, ask the business to value their requirements relative to each other, then allow the team to estimate those items. After doing this, it will help with getting the bigger picture and understanding more about the scope from both; technical and business perspectives. Keep in mind that when the team do their estimations, avoid using absolute estimation (more on this topic in a separate article).

Change is Inevitable

Most, if not all projects have their good and nasty surprises throughout their life-cycles, this can make delivering projects exciting, challenging and rewarding. But, that can often depend on how well ‘change’ can be dealt with. Change is inevitable, in fact any project, in itself is just a mechanism to introduce change in some way or another. One of the twelve agile manifesto principles states ‘Accommodate changing requirements throughout the development process’, I don’t think that this statement is necessarily solely referring to the change requirements related to the product or service. I think it also includes the changes that get introduced that improve the way we work, this often comes from the outcome of a Sprint Retrospective (or at least it should be!), or through regularly reflecting on progress. Being able to welcome change when it occurs, helps enable the ability to be adaptable when it counts.

Where the Focus Should be

Delivering high quality value to the customers and end users should be the primary focus. It pays to actively seek feedback, and not just from stakeholders, customers and end users, but also from the team too. Getting this feedback early, and frequently will allow you, and the team to learn whilst enhancing your understanding of the problem that you’re all trying to solve. Always be on the lookout to take advantage from what you can learn from feedback (improvement changes for the product or service), and from the Retrospectives (improvement changes in the way the team work), and then pivot to change your direction accordingly.

Regularly Introduce Small Changes of Improvements

I spoke about this earlier, and I’m going to do it some more! Being able to effectively deal with change will soon show overtime that it can provide opportunities with positive outcomes, and limits the amount of re-work. It also aids towards revealing new opportunities when they appear. When you are regularly introducing small changes of improvements, then this makes ‘change’ itself easier to implement and adopt. Prime example, when a customer or Product Owner has a requirement that changes, or hasn’t been clearly defined.

Choosing the Sprint Cycles

I’d suggest trying to get those cycles between 2-3 weeks or less, as you want to shorten the feedback loop as much as possible. Plan to deliver work in vertical slices, i.e. shippable software at the end of each Sprint. That means that each vertical slice makes an independent user story, one that has pieces of layers in it that include: Database, API Logic, User Interface (UI). This forms together to become a fully functional feature. The planning, designing, testing and development all have to happen within the Sprint cycle. Therefore, make sure you choose the right Sprint cycles that is suitable for the scope, team and the organisation.

Conclusion

Work closely with the customers and end users to gain early feedback, use the approach of taking the small steps in delivery using vertical slices, focus on allocating resources at the start to deliver high valued items using minimum effort, and welcome change. This should all help towards reducing risk and costs - ultimately, taking advantage of being agile will increase the chances of delivering on time, and within budget. Most importantly you’ll be actually building the RIGHT product or service, one that suits the needs of the customers and end users. And when that happens, working on software projects become so much more enjoyable and rewarding.