Scrum Master! Who are you to tell me what to do?

I am regularly asked for help from people with a distress call along the lines of, ” I am a Scrum Master now, apparently, what do I need to do?” This is roughly my response:

There are some teams that have chosen to adopt Scrum, and I wish them the best, although they probably won’t need my well-wishes. Merely the fact that they have CHOSEN to try scrum exposes all manner of values and behaviours. To start they clearly have a degree of empowerment over their ways of working, and they also likely have a sense of commitment and passion about what they do, enough to try something to improve their situation. If they have chosen Scrum, it is likely that they have considered their context and their situation and believe that either it is a good fit, or that they can make some internal changes to enable it to be a good fit. Either way they will either look to recruit a Scrum Master or one of the team will look to adopt the role with a view to, if it works, make it a permanent full time function.

There are some teams in an even better situation, they are formed as Scrum teams in a context that is suitable, often referred to as “Agile by birth” and will often be supported by dedicated Scrum Masters – I had the good fortune to work in a team like this – the most rewarding experience of my career.

 

In my experience though, this is not the norm, due to their size many, many software delivery professionals find themselves inside large corporations where the freedom of working practices are more than slightly constrained. Often there is a degree of close interaction between teams that rewards aligned working practices within a value stream (for adaptive organisations – or skill based departments for others). Now in this context the choice to use Scrum hasn’t really been taken by the team, it has been suggested, encouraged, expected, requested or mandated depending on the culture of control within the organisation.

This brings interesting and typically unconsidered challenges, especially for the unfortunate scrum master who has been unwittingly appointed. In the type of organisation that has imposed Agile there is likely to be the expectation that the Scrum Master will impose the practices of Scrum. Typically this is in service of a wider Agile transformation imposition, and we are now looking at command and control from the top, through the departmental level and down to each and every team member. Attempting to achieve Agile values through rigidity is unlikely to be successful. People choose to do things, people choose to change or adopt new things and whilst they may do this in light of new information, it remains THEIR decision. You can’t forcibly change someone, attempting to forcibly impose working practices is deeply destructive, the team need to choose to adopt them. Here is the heart of the challenge of the expected / imposed scrum, because the team didn’t actually CHOOSE Scrum, it becomes very hard to hold people to its practices.

My suggestion in this situation is simply, not to. I think it is reasonable to have someone explain what Scrum is, and how it is different to their current operation, but then shift the focus of this coerced Scrum Master from working within Scrum guidelines to working within “Team Agreed Practices”. The role of the Scrum Master then becomes an enabler of continuous improvement rather than some Agile process police.

 

The role of a Scrum Master that was appointed, not aspired to, in a team that has Scrum requested of it, rather than chosen by it, is this:

To be the voice of conscience, to hold the team to account against how the team has chosen to operate; and to facilitate the regular discussions of how the team should operate.

When we start to talk about how things SHOULD be, then you’ll trigger questions like:

• Why are we doing stuff?
• What is going on?
• How can we be better?

With a little support the teams will start to increase transparency, value delivery starts to become more important. The team will reflect on what they are doing and look to change, to inspect and adapt. The team will slowly build up to something pretty close to Scrum, and if they don’t it will ultimately be because they have found something better than Scrum given their unique context.

Remember that Agile is not the goal, Agile and all the practices and terminology that come with it are just other people’s ideas that helped them be better. Try to enable your scrum masters to be “betterment people”, rather than “enforcers of a process I didn’t choose”. This approach will encourage your people to be proactive about improvement, rather than instruments of repressive control.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

or reach me on LinkedIn here

Why should I have a Retrospective?

Retrospectives: one of the first terms you’ll encounter in the weird and wonderful world of Agile delivery; but what are they and why are they important? Didn’t we cope well enough before without them?

So first a little definition, the term really entered our lexicon through the widespread adoption of the Scrum framework, in the scrum guide it is defined as follows:

The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.

I am increasingly finding that Agile-y terminology is a barrier to understanding and adoption. Unfamiliar terms can make us feel inferior or foolish, and new “In Vogue” practices can feel threatening because we may feel judged for not being part of the “In Crowd” which in turn can result in people rejecting these ideas as a matter of principle to avoid loss of face. Whilst this definition is technically correct, Retrospectives are far too useful to be constrained within the Scrum framework, and can be beneficial to people not in Scrum teams and not doing things in Sprints, or even in Software delivery….

Retrospectives are really just an agreed time to focus on improving. Taking a step back from being down in demands of delivery to consider how things are being done; look up for a while.  This could be alone, reflecting on how you are responding to your situation; something that is significantly undervalued, but typically, retrospectives are a group activity, an opportunity for a group to reflect on how they interact.

 

To start it is helpful to discuss what a Retrospective is not, to clear up common misconceptions you’ll encounter. It is not to decide how to deliver a specific output, that would be a planning or design session. It is not to review something we’ve done, that would be a review. It is not about WHAT are we doing; it is very much focused on the HOW are we doing things.

It is important to appreciate why we need them now, when we didn’t really need them before, and really this is a recent solution to a recent problem. Historically organisations had strong hierarchies that existed to “command and control” large workforces; to ensure everyone did as they were instructed. As the work became harder to define and understand, we moved away from structured formulaic industries and towards an adaptive creative economy. We’ve seen the fundamental principles of scientific management collapse as we’ve delegated the decision making to where the information lies – which is rarely at the top. However, if those operating practices have been delegated to teams, then they need some opportunity to define and refine those practices. Put simply, we didn’t need retrospectives before because we told people what to do.

Any group of people that are engaged together, with collective ownership and responsibilities to deliver something, that requires a degree of creative thought will benefit from Retrospectives.

 

I still regularly encounter teams of people working together that resist having anything akin to a retrospective. If you are free to choose how you work and the work is in any way creative then I am going to stick my neck out and say there is no good reason not to have one.  The two most common defences I hear are:

“We are too busy”

“We don’t need to change”

I will rephrase the first as “we are running so fast we have no time to reflect”, which clearly is an unsustainable business model.

The second is also rather short sighted, we don’t need to change means we don’t need to improve.  Either improvement, hence performance, doesn’t matter, or maybe, just maybe your delivery unit or team and the interactions you have with your wider context is perfect. Perfect… Maaaaaaybe.

Usually though, these defences are excuses for something much more troubling. I don’t want a Retrospective because I don’t want the team to think for themselves, because I want to retain control. If you are in this situation then you need to engage at a level higher and talk about principles.

 

When it comes to retrospectives there are three things I recommend:

1. Have it on a cadence as frequent as pragmatic
2. Try to make the attendance as consistent as possible
3. Try to make the retrospective as different as possible each time within the two previous constraints

A regular cadence (the regular interval they are scheduled for) will ensure that they actually occur,  Like the difference between saying you’ll go for a run, and actually going for one… Retrospectives are playing the long game, immediate return is unlikely – but in the long term beneficial. It also helps to keep the conversations balanced and not drift into crisis management. You really want to be talking about the way we do things under normal circumstances, on boring Tuesday afternoons in March, rather than be overly influenced by extreme isolated incidents. The frequency will dictate the topics you are needing to cover and needs some balance; infrequent retrospectives can be overwhelming because of the amount of content that comes up, too frequent and the administrative overhead starts to creep up.

Consistency is important, you want everyone’s opinion but also the ways of workings you are trying to optimise will be related to the relationships within your delivery. If you keep changing those relationships then you keep changing the target you are trying to hit and you’ll forever fall short.

My third recommendation is where I see the biggest opportunity to improve with most of the teams I encounter. They have tried something, and it worked, so they have repeated it. There is merit to this normally, we practice and refine until we perfect. Retrospectives are curiously different and the expression, “if you always do what you’ve always done, you’ll always get what you’ve always got” is more appropriate. The principle is that by approaching the challenges the team faces in new and interesting ways each time, then the results and the suggestions you are going to get are likely to be different. Many retrospective techniques pull on expressing issues through different mediums, imagery or metaphor, this is to try to stimulate different neural pathways which will enable new viewpoints. There are many great retrospective techniques that you can use, and for me the best one, is the next one. I have a few that I fall back on when asked at short notice, but for a team I have worked with a lot, I typically try to do something different each time.

I am often asked to work with a new team and I only ask for one thing to be present before I accept, that the team is willing to run Retrospectives. If that is declined then I would strongly suspect that my involvement with the team will not delivery the results that are expected.

 

So, if you are a team, and you are not running retrospectives, why not? What are you afraid of?

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

or reach me on LinkedIn here

Is SAFe safe?

Recently I was at a Scrum discussion group hosted by Tobias Mayer. Noel Warnell posed the question, “Why scale?”. That was about as clickbaity as the title to this article and certainly attracted attention; and the conversation led me to the following realisation.

When we talk about scaling, we fall into one of two camps: either we are looking to grow our delivery capability and realise we will have too many people for a single team, or we already have lots of teams and are looking to make their delivery better. These two situations are enormously different and SAFe is suitable for one, but not the other.

When there is only a single team, likely collocated and cross-functional, then things are probably working well. The relationships within the team will be strong enough as to not require any compensating processes and you’ll find the Scrum guidelines will be a fairly comfortable fit. With this situation, if you need to grow, then your focus will be to not break things. You want to increase delivery rate BUT maintain all the great stuff you have with that engaged team.

In contrast, consider a situation with lots of teams all working together, in a borderline anarchic system, chances are things have grown organically or possibly as a result of an acquisition. I would expect multiple locally optimised groups, possibly clustered around technical components that are drowning in dependencies and technical debt. Having seen this many times I find it often stems from a misalignment of objectives and a “too busy to improve” culture. Commonly there is failure to appreciate it is attitude and relationships, rather than individual talent, that make great delivery. In this situation the objective is to fix the system rather than grow it.

When we talk about scaling we need to be clear whether we mean to GROW something, or FIX something, and the solutions to that challenge are likely to be very different. This brings me to SAFe.

Returning to that single team, all keen and dynamic and you put the SAFe picture on the wall and proclaim proudly that one day we’ll be a huge machine all using this approach, chances are you’ll get some strong feedback. There are very clear and understandable reasons why not a single signatory to the Agile Manifesto currently endorses SAFe, and many are vocal opponents; it isn’t really very “Agile” in the original context (and for more context and a few rants, Google is your friend). What you’d probably be looking for is something more like a hive mind, a network of highly engaged teams each swarming over their own challenges, connecting over common values and simple clean components. Pretty sure that isn’t SAFe.

However in the other situation, if you have an anarchic system with a lot of effort but little value, high utilisation but little alignment, then the introduction of something with significant structure and assurance for those that are trying to make sense of the madness is not the worst thing to do.

We need to consider how we naturally would look to improve a complex system. I suggest we’d take the following steps:

1. Impose order to understand the current state
2. Constrain delivery to identify the issues
3. Identify opportunities to divide the system into simpler parts
4. Ensure a simple interface between potential parts to ensure they can separate without immediately rejoining or breaking
5. Reorganise to break the system into smaller parts
6. Improve each part in a custom fashion for what you need it to be

If you consider that Scrum is a delivery framework for solving complex problems, then this approach isn’t too far from that. Apply order (sprint), break work down with clear interfaces, deliver…

Realistically if you discussed the situation with senior management, the chances are they would like to reach stage five for their teams but are very nervous as to how to achieve it. The challenge is always to be able to improve whilst maintaining delivery expectations; change the plane’s engine while keeping it in the air. Very crudely, the LeSS framework looks to get to stage 5, but rather optimistically looks to leap to step 4 and hope that through strength of character things will pan out well. SAFe, on the other hand, is a lot less disruptive and so compliant to the status-quo governance and culture, that it really doesn’t have ambitions beyond the step one above.

If you are on a building site and it is on fire, it doesn’t matter how spectacular the architect’s plans are, what you need right now is a fire extinguisher. That is how I see SAFe: it is a coping mechanism. Once the fire is out, then you can start building. Awareness is a critical prerequisite to change, and SAFe brings that clarity, however it won’t really fix the situation. SAFe also comes at significant cost to surface and manage all those dependencies, and doesn’t really suggest how to remove them, but once you have visibility of what is happening, what value each role adds, or could add, then you can appreciate how to improve further. The real benefits come from moving beyond SAFe, not moving onto it.

So SAFe is safe as long as what you have is already broken, but only remains safe if you don’t stay SAFe forever.

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter: @philagiledesign 

You can buy Agile, but should we sell it?

Here is your Agile Transformation sir, I even put a ribbon on the box…

I enjoy reading the opinions and debates within the Agile community on social media, even contributing from time to time. Of late a few articles have stood out, maybe it is because I am seeing a growing trend of concern, concern for ourselves. The deepest concerns focus on the topics of “selling Agile” and “imposing Agile”, although I feel the question of imposing agile is related, in part, to resenting a revenue stream that others are achieving through “Selling Agile”.

Agile, at its heart is about feedback, about giving back and learning. Those who initially consolidated their ideas down into a written manifesto did for the best of intentions, the second line of the manifesto even states “… and helping others do it”. The point here is that the concept of Agile approach is a gift, for all. It was never created to make money.

There are very few things that have been created and given away for the betterment of the world, Penicillin is the poster child, but the concept of the internet could also be considered. The problem is what happens next – look how much money is now made from the internet. Wherever there is the opportunity to make money, someone will attempt to, and the more successful they are at doing it, the more others will be encouraged to follow.

Tragically Agile has moved from a theoretical ideology backed with a reasonable description, to a commodity. There are many many people bemoaning this slow transition, nearly all of whom are culpable – myself included. As they invested their time and efforts to gain skills and experience in this new concept, they needed to feed their families and pay their mortgages and started to sell what they had; in the knowledge that was “valuable”… You can either sell a service or a product. A service is customised to the client and is typically high value but being so customised is not very scalable,  it can’t be resold. Products on the other hand are consumer agnostic, one iPhone X is the same as another. Products are much cheaper than services, but they leverage economies of scale to enable huge profits. This is what has slowly happened.

There is now an “Agile Industry”. This used to be a few independent consultants contracting into organisations to support their self improvement along Agile principles, that work slowly morphed into what we call an Agile Coach. Then came engagements with larger organisations that required more work and the concept of the Agile transformation started turning up and that introduced the money pot of Agile training. The final step in the transition to a commodity was the certification; which is really an attempt to patent an idea. Now we have a multi-million pound industry ranging from independent consultants to large dedicated organisations selling transformation. The ultimate Agile product is the “Scaled solution” a highly comprehensive, easy to understand, standardised, easy to pitch, silver bullet offering rainbows and unicorns to all….

The problem with the product of “Agile” though, is that while most know of it, and everyone wants it, very few really know what really good feels like. We are now in the incredulous place with some massive multinationals investing in “Scaled solutions for Enterprise Agile Transformation” not because they really know what it is or means for them, but because other companies near them are investing in it. These companies are buying into their competitors decisions without actually having any competitor results to compare against. All companies want to improve, but few will naturally invite change because that is disruptive and risky, so if someone offers improvement, without making any necessary changes clear, then it is tempting to buy it. People are buying a transformation where nothing changes, a real twenty-first century emperor’s new clothes.

This is the salesman’s dream, the ability to sell something to someone who will buy it only because someone else has. If you can sell something without needed to tie a value return to your product then you can make millions, and millions are being made.

This is not to say that I don’t believe that an organisation becoming more Agile will be beneficial to them, I am just deeply uncomfortable that I can sell promises and dreams, and retire rich; free from the responsibility to ensure that those promises come true. If you don’t have to worry about the success of your product then you can afford to tailor your offering to maximise profits, which typically will mean to standardise the offering, shift it from a service to a product. To refer to a great Dan North quote, “Behaviours are practices in a context”; to get the desired behaviours you need to tailor your practices or change your context, or ideally a bit of both. However if you are selling a standard product then you need to be context agnostic, which means the results will be extremely variable.

Having worked in numerous organisations trying to make things better, I have concentrated on introducing practice at the bottom and changing my context through engaging at the top. If you can’t engage high enough in the organisation then you’ll struggle to impact the context you are working in, and the culture slowly erodes your efforts. If you only engage at the top, then the practices you are advocating will feel imposed and inappropriate which will manifest as resistance and failure. In my experience the lasting changes come from bottom up activity, enabled with top down intent based leadership, you need both. Importantly both come from within. It’s really quite hard to do this from outside and impossible to do without a locally customised approach.

I recently have had the opportunity to discuss Agile transformation with some of the most prestigious strategy and management consultancies. They are rightly reluctant to engage in snake oil promises to their prestigious clients, their reputation is worth too much to risk and they have seen their more delivery focused competitors flounder and suffer through overly commoditised transformation initiatives. However all are now feeling there is opportunity here; whether they all have the sufficient business agility to adapt their typically structured engagement models to support the more adaptive, immersive approach necessary to achieve real value change, I am not certain, some do for sure. If you start with the premise that we can do a rapid assessment followed by some predetermined structural and process changes from a standard playbook where the constraints to success are your own innate talent and efforts, then I struggle to believe you be successful. Things are likely to be different, but better?

If you want to help an organisation to become more Agile I firmly believe you need to have skin in the game of the improvement, you can do this as an external contractor, or a team of consultants but in both cases these people need to get inside the organisation, to be part of it, mutually learn with it. It is more of an experience based model than an assessment based one. Change comes from within, you can’t impose it from the outside. If you as a person want to be happier then that comes from within, from the outside I can dress you in jolly colours and paint a smile on your face but on stepping back, I now just have a sad clown.

The Agile industry isn’t really selling Agile, what is being sold is an ingredient in a recipe for success that also requires a lot of time, a lot of effort from within and no small amount of discomfort, but that doesn’t seem to sell quite as well. We aren’t selling cakes, we are selling flour, and the buyers need to be informed they’ll have to break some of their own eggs to get any benefit.  

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me on twitter or here at @philagiledesign

 

For supporting perspectives and related ideas read these excellent articles:

https://blog.agilityscales.com/can-big-consultancies-deliver-agile-transformations-56bd3c54c87f/

https://guntherverheyen.com/2019/01/07/the-illusion-of-agility-what-most-agile-transformations-end-up-delivering/

https://www.leadingagile.com/2019/01/raise-no-more-devils-improving-organizational-capacity/

https://www.linkedin.com/pulse/rethinking-transformation-tobias-mayer/

https://www.linkedin.com/pulse/adopting-agile-youre-aiming-wrong-target-tim-snyder/

 

Own your feedback

There is the highly quotable phrase: “Own your process, or your process will own you!”, well at least highly quoted by me… I have used it as a segue into pragmatic and value based discussions to avoid the worst consequences of dogma driven transformation. The premise being that the process should be adopted, not imposed; chosen by the people for the people (insert other inspiring taglines accompanied by images of eagles soaring over glaciers here). Jokes aside, there are some important principles at stake here, mostly around the benefits of empowerment and the importance of context to complex systems.

I believe that the underlying point of empowerment and context should be applied to other areas of our product delivery. If we want to consider our approach to be Agile, to enable the organisation to achieve business agility, then we have to focus on feedback. Feedback is at the heart of all things Agile.

I would advocate that we, “Own your feedback, or your feedback will own you.”

What do I mean by this? Well that if a product delivery system is proactive in its approach to feedback then it can use this data stream in an incredibly powerful manner. It will learn through iterative delivery to build a better product or service than could ever be initially conceived. Delivery that takes the strategic direction of the company and leverages real world feedback to adapt that vision to maximise value return. However, if we are reactive rather than proactive, then we either continue blindly on, or are led by the nose by a vocal minority to a destination, potentially far, from our original purpose.

 

To elaborate step by step: below is product delivery in a waterfall world. Assuming implementation into a simple environment where the consequence of our delivery is absolutely known from the outset, where the output leads unequivocally to outcome.

Here there is no feedback, there is no need for feedback, we know everything already. Delivery like this, is one of: rare, lucky or foolish, depending on your industry. Large scale technology delivery has been proven repeatedly to sit in the complex space where output ≠ outcome.

To be able to manage delivery in a complex adaptive system we have introduced iterative feedback led techniques, within technology we invented the term Agile although the concept of empirical adaptive processes was born long before. W. Edwards Deming (1900 – 1993 to give you an idea of when this dates from) advocated the use of what he referred to as the Shewhart cycle from Walter Shewhart (1891 – 1967, so even earlier) for which we now use the term “The PDCA cycle”, or Plan Do Check Act.

 

If you apply the PDCA approach to product delivery then you get something a little like this, where each iteration delivers output and you repeatedly revise that output based on contextual feedback until you confirm you have achieve a desired outcome.

A slight tangent but it is worth noting that delivery continues until “A” desired outcome is achieved, rather than “THE” desired outcome, as good product delivery is cognisant that we drive to a direction rather than a destination.

Now consider the types of feedback that are available: I choose to split them into two groups:

• Feedback we solicit
• Feedback directed to us.

 

Feedback we solicit

When the product delivery was initiated, it would have been to address a problem, a need, which needs to be able to be continually understood / measured so as to ensure that the changes are alleviating the problem / meeting the need. So this understanding or measure is a type of feedback that we proactively solicit. The feedback will ideally be a lot more sophisticated and built into the product, giving a lot of information about user engagement to the product. Product owners are typically all over the following information:

• When is our product used?
• How long is the product used for?
• Are some workflows used more/less than expected?
• Are there points with significant dropout?
• What are the workflow completion rates (conversion for a payment)?
• Proactive discussions with representative users on their opinions

Then on top of this, close user research would be maintained to observe first-hand the use of the product.

All of these pieces of information can be aggregated to paint a rich picture of the outcome of the delivery – as distinct to the output.

 

Feedback directed to us

This is feedback from users that are so affected by the introduction of the latest output that they expend the effort to inform the organisation about how they feel. They might be going out of their way, interrupting their day job, to let you know how awesome the delivery is, or, more realistically, that the latest changes stink, how much they stink and why they stink. They may be cordial enough to limit their frustrations though agreed formal channels – or they may just choose to vent their fury on social media. Critically however, the feedback is only from a proportion of the user base – a self-selecting proportion. It is fair to say that if some people contact the delivery organisation to say they are unhappy, then there are others that haven’t reached some critical “annoyed enough to complain” threshold; but it doesn’t mean that some don’t actually quite like it – and that “some” could be the majority.

 

Both these types of feedback are important, the former gives a full picture, the latter shows areas that are likely to be disproportionately impacting the users. These two feeds need to be balanced against each other. If 90% of the users are getting on really well, deriving value, and 10% have issues, then the delivery should focus on that 10% to either adapt a custom offering or provide training and support. whilst progressing on with the 90%. Consider what would be a likely scenario if only one of these streams were available?

Realistically one of these streams is always available, if users are unhappy they will make themselves heard, eventually, and the longer you leave it to listen to that feedback stream the more serious the consequences, until their final piece of feedback: “Goodbye”.

A product delivery not investing in their own proactive feedback is much more common. This is represented below and can easily trigger the reactive feedback stream to grow in importance – the delivery starts to believe it has a solid feedback approach in place because of the strength of the user comments.

In this scenario, response to user comments becomes a delivery measure, addressing vocal problems becomes more high profile than delivery that doesn’t cause any. The initial strategic direction starts to be clouded by the “angry mob” to whom there is no data driven counter, and slowly but surely, the delivery descends into firefighting. It is like navigating through a hay barn with only a burning brand for light.

 

There are many reasons why the product delivery could end up here. It could be due to a naïve belief that they have the right solution up front – a refusal to accept the complexity of their environment. It could be due to a lack of skills or lack of capacity in product ownership, or more troubling or a lack of genuine ownership. I believe that the cost of not having a solid proactive feedback stream exceeds any involved in addressing skill or capacity issues. A lack of acceptance on complexity or a lack of ownership are more fundamental challenges to address however.

When initiating or looking to improve product delivery, shortly after owning your process, make sure you have established how to own your feedback, ideally before having to call the metaphorical fire brigade.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Tweet me at @philagiledesign

 

 

 

Why aren’t my teams the best?

I have worked with many organisations, both large and small, in house and as an external consultant, and one question that is common is, “What was the best delivery you have seen?”, usually with the hope of emulating it.

Identifying examples of good delivery is relatively easy as long as you have sufficient experience. Eventually you’ll stumble on something good, you may even have had the knowledge, skill and luck to have enabled that “something good” to have occurred. What is much much harder is to find the common thread in them, what made them good? Or maybe the question should be what made the others less good?

 

The “best” teams in my experience used Scrum for the most part, so it would be tempting to say that because they used Scrum they became a good team. Personally I do not think this to be the case. I believe that they had some characteristics already which enabled Scrum to be effective. The Scrum framework and its underlying Agile principles would likely positively reinforce those characteristics, but the effective use of Scrum is a consequence not a driver in my opinion.

This also gives a counter corollary that if those characteristics are not present, then a team will struggle with Scrum, it will be seen as “A poor fit”; “Doesn’t work here” will be a common opinion.

The existence of these underlying characteristics can be considered to be assumptions that we make when looking at undertaking an Agile transformation. I don’t believe these are sufficiently understood or validated before people start talking about manifestos and associated principles and frameworks.

I would summarise these assumptions as the following:

• Our people work in teams
• Our leadership set an example
• Everyone is engaged to a common purpose

 

Teams

I have not encountered an organisation that would say they don’t deliver in teams, but often their definition of team doesn’t align to mine. A group of people under a common line manager does not constitute a team. Tom Loosemore, from GDS, I believe captured the essence in saying, “the unit of delivery is the team”. Simply a team is a group of people that have a common sense of success and failure; the success of one is defined by the success of all. If you operate in this manner then other characteristics such as collaboration will be a natural consequence.  For a team to identify with collective success they need a common purpose. If different team members are pursuing different goals then you will have a situation where some team members can feel they have achieved and others haven’t; at this point the team fractures, it is not really in their best interest to support each other. You can see how Scrum will grate on this type of delivery; there is little benefit one team member sharing what they did yesterday and will do today, if their peers do not have vested interest in that delivery.

Ideally teams will be cross functional, that is to say that they have all the skills needed to provide value within them. When some skills needed are outside the team, either you’ll build up dependencies to these external teams with the finger pointing that comes with it, or the team will look to do their best in that area with the skills they have; thereby bypassing the external team as much as possible, creating poorly used ivory towers of siloed skills.

We need to provide purpose,  and reward and recognise delivery at the team, rather than the individual level, if we want more than groups of people with a common line manager.

 

Leadership

What we want from our leaders is for them to set a direction, a vision, and series of goals and then enable everyone to be able to do their best, be their best to achieve it. When you hear tales of heroism in the military they are often justified with the phrase “they would do the same for me”. That is exposing the presence of real servant leadership, where the leaders primary concern is to bring out the best in their people and demonstrate the practices and behaviours that we should all adhere to. Our leaders shape the culture which defines the organisation. If we are looking for Agile principles to be adopted by our delivery teams they must first be adopted by our leaders, so the culture can be seen to be aligned. We can’t expect team COLLABORATION over team CONTRACTS if leadership are holding the delivery to a fixed time + scope contract. If we are looking to reduce work in progress at a team level, we must first look to reduce work in progress at a leadership level. As an example; I attended a presentation on an Agile Transformation within a UK high street bank at a MeetUp, this was floundering with a lot of process change but little benefit until they managed to show an Agile approach was being used at the board level to manage priorities and show transparency of effort, from that point on it became the path of least resistance (not no resistance mind).

We need to to be transparent about our Agile adoption at the highest levels of our organisation if we want the culture to align

 

Engagement

I have left this one till the end because it is the most powerful and the single biggest factor in my opinion between a successful team and one that isn’t. There was a Carnegie Institute of Technology study of successful people that gave the results that: success was 85% attitude and only 15% talent. The best team I have ever worked with wasn’t the smartest or most experienced, it was the one than cared the most.

I worked in a reasonably large multi team delivery some years back and one of the common complaints was “They don’t see the big picture”. I didn’t really understand this at the time, there was a lot of effort to explain the wider operation of the organisation and this project within it – with little result. I now understand the real issue was, “the teams delivering the system don’t seem to care as much about it as I do”.

In EVERY large multi team delivery system I have seen, this is a problem. Those systems are usually made of interdependent component teams where the concept of value is split across multiple teams. Here you have a separation of VALUE and DELIVERY. Many teams do not have the benefit of a personification of purpose within them. Their purpose is expressed as a contribution towards a goal owned somewhere else, by someone else, to be delivered at some point in the future. In this scenario is it very easy for heads to drop and a pervasive enterprise apathy creep in. At the heart of Agile, and facilitated by Scrum, is the concept of empirical improvement, if perpetual mediocrity is permissible then why go to the efforts of improvement?

Fundamentally Scrum works when you have something to deliver, if the consequences of lack of delivery are not felt personally and emotionally by the team, then the efforts required in Scrum will be resisted because the benefits aren’t really valuable – nobody really cares enough. Management may counter this by saying that they have been provided deadlines – but so are students for their end of term essays, which are typically started late and rushed, doing just what was needed, and this example matters a lot more than “someone else’s deadline.

One of the big differences between these large delivery systems and the smaller single team approach is how that Value or Purpose is personified. This is referred to as the Product Owner in Agile terminology –  someone who is emotionally, and ideally, physically present with a team through the delivery; not just at the start and the end.  They continually provide commitment for the team and are rewarded by commitment from the team. We may see the role in terms of their activities of requirements definition or prioritisation, but their greatest contribution is that they provide passion; they provide the team with drive – and simply – they often just aren’t there for each team in large delivery systems.

The problem is that drive is hard to measure and we naively assume that because the value can be articulated by a single person, then just one person is sufficient across the multiple teams involved to sustain the passion needed.

We need someone in each and every team who really cares about the outcome of the work if we want to sustain the maximum intensity in our delivery.

 

Comments are welcomed – even criticism. It is only through feedback that we learn.

Follow me at @philagiledesign

 

 

 

 

 

Can a Teal society ever survive?

I recently attended an interesting talk on the nature of what it means to be a Teal organisation using the concepts from Frederic Laloux’s 2014 work “Reinventing Organizations”. If you aren’t familiar with the model then have a look at a good overview here The Future of Management is Teal.

 

I appreciate the premise that we can look to classify an organisation, or at least part of it at any moment in time, based on the levels of collaboration found within it. Classifying things is rewarding, we are not programmed to revel in chaos, small steps to push back against the entropy of the universe gives us a feeling of control. Simple classification however is a blunt and brutal tool and much of the conversation I listened to wisely warned against this. The world is not made up of purely Red, Orange or Brown companies with some Green ones looking enviously at the smug Teal one in the corner, it is much more nuanced than that, companies change and often demonstrate multiple behaviours within them at once.

There was an undercurrent in the talk that the progression through the colours to reach Teal was in someway more, “good”, representing a better citizen, and if we imagine a world where all companies were Teal then the world would be a better place – and it is hard to stand opposed to that. There were sensible points made that some functions within companies are well served by a more autocratic operation (distinctly not Teal), emergency triage, legal etc but it was clear that Teal is something to be aspired to. My point is that I am sufficiently pragmatic, grounded, realistic, cynical, bitter and twisted (depending on your perspective) to not believe that we will ever get there – and this is why:

 

There was one contributor that raised the concept that hierarchies will always exist, that really resonated with me. The response to this was that we should consider multiple hierarchies at once, varying by subject; so, I’d look to you in matters of finance and you’d look to me in matters of marketing. This inspires visions of a beautiful harmony of thoughts and decisions, swirling round an aspirational idea of mutual respect and oneness with others. It only takes a couple of steps for this organisational psychology to cross a line into spirituality and I think this is where I felt the conversation crossed an invisible line of pragmatism into ideology.

One of the other talks I attended made reference to the distinction between our primitive “Red” mind (cerebellum and limbic system), keeping us alive and giving emotion, and our thinking “Blue” mind (neocortex), giving us curiosity and reasoning. Our Red mind has been around for thousands of years whereas our Blue mind is a very recent development. I believe Teal organisations cater to our Blue mind, but what of our Red mind? The theory that gave this distinction also identified that the blue mind can only operate if the red mind is satisfied.

It is overly simplistic to see the world in terms of good and evil, but seeing as Laloux felt ok to categorise to make his point, for the purposes of making my point, I’ll carry on! In my experience people have immense capacity for goodness but equally the willfully destructive actions of some can have horrendous consequences on many. The more we ignore the opportunity for evil then the greater harm it can inflict, this is one reason we have a military even when at peace. The idea of a Teal state ignores the evil in us all, the desire for status, power and control. My concern is that the aspirational Teal state cannot be achieved because it requires a level of consistent goodness in us that we cannot sustain; there will always be at least one that succumbs to baser desires to the detriment of the society around them. This is not to mean that we should not aspire to this state, but not to be disheartened when we fail to achieve it, or sustain it.

In the image below I have crudely overlaid Laloux’s progress of organisations with humanity, where the lines cross represents the point beyond which the evil in society corrupts sufficiently as to prevent an ideal state. Clearly this is a graph without scale or metrics but I feel those lines cross well before we reach universal adoption of Teal behaviours.

Jessica Prentice’s excellent article, The most dangerous notion in “Reinventing Organizations” offers some solace. In it she reminds us that our culture has a depressing habit of after understanding something, believing we’ve invented it – the way that Christopher Columbus apparently discovered a new land, even though people had been living there for thousands of years already.

What she advocates is that societies long since crushed, using the example of Native American peoples, valued truthfulness, wisdom and community, and operated much closer to the Teal living organism paradigm than our capitalist societies of today. Therefore maybe it is something about our current society that enables the evil in us to run sufficiently wild as to prevent Teal being seen to be sustained. It is interesting to note that ideal state societies in literature such as the Elven kingdoms in Middle Earth or the Eloi in The Time Machine are very much more Teal than our current reality.

This isn’t to say it hasn’t been attempted, there have been multiple attempts to create a hierarchy-less collaborative “good” society. This has occurred in pockets, but small ones and usually not long lasting. A classic large-scale failure of this has to be the rise and fall of Communism in the twentieth century. The premise of the society is laudable, equal and harmonious, everyone working for everyone in a self-sustaining utopia; but when you remove the protections we have against humanity’s darkest capabilities the more terrifying their imposition becomes when inevitably they surface.

 

So where does this desire for status and control come from, if we consider that earlier societies didn’t have it to the same extent. Peter Drucker is purported to have said “you manage what you measure”, what if we take that to a societal level? Our current capitalist society measures, and by consequence judges, based on power and wealth. In such a society can a Teal organisation ever survive and thrive? A Teal organisation is likely to generate much goodwill and collaborative behaviours because that is what they are looking to optimise; but when pitted against an Orange “Machine” type organisation, according to the wider society’s measures of power and money, they are likely to lose out.

 

In conclusion while I will proudly state that I believe Teal characteristics as desirable and will continue to reward and nurture them where I find them; I am accepting, with a heavy heart, that I am unlikely to ever see this become the norm until the society I am in replaces power and money with collective fulfilment, as its measure of success.

 

Comments welcome

Phil Thompson

follow me on Twitter at @PhilAgileDesign

Transformation? Here’s what you need:

As those that have read my blog before will know; I have had my fair share of software delivery transformation experience, I am growing increasingly reluctant to even call it Agile these days to avoid any kind dogma based resistance. Some of my efforts have yielded results, some I’d even be brave enough to say were successful; but there are others that were complete failures. By failure I mean that the real fundamentals of delivery and value were not improved, people may have felt better, those refinement sessions were better organized, but the things that really matter didn’t move.

So I’d like to reflect and share what I feel makes the difference between success and failure, between charting a course though a minefield and rearranging the deckchairs on the Titanic.

 

I believe it comes down to having three things:

• Knowledge
• Understanding
• Trust

Knowledge is pretty fundamental, whenever there is a discussion or article espousing the virtues of soft skills there is always some precondition that you need to know what you are talking about first, and my experience backs this up wholeheartedly. The knowledge in my world is mostly about Agile theory, practices and the management models that support them. Things like Scrum and complexity theory, Kano analysis and TDD, Lean UX and the workings of those highly controversial scaling frameworks. However, the big differentiator here is that it is more than theory, more than what can be studied and parroted back from Wikipedia articles, the ability to know what theory to apply in a given situation, that is the real skill. The difference between tacit knowledge and explicit knowledge.

When I refer to understanding it is about context, do you really understand what is going on, how the organisation reached its current situation? The drivers that got it to where it currently is are likely to still be the strongest forces that will be applied to any of your transformational efforts. Ignore local politics at your peril. As they say “Culture eats strategy for breakfast”. It takes time and an open mind to really understand this, to hold back from fixing the “simple problems” until you appreciate why they exist – chances are they won’t seem quite so simple when you do. There is a tradeoff to be made here though, the longer you work in a context to understand it, the greater the chance of that context influencing you, you go native and become as much a part of the problem as everyone else.

Lastly and most importantly trust. Without trust then you won’t get to influence the people that really can make a difference. Trust is the difference between being heard and someone taking action. As a transformation agent we have a number of skills we can pull from, facilitation can be beneficial with limited trust, mentoring requires a stronger relationship and coaching even more. Trust is usually harder to win the higher in an organisation you go, the time you spend with these people is less and they have more to lose.

This quote by S Covey pretty much sums this up:

“You need to have a good idea, you need to know how to implement it and you need the trust to carry it through”.

 

Requiring these three things also implies a fourth, something that people may not like to accept: time. Building knowledge, learning about the organization and winning trust; all take time, the latter two require time specifically in the current organisation. You can’t hope to enable substantial transformation quickly, regardless of your potentially staggering intellect.

The best approach I have seen is to focus on achieving understanding and trust through small changes at a low level that enable slightly larger changes at higher levels, until you work to a position of being able to support substantial changes at the highest levels around the same time that you have a deep understanding of the organisation and the trust of those that are accountable for it.

 

Best of luck

It depends…

Scrum or Kanban? Should we estimate using Story points? and if those estimates are clearly wrong once we start work, should we re-estimate them? Should the PO attend the retrospective? Design Sprints? Technical Product Owners and part time Scrum Masters…? the list of questions goes on and on. This is my life, fielding an endless stream of questions from well-intentioned inquisitive people looking to improve their lives and the lives of those around them.

The answer to all of these questions is the same, always the same, “It depends”.  Most questions I am asked are focused on the practices that teams or individuals undertake within some framework of Agile delivery, so these are questions of process or tooling; usually HOW or WHAT questions rather than WHY questions.

 

Dan North neatly explained a lot of Agile execution with the neat paradigm of

Practice + Context = Behaviours

“Agile is a culture not a process” – another soundbite, this time from Jeff Patton, and the point is that what matters are those Behaviours, that Culture. The Practices, the tools and processes that we employ, are being used to try to encourage those Behaviours that we are searching for. The deep difficult WHY questions are about these Behaviours, the HOW and WHAT questions are more typically on the Practices.

How to use the practices is therefore dependent on the context in which they are being used. Context is critical, the context is also unique to your situation, and it is always changing, as a result the answer to those HOW and WHAT questions will always be different as the context is always slightly different.

One of the dimensions of explanation used with Cynefin are the concepts of Best, good emergent and novel practices. Complicated situations where context is predictable can employ Good practice, but in complex situations such as a team of people working together to build new software, then Emergent practices are favourable, which imply emergent responses to questions – that usually start…. It depends!

The downside of this is that discussions with Agile coaches can be very frustrating, those that see the role, and often by association the software delivery process, in the complicated space will find that they never get a straight answer. The coach will be seen as vague, elusive and non-committal.

Coaches have a responsibility to ensure that they are not seen in this light, to leave the situation in that state is to undermine their own capabilities because this damages trust. We should never say just “It depends”; it should always be followed up by some balanced contextual reasoning. Asking the opinion of the questioner is typically a good approach, it also puts the questioner into space of owning their own processes and practices, avoids the coach unwittingly doing the thinking for the team which leaves them open to adsorbing accountability and slowly disempowering the team.

 

Most coaches will agree with the sentiment in this article, as to whether it is useful to you, well that depends…

Tools, tools, tools – stop talking about tools!

I mentioned something about Agile tools on LinkedIn recently and my profile lit up like a  lightbulb; clearly this is an issue that people feel strongly about. The point that resonated most with my peers in the Agile community is that there is too much focus on tools – a little ironic, the thing that gets people talking is a comment that there is too much talking…. about tools.

JIRA, Github, Jenkins, Rally, Sonar Cube I could keep going for a while. These are tools that are used in the creation of software, often associated with the most current techniques, some of these are very “Agile organisation” orientated, others more targeted at the integration and deployment end of the cycle, but all of them help teams in their ability to deliver.

However you don’t get immediate results just because you have them. “We’re Agile because we use JIRA”, heard that one before? So why all the fuss, why all the focus? I believe this is simply because they are visible to management- their use can be identified by those who oversee delivery and are interested in any changes that are taking place within our teams. It is hard to see commitment increase a little, but easy to identify a JIRA board being used where previously work was tracked in a chain of emails.

What needs to be made clear is that tools are a means to an end; and as teams look to improve their ways of working they will likely encounter and experiment with some tools along the way, adopting a few that help, tweaking them to their context. The point here is that the team is looking to improve and chooses a tool. The use of the tool hasn’t driven the improvement – it is psychologically the other way round. Which is why the imposition of a tool won’t deliver any results independently and measuring the use of a tool can give misleading results. If the goal of your organisation is to have everything in Jenkins then a mass rollout and migration is just what you are looking for, but it is more likely that the goal of your organisation has nothing to do with Jenkins, probably more to do with selling something, and customers, and other much more normal stuff.

 

I’d like to look at these tools using the analogy of, err, tools. The kind of tools that people thought of when we said tools 20 yrs ago, the kind of tools that people outside our little software bubble still use the word for, like hammers and screwdrivers etc. I have quite a few of these tools in my house, and I consider myself pretty good with them. If you were to come to my house you may see the consequences of those tools all over the place, Shelves that are up, still up, and have never fallen down, Skirting boards that fit, units that have small modifications to fit into irregular gaps etc. What you are unlikely to see however, is any actual tools. You’d probably be quite surprised if you went to a friend’s house for dinner and they brought out their new 48 piece socket set to show off, or a box of screwdrivers with those nice rubberised handles you can get now. They might show you into the lounge with a large television on the wall on one of those moveable arms, and tell you they put that up themselves with a hint of pride, but the tools they used to do it, well they won’t get much airtime. The consequences of the tools are what we are interested in, maybe we used a hand drill and took hours over it, maybe it was a rechargeable cordless drill, maybe that old drill that you inherited from your grandpa and is still going strong – doesn’t matter really from the perspective of the person looking at the TV on the wall.

The choice and use of the tool probably matters a little to you in terms of how efficient you are with your time, and if someone asked how you put your TV on the wall because they quite fancy doing the same, then you might talk about tools, so there is a time and a place for those kind of discussions, but should be very much focused on the job in hand.

The other point about DIY tools is that ownership doesn’t infer competency. Just because someone owns a drill, spirit level and a screwdriver doesn’t mean that they can be trusted to put up a shelf… If you want to know if you can trust them to put on a shelf, go to their house and put something heavy on their shelf….

The last point I want to make about tools is context. If you are putting together a shed on your own, and you have a strange star shaped screwdriver and a set of weird star headed screws, then you could work quite happily to produce your shed – and the resulting shed in terms of speed to build and quality would be the same as someone using a more standard screwdriver and screw head. However if there were 4 people building this shed and each person brought their own unique set of screws with matching screwdriver then it would be clear the kinds of chaos that would ensure and the inefficiencies that would result. In this slightly bizarre world of multiple screw types, it would probably be worth taking a minute before starting the construction to agree on a shared standard, and the more common the chosen standard is, the less discussion would be required and the simpler the adoption from the group.

 

So now, enough talking about tools…