What gets measured gets gamed

measure-upOKR (Objectives & Key Results) are an implementation of Peter Druker’s “Management by Objectives.” as described in his 1954 book, The Practice of Management.  Roughly, every department/team/person is set a handful of measurable targets quarterly or so. There is transparency across the whole company – both about what the targets are and to what extent the previous targets were met.

OKR have a stamp of cool because Google use them. Google is wildly successful. Google use OKRs. So, if I use OKRs, I will be successful too. Well…

Something else is going on. Recent technological change has cause an explosion in the amount of data collected about all sorts of things. Also the timeliness/accuracy/etc… in which it is collected has improved dramatically. I can change a button on my website for 1% of my site visitors and see straight away whether they click on it. I can work out precisely how many extra sales I will get (or lose) from making this change permanent for all visitors. I can quantify my sleep patterns to the extent that this determines when my alarm goes off. I know in advance if the traffic will be busy up ahead.

As a result there has been a huge lurch towards data-driven everything. Data can solve everything, didn’t you know? Measure it! Measure it! Measure it!  Give teams and individuals measurable goals.

Hold your horses! Edward Deming’s cautionary tones resonate with me. Deming sees this kind of thinking as “an attempt to manage without knowledge of what to do.” The focus of the organisation becomes on outcomes without looking into the processes that produce them. Deming estimates that the system that people work in and the interaction with other people accounts for 90 or 95 percent of performance. Individuals really have very little control over what really determines their performance. As a result, most of the energy of the organisation goes into gaming the metrics rather than the real hard work of improving processes. Improving processes usually takes time and requires collaboration with a large number of people across the organisation. It’s really tough. If any actual change is achieved, this will be to make the visible metrics look good at the expense of the invisible and difficult to measure – it is usually some kind of quality which suffers which will hurt the organisation in the long-term.

Deming  alsomakes an interesting point about targets. A process is either predictable (“in control” in Deming’s terms), in which case there is no point setting goals – you will get what you will get. Or a process is unpredictable – in which case there is no knowing what you might get – so again, there is no point setting goals. In a corporate context, most meaningful activities will be complex enough to be unpredictable. What is an appropriate goal then? Who knows? If true performance is really unpredictable, how is it that some people can fairly consistently hit their targets and other not? We are creating a system to select for particular behaviours – an ability to find areas where it is easy to take credit for quick measurable progress, an ability to negotiate targets down, an ability to rationalise and explain why failure is somebody else’s fault. People who master these behaviours will thrive. Does this really make for a high performing organisation?

Is there anything good about the OKR process? Yes! The alignment that results from the initial conversations about what we would ideally like to measure and improve if we could. What is important? What would we like to improve next if we could? This is great! The wheels come off in the second stage of the OKR process, where we reject all the things we can’t measure and focus down on a handful of metrics and set an individual or a team a target for the quarter/year.

To be clear, Deming himself wasn’t anti-data. In fact, he coined the immortal phrase; “In God we Trust, all others bring data.” He was just alive to its limitations. He believed data should act as the foundation for decision-making, not as a substitute for judgement. He believed that the most important figures for management of any organisation are unknown and unknowable. An unprovable assertion. Does it square with your experience? It does with mine.

There will be a backlash sooner or later against this swing towards the idea that data can solve everything. Mark my words, the Oracle has spoken!

More about Deming vs. Drucker at:

Deming’s Point 11.b of 14 – Deming versus Drucker

Should I adopt SAFe?

safeThe Scaled Agile Framework is the leading framework for, well, scaling agile; that is getting more than a single team to “be agile”. Beloved by some, source of all evil for others. Is it for you?

Why SAFe?

  • A complete agile pattern library with high quality documentation available for free on the Internet!
  • Provides a common vocabulary, pitched in enterprise terms to reassume enterprise adopters (SAFE aims to get agile to cross the chasm). If you work in a PMO, you will find SAFe has a very reassuring tone. It reaches the parts that many of those long-haired, sandal-wearing agile coaches can’t.
  • Structured training is available and an increasing number of SAFe coaches/consultants can be brought in ready to go
  • The agile dream of single-handed delivery of customer value by single team is in reality elusive as ever in most contexts – SAFe aims to be a pragmatic compromise and considers the programme (team-of-teams) to be the core unit of value delivery – not really the single team. Programmes (teams-of-teams) will exist anyway. Might as well structure it using SAFe as the pros outweigh the cons
  • There are lots of case studies of organisations having got value from SAFe adoption. Moving from funding projects to funding teams-of-teams is by itself a massive driver of value, even if you don’t do anything else
  • Deciding to adopt SAFe provides visibility and momentum to agile transformation that ad-hoc adoption of scaling practices does not, particular good at mobilising middle-management (who don’t really have a role in most other frameworks)
  • Its flexible, you can choose the bits you like
  • Is getting better all the time
  • Only my personal experience, of course. When I met the creator of SAFe, Dean Leffingwell, I was impressed by his genuine agile vibe. He struck me as a pukka agile dude with his heart in the right place.

Why not SAFE?

  • Contains lots of hidden compromises with the true agile spirit in order to pander to “this is what management can cope with right now” e.g. lots of middle-management roles, accepting that multiple teams are required to deliver value, …
  • There is actually little need for the overhead of a framework like SAFe, individual scaling practices can be adopted by skilled practitioners when needed
  • Organisations tend to take the things they feel comfortable with. Because SAFe contains so much, it is way too easy to take all the comfortable stuff and miss the real agile principles and culture that underlie SAFe
  • SAFe is grounded at the team level in practices that have been broadly adopted across many organisations (Scrum, XP). SAFe is more experimental at the team-of-team level (Program Increment) and is not much more than a sketch above this (Portfolio/Value Stream Level). Adopters desperately seeking to show everybody they are drinking the agile kool-aid often miss these differing levels of maturity
  • Adopting SAFe takes energy away from what really matters in agile adoption at a team level like mastering Scrum and XP.
  • Case studies of value got from SAFe are not all entirely convincing. There are also examples of companies having abandoned SAFe. All very context dependent and impossible to validate the results scientifically (this could also be said of any other agile approach too – scrum is still scientifically unproven too)

Recommendation – SAFe or not then?

On the whole, it depends!

In my limited experience (which might be 20 organisations or so), organisations are often best served by first focusing on mastery of Scrum and XP for single teams. Get good at replicating this. Walk before you run. Don’t scale what ain’t working. Management should work out what systemic impediments there are to having these individual teams perform and remove them – this is often enough change for the next 5-10 years or so – it’s a really big ask. Some of those impediments are really tricky.

For scaling, adopt scaling practices when needed and do absolutely steal with pride from SAFe. SAFe has great formulations for say, aligning on quarterly planning, team-of-team retrospectives, what it means to build quality in and so on.

A SAFe rollout might be useful in certain contexts. In some organisations, it’s the only way to get management attention for agile transformation because as the rest of agile has not really crossed the chasm (some would argue this makes agile transformation doomed to failure in this organisation anyway 🙂 ).

A brand new programme with people who had never worked together would also probably benefit from experimenting with a SAFe rollout to start with. Even then, be careful not to take management attention away from setting the individual teams up for success. On a similar note, SAFe might be useful in rebooting a failing programme, and provides a ready-made template for redefining roles, expectations etc. (although if the underlying issues which cause the programme to fail in the first place are not addressed then failure is certain whether SAFe is used or not).

In short, its still early days for scaling agile beyond a single team. Nobody has all the answers yet, including SAFe. Exciting to see how this will evolve in the coming years!

Learning mind-set? Me? Of course!

brain“Do you have a continuous learning mind-set?”

“Yes, I’m always looking to learn more, me.”

Well, I thought so to, then something happened that makes me not so sure.

Newbies are from Another Planet

The company I am currently working with will have lots of people retire in the next few years. They are massively beefing up their graduate programme to compensate – almost every team seems to have a graduate attached. What I’ve noticed is that when these graduates come across something they don’t know, their response is dead straight: “I don’t know that. Tell me about that.” Sounds kind of banal. Yet, the outcome is that they out-learn anybody else. Now I’ve spotted this pattern, the difference between this group and the people I normally see is so immense it takes my breath away. Really. It’s massive. I can’t stop thinking about it.

The people I normally see in large companies, usually view new learning with suspicion. I know they don’t say this out loud of course but they feel it anyway. Learning leads to change and change is in their experience usually painful and involves failure and loss. They have invested a lot to get where they are and don’t want to loose it. They don’t see it as a major part of their role to learn new things – that’s for the new guys. Not knowing about your job makes you look incompetent. The job is to deliver stuff. In any case the system does not really support learning – nobody gets their bonus just because they learnt a lot.

On the other hand, the graduates know they are here to learn. It’s OK not to know. It’s OK to spend time on finding out. There is nothing to loose by learning.

Do I have a Learning Disability?

Consider this: experienced people have what might be termed a learning disability. How they relate to their wealth of experience hinders them from learning.

Zen Buddhism provides a suggestion about how to overcome this disability.  A “Beginners Mind” is dropping expectations and preconceived ideas about something, and seeing things with an open mind, fresh eyes, just like a beginner. Something to practice – one doesn’t get good at adopting a beginners mind overnight.

So far, so good. Then it hit me. The way I look at all these people and think “Poor saps, they don’t even know they have a learning disability, let alone what to do about it.” Perhaps somebody else is looking at me and thinking the same? I can’t see what is holding me back from learning – if I did, I’d be addressing it! So, what’s my disability?

Thinking further

Couple of things you could join me in thinking about further…

  • Peter Senge, of Fifth Discipline fame, has some interesting suggestions for common learning disabilities in an organisation. They will make you smile, as you will recognise them all in other people. The challenge you may share with me is to find them in yourself.
  • Consider what systems/policies/procedures are in place in your context to prevent people, even if they wanted to, from learning effectively. It might not all be you after all, it might be the system you exist within that creates the learning disability! What would need to change to fix this?

Agile Scorecard? No! A better idea…

scorecarddOh no, yet another management team has asked for an agile adoption score card so they can “know how agile the teams are.” Wrong question! Here is why…

What gets measured gets manipulated

What happens next is that all teams are measured. To increase our score, my team need to do something called retrospectives. Fine let’s put another useless meeting in for the whole team. We need somebody called a scrum master? Fine, Dave can do that in addition to his already crazy workload. He can also spend the time writing post-its and putting it on a board (Yaahaay! A board = more points on our scorecard). Destroys value. Frustrates everybody. Yet another thing management put in the way of actually doing the work. Sigh.

Why do management care about how agile the teams are? Surely management really cares about things like return on investment, customer satisfaction, speed of response to the market. Measure these things if you like – although these are lagging indicators so aren’t very practical for decision making but this is a topic for another day.

Two better questions management might ask

Surely, if a team has a good understanding of agile practices, they can be trusted to adopt the practices that add value. Instead of a score card, here’s the first question management should ask each team:

Q1: Does the team have access to agile experience?

Experience means “having done it before successfully” – be they developers, product owners, scrum masters, agile coaches, etc. Agile practices are context specific so it’s best if the team have access to somebody or somebodies who have done it multiple times before. Somebody who has already had the “aha moment” that what worked in one team, does really work in the second team – it needs adapting.

Not everything is under the team’s control. So the second question management needs to form a view on:

 Q2: What barriers to experimenting with agile adoption is the team experiencing that are outside the team’s control?

Don’t just have somebody send a survey out. Don’t delegate it to a “transformation” team. Management must Go See to get close to the work and have a personal experience of what is really happening.

Set up the Systemic Improvement Service

When management have an initial list of systemic barriers to adoption, prioritise them and get to work removing them –  keep going forever. This will need quality time from management – the issues thrown up are likely to be tricky to resolve. LESS calls this an Improvement Service which anchors it firmly as a service management provide to the teams  Here’s some classics you might find near the top of your improvement backlog:

  • No widespread alignment about why we need to be agile/how urgent it is for the organisation/what it means to us
  • Senior management believe they can define in advance where value is and when it should be delivered by
  • Loads of handoffs to people external to the team
  • Teams unwilling to experiment due to delivery pressure, fear of failure, …
  • Technical debt rarely paid back
  • Product owner not empowered to prioritise
  • Temporary project teams
  • Teams too big
  • Slow and painful interaction with enterprise architects
  • Infrastructure and deployment processes sub-optimal

Think bottlenecks

If you think your bottleneck is that most of the teams don’t have access to agile experience, then get going with recruiting more scrum masters, coaches, etc. More likely is that the bottleneck is the capacity of the organisation to remove systemic impediments (i.e. chew through the list above). Work on expanding this capacity! The teams will become more agile when their environment lets them. The job of management is to shape this environment. Increasing your capacity to do this shaping might just be your best investment.

The Good, The Bad and The Ugly of Large Scale Scrum (LeSS)

lssHaving just attended Craig Larman’s 3 day LeSS (Large Scale Scrum) training course, I’m full of thoughts:

The Good

LeSS comes from a good place – a scaled version of scrum! There is a real effort not to add anything when scaling to multiple teams that is really not absolutely necessary and the spirit of scrum is preserved. Craig has poured a lot of relevant experience into LeSS. I sharpened up a few misaligned assumptions that I had with scrum – Eh, I didn’t know single team scrum as well as I thought. Then there are all sorts of practical implications of multi-team scaling which Craig has lots of really good thoughts on: continuous integration, communities of practices, the implication of self-organisation on hiring and firing practices etc. There was a lot for me to learn there and I think I need to reread the LeSS books again (oh, despite having read them, it seems like I could get more juice out by reading them again – see at the end of this post for links. Read these books!).

As with scrum. LeSS has an appealing purity – it describes the perfect end state (as opposed to the more messy approach of Scale Agile Framework) . LeSS is a marginally better than Scrum in describing how to facilitate some of the steps on the journey.

The Bad

LeSS proposes the immediate elimination of all overhead roles (project managers, testing groups, component development groups) as a first step and the forming of feature teams aligned to customer-value. Whilst a laudable idea and a direction to look in, in the organisations I have worked with, the complexity of the business domain and the state of the legacy code, means a wholesale adoption of approach would be bounced out immediately “You just don’t understand our business” they would say “Take your theories elsewhere.” Remember Conway’s Law? Systems resemble the organisations which built them. Slow, large complex organisations lead to slow, large complex software. “Our business is slow, large and complex – changing our product development organisation will just create a mismatch?”

When pressed for examples of where Craig’s approach had worked, Craig provided a lot of general references but was a bit short on details. I’d like to hear from large organisations who are not primarily software product focussed who have actually done this. It doesn’t seem to me that LeSS is well matched to the kinds of organisations I have worked with. It seems to be for small sub-set of software R&D focussed organisations who are so desperate they will try extreme measures.

And The Ugly

There will be massive resistance from middle management to introducing LeSS – since most of their roles are eliminated. Craig’s solution is to ensure support from senior management. I (and I project everybody in the room except Craig) have never come across this situation where senior management would be willing to provide this necessary support. They just don’t see it as enough of a problem to go through the pain. Craig walks away from organisations that don’t provide the senior support for the change – otherwise he he will just be “rearranging the deckchairs on the Titanic.” OK, fair enough. I project there are, maybe, only 1 in 1000 organisations who have the senior management support for LeSS. What about the other 99.9% of the market? How does LeSS help them take the next step on their agile journey (By the way, Continuous Improvement is one of the ten principles of LeSS)? It doesn’t. LeSS doesn’t even provide any help with this since Craig has no experience about making the problem visible to senior management to the extent that they are ready to take action.

In short, cherry pick ideas from LeSS. As a generalised scaling approach – a big thumbs down! The industry is still waiting for a good scaling approach!

larman2 larman1

Starting Scrum: Inception Phase & Sprint 0

2015-01-23 12_19_44Scrum, as the predominant agile approach, is maddeningly simple – have a single team deliver a potentially shippable increment every couple of weeks. It says nothing about how to get this promised land! So, how do we get there from a standing start? The transition to regular value delivery can be split into three phases:

  • Prior to forming the team (Inception)
  • Team formed but not yet sprinting (Sprint 0)
  • Team sprinting

Prior to forming the team (Inception)

What kind of team do I want? Does it make commercial sense? How will this fit in with all the other stuff going on round here?  Are business stakeholders aligned that we should do this? These are all good questions to ask up front so many companies have a process for this – often very PRINCE2 Project oriented.

Where can we get agile inspiration for this? The portfolio level in the Scaled Agile Framework(SAFe) provides some guidance (Lightweight Business Cases, Epics etc.). It  separates the flow of work from the creation of capacity to do the work (motto “move the work to the people, not the people to the work”). SAFe almost kills off the project notion entirely in the interest of have stable (and therefore high performing) teams. This is a good direction to look in. If this is a step to far for you, Discipline Agile Development (DaD) has a specific name for this early phase: Inception. In the DaD Inception Phase:

  • Form Initial Team
  • Develop Common Vision
  • Align with Enterprise Direction
  • Explore Initial Scope
  • Identify Initial Technical Strategy
  • Develop Initial Release Plan
  • Secure Funding
  • Form Work Environment
  • Identify Risks

Sounds like the right kind of things, doesn’t it? The challenge is that these are all unbound activities – how do we prevent endless polishing that ultimately delays finding out whether we have something of value or not (by building a bit and getting it out there).

I’ve had reasonable experience with setting a target time for these Inception activities but anything that involves a gateway (e.g. typically Secure Funding) can not be fully time-boxed because, if the funding committee say “No! Not good enough” then the proposal is bounced back to be further refined. (By the way it’s a good principle of process design that you should not have a stage gate without a way of limiting work-in-progress upstream.)

Team formed but not yet sprinting (Sprint 0)

The team are now here (incidentally, recruitment of team members can typically take 3+ months so Inception can be quite long). Should they start sprinting immediately? Most practitioners use a Sprint 0 whereby the team prepares itself to be delivering value. What should be in sprint 0? Here are some suggestions:


  • Architectural goals/approach identified and made visible.
  • High level architectural milestones understood
  • Dependencies and risks have been identified and made visible.
  • High-level conceptual design has been completed.


  • Network requirements arranged
  • Minimum environments ready (Development/test)
  • Development machines ready (Local development environments)
  • Logistic requirements in place (phone, desk, etc.)
  • Tools for testing, coding, integrating, and building have been selected and installed


  • The team has received required training
  • Roles and responsibility have been defined
  • Team board is set up
  • Stakeholder map created
  • Definition of done agreed.

When is sprint 0 done? Is it a fixed scope (all these things must be done) or fixed time (do as much as you can in 2 weeks). My encouragement is that it should be primarily on a fixed-time basis (as much as possible in 2 weeks) except for one item. This one:

AS A: Scrum team
I WANT TO: Create a Definition-of-Done and a tiny bit of working software (“hello world”) that fully meets this Definiton-of-Done
IN ORDER TO: Ensure the development pipeline works end-to-end
- Demonstrated/Reviewed by Product Owner


The Definition-of-Done should include releasing software into a production-like environment (or even better, to production itself). The reason I like this a lot is that it drives out all the problems around environments,  documentation, version control, testing, security, release management, etc.

If you are not able to demonstrated in Sprint 0 that you can release to a production-like environment, you’re simply not ready to sprint.

Team sprinting

Once the team is sprinting, then the sprint retrospective within Scrum is the mechanism whereby the team takes time to check whether they are (still?) in the promised land of regular value delivery and make changes to how they work as necessary.


Ready for agile? A test for your organisation

I heard a tale of an agile coach who had a rule as follows: If an organization is using Internet Explorer version 6 then they are uncoachable (latest is version 11). This was based on his experience – he had never got anywhere with a company who was so far behind the curve. Adoption of Internet Explorer is an indicator of something about the organization that is directly related to their hunger to absorb new ideas about work (i.e. the agile revolution).

Adoption of new ideas is characterised by the technology adoption lifecycle shown below:

chasmcurveThis curve suggests that a small number of people/organisations leap on new technology.  The majority take some more time and a handful are really really slow to jump onboard. (See this fun 3 minute video of people dancing at a festival to get this).

Individuals who champion agile within large organisations are typically early adopters. The primary need of these individuals is to see that it works – ideally much better, not just a bit better than what went before. Well, agile really does work – much better than anything else we know of so far. So these people totally “get” agile.

Often these agile champions are bemused and confused by the pushback from their organisation when they try introducing agile ideas. This is because their organisation as a whole is not an early adopter of an agile approach. Their organisation is in the early majority, late majority or laggard category.

In Crossing the Chasm, Geoffery Moore suggests viewing individuals and organisations using this model leads to two insights:

  • Pick off a group at a time. Moore suggests its most effective to work the curve from left to right, targeting sales and marketing efforts at one group at a time. Once this group is on board, move to the group to the right. With agile adoption, we could say that the early adopters are on board and it is only now the early majority that should be in focus.
  • Early adopters and the early majority have different needs. This is the “chasm” which agile needs to cross. Early adopters care only whether agile works or not. They want to get ahead of the competition and don’t mind disruption to the organisation or an approach which is not perfect.  The early majority have other concerns – they are looking primarily for a productivity gain to their existing way of doing things and don’t want major disruption. They need to hear that others in their industry are adopting it. They want to be sure their “agile supplier” is a market leader with a good reputation and they feel comfortable if there is choice/competition between different suppliers/approaches. Above all they prize the stability and effectiveness of their organisation as it is today and want to minimise any rocking of the boat. They prefer a series of small  changes to one large bang  – unlike the the early adopter who are looking primarily for large step changes in performance (which normally implies a big bang).

So, to return to versions of Internet Explorer. Perhaps organisations who are, say, in the early majority for one thing, tend to be in the early majority for everything? If you organisation is a laggard with browser versions, it will also be a laggard with respect to agile adoption? What else might be correlated with this? I don’t have enough data to validate the test below (and it is culturally specific), but score your organisation anyway. Give yourself one point for each of the following:

  1. Green tea is available at the office.
  2. 360 degree feedback is the primary form of appraisal.
  3. You can get a new laptop within a day of requesting it.
  4. iPhones not Blackberrys.
  5. The corporate intranet is a Wiki, not Sharepoint.
  6. Free bowls of fruit available in the office.
  7. Guest wifi freely and easily available.
  8. Widespread use of open video technology (Skype, Google Hangouts, Facetime).
  9. A new access badge is issued within half a day of requesting it.
  10. Not using Internet Explorer 6!

Score as follows

  • Score 9-10: Your company is an early adopter and likely to already be doing agile!
  • Score 4-8: Your company is in the early majority. Fair chance of successful wide-scale agile adoption in the near-future.
  • Score 0-3:  Oh dear, your organisation is in the late majority or a laggard. Move to another company or wait  (possibly a long time). Agile is unlikely to take hold in your organisation any time soon.

Cracking SAFe

safeEvaluating whether the Scaled Agile Framework (SAFe) could be something to experiment with in your organization? If so, here is a personal view.

If you want the one line summary: fundamentally flawed but will add value in most organizations.

Hats off to Dean Leffingwell et al. for “making early and meaningful contact with the enemy.” The product isn’t perfect but they have got it out there and are getting feedback from the market. Now the SAFE authors need to demonstrate their agile credentials by rapidly iterating this product to become even better. I hope that the market success the framework currently enjoys will stimulate a period of rapid innovation in approaches to “scaling agile,” both within and outside of the SAFe framework.

The good

  • Defines a program level heartbeat. The program layer in SAFe provides a way of scaling up scrum – a sort of scrum for a team of teams. It provides roles, events, artifacts etc. for this level of activity.
  • Encompasses lots of other valuable frameworks. Much of the agile good stuff appears somewhere: most of extreme programming, an adapted version of scrum, some kanban stuff, some devops and a nod to lean product development all appear somewhere. It’s good to get an overview picture of this.
  • Acknowledges the realities facing many companies. SAFe proposes, for example, a releasable product at least every 3 months, which is perhaps a more realistic target for many enterprises than scrum’s every 1 month or less.
  • Its probably a lot better than what most companies are doing Agile thought leaders might deride SAFe because it represents a step back from where their thinking is. Yet it could well be a mega-step in the right direction for the people it is aimed at: large companies struggling with large scale software development.

The bad

  • Assumes big is beautiful. The SAFe approach assumes you have a program of 5-12 teams. There is no solution proposed for a 1-4 teams. There is no questioning of whether you need this many teams or what you can do to reduce the number of teams over time. There is broad agreement that scaling the number of teams up from one is the very last thing you should try when you are really out of other options. In SAFe there is no encouragement or support for smaller programs.
  • Stomps on scrum. SAFe talks a lot about scrum but breaks the core scrum rules that: a) the product owner is one person (in SAFe the product manager shares some of this role), b)a potentially useable product is produced within a month (SAFe says 8-12 weeks) and c) there are no dependencies outside a team of 9 people or less. Many companies struggle to implement these but at least with true scrum, they know at least know where they should be heading. A real fear is that companies will do SAFe because they don’t have the courage to do scrum. Consequently they won’t really get much juice out of the agile revolution.
  • Not much help for getting from here to there SAFe is so massive and sprawling that it is hard to know what is important, where to focus first and what we can leave to later.  There is no process for the adoption of SAFe. It seems like it’s implied that it’s a big bang – i.e. SAFe framework adoption is not an iterative adaptive process in itself. Where is the inspect and adapt activities on the adoption of the framework itself? There is no help for the organisation to “uncover better ways of developing software
  • Prescriptive tone SAFe says… Do this. Do that. Very little of how it is set up refer back to any underlying principles. It’s also a one size fits all model. SAFe is rooted in the experience of its authors and the tone is authoritarian.  Like all of us, they have limited experience. How many companies have they really implemented all of this with? Contrast that with the work of Larman & Vodde who present their experience in fairly humble tones as patterns that worked for them that others could try.

The indifferent

Some minor gripes…

  • The top (portfolio) layer is pretty thin. The portfolio layer is a valiant attempt to complete the enterprise picture. In most companies, how projects and programs get started is a murky political affair. Initiatives with significant backing will always circumvent defined processes. I see projects and programs as being like laws and sausages – its better not to see them being made. I can’t see how imposing a simple standard process model at this level adds any value.
  • Weighted-shortest-job-first prioritization is not implemented correctly. This economic approach and as such the cost of delay needs estimating in $ or £ or whatever. Relative estimation of cost of delay is just wrong. This gives no information to the team(s) what the company might be willing to pay to expedite the work. Using relative values is the easy way out.
  • Not clear what is and isn’t in SAFe Is it a toolkit? A source of inspiration? When can I say I am doing SAFe? Not clear.
  • Process over Individuals & Collaborations SAFe does have values like transparency and alignment but most of its thrust is around the big process -which doesn’t seem terribly agile. This is also, ahem, a criticism you could make of scrum – yet scrum says so little this can easily be justified as “just enough process”. The process picture appeals to management. Is this just pandering? Giving them what they want, rather than what they need?
  • Slow (8-12 week) program adapt & inspect This seems an awfully long learning loop. Contrast this with Larman & Voddes Framework 1 & 2 which have joint sprint retrospective at the end of each sprint.
  • Responsibities between Scrum teams, System team and DevOps.  As written, it seems like the DevOps team is the Ops part of DevOps and the System team is the Dev part. Doesn’t feel like true DevOps. Also, the system team seem to have a lot of responsibility for testing the system etc.  This will promote a lack of ownership of system issues in the scrum team.
  • The different agile approaches in SAFe don’t join up. The SAFe training material includes, for example a summary of lean product development (e.g. batch sizes, queues,…) yet this work is rarely cross referenced in any of the other chapters.


Five reasons why you might not really doing scrum after all

scrum-hardScrum is the best known and most widely adopted agile approach. When a manager in a large organisation says to me that their team(s) are doing scrum, my suspicion is that they don’t really know what scrum is because, well, it’s really hard for most large organisations to do scrum.

The formal definition for what scrum is is the scrum guide. The key sticking point in the guide are:



  1. End-2-end cycle time of less than 1 month “The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.”  This means that if marketing decides that the product is good enough at the end of the sprint, it can go out to customers without negligable further technical work. Useable doesn’t mean a prototype or a product that needs further testing in some way (regression, security, …) since this would mean that the output of the sprint wasn’t useable in itself. Scrum is in stark contrast to SAFe which suggests that one can have hardening sprints (HIP sprints) to sort these kind of things out before every release. Scrum effectively says; be ready to do a release at the end of every sprint.  So, can your scrum team(s) really go from prioritising a feature to a potential product release in a month or less?
  2. No dependencies outside of team “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.” To deliver the product, there are no dependencies outside the team. Everybody needed is in the team; infrastructure, architecture, documentation, … Note that the scrum guide also says: “Having more than nine members requires too much coordination.” so you can’t make the team very big to solve this problem. Large organisations with lots of departments responsible for different parts of the product development process struggle with this.
  3. Fully empowered product ownerThe Product Owner is one person, not a committee.”  Scrum is very clear – the one person who is the product owner has full authority on product prioritisation decisions. Most companies have competing departments who all want their say in how the product should be and struggle to devolve responsibility to one person who is so low in the hierarchy that he/she has time to fulfil the product owner role.
  4. Team members all have the title “developer” “[Development team is] self-organizing. Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;” A key barrier to effective self-organisation is typically entrenched job roles. “I’m a tester,” or “I’m a business analyst.” Human Resources(HR) departments in large companies love this  as  somebody can be a Junior Tester and somebody else cane a  Senior Tester which maps to HR’s job and pay scales. Some people like this (typically those with “senior” in their title) because it highlights their skills, makes them feel special and makes it easier to justify why they should  be paid more than the other guys. It can also affect reporting lines (e.g. all the “testers” need to report into the testing manager). It’s hard to find people who will actively support the notion that we are all “developers.”
  5. Scrum Master as facilitator “The Scrum Master is a servant-leader for the Scrum Team” Most companies struggle with both the notion of servant-leadership and  the facilitating/coaching nature of the Scrum Master role. Sometimes, Scrum Masters are seen as project managers and accountable for team success which is really not what is intended. Other times they are simply ignored. Scrum defines them as being responsible for ensuring scrum is understood and enacted – they are process coaches – making sure the scrum process framework is being adopted. They are not part of the product development process itself but a facilitator of how that process runs and adapts itself in the light of new learnings or changing demand.

So, are you really, really doing scrum?




Agile PMO: Four Questions for IT Management

pmo-dartboard (1)Just finished reading “Best Business: The Agile PMO – Leading the Effective, Value Driven, Project Management Office, a practical guide” by Michael Nir. Bit lightweight really. The most amusing bit is the way he lists how PMO’s often destroy value:

  • Focused on tools
  • Focused on processes
  • Focused on standardisation
  • Focused on managements needs (for reports, policing, the appearance of being in control, …)
  • etc.

… and so on. His key point is that a PMO needs to be focused on maximising the value generated by the organisation it is serving. Yeap. I buy that. Everybody in the IT department needs this focus. The issue  is that… well… the book is a bit short on answers about how to do this.

Lets start from basics. Do we need a PMO? IT management should also be primarily concerned with maximising value delivered. Four questions that projects by themselves struggle to answer may help with this:

  1. Do we consistently work only on the most valuable projects (and not too many of them)?
  2. Do we consistently ensure bottleneck resources are allocated to projects in the best interest of the company?
  3. Do we consistently identify bottleneck resources and what can be done to increase their capacity?
  4. Are we effective in transferring learning from one project to another?

The questions are not whether IT management do all these things but more whether they know that these things are happening properly (“work on the system, not in the system”).

I’m guessing most IT management teams would answer “Don’t know” to these four questions.

I suggest that responsibility for these questions can not be delegated to a permanent side organisation (a PMO) since these issues are all too difficult to solve without management’s direct involvement – which is why projects struggle by themselves.

I can see a case for having a temporary change organisation charged with helping the organisation adopt practices which help with the above. Some examples might be: Kanban (helps identify and manage bottlenecks), T-shaped individuals (increases capacity at bottleneck), Cadenced resource scheduling (helps with allocation of scarce resource), Cost-of-delay (identifies the most urgent requirements – good for all types of prioritization discussions), Retrospectives (good for capturing learning) etc.

None of these practices are magic bullets and so, in my vision, it goes on in endless waves: management review the 4 questions, decide which one(s) most impede value delivery, identify some practices to embed in the organisation which might help, set up a temporary change programme to drive this embedding and, after a while, the programme is over and  it’s time to review the 4 questions again.