How a 5 year old Agile program went through a strategic realignment

A software program stuck after 5 years running in Agile

  • 90-100 actors, 8 teams, 5 year doing Agile (Scrum)
  • metrics were sinking (velocity, business satisfaction)
  • business was about to drop support and funding
  • friction among the teams (“my Agile is better than yours”), and among the roles (support vs dev, PO vs devs, SM vs the world), among the hierarchical lines (3 hierarchy intertwined in the program)
  • an intricate complexity of legacy software services to talk to

A simple goal: project ROI back in the black

  1. Find a breakthrough strategy to turn the situation around
  2. Work better together as team of team

Approach: Strategic coaching + Agile coaching

  1. With program directors and head of division: change management coaching (inspired by Kotter model of change)
  2. With managers and team leaders: strategic coaching as a leadership circle
    • Bi-weekly coaching to become a highly performing team steering the transformation
    • Strategic Planning and Strategic follow up (workshops)
    • Systemic Thinking
    • Agile management coaching
  3. With Scrum Masters, Product Owners, teams: Agile coaching to step up their game
    • reviewing rituals and practices upon team demand (retrospective, planning, story mapping, etc.)
    • dispelling some misleading practices and myths about Agile
    • introducing sharper Agile tools and practices (facilitation skills, roles and responsibilities workshop, advanced retrospective techniques, etc.)

Outcome: a new dynamic and a situation back to green in 6 month

  • 45 days of coaching over 6 month + yearly follow up for 2 years
  • Program on track / out of “red state” after 1 year
  • Leadership circle remains the spinal chord of the project governance
  • Continuous improvement dynamic still vivid at organisation level
  • Hierarchy lines clarified / streamlined
  • Team restructured as Feature Teams
  • PO working hands in hands with their teams

Startup re-aligned on product vision and renew its innovative edge after scaling up

A growing startup loosing focus on product strategy and delivery

• Located in Jakarta, 50 actors among several development teams, 1 market team, 3 managers

• Many features mismatch with users expressed interest or business focus after delivery

• Mix and match bag of online services, disparate look & feel, due to lack of coordinated product approach

• Local culture of conflict avoidance prevents raising problems and nurture hidden conflicts

• Agile practices, first introduced by an internal Agile enthousiast, need an expert to raise the bar and straighten up several practices as the business scales up

• Most profiles are young (under 30), most product owners and Scrum Masters are new to the role and untrained

Approach – organisation aligned on a product vision + coach performance driven behaviors

1. Align CxO & Product Owners on a shared product vision

• Product workshop : 2 days offsite to reframe product vision, targetted users, user experience, story map and roadmap

• Coach Product Owners with attention to leadership posture toward their team

2. Setup entreprise-wide product ownership through LeSS oriented organisation and practices

• Shift organisation toward Feature Teams & Chapters

• Multi-team backlog setup and associated rituals

• Scaled agile estimates & planning

3. Inspire performance driven behaviors in teams

• Coach Scrum Masters as Agile Facilitators

• Use retrospective as a safe space to explore radical candor-type behaviors (caring disagreement, assertive reformulation, personal feedbacks, …)

• Use PDCA to seek improvement opportunities (collective problem analysis, decision follow up)

• Unleash visual management (walls as information radiator)

• Review and improve Agile rituals

A renewed sense of purpose brings a new forward momentum within 2 months

• ⅓ of features were de-prioritized, several team effort redirected toward more disruptive features, bringing more innovation edge

• Taking advantage of this capability, the company entered two new target markets to solidify growth

• Following the work on product vision, CEO led a brainstorm on the entreprise mission and day to day emphasizing on the enterprise culture

• Staff turnover went from standard to none for the next six month, while still scaling up

• Several young profiles stepped up and asked for more involvment in the organisation

How we combined virtual coaching and local coaching to kickstart a multi-continent, round the clock team of teams

Multi-continent teams caught in a spiral of ever-growing support effort

• 4 teams across South East Asia and South America answering IT backend demand from various business lines 24/7

• A no barrier policy for answering demands led to excellent support ratings but increasingly harder to sustain as demand grows

• IT teams needs to step up as a force of innovation as a technological disruption is foreseen to hit the business within 5 years

• Agile practices are to be experimented

• To make space for a product strategy balancing between support and value-adding development

• To increase team development efficiency

The teammates have never worked in Agile nor been trained

• 12H time zone difference renders every synchronisation a challenge

Our approach – coach the teams as a SAFe Agile Release Train led by a virtual Program team

• Worked with a pair coach based in South America

1. Onboard teams in Agile at each location with intense 2 weeks coaching

• Agile training & Agile Roles coaching

• Team coaching (values, vision, roles)

• Fast paced Agile iterations for accelerated learning

• Alternate trainings as needed through coachings for maximum learnin

2. Adapt Program rituals and artefacts to realities of across-the-globe communications: time zones, culture, alignment

• define synchronisation points in a minimalistic manner

• define protocols and artefacts templates to help team align on wordings

• Experiment about effective coaches synchronisation

3. Virtually coach a distributed SAFe Program team across 3 continents

• Online team training and coaching

• Remote meeting facilitation experiments

• Relayed with face to face coaching at each location

• In coordination with US Agile supervision entity

After early struggles on team synchronisation, the teams rose to a force of innovation for the organisation within 3 months

• Teams fully autonomous in Agile, building their own custom practices after 3 month

• Program Team found its footing and took the lead of its own SAFe experiment within 3 weeks

• New profiles have emerged as Product Owner with a fresh sense of leadership

• Team has started challenging and proposing business users to help them better

• Learnings have help reshaped coaching approach for upcoming Agile Program transformation on other business branches

• Product Owners and Program Team have become valued mentors for other programs

Make my Facebook wall great again! by applying technical debt principles

18 month ago my facebook was a mess. I disliked it, most posts were from people I had no recall, and too many times the posts were troll, people whining about the world, if not purely xenophobe. Every 5 minutes there was 30 new posts, so I couldn’t catch up with anything.

As thousands of friends were stacked from my past involvement in Rotaract (a worldwide humanitarian organization related to Rotary) a big spring clean up was just too big to be done at once -been there, failed several times. When browsing my contact list it’s hard to find who’s been posting what. Some I didn’t recall and some I’m happy to keep as “maybe” contacts when I recall them. Reviewing each FB friend takes 30s to 1minute… I’m set for dozens of hours.

I was about to give up Facebook at all (I barely checked it every 3 month already), until I decided to go backpacking for a few months in South Asia.

Then I had to use FB again. Many travelers use it as a go-to communication platform, it’s a cheap and easy way to send news to family and friends. Then there’s the ton of pictures you want saved on the cloud before your phone get wasted in sea water (been there). I had to.

Quick filter with a split-second rule

As a last resort I went for another approach : to forget the past, then to focus on practical issues only as they appear. As for Facebook it came down to one simple rule :

if I strongly dislike your post, I unfollow you.

Literally 1 second.

In less than 2 days, a Pareto law of annoyance was revealed before my eyes : 80% of the annoying posts are generated by 20% of your Facebook contacts. Actually more like 90%/10%.

Suddenly my wall became a place I had pleasure to go to again.

Unexpected discoveries

Originally I learned that approach in dealing with technical debt in software development : you give up solving the whole mess proactively and just start reacting to bugs as they are discovered or rediscovered. Here I had a  few more learnings.

1) I realised what I was looking for along the way

  • the positive and appreciative people
  • the proactive and socially progressists
  • sharp humour
  • Internet / music curation of my liking
  • news of people I care about
  • news of parts of the world they care about

Those who annoyed me were

  • the ones whining about anything
  • the pessimistics and cynics turning anything negatively
  • the lecturers (“Do a detox diet coz you suck at eating, all right?”)
  • the Facebook frenzies (one post every 10 minutes)
  • the boring (“hey my bus is late”)

2) My biggest assumption about the need of a spring cleanup appears wrong

my forgotten friends are mostly silent. Some become active sometimes and are actually nice contributors to my wall.

3) Friends can be a very efficient source of world and local news

This comes with a clear filtering bias but this bias is more obvious to spot than bias in conventional media (or my own choice of news media)

Not fun conclusion : in the wake of the Paris attack 3 month later I was away in Hong Kong. My Facebook became my primary point of communication and news. I’m glad I had this place to be surrounded by these good people and read their fine words.

Avoiding confusion about what iterations means

In agile, we call Iteration a fixed time period. In Scrum (one of the agile methods), an iteration is called a Sprint. By that we mean a fixed cadence of work.

I witnessed several trainings struggling on the same topic, trainers and attenders alike. I heard many people I coached mixing notions right out of a Scrum training.

So let’s see if we can spell out this confusion for the future.

Overusing the Sprint / Iteration words

Many times I hear the word sprint used for “a fragment of the product” or “an amount of work to do”. I guess it’s originally a shortcut from “fragment of product done in the time of a Sprint”, or “amount of work planned for the time of the next Sprint”.

However, for someone not used to agile, it’s confusing. Trainer said it’s a fixed time period. Then trainer seems to say it’s an amount of work. There’s something that magically make an amount of work fit in a fixed time frame. Coz for someone discovering agile it’s painted with mystery.

In a recent training our attenders where from waterfall world (where you plan according to effort), and started ask questions mixing notions of effort and time. The other trainer and I have been paddling for 20 minutes not knowing why our trainees kept mixing notions despite our explanations… until I realized we abused the meaning of iteration. So much for clarity.

The trainees didn’t see that in Agile we are now planning in term of time box, giving a pace of work where the amount of result is variable. In their previous world you start planning from effort that will span in phases of variable durations.

Classic check that you failed to lead to cadence thinking

If you don’t sort this early, later on the project they will be surprised when through the course of a sprint (again, a fixed time cadence) throughput don’t go as planned. They weren’t prepared for that since they weren’t driven away from there previous “effort” frame of reference. Again, they’re confused.

Usually I let it go since after a few sprint they will get it, but in the meantime they struggle and they are unable to explain it to other project partners and stakeholders that are not used to agile projects.

Well, they get it… actually I’ve seen Product Owners and even Scrum Masters still mixing notions after a year. I also saw agile veteran projects, year longed, intoxified by the notion of planned throughput.

A few classic tense to avoid

Guess what ? I saw coach and trainers also not being able to precisely sort the notion. (yes, me angry here)

Here’s a few quotes I heard from trainers that led trainees into mixing the two notions

  • “you did all the Sprint”, “you didn’t do all your Sprint”. Of course they did. How could you fail or succeed 2 weeks?

    Instead, you can say you achieved in the course of the spring less than you predicted, or more.

  • “let’s plan your releases into iterations”. You just can’t decide that.

    Instead, you can say (after the project has acquired its rhythm), “let’s try to predict what will be done at each iteration”.

  • “we will report the sprint on the next sprint”. Again, it may be just that you are shortcutting words, but for those discovering agile, it’s confusing. Instead you can say “During the next sprint we will work on the user stories that aren’t Done”

Avoiding the big trap of the initial project -planning-

After starting to spot the confusion, I realized it came mostly during the first initial roadmap creation, and can be avoided there.

Today I pay great attention to not use the notion of time when doing the first story map and roadmap definition (inventorying the project features scope and setting it into successive interesting releases).

By extension I don’t use the word iteration or sprint either.

I carefully choose my words since it may be that my coachees has been misled during a previous training (more on that later).

So far, it works, I have very little questions that mixes the nations. So the confusion went from me.

Practically :

when I do a roadmap, I ask the product owner to prioritize items typically by one of these two strategies :

  • “Buy a feature” exercise

    “If you could have 3 of these features in short term (or Epic, or macro-story whichever terminology you use), which one would you like to see done and working ? Then which ones would you pick next ? etc”. See ? Sequence thinking, but no notion of time.

  • Dichotomic prioritization

    “here’s a line, this is your mid-project. What would you see first ? What would you see next ?” (you can also use “must have / should have / why not, or any criteria to make prioritization happen)

    Then I draw another line in the middle of the first and second quadrant. (interesting variant : I draw 4 lines and ask for 4 releases directly ; let’s not digress)

    At this time, I never introduced the notion of When things are going to get done. Only what should comes first.

The notion of time will only be introduced on a next estimates workshop. Then I will follow the advice of J.Rothman and only use the words predictions.

Erm, Scrum industry, wtf ?

You mind if I end with a rant ? Gotta unload my heart. It was my first impulsion into writing this.

Scrum industry, you’re a powerful machine, you help popularizing agile and raise new generations of Agile Trainers and coach by the hundreds. But when you fuck up such detail we coach in the field have a hard time cleaning up the mess.

And no, don’t look away, the mistake can’t be made in flow-style Agile (Kanban and such) since we just speak about cadence and don’t even talk about iterations planning. I spotted that constantly will people coming out from various Scrum trainings.

So to my beloved pairs teaching Scrum : can you check that the confusion of iteration = time is not engraved in your training slide ? Thank you very much

Bisous bisous