Culture eats strategy for breakfast

This is my (Chris Berridge) last blog post as I am leaving the company. The LPD coaches (Ozlem Yuce, Lisa Doa) will continue to publish blog posts on an ad-hoc basis but probably not weekly. So here is my farewell rant/words of wisdom. Thanks for all the readers who have contacted me to say how much they appreciate the blog. If you are desperate to get me a farewell gift, a recommendation on LinkedIn is always nice:-)

I first thought to write exhorting you to deliver even more value in even smaller chunks in even faster cycle times. Well you should. Once you understand the magic of focussing on overall value (and not cost or some other sub-optimising dimension), the incredible benefits from reducing batch sizes and the almost silver bullet like properties of fast cycle times, it’s obvious.

These are the processes and tools of lean-agile thinking. What it’s really all about is mindset, attitude, culture. The agile manifesto captures this where it says that there is more value in “people and interactions over processes and tools.”

I got this at some level when I started this job but I’ve been getting it at a deeper and deeper level as time goes on. As Sigrid mentioned in last week’s blog, Linda Rising talks of two mindsets “fixed” vs. “agile”:


Fixed mindset Agile mindset
Ability – static, like height Ability – can grow, like muscle
Goal – look good Goal – to learn
Challenge – avoid Challenge – embrace
Failure – defines your identity Failure – provides information
Effort – for those with no talent Effort – path to mastery
Reaction to challenge – helplessness Reaction to challenge – resilience

We all spend time in both places. I offer it for your consideration that you have more fun, are happier and have a greater impact on the world if you spend more time in the agile mindset. If you suddenly wake up to find yourself in the fixed mindset, then there is nothing wrong. Pick yourself up and move over to the agile mindset. The trick is to practice this movement – aim for mastery.

In the agile mindset, we are all a work in progress. The development process isn’t fixed but will continue to improve as it ages. We have in our PEX methodology an emphasis on continuous improvement but we are woefully short of getting the hang of this. We boil down our PEX methodology to PostIt notes and a fear of variation. We boil down lean-agile thinking to kanban boards, CD3 prioritisation and fast cycle times. Yet we are missing the key point. In the book Toyota Kata, Mike Rother looks into what Toyota’s success is really about. The have a behavioural pattern or culture (“kata” in japanese) they have managed to institutionalise where they:

  1. Identify one action that could be taken towards moving towards a vision
  2. Take it.
  3. See whether it did move things in the right direction.
  4. Rinse and repeat forever and make these learning loops as fast as possible.

They do this for everything from the company strategy down to the tiniest thing. What that enables them to do is to out-learn the competition. They understand that learning happens at every level.

“Yea, yea we know all this. I’m always looking for opportunities to improve.” I offer it for your consideration that you are playing this game small and you can play it at a whole new level. You rarely focus on improving just one thing, preferring long action lists and “projects” instead. You rarely understand what the required direction is (what is the vision for how your team communicates? for example. Do you have one?). You assume that you are not empowered to make the necessary changes. You are not ruthless in adjusting and learning quickly, you prefer to schedule meetings for the week after next instead. What both you and the company needs is to maximise the rate of learning. Your mission, if you choose to accept, is to find out how. Adopting the behavioural pattern above is a good starting point.

So here is my farewell call to action. By reading this blog, you are prioritising taking time to learn. To get results, add some courage and steadiness to apply what you are learning. Wherever you sit in the organisation, put on your agile mindset and offer some leadership in adopting the continuous improvement behavioural pattern described above. Have the ambition to apply this pattern to everything. Find out what it takes to make this happen. Experiment!

Research shows that we are encouraged and influenced by other’s behaviour – your colleagues will be influenced by yours. When you start playing the game at a new level, you’ll probably find you won’t recognise yourself and, ultimately, Maersk Line won’t recognise itself.

So long!




The developer’s paradox

A guest post this week from Sigrid Rohboll, a student working in the FACT team…

The developer’s paradox

After having attended the Goto 2012 developer conference with only 7 months of practical knowledge of lean-agile techniques and then sitting here 3 days after with a notebook full of ideas from presenters, there is one thing that stand out: the developer’s paradox .

The developer’s paradox is based on Hadi Hariri’s talk on the fact that developers’ are lost in agile perspectives. According to him, developers feel they are being pushed towards more tools and processes when actually trying to make it about people and interaction. E.g. Kaizen sessions, stand ups, a continuous building of time-boxes that do not suit the craftsmanship inherent in the developer mindset.  We see it often at Maersk Line too; with some developers trying to cut down on the daily stand-ups because it feels like a waste of their time. When they do show up at Kaizen sessions, their main concern is that they cannot match the process measures set out for them (e.g. cycle times) and they blame it on the process. Basically they are saying: ”Let us build, code and design, and we will leave process planning, communication strategies and agile thinking to the rest – in that way we can focus on coding fast which is our contribution to the whole lean-agile thing.”

Why do we have this problem? Developers often think they understand a business requirement perfectly. Yet time and time again we see examples of a requirement that needs to be changed as we learn more. Much of the waste created in going back and forward in the process is due to developers believing that  requirements have been communicated to them perfectly. They are fixed in a mindset whereby they see that their job is to do the coding and not to engage in a conversation to refine the requirement. They have a focus on maximising KPI scores (e.g. cycle time) instead of performing on a team-based level.

How do we change this? Linda Rising’s talk at the Goto conference on “fixed” verses “agile” mindset seem relevant. Rising’s point of departure was that abilities can be seen as either fixed or agile. Adopting the “fixed” mindset means that you have the abilities you have and there is absolutely no need to improve them because it is simply impossible.

What this suggests to me is that we have been stuck in creating an agile work environment instead of promoting an agile mindset. We need to coach developer’s to help them realize that they are capable of understanding non-coders, that they can talk directly to customers and that communicating with their team does not necessarily mean they are distracted from their craftsmanship. Cycle time is a good measure but it becomes an obstacle if we focus on it excessively.

In a very schoolteacher-meets-pupil kind of way, we have introduced the star team reward to our kanban meetings within the FACT portfolio. We collect the data on which team performance both by looking at the cycle time KPI’s AND if all the stages in the process have explicitly been used for their set purpose (which in our case is a rough measure of the level of communication in the team). The winning team has their names on a star that is on the board until the next release. The developer is hereby being acknowledged as part of the team and that his (and her) effort are appreciated from a team perspective. Its a small thing but it pushes in the right direction.



Key themes from Goto 2012 Conference

​I just returned from the Goto 2012 software development conference in Aarhus – a surprisingly large conference with speakers who are world class rock stars within the software world. I thought I’d start with my key themes I noticed:

  • DevOps is becoming a really big thing. If you work in development or IT operations and you don’t know what this is you need to. There are many factors pushing development and operations together. Jez Humble, author of my favorite book on this topic, emphasized the continuous improvement nature of this journey and the importance of getting started – it’s a tough change to make.

  • Agile development has long been the accepted wisdom at these kind of events. When we started our Lean Product Development initiative 2 years ago, lean and kanban idea’s were still relatively new. Industry adoption now seems to have really taken off. At least three speakers raved about Don Reinertsens book. (I mean raved. One of them wondered whether Don is the software Jesus but nobody has told him). Happily we have been on to this for a while. His tough-to-read book has been our guiding light (” don’t diss the Don” as we say in the LPD coaches team) and we have had Don personally come and train about 25 Maersk people.

  • Getting to validated learning fast, minimum viable products and other Lean Startup ideas  are coming into focus. I particularly liked the use of the terms “done” = we’ve stopped working on a feature and “done done” =we’ve found out whether what we did was valuable (I.e. we have collected and digested metrics on it’s use) Are you “done done”? Do you even care?

  • NoSQL databases. Lots of product vendors all pitching their wares. Clearly a big, innovative and chaotic growth area.

  • Shortage of developers. Lots of companies trying to hire developers. Google and Amazon were there. I spoke with the Amazon people who apparently were finding it difficult to get Danes to consider moving to Dublin or Edingburgh. Ha! Ha!

  • A gazillion programming languages. Functional languages  are on a roll right now as they are well suited to multiprocessor environments. There are also plenty that compile into java bytecode or even JavaScript which add some, apparently handy, features. I’m not sure whether any real innovation is happening here or whether this is just nerdy over-engineering.

  • Gender balance. Overwhelmingly guys at this event. One speaker covered the research which suggests that single sex teams (male or female) underperform compared to teams with diversity. One conference attendee recorded her own experience of sexism which actually occurred at the conference on her blog.

  • One speaker, who is currently writing a book on agile contracts, made me think when she unconsciously assumed that none of the people in the room would be senior/powerful enough  to make the changes necessary to bring about a true agile transformation. Why are theses people not here? This made me wonder whether the people on the coal face of software development are actually ahead of senior management in this respect. What can be done to accelerate their agile journey of senior managers to help them catch up?

  • Continuous Improvement mindset. This came up in a number of talks and there were several pointers to abook on Toyota’s culture which suggests that all the lean tools are good but are just tools. Toyota ‘s success actually comes from a habit, reinforced by a coaching culture, of improving all processes every day at all levels. Could Mærsk Line do with a reboot on this one?

  • Service oriented architectures(SOA) were conspicuously not in focus. Not a single session on this – I guess this is not so new any more. There were some interesting reflections in other talks that a service approach is what makes Amazon stand out compared to Google. Sky presented their agile journey and their chief architect stated that their strategy is that they will never use an enterprise service bus (adds complexity and dependencies between teams) or employ WSDL/XML schemas/SOAP (Gives a false sense of security that the interface is well understood and promotes systems to reject data which is not 100% perfectly formed    they use the lighter weight JSON instead). A couple of other speakers echoed this theme.

Some of the specific talks were very relevant to Maersk Line and I’ll write about them in detail in future blogs.





Prioritise my stuff first!

Seeking inspiration in what to say to a project which desperately wants it’s stuff prioritised first? Try this…

Hi project!

Our delivery team is committed to managing the capacity of our development pipeline in a way that provides the best outcome for the company as a whole. We use CD3 (cost-of-delay divided by duration) as a framework for prioritization since this maximises Maersk Line’s overall return-on-investment.

Using this approach, if the work you need us to do is not prioritised straight away, we will explore the following options together with you:

  1. Wait. The project shouldn’t start any related work until the bottleneck resource is finished with higher priority work.
  2. Redesign the solution to reduce the scope of the work required. Smaller pieces of work block the pipeline for shorter periods and increase the CD3 priority score (if the cost-of-delay remains the same).
  3. Redesign the solution such that the work is not is not needed. This can either be by pursuing a tactical solution which later will be replaced or by finding some way of not needing that functionality after all.
  4. Increase capacity at the bottleneck. This could be temporary or permanent. If we see it as a temporary bottleneck, the best would be that other project members go help with the bottleneck for a while if they have the skills (T shaped individuals, please!)
  5. Abandon project. It may be that the project simply isn’t as valuable as other projects we could work on and we don’t see this changing any time soon.

We believe these options create value for the company. There are two further options which generally don’t add value for Maersk Line:

  1. Start more work in parallel. It’s finishing work that makes a difference, not starting it. Starting too much at once means that we lose focus, overhead/switching/coordination costs increase and some value is delivered later than would otherwise have happened.
  2. Complain to the LMB or SLT or some other authority to get the priority score of the work increased. This can be by increasing the cost-of-delay for “strategic reasons” or because we have “suddenly” found some extra $ benefits of the project. If this kind “tampering” really really can’t be avoided, we insist that it is the cost-of-delay which is manually adjusted such that the increased urgency of this work is communicated to all teams that are involved in producing the feature. This way we avoid a situation whereby one team considers a feature very urgent and another team considers it less urgent.

In the interest of the company as a whole, we want to steer you away from these last two options.  “Removing roadblocks” is often perceived as a core skill in our management culture but exercising either of these option is not normally removing a roadblock to value creation.

We look forward to exploring this further with you to get the best outcome for Maersk Line as a whole!

Best wishes

The delivery team


The end of waterfall?

I was reflecting on why we don’t all simply do things in a lean-agile way by default. Why are short iterations, fast feedback and a collaborative working style not the natural way of doing things? What is so attractive about organising the development process around a single pass, stage gated approach (typically referred to as “waterfall”) that we need a whole change programme to address it?

H. L. Mencken quipped, “For every complex problem, there is a solution that is simple, neat, and wrong.” One root cause of waterfall’s historical popularity could be that software projects have been inappropriately associated with a predictable manufacturing paradigm (such as manufacturing TVs or cars). In this paradigm, things can be predictably specified and planned, in contrast to the the chaos and uncertainty associated with a new product development paradigm. Since predictable manufacturing is the wrong paradigm for software, practices and values rooted in it are not helpful. Two assumptions in particular is are a source of amusement or dismay to developers of software solutions:

  • There is a single set of requirements and delivery options that describe what the business wants to do (requirements) and how it will be delivered (analysis and design).
  • The specifications do not change, or only change minimally (and perhaps predictably) during the construction and test phases of the project, subject to a strong change management process.

The deep appreciation—that building software is complex, new product development with high change rates, and not predictable manufacturing—is at the heart of the motivation for lean-agile methods.

Another possible factor is that single-pass waterfall gives the illusion of an orderly, predictable, accountable, and measurable process, with simple document-driven milestones (such as “requirements complete”). There is a special irony in choosing a simple-to-track process that yields higher levels of risk since the high risk activities – testing, integration and most of all, finding out whether the solution is valuable, are pushed to the end.

Software development is a young field, so it is no surprise the simple formula of “requirements, design, implementation” have dominated during the first attempts to create a skilful development process. The single-pass waterfall has the simplicity of explanation and recall (“do the requirements, then design, and then implement”);

So is the IT industry abandoning waterfall as it matures? Last month Gartner (in a research note entitled “The End of the Waterfall as We Know It” – requires a Gartner subscription) confirmed that waterfall is still the dominant approach across the industry (52% of development projects). They go on to say…

“Quite simply, waterfall methods, when used in the traditional, project-based manner, are inconsistent and risky. Since there are other choices available that have the potential to be more consistent and less risky, it’s time to begin the transition to these methods.”

Seems to me that we are reaching the tipping point as the IT industry moves to adopting lean and agile approaches!

Background Reading



A comical view on Big-Design-Up-Front inherent in a waterfall approach (source:

Abolish Personal KPIs

Continuing in the theme of leaning further and further out on this blog, I’m going to take a pop at Personal KPIs (Management By Objective as they are also known as). They don’t serve Maersk Line. We don’t need ‘em and we should follow a number of leading companies and get rid of them (see references below).

Can you relate to this hypothetical situation?

The CEO requires the VP of sales to “grow sales by 10 percent,” manufacturing VP to “reduce costs by 5 percent,” and VP of finance to “reduce overdue accounts receivable by 7 percent.” Using management-by-objectives, the CEO concentrates on what, not how-the manager determines the latter. To provide incentive, the CEO promises fat bonuses for meeting goals and consequences for those who don’t. Management 101. Carrot and stick. What happens next is predictable. The finance VP gets tough, demanding prompt payment and putting delinquent accounts up for collection. The VP of sales shouts as chronically late-paying but important customers get upset and cancel orders. The manufacturing VP based his production forecast on the higher sales goal and gets stuck with too much inventory at year-end. The VP of finance achieves her goal and gets her bonus, but at great expense. Tempers boil. Teamwork collapses. Sales are down and costs are up. Did the CEO get what he wanted?

Everyone propels himself forward, or tries to, for his own good, on his own life preserver. The organization is the loser.

Deming, the founder of Six Sigma, challenges the notion of setting goals at all.  He said:

If you have a stable system, then there is no use to specify a goal. You will get whatever the system will deliver. If you have not got a stable system, there is no point in setting a goal. There is no way to know what the system will produce.

Hold on a minute. If there are no goals, how can accountability exist? Deming suggests that the job of management is not supervision, but leadership. Management must work on sources of improvement, the intent of quality of product and of service, and on the translation of the intent into design and actual product. The magic ingredient is leadership which he defines as the ability to instil in people a desire and urgency for change. Holding managers accountable for good execution, instead of achieving arbitrary results, puts the emphasis in the right place.

It’s also true that the goals of empowering people, encouraging collaborative teams, and improving the whole system are in direct contradiction with assessing individuals on their performance. The latter is focused on ultimately holding individuals accountable, detracting from a full commitment to the team and organization. The bulk of performance is actually due to the system in which we work, rather than incremental increases in our individual efforts. As such, assessment on those individual efforts is actually an ineffective, if not directly harmful, way of improving overall organizational performance.

Other organisations are finding other ways of distributing pay and bonuses (e.g. W. L. Gore  award pay and bonuses based on how associates rank each other on contribution to overall team performance) and are investing instead in coaching & development to improve performance. We should move in that direction too!

Some reading:


Transforming Maersk Line through continuous innovation

Our industry is in trouble. The most “innovative” thing we have done in the last few years is to simply slow down our ships. Whilst this has been great for absorbing excess capacity, reducing bunker cost and improving reliability, it’s not something that is likely to differentiate for very long because it’s easy for our competitors to copy (everyone is doing it now). It’s also not something that our customers are likely to pay more for.

To really build competitive advantage, what we need is a framework for continuous innovation:  A way of  building products and services that create value much faster. We need to skate to where the puck is going to be, not where it is today.

How might we establish a framework for driving continuous innovation then?

I’ve just finished reading “The Lean Startup” by Eric Ries, and there are five key points that I believe are relevant for us as we seek to innovate our way to creating winning businesses.
Take away #1: Every business case has a set of assumptions

We need to accept the fact that many strategic opportunities have higher risk and inherent uncertainty than tactical fixes – especially when we are looking to increase revenue. It is the risky ideas that unlock new markets, where there is often an asymetric payoff and the potential benefits can be huge.

It can be difficult to establish a direct link between the idea and the vision, and we often have to make leap-of-faith assumptions in our business case:

  • Which customers do we think want this?
  • Are the customers willing to pay higher rates for this product?
  • Can we open up to new markets if we offer this product?
  • Is it feasible for Maersk Line to do this?
Take away #2: Think big start small
Most of us intuitively strive to be part of something big; a big project that will change the way we serve our customers, or a totally new way of shipping containers.
This is reflected in many of the projects we’ve seen at Maersk Line. They typically set out to achieve great visions, but end up falling somewhat short of expectations. For instance, we have learnt from our experience with the X-Leap that adding more people into a project, having multiple work streams in parallel does not make the project go faster. Instead it increases the complexity and coordination costs massively.
The solution is to find a way to break the vision down into smaller increments of value and iterations of quality, allowing us to experiment and validate those leap-of-faith assumptions we had to make.
Building the capability to scale up before scaling up is more solid; and we can only do this by starting small.
Take away #3: Validate your assumptions as early and as cheaply as possible
Developing innovative products and services is a complex process. The reason for this is the nature of the work involved: we do not develop the same idea twice, they all differ in size, and hence variation is inherent in the process. In fact if there is no variation, there is no value-add taking place. But the challenge is that innovation involves high risk and uncertainty.
So how should we deal with risk and uncertainty?
  • Experiment with new ideas as fast as possible, invest the minimum time and money.
  • Experiment with as many ideas as possible at the lowest possible cost.
In Ries’ experience, the experiment needs to be with a real product or service. He is not referring to the prototypes that we show to customers to get feedback.
What he means is building a working version of a product that can be launched to a segment of customers who have the potential to be early adopters. In his view, we need to validate our assumptions with real products or services, simply because what customers say they want might be totally different than what they really want.
This early version of the product or service will not contain some important features that would lead to 100% adoption by our customer base. However it will allow us to validate our leap-of-faith assumptions as early as possible.
Take away #4: Pivot or Persevere as you learn
Stopping a project can be just as hard as it is hard to start it. This is especially true when software is involved; you can always add a feature here and there, make it a little bit better.
The question is: How do we know when we are done?
Implementing actionable metrics will enable us to understand the cause and effect of the choices made. These metrics will guide us to make an informed decision about which direction to take. Of course the performance measures of the delivery teams need to be aligned.
The ability to stop or change direction quickly is critical when you are innovating. After all, who cares about the delivery being on time/on budget/on scope if the solution doesn’t deliver value in the eyes of the customer?
Take away #5: It’s a culture change
Innovation requires us to work and learn together. It requires a discovery mindset. We need to create a culture where people work together as one team. Instead of handovers between several departments, stage gates with approvals, we need to form cross-functional teams that can achieve validated learning.
And teams need to feel encouraged to experiment with new ideas. Validated learning should be celebrated as much as the results achieved. Failures should be acceptable as long as the teams learn something new about what the customer wants and how to build the product.

To create winning businesses for Maersk Line we need to innovate… This requires us to make brave assumptions, start small and validate as quickly as possible pivoting or persevering as required. It also needs us to work together with the right mindset. We can’t avoid the high risk and uncertainty associated with creating new products and services. But we can change how we work to increase the chance that we will succeed.

Read more: