Saint Sebastian and Scaling Agile

Last week we visited Florence and then spent a few days in Tuscany ( instead of attending Agile20xx like last year ). The Uffizi Gallery in Florence was formerly the office of the Medici family and is now one of the preeminent collections of Renaissance art in the World. Truth be told, the buildings and architecture of Florenze are more impressive than the art. For some reason, the pictures of Saint Sebastian (Thumbnails below with bigger images at the bottom of the post) held a particular interest for me.

20140727-102909-37749409.jpg20140727-102907-37747771.jpg20140727-102911-37751456.jpg

After a while I realised that they are a counterpoint for Scaling Agile. The Artists all agree on certain points such as “St Sebastian was male”, “He was bound and shot with arrows”, “The arrows do not seem to affect him” and “He was wearing shorts made of a sheet”. They did not agree on other points though such as “Was he young or old”, “Where did the arrow pierce his body”, “Did the action take place inside or outside”. To the artists and those in the church who commissioned the works, the differences did not matter. All that mattered was that a Christian Saint was shot with arrows for his faith and survived. I sometimes feel that some of those involved in Scaling Agile are focusing on the details that differentiate them rather than the common things that are important. In a particular context, each of the approaches to Scaling Agile may be more or less relevant.

Instead of focusing on the differences, we should focus on the core common elements and then identify the context where the appropriate approach is more appropriate.

For the past year or so, @TonyGrout and I along with a bunch of other coaches have been trying to help a company to Scale Agile. This is the diagram and explanation I have been drawing for the past few months to help others understand the constraints and issues that we face.

Here is the description I’ve used to some success.

The scaled investment process starts with an Investment Decision Process which identifies an ordered list of investment possibilities ( I call it a list of Unicorn Horns as they are not realistic ). The ordering and naming of this list will be culturally specific. Do they use Weighted Shortest Finished Job, or Cost of Delay, or Business Cases, or just Hippos ( Highest Paid Person’s Opinion ). Who decides on the order? Do they call them MVPs or MVFs, or MMFs, or BVIs, or Investments or Stories or Bets or… The point is that the culture will determine the process to give a rough ordering to the list of potential investments. I will call them MVPs for this post.

20140727-125549-46549422.jpg

The next step is to perform Capacity Planning for the coming period of time (typically quarterly).  For this, the owner/promoter of each MVP contacts all of the groups* that need to provide input to deliver an MVP and asks them for a SWAG ( Sweet Wild Assed Guess ) in units of Scrum Team Weeks. The group puts as much effort as necessary into the estimate ( I recommend a solid five to ten minutes at most ). The group also provides their capacity for coming period ( Default is number of Scrum teams in the group multiplied by weeks in period times by 50% ). <Editor’s note. I realised I have not described this process in full on this blog. Watch this space>

* Group – Random name representing a group of one or more Scrum Teams that can work on a component or system within the organisation.

20140727-130144-46904739.jpg

During Capacity Planning, the business investors ( whoever they are ) all come together and select items from the list of Unicorn Horns. For each item they select, they reduce the capacity of the impacted groups. This means the groups form the constraints rather than a generic mythical man month notion of organisational capacity. There are two outputs from this process. One, an ordered backlog for the organisation that all business investors agree to which provides direction to the teams. Two, a list of groups that are constraining the organisations ability to deliver. Note that the constraints are dynamic based on the kind of work involved, although most organisations have a few groups that are needed for pretty much everything. The backlog is the focus for those interested in delivery (short term). The list of constrained groups is of interest to those managing organisational liquidity (longer term).

The Delivery involves the teams adding the items to their team Backlogs. They build the things needed for the MVP which eventually results in a release. The release results in an outcome which feeds back into the investment decision process. This is all very standard Agile/Lean practice.

20140727-132527-48327962.jpg

This is also where our experience differs from standard Agile Doctrine. The belief is that teams will self organise to ensure delivery of the MVPs. This is not what we have experienced. The teams deliver but the organisation does not.

To address this issue we proposed that each MVP is assigned a Product Owner and a Scrum Master who are responsible for its delivery ( I consider accountable and responsible as synonyms. Hopefully someone will explain the difference ).

20140727-135434-50074438.jpg

The MVP Product Owner is responsible for the value delivery of the MVP (The Outcome). As the teams develop the MVP, the MVP PO will let them know what can be descoped without impacting the value delivery.

The MVP Scrum Master is responsible for the delivery of the MVP. They will ensure that the MVP is initiated properly so that everyone involved is aware of their expected contribution. They will ensure that an appropriate architecture is in place. They will set up and facilitate the MVP Scrum of Scrums and Retrospectives. They will ensure transparency on the MVP to ensure all involved can see the status.

The roles are similar to traditional Project Manager and Business Analyst roles with one huge and significant difference. They have NO authority. They influence using transparency and they rely on facilitation instead of direction. This is particularly important as they will develop influencing skills they need when they operate on areas where they do not have authority or influence such as in clients or other business units. They will be servant leaders. To do this, they will need tools to report and show progress.

So this is the software investment process in full. However, we also need to consider governance. A governor was a device on a steam engine that stopped it from blowing up. Two balls would spin around, their speed a function the steam pressure. If the steam pressure went too high, centripedal force would force them out causing them to rise, opening a va would release steam resulting in the pressure dropping. The purpose of governance of governance in an organisation is the same. It ensures that the risks within the system are managed effectively.

20140727-141340-51220167.jpg

The risk managers of the system ( another role without authority other than the power of transparency ) is to ensure that the risks in the system are properly managed, and if the individuals do not have the appropriate skills and experience to manage the risks, ensure that they are provided with coaching so that they can. Consider people playing by a cliff. The risk manager would help to make them aware of the danger. They would show them the cliff and help them work out an appropriate risk strategy. If they wanted to build a wall but did not know how, the risk manager would introduce them to people who could teach them how. The risk manager would monitor the risk to ensure it continues to be managed. This is not about control, but more the appreciation that whilst we are playing in the field, we might forget about other things like risks and demons. Recasting definition of done as a set of risks to be managed allows the teams to find the best solution for their context whilst ensuring that the organisation is not exposed to known risks.

These risk managers are responsible for staff liquidity at the team, group and organisational levels. They are responsible for ensuring the overall investment portfolio is balanced as well as ensuring investment is occurring where it should rather than where it is easy. Rather than simply looking at status of a team, they are considering the health of the organisation as a whole as well as in parts.

One of the most critical risks to address is to ensure that the correct approach is taken to building the teams backlog for the MVP.

20140727-143010-52210199.jpg

The Cynefin Framework is ideal ( and necessary ) for helping teams understand whether they should build the backlog iteratively ( in the complex domain ), or build independent solutions ( in the chaos domain ), or up-front ( in the complicated domain ) or simply let the team do its thing ( for obvious domain ).

A risk management and coaching based approach to delivery and governance is vital for Scaling Agile. It allows software development to fulling integrate with the entire business. However, Cynefin is the “Fifth Discipline” of Scaling Agile to the organisational level, without it, we will be doing the “Wrong things righter, er, The right things wronger”.. without it, we will be barking at the wrong tree.

So have I painted a process where we agree he was shot with arrows? Or does this invite discussion about how old or how good looking he is?

Thoughts?

Paintings of Saint Sebastian

20140727-102911-37751456.jpg

20140727-102907-37747771.jpg

20140727-102909-37749409.jpg


Starboard! It Greg Brougham about to tack.

Dear All

Please welcome Greg Brougham ( @SailingGreg ) to the itRiskManager family of blogger.

sailing-greg

Greg is an experienced IT Risk Manager with an amazing knowledge of the Cynefin framework. Check out his Cynefin article in Infoq. Greg was the person who explained the practical usage of Cynefin that lead to my taking the course.

Welcome aboard Greg.

Regards

Chris


The Risks of Adopting the Wrong Approach

In Achieving success in large, complex software projects Sriram Chandrasekaran, Sauri Gudlavalleti and Sanjay Kaniyar of McKinsey (1) advocate moving from a functional delivery model that is silo based to one that is based on cross-functional teams that are module orientated. There are two problems with this model that I would like to raise.

The first is that the article describes large project as complex in nature without understanding that in a complex system behaviour is emergent. There is a short introduction to complex system in the recently published Cynefin paper on InfoQ (2). One of the key points is that no amount of analysis or planning will lead to understand of how a complex system will develop. They are dispositional in nature and therefore have a tendency to evolve in certain directions but this is not given and cannot be assumed. In this type of system the only viable delivery strategy is one that iterative/incremental in nature which allows you to manage for development of the systems in a desired direction. Trying to base the delivery based on a set of point in time requirements is unrealistic and fundamentally flawed, which the agile community has known for years. Simply moving to a cross functional model will not address this fundamental issue with traditional delivery models. As an aside Brian Appleyard (3) notes, in his most recent book, that simple solutions don’t work for complex problems.

The paper goes on talk about grouping of the work based on use case to support these cross functional teams so that can operate in parallel. This assumes that work can be grouped by use case but it does not elaborate on how, this in itself will support parallel working. One of the key things that you need to ensure is that the use cases are disjoint and one way that you can ensure this is by relating them to capabilities (4), along the lines of domain driven design (5). This allows for partitioning of the problem space and for parallel stream of work to be undertaken. This allows you to manage the parallelism which is mentioned as an issue with agile practices. It is not really an agile issue but one that is generic in nature of large programmes.

References

  1. Achieving success in large, complex, software, July 2014
  2. Cynefin 101 – An Introduction, July 2014
  3. The Brain is Wider Than the Sky: Why Simple Solutions Don’t Work in a Complex World, Bryan Appleyard, Sep 2012
  4. The Next Revolution in Productivity, Ric Merrifield, Jack Calhoun, and Dennis Stevens, Harvard Business Review, June 2008
  5. Domain-driven Design: Tackling Complexity in the Heart of Software, Eric Evans, Aug 2003

A tale of two Feature Injections ( A Cynefin tale )

Earlier today I listened to Liz Keogh describe Feature Injection and state that “Feature Injection is a useful model but it does not work in practice”. The Feature Injection Liz describes is nothing like the Feature Injection tools I work with. The one Liz describes is a way of breaking down projects.

To differentiate them, from now one, I’ll refer to the one I use as “Value Mapping”**. I will also describe how you can use it relating to the Cynefin framework.

The key differentiator in Cynefin is between outcomes that are certain and outcomes that can only be known in retrospect.

If you are dealing with a product where the user has choice as to whether they use it, you are almost certainly in the complex or chaotic quadrant. In complex, you need multiple safe to fail experiments. Feature Injection Value Mapping can help by forcing you to look at the value to the user and the organisation. Once the value is better understood, you can identify a number of options (hypotheses) to deliver that value (Those multiple safe to fail experiments). You can then use feature injection Value Mapping to identify the dependencies needed to deliver the value and the options to deliver them. Value Mapping in this usage is very similar to Impact Mapping.

If you are dealing with a product where the user has no choice to whether they use it, you are probably in the complicated quadrant where enterprise software hangs out. You can use feature injection Value Mapping to help the user find the value and then get them to draw the output they need from the system to deliver the value. You can then use Feature Injection Value Mapping to identify the delivery options. One extra point, in enterprise software land you often do not want to specify the user group in advance.

From experience (been using it for a decade now), people on projects tend to zoom in on complicated problems like clever maths and stuff. Value Mapping is great for quickly surfacing complex issues such as necessary changes to business practices. Complicated problems are much easier to risk manage than complex ones… you just need to do analysis or find the right expert.

 

** A name that Dan North came up with.


Why we need Managers in the Agile Enterprise

So you’re a manager in an organisation with 500 or more people and you build product that in some way involves software. We could spend a lot of time discussing whether organisations need tens to hundreds of teams. The reality is that a considerable number of organisations operate at this scale. Even if they decided to downsize, that’s not going to happen fast and they’re still looking to improve their agility. The organisation has drank the kool aid around agile and lean startup. From reading the agile literature you imagine an org chart with the CEO at the top, the teams underneath and nothing between. No mention of manager, only self-organising teams.

CEO-Teams

So is it time for that career change into frozen yoghurt making?

Unfortunately not. The reality is that the organisation still needs you and others like you.

So why do we need managers?

Managers in agile organisations have a different perspective to developers and managers in a traditional organisations. They need to look at the organisation as a system. They help increase the value the system delivers by managing the systemic risks

The team handles mitigating or implementing contingency for any risks it is able to. However, the team has to function as a component of the larger enterprise. Now Deming’s statement on component selfishness kicks in.

“A system must be managed. It will not manage itself. Left to themselves in the Western world, components become selfish, competitive, independent profit centres, and thus destroy the system. . . . The secret is cooperation between components toward the aim of the organization. We can not afford the destructive effect of competition.”

via W. Edwards Deming – Wikiquote

So at best teams won’t be in a position to see the organisation risks that could occur. At worst they’ll attempt to optimise for their own efficiency at the detriment of the organisation. I use the example that we have the constructs of government, states and local councils in everyday life to prevent individual or tribal selfishness harming society as a whole. We can argue that some are more effective than others but in general we’ve yet to come up with a better model. So in software development this is where managers come in.

Managers are able to stand back and look at the organisational system and see risks at this level. They help balance team, product, organisational and customer risks. Risks such as regulatory compliance, key person dependencies, funding risks, contract risks, third party dependency risks and market competition risks. The managers role is to harvest and manage these risks. Yes, the team could mitigate some of these systemic risks, but they don’t. Why? Because the resolution would be wasteful for them as a team.

So the manager protects the system from this selfishness by applying constraints on teams. These constraints describe what needs to be done but not how. Some call them “guard rails” for the organisation. The team then works out the best way to deal with the constraint. The manager can help here by using Socratic questioning to help their teams come to better ways of addressing the constraint.

Conclusion

Development organisations that employee hundreds to thousands of developers exist and want to become more agile. Their ability to deliver a project or product has many more ways of failing than succeeding.

An agile manager’s job is supporting the CEO in reducing the likelihood of events that can cause systemic failure to happen, or shepherd the organisation around them.


Say hi to Tony, and play nice people.

Hi All

I’m pleased to announce that Tony Grout ( @tonyGrout ) will be join me as a blogger on the theItRiskManager.com

Tony and I have been working together for the past year. He has been my partner in crime as we use Theory of Constraints and a Risk Management based approach out to support an Agile Roll Out at Scale. Before his important role as Head of Agile Transformation at Skype, Tony had an important Agile job at IBM where he learnt about the importance of data and risk.

All the best

Chris

P.S. He particularly likes it when people leave snarky comments on his posts, especially about the fact that none of the stuff he talks about has anything to do with Agile.


Learning and Risk

How do people learn? Take a minute or two to write down as many ways you can think of.

Now consider the Kolb circle of learning. Below is the way I interpret the Kolb model.

kolb

Now see how the things you thought of fit into the different styles of learning.

Observation : Reading, Watching others, Watching videos, Attending lectures, ….

Modelling : Creating a model to explain the idea you’ve encountered.

Experiential : Doing the thing, pairing. In Nike terms… Just Do It.

Reflection: Talking to others to discuss the learning subject.

Have you ever thought about the risk associated with different learning styles.

From the individual’s perspective, observation and modeling are the safest options. No one need know you are learning a new subject. You can hide under the duvet reading the book by torchlight. There is also very little chance of failure if you don’t actually try to do it.

Experiential learning can knock you back if you find you are not as good as you thought. If you take hours to download an IDE, when you thought you could dance around the code within minutes. That first, ten line, program in Pascal that generates twenty pages of errors when you forget the word “program” at the start. The two hour hunt for a missing semi-colon.

Reflection can be scary as you expose your potential ignorance and naivety about the subject. Especially if the class expert / bully ridicules your mistakes.

From the team or organisation’s perspective, experiential and reflection are the safest options. Experiential is good because the first thing you do is a simple program like “Hello World”. You then try and do something real that reveals your “… in 21 days book” don’t hack it and you hit Bing ( or Google ). Thirty minutes later you solve it or are e:mailing someone to ask for help (Its never anything profound, normally its syntax). You pick another problem to solve, you hit a snag, and before you know it, it sparks an insight that inspires you to write a blog that evokes a response from world experts. You are a world expert* in approximately 0.0001% of the subject and are completely unaware of 99% of the subject. You also have a healthy respect for the subject and the depths of knowledge required.

*An expert in something no one else in the world will ever use, or care about. That’s the beauty of context.

You discuss your successes and failures with your colleagues and friends and anyone vaguely interested. You make a joke about your failure and tell everyone. The joke travels and you inoculate your team and possibly your organisation and community against making the same mistake. The guys who are reading books share what they learned, and guide you to the right books to read. Everyone respects each other for the value they bring, especially the world expert in 0.0001% of the subject.

There is a risk line I draw on the Kolb Model.

kolb risk line

On one side of the line is safe learning for the individual in a culture where a fear of failure is dominant. A risk averse culture.

On the other side of the line is the place where the organisation needs learning to feel good. Not every individual needs to be on this side of the line but the organisation needs a healthy proportion on both sides to ensure that the risk associated with learning is managed effectively.

Just in case you think this is new, Kaplan of Organisational Learning fame said the most important factor in the success of creating a learning community was the leadership’s attitude to failure.

Conclusion

If you find yourself in a culture where no one turns up to learning sessions that are challenging or controversial. A place where leaders create fear or conflict or disrupt learning or make it hard to learn in the way you want…. Run! Run fast!… to avoid the blast radius as the company implodes. Your culture is sitting on top of problems that you do not want to acknowledge. Problems that will blow it up sooner or later, and take the company with it. <Cynefin>Chances are you are in a complicated culture.</Cynefin>


Follow

Get every new post delivered to your Inbox.

Join 55 other followers