Transparency is a central principle of agile working. However, the pursuit of transparency can physically manifest itself in many forms and they're not always necessarily good or useful. In practice I often see the two extremes of the spectrum, a total lack of transparency through to possible sensory overload from overly excessive, illy considered and poorly implemented visual management and other techniques.
The former is a case of flying blind without the ability to see how things stand, the current state of play, where we've been and where we might be heading. In an attempt to counter this teams often find themselves in the opposite space of flying blinded where there's just too much information and detail to absorb. The outcome though is similar, a lack of ability to see and understand where we are and what's going on around us.
Flying Blind
This scenario is pretty straightforward to spot. Take a walk into the team area, take a look around and there's probably not much to see. No visual indicators of what work is in progress or board to indicate the status of the work. Furthermore, there might not even be an electronic or tool based visualisation you can take a look at. The team are simply drifting along, although some of them may profess to have everything stored in their head.
"We don't need any boards or anything else, we know what's going on" they might say.
At the very least most members of this team probably have a unique interpretation of what's going on and of where things are heading.
Furthermore, in a wider context, the organisation also has little idea of what's going on. There's no view of work in the backlog, priorities, estimates, progress to date or anything else.
"You'll get it when you get it" is often the extent of any progress reporting in place. Sure, that may technically indeed be true although it's not particularly useful. In return I've seen organisations react to this by demanding all sorts of measures and artifacts, most of it as equally ill considered as providing no information at all; detailed backlogs, detailed story breakdowns, low level estimates for everything, burn-up, burn-downs, throughputs, task counts, actual vs forecast and just about anything else that can be fudged together.
If not able to effectively push back on this the team and organisation that's flying blind can quickly find themselves transitioning to flying blinded.
Flying Blinded
A team and organisation that's flying blinded still has little idea of what's going on. For the uninitiated this seems somewhat more difficult to spot, although seemingly obvious for the more experienced, or just half-thinking, practitioner.
Blind adherence and cargo-cult thinking are prime drivers in this area. "We're agile so we need our reporting represented on burn-down/up charts" or something similar will often be heard, even if it isn't clear what the charts are showing. I've seen all sorts of horror shows in action. Charts with more lines on it than a motorway atlas, a mixture of measuring units and indecipherable keys. As an aside, this is more often than not a case of using some electronic tool that automatically produces the chart and an example of putting rubbish data in and getting rubbish data out. The point stands though that such an artifact still tends to be published or provided to the organisation because that's what "agile reporting" looks like.
Another manifestation of flying blinded can be seen with a team task/scrum/kanban/anything-else board that tells you nothing much more than the number of different coloured index cards the team possesses. The point here is that the board is there primarily as an agile artifact, the team has one because "that's what agile teams do". If there's no real consideration behind what the board is displaying and how it is being used it will likely evolve into something that displays a bit of everything but doesn't really show anything. Anybody looking at such a board is likely to be blinded by detail and colour.
I have three simple principles and three rules for providing effective transparency:
- Principle 1 - You should be able to see what's been before.
- Principle 2 - You should be able to see what's currently under way.
- Principle 3 - You should be able to see what's possibly coming up next.
- Rule A - There should be a single source of truth for the above and everybody should know where to find it.
- Rule B - Anybody can quickly look at the information and figure out what they need to know without anybody else having to explain it to them.
- Rule C - The information should be value/business focused.
Transparency means that everyone involved needs a common understanding of what's going on in order to support decision making around optimising value and controlling risk. It's impossible for this to exist both in a state of total blindness and in a state of being blinded by over-powering and extraneous information.
It's time to push back against the "mavericks" who would wish to visualise and radiate nothing and time to sack off the cargo cult tendencies and requests of others. It's time to reclaim the middle ground and provide true transparency by the provision of information that is appropriate, easy to find, useful and value-adding. Sometimes less really is more!
Showing posts with label 3. Enabling Team Structure. Show all posts
Showing posts with label 3. Enabling Team Structure. Show all posts
Sunday, 18 December 2016
Tuesday, 28 July 2015
How Does Your Team Make Decisions?
I recently attended a talk by James Priest on the topic of Sociocracy 3.0, a collection of sociocratic patterns and practices for helping to steer and evolve organisations. At the heart of Sociocracy 3.0 is the concept of Consent Decision Making. It was discussion of this concept that got me thinking about how we work towards decisions in agile teams, the difficulties we experience and whether it’s time for a shift in how we think and work – a shift away from traditional consensus based decision making and towards a sociocratic consent based model.
I’ve seen many agile teams experience something which James Priest expressed as decision making by endurance. Teams locked in discussion, seemingly forever, in a quest to reach agreement on how to proceed or how to approach a particular problem. At best this can be tiring and frustrating, at worst it can be completely ineffective as teams look to minimise conflict in order to derive a consensus decision, giving rise to groupthink. Difficult and potentially valuable discussions are often dodged for the sake of coming to faster and easier group agreement.
Many agile teams describe themselves as consensus driven, they’ll even adopt tools such as fist of five voting. Indeed, Jean Tabaka (2006) lists consensus driven decision making as one of the characteristics that makes up a high performing team. It’s almost a given, even in the face of the issues above, that a consensus based model is the ideal way for teams to make decisions.
There’s another key issue that comes from consensus based thinking and one which is perhaps particularly worrying for agile teams. A decision making model based on consensus works towards agreement by the majority of the group. Innovation, on the other hand, often comes from the minority, with those willing to question the status quo and think about things in new ways. Striving for consensus arguably marginalises innovative thinking in favour of minimising disruption and going with the flow.
Consent decision making moves a team from a space of making decisions based on what is generally agreed to be acceptable to a model of only doing things if there is deemed to be no good reason not to do them. In other words it hands supremacy back to reason where a team works to decide not to do something only if it’s harmful to the flow of value.
Such an approach draws on the collective intelligence of the group, with the action of deliberately seeking objections helping to harvest information and identify misunderstandings early. It’s act that brings the team together, helps them to develop a shared understanding and to build an increased sense of accountability and engagement around their decisions. Consent decision making also keeps things moving forwards, avoiding the dreaded decision making by endurance, and aims to treat decisions as experiments. Those experiments should be good enough for now and safe enough to try, a tenet that supports the team’s ability to fail fast, to continuously learn and to pivot and adapt in response to that learning – their ability to be agile.
Key to enabling such a mechanism is the concept of equivalence. Equivalence is the state of being equivalent, having equal value and standing. In consent based decision making this means that everyone affected by a decision has the power to withdraw consent based on reasoned objection. Any team member has the power to raise an objection if they believe that what is proposed stands in the way of a more effective satisfaction of the driver. So how would this work in practice? Sociocracy 3.0 gives us a five step consent decision making process:
1. Present proposal (Driver)
2. Quick response and clarifying questions (is the proposal understood?)
3. Harvest objections (reasons not to follow proposal)
4. Integrate wisdom (amend proposal as necessary)
5. Test proposal, succeed, fail, celebrate!
Of course, this process needs to be carefully facilitated, ensuring a practical balance between equivalence and effectiveness and keeping the focus on the values of the team rather than those of individuals.
This five step process moves us towards the sociocratic principle of conscious collaboration. Rather than being unconsciously pulled along into suboptimal and under-considered decisions we’re now working together, from a position of equivalence, consciously searching for objections and seeking out decisions that are good enough for now and safe enough to try.
Is this something that could benefit your team? I’ll let you decide that for yourselves.
I’ve seen many agile teams experience something which James Priest expressed as decision making by endurance. Teams locked in discussion, seemingly forever, in a quest to reach agreement on how to proceed or how to approach a particular problem. At best this can be tiring and frustrating, at worst it can be completely ineffective as teams look to minimise conflict in order to derive a consensus decision, giving rise to groupthink. Difficult and potentially valuable discussions are often dodged for the sake of coming to faster and easier group agreement.
Many agile teams describe themselves as consensus driven, they’ll even adopt tools such as fist of five voting. Indeed, Jean Tabaka (2006) lists consensus driven decision making as one of the characteristics that makes up a high performing team. It’s almost a given, even in the face of the issues above, that a consensus based model is the ideal way for teams to make decisions.
There’s another key issue that comes from consensus based thinking and one which is perhaps particularly worrying for agile teams. A decision making model based on consensus works towards agreement by the majority of the group. Innovation, on the other hand, often comes from the minority, with those willing to question the status quo and think about things in new ways. Striving for consensus arguably marginalises innovative thinking in favour of minimising disruption and going with the flow.
Consent decision making moves a team from a space of making decisions based on what is generally agreed to be acceptable to a model of only doing things if there is deemed to be no good reason not to do them. In other words it hands supremacy back to reason where a team works to decide not to do something only if it’s harmful to the flow of value.
Such an approach draws on the collective intelligence of the group, with the action of deliberately seeking objections helping to harvest information and identify misunderstandings early. It’s act that brings the team together, helps them to develop a shared understanding and to build an increased sense of accountability and engagement around their decisions. Consent decision making also keeps things moving forwards, avoiding the dreaded decision making by endurance, and aims to treat decisions as experiments. Those experiments should be good enough for now and safe enough to try, a tenet that supports the team’s ability to fail fast, to continuously learn and to pivot and adapt in response to that learning – their ability to be agile.
Key to enabling such a mechanism is the concept of equivalence. Equivalence is the state of being equivalent, having equal value and standing. In consent based decision making this means that everyone affected by a decision has the power to withdraw consent based on reasoned objection. Any team member has the power to raise an objection if they believe that what is proposed stands in the way of a more effective satisfaction of the driver. So how would this work in practice? Sociocracy 3.0 gives us a five step consent decision making process:
1. Present proposal (Driver)
2. Quick response and clarifying questions (is the proposal understood?)
3. Harvest objections (reasons not to follow proposal)
4. Integrate wisdom (amend proposal as necessary)
5. Test proposal, succeed, fail, celebrate!
Of course, this process needs to be carefully facilitated, ensuring a practical balance between equivalence and effectiveness and keeping the focus on the values of the team rather than those of individuals.
This five step process moves us towards the sociocratic principle of conscious collaboration. Rather than being unconsciously pulled along into suboptimal and under-considered decisions we’re now working together, from a position of equivalence, consciously searching for objections and seeking out decisions that are good enough for now and safe enough to try.
Is this something that could benefit your team? I’ll let you decide that for yourselves.
Monday, 13 October 2014
Don't Ignore the Good Stuff
When it comes to retrospectives many of the teams I encounter use them to focus on problems. Although the aim of regular reflection is to support the continuous improvement of the team, this doesn't and shouldn't mean only focusing on things that aren't working. When it comes to ensuring a focus on what's working well I've observed three main behaviours:
1. Ignoring the good
In my experience focusing solely on problems can lead to retrospectives becoming tainted. They can become a session that the team identifies with negativity, leading to low energy and demotivating sessions. In the longer term a reluctance to attend and fully engage in such sessions may emerge, or even a lower team energy and morale level in general.
So, not just focusing on problems should seem obvious, it's depressing and potentially damaging.
2. Acknowledging the good
In recognition of the above some teams move into this category and will take time in their retrospectives to acknowledge things that are working well. So in collecting their retrospective data these teams will also note their successes and things that have made them happy.
This is a good start although sadly it's also where some teams stop. Acknowledging success is a good thing and can help prevent some of the problems associated with demotivation etc but on it's own it isn't enough. To fully benefit as team we need to move beyond just acknowledging the good and into the realm of understanding the good.
3. Understanding the good
Teams in this category are committed to moving themselves forward by not just understanding what isn't working well but also taking time to understand the reasons behind the things that are working well. It may seem obvious but just because something has worked well in the past doesn't mean that it will continue to work well into the future. The previous occurrence may be the result of a certain set of circumstances or conditions that fortuitously came together in a particular moment of time.
If we can understand why something happened then we're going to better positioned to try to ensure that it continues to happen going forwards. So if that something is a good thing, something that is positive for the team then it's important that we try to keep hold of it.
When moving into generating insights on collected data, don't ignore the good stuff. Spend time generating insights into that stuff also, build an understanding around it and build the ability to hold onto it and enable it going forwards.
So don't ignore the good stuff. At the very least acknowledge it. Ideally though work to understand it, keep sight of it and continue to benefit from it.
Wednesday, 13 August 2014
Improvement Mapping: Using Visualisation to Support Continuous Improvement
Visualisation is a powerful technique. In all walks of life it can aid us in achieving many things, in directing our thoughts, in becoming better at what we do and working towards our goals. Visualisation is often a mental technique but we can also use it in a more practical and physical sense. It's this practical visualisation which I explore here in terms of supporting a team's continuous improvement.
One thing I've often wondered about over the years when working with Scrum teams is how best to keep track of the agreed improvements that come out of retrospective sessions, in terms of things we've tried and their effectiveness or otherwise. How do we keep track of the possible improvements which we think might be useful, but which we won't yet implement?
At the most basic level we can include a review of the most recently agreed improvements at the beginning of each retrospective, we can keep the things that worked and ditch the things that didn't. Going forwards we can maintain a list of those things so that we can revisit and consider as appropriate to support our continuous improvement.
Long lists can be hard work and difficult to interpret though, and they're never very engaging. So I wonder whether there's a better way, a way which quickly enables the team to visualise improvements, things they've tried, things that worked and things that didn't. A way that helps increase the team's understanding of how their process is evolving. Moreover, can that increased visualisation and improved understanding be used to support a greater buy in and ownership of their process?
Impact mapping is an emerging tool used to help visualise and shape what's being developed my mapping outputs back to outcomes, i.e. features back to the required impact/value. Gojko Adzic describes impact mapping as follows:
"Impact mapping can help you build products and deliver projects that make an impact, not just ship software. Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and makes better roadmap decisions"
If we can map and visualise product deliverables back to their impact then is it also possible to map process changes back to impacts? In line with the above definition could this help us align our team activities against the overall objective of continuous process improvement?
Another pattern which I've often observed in retrospectives is a focus on the negative, or a sole focus on trying to fix the things which aren't working so well. An effect of this is that teams can often lose sight of understanding what's working well and, more importantly, why those things are working well.
Ed Catmull in his recent book, Creativity Inc, describes how one of the core principles at Pixar Animation is to understand what works well as part of making any particular film. Not just noting the 'what' but truly exploring the underlying factors that enabled that success. If we can understand something then we can be better positioned to replicate and benefit from it again in the future.
Hence if we can better visualise the things that are working well as part of our development process and we understand the impact those things are having then will we be better positioned to protect and continue to benefit from those things going forwards?
My experiments with adapting impact mapping to improvement mapping aren't at all scientific and so far are rather limited in size and scope. I look forward to developing and experimenting some more with this and will report more findings when I have them.
My feeling though is that if we can see how our process is improving, if we can visualise and understand the impact/effect that changes on the process are having, if we can use that to shape future changes, if we can be more mindful of possible changes that we haven't yet tried and if we can be more aware of what's working well and why, then overall we'll be better positioned to work effectively as a team towards the goals of continuous process improvement.
One thing I've often wondered about over the years when working with Scrum teams is how best to keep track of the agreed improvements that come out of retrospective sessions, in terms of things we've tried and their effectiveness or otherwise. How do we keep track of the possible improvements which we think might be useful, but which we won't yet implement?
At the most basic level we can include a review of the most recently agreed improvements at the beginning of each retrospective, we can keep the things that worked and ditch the things that didn't. Going forwards we can maintain a list of those things so that we can revisit and consider as appropriate to support our continuous improvement.
Long lists can be hard work and difficult to interpret though, and they're never very engaging. So I wonder whether there's a better way, a way which quickly enables the team to visualise improvements, things they've tried, things that worked and things that didn't. A way that helps increase the team's understanding of how their process is evolving. Moreover, can that increased visualisation and improved understanding be used to support a greater buy in and ownership of their process?
Impact mapping is an emerging tool used to help visualise and shape what's being developed my mapping outputs back to outcomes, i.e. features back to the required impact/value. Gojko Adzic describes impact mapping as follows:
"Impact mapping can help you build products and deliver projects that make an impact, not just ship software. Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects, by clearly communicating assumptions, helping teams align their activities with overall business objectives and makes better roadmap decisions"
If we can map and visualise product deliverables back to their impact then is it also possible to map process changes back to impacts? In line with the above definition could this help us align our team activities against the overall objective of continuous process improvement?
Another pattern which I've often observed in retrospectives is a focus on the negative, or a sole focus on trying to fix the things which aren't working so well. An effect of this is that teams can often lose sight of understanding what's working well and, more importantly, why those things are working well.
Ed Catmull in his recent book, Creativity Inc, describes how one of the core principles at Pixar Animation is to understand what works well as part of making any particular film. Not just noting the 'what' but truly exploring the underlying factors that enabled that success. If we can understand something then we can be better positioned to replicate and benefit from it again in the future.
Hence if we can better visualise the things that are working well as part of our development process and we understand the impact those things are having then will we be better positioned to protect and continue to benefit from those things going forwards?
My experiments with adapting impact mapping to improvement mapping aren't at all scientific and so far are rather limited in size and scope. I look forward to developing and experimenting some more with this and will report more findings when I have them.
My feeling though is that if we can see how our process is improving, if we can visualise and understand the impact/effect that changes on the process are having, if we can use that to shape future changes, if we can be more mindful of possible changes that we haven't yet tried and if we can be more aware of what's working well and why, then overall we'll be better positioned to work effectively as a team towards the goals of continuous process improvement.
Saturday, 13 October 2012
Agile improvement through marginal gains; a useful paradigm?
The Olympics brought many things to mind not least whether the organisers were going to wheel Paul McCartney out for a closing ceremony encore. Thankfully they didn't.
On a performance level it was interesting to note the British cycling team's response to questions regarding their continued dominance in the velodrome. Any other teams looking for a silver-bullet solution to improved performance are unlikely to find it. The success, it seems, comes from lots of small reasons and the accumulation of marginal gains that comes with them.
There's never a shortage of people that believe there's a silver bullet solution for increased productivity and improved performance in software development. These people pronounce that being 'Agile' will lead to better and faster results. Rather ironically perhaps, it tends to be the same people who are least able to explain what this actually means or how it might work. I see it as akin to a cycling coach who urges his team to train 'smarter' without any further direction or insight.
So why do so many people continue to be aligned with that view? Perhaps it's because that tends to be the message pumped out by one size fits all Agile consultants? Perhaps it's because they don't fully understand the complexities of software development? Most probably it's some kind of combination of the two - a lack of understanding of both the problem and the proposed solution.
If we accept that this lack of understanding exists then what can be done about it? Perhaps first, as the Agile community, we need to accept some responsibility for failing to effectively communicate what Agile is about. With all the hyped up literature it's maybe not surprising that some see it as a one-stop-shop for guaranteed successs. Others see it as some sort of mysterious science whilst struggling to identify what it actually means in a practical sense.
The truth is that improved performance in software development doesn't come from an overarching theoretical directive. Moreover, it comes from actual and targeted improvements at a more granular and practical level. If we apply the concept of marginal gains then we can propose an overall shift towards a better way of working, realised from the manifestation of lower level improvements in an array of areas.
The idea of improving in lots of different areas is nothing new, indeed it's at the heart of Agile. We can look towards the manifesto and the twelve principles of Agile development for the areas in which we might want to focus improvement. What is new is the suggestion that we can adopt a more mainstream language to better communicate how Agile improvement works.
With the concept fresh in people's minds and seemingly easy to understand maybe now is the ideal time to start talking about 'marginal gains' as the driver of Agile process improvement. Perhaps the familiarity with this concept can help demystify what being Agile means and how teams can get there. In turn this demystification might help move wider understanding away from the silver-bullet solution and towards a practical understanding of Agile application?
Who knows. What is clear to me is that as we strive to be as transparent and as open as possible within the Agile frameworks that we adopt we should also strive to be as clear as possible about the development approach in general. Agile; it isn't a silver bullet and it isn't a mysterious science. Moreover it's a practical approach to development focused on continuous improvement through marginal gains.
On a performance level it was interesting to note the British cycling team's response to questions regarding their continued dominance in the velodrome. Any other teams looking for a silver-bullet solution to improved performance are unlikely to find it. The success, it seems, comes from lots of small reasons and the accumulation of marginal gains that comes with them.
There's never a shortage of people that believe there's a silver bullet solution for increased productivity and improved performance in software development. These people pronounce that being 'Agile' will lead to better and faster results. Rather ironically perhaps, it tends to be the same people who are least able to explain what this actually means or how it might work. I see it as akin to a cycling coach who urges his team to train 'smarter' without any further direction or insight.
So why do so many people continue to be aligned with that view? Perhaps it's because that tends to be the message pumped out by one size fits all Agile consultants? Perhaps it's because they don't fully understand the complexities of software development? Most probably it's some kind of combination of the two - a lack of understanding of both the problem and the proposed solution.
If we accept that this lack of understanding exists then what can be done about it? Perhaps first, as the Agile community, we need to accept some responsibility for failing to effectively communicate what Agile is about. With all the hyped up literature it's maybe not surprising that some see it as a one-stop-shop for guaranteed successs. Others see it as some sort of mysterious science whilst struggling to identify what it actually means in a practical sense.
The truth is that improved performance in software development doesn't come from an overarching theoretical directive. Moreover, it comes from actual and targeted improvements at a more granular and practical level. If we apply the concept of marginal gains then we can propose an overall shift towards a better way of working, realised from the manifestation of lower level improvements in an array of areas.
The idea of improving in lots of different areas is nothing new, indeed it's at the heart of Agile. We can look towards the manifesto and the twelve principles of Agile development for the areas in which we might want to focus improvement. What is new is the suggestion that we can adopt a more mainstream language to better communicate how Agile improvement works.
With the concept fresh in people's minds and seemingly easy to understand maybe now is the ideal time to start talking about 'marginal gains' as the driver of Agile process improvement. Perhaps the familiarity with this concept can help demystify what being Agile means and how teams can get there. In turn this demystification might help move wider understanding away from the silver-bullet solution and towards a practical understanding of Agile application?
Who knows. What is clear to me is that as we strive to be as transparent and as open as possible within the Agile frameworks that we adopt we should also strive to be as clear as possible about the development approach in general. Agile; it isn't a silver bullet and it isn't a mysterious science. Moreover it's a practical approach to development focused on continuous improvement through marginal gains.
Thursday, 26 July 2012
Short Shorts. The Key to Product Owner Success.
An effective and capable Product Owner is key for any successful Scrum project.
So what do we look for in a great Product Owner?
- Product expertise
- Vision
- Decisiveness
- Experience
- Flexibility
- Works well with developers
- Focused
- Responsive
- Practical
- Great collaborator
- Great communicator
I see all of these things as important in making up a Product Owner that can drive a project towards the realisation of value. There is however one thing that's arguably more important than any of the above and that's a pair of shorts as modelled below by @brightsweb.
Maybe it has something to do with the re-routing of the blood supply to the brain. I'm not sure, I'll leave that to the scientists out there. All I know is: Short shorts. The're the key to success.
Note: The picture was taken in 2012.
So what do we look for in a great Product Owner?
- Product expertise
- Vision
- Decisiveness
- Experience
- Flexibility
- Works well with developers
- Focused
- Responsive
- Practical
- Great collaborator
- Great communicator
I see all of these things as important in making up a Product Owner that can drive a project towards the realisation of value. There is however one thing that's arguably more important than any of the above and that's a pair of shorts as modelled below by @brightsweb.
Maybe it has something to do with the re-routing of the blood supply to the brain. I'm not sure, I'll leave that to the scientists out there. All I know is: Short shorts. The're the key to success.
Note: The picture was taken in 2012.
Subscribe to:
Posts (Atom)