Manager @ Gemba Checklist

(Prepared with the help of Agile Zen Master, Kevin Lynch)

Things to do at Gemba

dos-and-donts-when-exhibiting339199172.jpg

  • Watch every single task of a PBI (every single one, make no assumption that you know how it’ll get done – see it with your own eyes).

  • Start a list of Tech Debt – prioritize it using business terms (no techie jargon)

  • Don’t fix everything as it happens; watch for a recurring pattern and commit to fixing one thing

  • Have lunch with the teams

  • Check the scrum rules (there aren’t many, so check to see if they are doing them)

  • Lighten the mood / elevate the tone

  • Talk about why the work is important to the client

  • Give short and non-emotional feedback in the moment and regularly

  • Look at the sprint plan – is the team adjusting?  Accounting for risks?

  • If team dynamics are ‘off’; observe!  Try to find out the causes and conditions driving the individual behavior(s). What about the whole is impacting the one?

  • Lead sprint planning and try to ensure all tasks are broken down to less than 4 hours

  • Lead a retrospective

  • Lead a Product Backlog Refinement session

Things not to do at Gemba

  • Don’t worry about looking dumb

  • Don’t worry about trying to impress the team

  • Don’t rush to judgement

  • Leave for long periods of time

  • Get frustrated at the first sign of issues/problems

  • Constantly check phone or email

  • Check-out

Questions to ask the team or team member

  • How are you doing?

  • Can I pair with you?

  • Is it worth communicating this to the product owner?

  • Would you mind explaining "x" to me

  • Tell me more about why you do “x” this way?

  • How is this tested?

  • Can that be automated?

  • Can this step be done earlier in the process?

  • How will this impact quality?

  • Should this be documented for others?

  • How will this impact the customer?

  • Has this item met the definition of done?

  • Does the process of delivering vary for some PBIs (where?  If so, why?)

  • Has this item met the definition of Done?

  • What’s on your mind?

Questions to ask myself

  • Is this an antiquated process that I can remove?

  • Is there a teachable moment here?

  • Can I make their job more enjoyable?

  • Is this a value added activity?

  • Is this a blocker I should remove or a blocker I should teach the team to remove?

  • Is this dysfunction related a historic management decision? 

  • How is the team interacting with the greater organization?

  • Is this a teachable moment for the rest of the team?

  • What skills should I learn in the future to make me more effective at Gemba?

  • Is there workplace suffering that I could reduce or eliminate?

How to run a SWOT analyses workshop in four hours

Background

I’ve always resisted using SWOT analyses. To me it was a tool that large consultancies used to charge companies a lot of money. They send in dozens of analysts to produce a huge binder that is never actioned.

Recently a client asked me to help them with a SWOT analyses of there organization and I was forced to revisit my thinking and biases.

How can I make it my own?

The SWOT analyses is a tool created by a management consultant in the 60’s named Albert Humphries. He created a framework for companies to analyze their Strengths Weaknesses, opportunities and Threats.

Rather then send in a small army of analyses I decided to trust that the collective wisdom of the leadership team would have the necessary information they need to do a comprehensive SWOT analyses. That also has the added benefit of the team owning the result rather than renting the result from a third party.

Preparation

Before the session, I divided the room into four sections and placed a flip chart in each section. I labeled each flip chart either STRENGTH, WEAKNESS, OPPORTUNITIES or THREATS.

At the base of each flip chart I placed appropriately colored Post-It notes.

The session

  1. I asked the leadership team to self-organize into groups of four.

  2. I gave them 25 minutes to generate as many ideas as they can(one-per Post it)

  3. After 25 minutes, I had one person remain to explain the board and the rest rotate counter clock-wise.

  4. During the next round, the presenter would rotate leaving behind a new presenter.

  5. We did this five times(25m,20m, 15,10m, 10m)

  6. I then brought the 4 flip charts to a central location for a debrief. After reviewing them and removing duplication I have each member three dots to vote what they felt where:

    1. The greatest strength

    2. The biggest weakness

    3. The greatest opportunity

    4. The most dangerous threat.

  7. They had three dots per sheet, that could be used in any way they want, three dots for a single post it or distributed.

  8. After this, I prioritized based on the number of dots and asked the question:

  9. Is this in fact the greatest two strength, weakness, opportunity and threats?

  10. After discussion and reorientation, we had the top 2,3 for each.

  11. After a break we took the top 2-3 from each and placed them on a separate board.

  12. I divided the group into four groups to generate as many ideas as we can and asked the following questions (one per team)

    1. What projects can we undertake to make these strengths even stronger

    2. What projects can we undertake to eliminate these weaknesses

    3. What projects can we undertake to capitalize on these weaknesses

    4. What projects can we undertake to turn these threats into opportunities

  13. Similar to above, we rotated until everyone had a chance to add their ideas

  14. Dot vote to select the most impactful ideas with the least effort.

Further resources

  • More on SWOT: https://www.professionalacademy.com/blogs-and-advice/marketing-theories---swot-analysis

  • Dot-voting: http://dotmocracy.org/dot-voting/

  • Diverge Merge: https://sloanreview.mit.edu/article/diverge-before-you-converge-tips-for-creative-brainstorming/

My 5 Laws of Facilitation

Click here for the Presentation Mindmap

Law # 1 - Prepare, but don't stick to the plan

You need to come in prepared. I usually spend twice as long as the session itself to prepare for it. The trick is to be prepared to let the plan go. Have a sample agenda ready. There's nothing like killing a great discussion by sticking hard to an agenda and forcing people to move on. Creativity gets stifled and peoples' minds remain on the previous discussion, as you try to move onto the next subject.

One of the biggest novice mistakes a person can make is forcing a conclusion to a thoughtful discussion. Time boxing is an art not  science. 

Flexibility is key to this first law.  

Law # 2 - 20/80

The key to this law is remembering it is not about you, it is about the people in the room. This is not a presentation. This requires a different set of skills. Don't worry about what you are going to say. The more you are focused on yourself, rather than the group, the more likely you are to stagnate the facilitation. Make sure the attention is off of you, do not stand in the front of the room especially when discussion is going on. See Sharon Bowman's technique for training from the back of the room.

For the 20% of the time you are talking, your role is to ask questions, as well as synthesizing what people are saying in the discussion. Synthesis should come after someone has given a long and elaborate explanation that can really be shortened into a Tweet, give them that Tweet so they understand that discussion isn't a place for wasting others time with drawn out statements.

For the 80% of the time that you are being a listener, you need to develop two habits: Active listening (see below) and reading the room. Reading the room is an art. If there is just two people talking back and forth, that means the discussion is falling flat. Stop those people who dominate the discussion with humor, or volunteer someone who has been quiet to give their thoughts. It is your duty to make sure everyone is contributing. If people are having trouble keeping their eyes open, something is going wrong and an adjustment needs to be made. But by the same token, if everyone is ultra engaged in what is going on, do not interrupt, unless the discussion has become repetitive and what is being said is not adding benefit overall. 

Make sure everyone is working. This can be accomplished by checking in on individual groups. Ask each member to use one word that describes their mood at that moment. Ask them to anonymously describe how safe they're feeling on a sheet of paper, and then read it back to the group. Have everyone say what one thing they want to accomplish in the meeting that day. 

Active listening can be broken into four parts: 

1) Contact

Listen to each participant and reinforce what is being said by maintaining eye contact and/or non-verbal responses

2) Absorb

Take in what each person says as well as their body language without judgment or evaluation.

3) Feedback

Paraphrase and summarize what the speaker says back to the speaker.

4) Confirm

Get confirmation from the speaker that you understand their points accurately.

Law #3 - Find the Qwan

The goal of the facilitation is to create a shared understanding amongst the group, it should ideally be a shared mental model. Your job is to take their ideas and help them build towards that common model. The tools are your disposal are:

The 5 whys: Simple enough, ask why continuously to get to the underlying cause or reason for a certain problem, or goal.  

Casual loop diagram: A visualization of how different variables of a system are interrelated. 

Sequence diagram: Shows how objects relate to each other and in what specific order. 

Influence diagram: A graphical representation of a decision situation. It shows all the key elements that go into the decision as well as outcome effects.  Great video by Kent Beck using influence diagram. 

The Qwan is found when there is a collective "aha" moment. When everyone gets on the same page, and has the same understanding, your job is complete. 

Law #4 - It should be fun

There might be nothing worse for a groups creativity and morale than monotony. You should start off by disorienting your group. Change the location of the session, take them outdoors if the weather is nice. Make the group do something that seems completely random, like making a group of MD's do air squats. It makes everyone seem a bit ridiculous and gives everyone the courage to be seen failing. 

Keep the sessions light-hearted. Be self-deprecating and employ humor into your facilitation technique, it keeps people lively.  People who are generally uncomfortable in group situations, become more comfortable with humor and group laughter. This allows everyone to feel like they can share their ideas, and the creativity flows even better this way. You can even play music, and start singing along and force others to sing as well (https://www.youtube.com/watch?v=KCy7lLQwToI). The measures of success for this law are smiles and laughter. 

Law #5 - Continuously Improve

Your first experiences as a facilitator likely won't be the best, so take every opportunity to practice facilitation. It may sound silly, but you can even try it with your friends or your kids at the dinner table. Take a step back from dominating the conversation and get others to throw their ideas out there. You'll gain subtle practice in asking the right types of questions in a comfortable environment. More practically, get feedback from the sessions you facilitate. Ask them what they liked, what they didn't like. Also, make sure to observe other facilitators, what do they do that intrigues you? When do you find yourself most engaged? And then add those things to your own arsenal. It's okay to steal from others if it makes you better!

Hackers and Slackers (Guest Post)

By Lynette A Cain (Scrum Master, Former Actress, Improv & overall awesome human)

Think back to the old Waterfall Days - not so long ago - and imagine the office at 5 PM. Most of the staff is packing up their bags, shutting down their computers, and has their minds on dinner. At 6 PM a handful of people remain, trying to finish up that last email or task. By 7 PM, only three are left: Molly, Evan, and Linda. Molly has been in the department for over eight years. She knows the most complicated rules engine code inside and out, and everyone knows it. The whole team runs their client-related tests through Evan. He has a dozen polite ways to tell the client that the problem is on their end without making his executive director nervous. Linda is the only person the department trusts to break down an intricate client request. Molly, Evan, and Linda have a bit of running banter, when they see each other at the water cooler: they’re the heroes, the ones who can fly through dozens of tasks after the slackers go home. They enjoy the rush of putting out fires and rescuing projects. Their peers quietly acknowledge their prowess. The heroes’ managers know they’re saving the day. It all seems to work.

Now let’s come back to the present time, in which Scrum has replaced Waterfall. Molly, Evan, and Linda each chose a different Scrum team. As usual, Molly, Evan, and Linda still rescue the department, while their teammates do…very little. Their lack of delivery is clearer, now. The “slackers” have little to report at daily Scrums while the heroes have a long list of what they completed and what they have in progress. The managers, and their own managers, wonder how they can get everyone else to work with the same sense of urgency. The Scrum Masters see waste, an unsustainable pace, and other symptoms something is very wrong here.  The heroes don’t want to hear the Scrum Masters’ observations.  Molly, Evan, Linda still know they are carrying the department and feel the Scrum Masters add no value - where are they at 7 PM while the heroes are still working? Long gone.

It’s clear the heroes are valued team members. But what if, in fact, they’re also bottlenecks? The Theory of Constraints tells us the entire team can only work as fast as they can. The knowledge and experience Molly, Evan, and Linda have is limited to them. If Evan gets hit by a bus tomorrow (and he could, since he’s so tired he’s barely aware of his surroundings), so much for the client testing. So why, knowing that Molly, Evan, and Linda are so valuable, isn’t anyone learning from them? They’re endlessly busy executing, with no time to mentor or teach new employees. Other team members are bored and frustrated because they want to do more than busy work.  They aren’t slacking; they’re frozen assets, unable to reach their potential.

Something has to change. The Scrum Masters propose an experiment: for a sprint, Molly, Evan, and Linda are not allowed to take on sprint deliverables – they are reserved exclusively as teachers and mentors. In the short term, this experiment is incredibly painful. The Product Owner sees a sharp temporary drop in velocity. The heroes sit on their hands, willing themselves not to take over and save the day as they have so many times before. Theirs is, in many ways, the biggest leap of faith. Surrendering knowledge and expertise makes them feel vulnerable. Who are they, if they aren’t always SMEs? Can they learn something new, becoming humble beginners again? The frozen assets, the people who weren’t previously meaningful contributors, are also forced to step outside of their comfort zones, unable to vanish into the background. They now carry responsibility for delivery. They fear, what if I can’t learn fast enough? The Scrum Masters observe, encourage, facilitate…but mostly worry that the results of the experiment will not come fast enough to make the sacrifice worth it in the eyes of the Product Owner and managers.

The experiment runs for a sprint, and then another. The product team gets benefit from starting to relieve the bottlenecks, and decides to continue in this manner. They document everything the heroes have been doing, so the next time that Molly fixes an obscure rules engine bug, someone else knows how to do it. Molly’s mentees are accountable for retaining and spreading their new knowledge; they are now the first responders. Linda and Evan take similar approaches, so that they are able to spend more and more time anticipating ways to add value instead of reacting to problems.

For a while, everyone works as if this is temporary, and some day Molly, Evan, and Linda will all return to their former habits when the team is up against a tough deadline. But somewhere along the way, Molly takes a vacation. Evan gets to learn performance testing, and it’s a nice change of pace. Linda feels a little exposed, since the teammates that never used to touch client requests have learned her tricks of the trade. She may doubt her value, but they don’t. They’re impressed by what a great teacher she is.

The truth is there are many experiments that could allow the teams to break through the bottlenecks. All of them come back to control, though: the heroes must surrender their burdens to both lighten their own loads, and give the others a chance to be meaningful contributors. Molly, Evan, and Linda aren’t the whole department. Once they don’t have to be, they will get to (or have to) turn to their coworkers and see true peers: equals, partners, and the reason they go home for dinner on time tonight.

Team based conference. A field experiment

Introduction

The first LeSS conference started with assumptions, questions and unknowns. 

One assumption was that most people come to conferences wanting to be entertained through interesting and inspiring speeches with other interesting people. As fun as that may be, the actual benefit to the conference attendee seems minimal. At best, they walk away inspired, a couple of new thoughts & contacts. What we wanted, was a deeper learning experience through interactions over traditional speeches. The idea of teams became a central theme of the conference. This raised a number questions.

Can a team of five full-time consultants who have never organized a conference before...organize a conference using Slack? Can we create a conference optimized for learning rather than simply entertainment? Would conference attendees be willing to participate in tactile exercises rather than simply listening to interesting speeches? Would (given the opportunity to opt-out) attendees create teams designed to encourage learning through dialogue? How do you even form teams of 170 people that have never met each other?

The only way to answer these questions was through experimentation; specifically a field experiment: 

Field experiments are so named to distinguish them from laboratory experiments, which enforce scientific control by testing a hypothesis in the artificial and highly controlled setting of a laboratory. Often used in the social sciences, and especially in economic analyses of education and health interventions, field experiments have the advantage that outcomes are observed in a natural setting rather than in a contrived laboratory environment. For this reason, field experiments are sometimes seen as having higher external validity than laboratory experiments. However, like natural experiments, field experiments suffer from the possibility of contamination: experimental conditions can be controlled with more precision and certainty in the lab. Yet some phenomena (e.g., voter turnout in an election) cannot be easily studied in a laboratory -Wikipediea

The experiment  

The hypothesis

Having conference attendees self-organize into teams will:

  • Increases the chances that you will try team self-design in their own company
  • Accelerate learning through dialogue and creating a product
  • Longer lasting relationships after the conference
  • More fun

The procedure

1] Bejewl each attendee
As part of the registration process, each attendee was asked 4 questions. Based on the answers, each attendee received a jewel to affix to their badges.

  1. Are you a certified LeSS practitioner
  2. Are you a developer
  3. Have you ever tried implementing large scale scrum
  4. Do you have any visual artistic abilities

2] Form the teams

I had originally budgeted for 75 minutes. The whole process took roughly 60 minutes.  What I covered:

  1. Explain the purpose and the background of the team formation exercise (see article)
  2. Team formation guide(see deck to the right)
  3. Form, storm, norm, perform in 5 minutes. After forming, I asked each team to get to know each other through a name association game and one interesting fact about themselves. 
  4. Brand the team. Each team selected a name and some even created a logo.
  5. Tweet a picture of the team(see below). My idea here was that there is something about taking a picture and tweeting it to the world that would make the teams more "real".
  6. Explain next steps: 
    1. Meet regularly for 30 over the next two days
    2. Create potentially publishable content for the scaling community
    3. Sprint bazaar at the end of the conference

3] Re-calibrate the teams, create a product & Review

  • Re-calibrate the teams (20 minutes). On the second day, Bas facilitated a re-calibration of the teams where teams could disband or choose to join another team.
  • 60 minutes to create a product. Many teams had been reflecting by creating visualizations of the conference. These final 60 minutes were to allow the teams to focus on the creation of an artifact that would be demonstrated at the sprint bazaar.
  • Sprint Bazaar and choose a winning team.
    1. Each conference attendee was given 30,000 in LeSS money. (We are a very wealthy conference :)
    2. Craig reviewed the concepts behind a sprint review
    3. Although, competition is not part of an actual sprint review, we decided that teams competing using the LeSS money would be fun.
    4. Conference attendees were given 6 cycles of 5 minutes to review the team output.
    5. A single team won by creating a very clever game.

Observations & Initial data

  • ~170 attendees
  • 5 opted out of the exercise 
  • ~18 teams were formed
  • ~11 products were created
  • 1 potentially publishable content
  • ~5 teams disbanded on the first and second day
  • Teams formed in less than 10 minutes
  • Attendees reported that the creation potentially shippable content was too aggressive a target for teams

Survey feedback

(Raw Data)

Did the teams makes the conference more fun

Did the teams increase learning

Should we do this expirement next year?

Did forming the teams increase the likelyhood that you would attempt this expirement

Did the teams increase the chances of longer lasting relationships than usual conferences

Improvement suggestions

Make process and idea clearer from the start.. Make upper limit smaller Make purpose & goal clearer Introduce a "PO"? Written instructions could probably help? -Magnus Vestin
I think when we started the team, the message wasn't clear i.e. what are we supposed to do. So clarifying that message up up-front would have helped. E.g. Creating a LeSS product based on learning from Conference and your team member knowledge could be a good description. I think we should introduce the concept of 'traveler' as well in this experiment. That way if a team is struggling with anything can call out to the traveler for any immediate help if required. -Dinesh Sharma
Give people more time to reflect, get coffee, do a toilet break etc. the team sessions where the moment where we could reflect, but most where getting coffee, visiting the toilet. i much liked the team idea.the different views on the subjects give me a broader understanding of the sessions.  -Just Meddens
  • Potentially publishable goal was too confusing (x4)
  • Provide more information about how teams form, storm, norm & perform.
  • Create teams around common interests 

Some tweets

The teams (not complete)

The mango revolution. A parable

Somewhere, in a warmer part of the world, there was an unhappy mango farmer named Becu. Becu dreamed of a living in a non-tyrannical regime. Life, in other parts of the world, seemed so much better. People had freedom, self-determination...not to mention nicer things. 

One day he had enough. Becu gathered the other local mango farmers and gave an impassioned speech about being free.

The mango farmers descended on the local square and would not be silenced. Soon the square was overflowing with people who also dreamed of being free from the tyranny of the oppressive regime. 

The mango farmers inspired a nation. Millions of people descended on local squares.

Eventually, the tyrannical government was replaced with a freely elected government resembling the ones on T.V.

The hope was palpable. The mango revolution was decalared a success. 

The mango farmers went home to their mango farms and went back to work farming mangos.

The mango farmers did what they always did, dropped off their produce in the same collection point they always did, except, there was no one there to pick them up as the central planning function had also collapsed. Millions of mangos went bad. 

Week after week the mangos would spoil. The mango farmers began to grow unhappy and blame the new government. 

Months later, with millions of spoiled mangos, the mango farmers once again descended into the streets, calling for the removal of the new government and a restoration to the way things were. 

The former system was restored.

Everything went back to normal with three notable exceptions; the original mango farmer was exiled, the restored regime became far more tyrannical and mangos were outlawed as a subversive fruit. And so ended the mango revolution...

Personal reflections

“There is nothing more difficult to take in hand, more perilous to conduct, or more uncertain in its success, than to take the lead in the introduction of a new order of things ”
— Niccolo Machiavelli

This story should be familiar to anyone who has attempted to change a large organization. I have personally seen this story play out a number of times in large organizational systems.

"They did too much too fast." "We needed evolution not revolution." "They didn't understand our culture" Are statements I have heard numerous times. 

Perhaps that is correct. 

What is undeniable is that the system has changed. Given enough time the system usually benefits from that change although, those who originated it are rarely ever given credit.

  • Introducing a large change into a stable system is insanely difficult. If its not hard, you are probably not changing much.
  • It will take twice as long as you think and you will be given half the time to do it. "Cause and effect are not closely related in time and space." -The fifth discipline. 
  • You will most likely be blamed. Think Michael Burry.
  • Given enough time the change will succeed and you probably not be given credit unless you managed to ride it out. Think Michael Burry again.
  • Do not attempt a large scale organizational change if you do not have the time and power to change it. Think Steve Jobs return to Apple. 
  • Personally, there is no greater calling than trying to change things for the better however difficult. 

Agile is dead. Long live waterfall.

Update: This was a poor attempt at an April fools joke :)

The Agile cult has been maligning waterfall for nearly a decade and a half. They would want you to believe that no software project was successful before 17 middle-aged white guys met in a ski lodge in 2001. Alas, that is not the case. We went to the moon, designed air traffic control systems and created the world wide web. It’s time to remove the wool from over your eyes and realize, that perhaps, waterfall, is the good guy. 

Flow is the talk of the town these days. Waterfalls LITERALLY flow. Yes, they literally flow. A big boulder, no problem, it flows around it. Elegant…Seamless..

Waterfall is far less stressful than agile. First of all, it’s very name is soothing. Say it with me, “Waaaterfall" My heart rate dipped by 5bpm as I said it. Just saying 'agile' or 'scrum' gives me anxiety. So abrupt…

Waterfall is magic. No matter how big the project is, it can be completed in 3 years. Year 1 is the requirements and architectural framework phase. Year 2 is 'Phase 1a'. Year 3 (where the magic happens) is when everything else gets done.

Waterfall is far less stressful. Whereas Agile projects tell you that you are screwed from the start, waterfall gives you two years of “green” RAG status. When the project eventually goes “red” all you have to do is replace the project managers who were out of their depth.

Waterfall is eco-friendly. All you need is Microsoft project and powerpoint to run any size project. Agile, on the other hand, is littering the world with post-it notes and magic whiteboard. How many trees have to die for Agile?

What’s wrong with big bang releases? If it was good enough for the world’s first large-scale project, the universe itself, why isn’t it good enough for building an accounting system?

I’m sorry waterfall. I was wrong about you.

Happy April 1

Waaaterfall

The story of the flying turtle

a version drawn by one of my clients

a version drawn by one of my clients

I’m a slow walker, but I never walk back - Abraham Lincoln

When I was running in the 2012 Marathon de Sables, I had to adopt a run/walk protocol due to an injury I had sustained during training. What this allowed me to do was maintain a constant pace throughout the race. I had no reason to stop and rest, I ate while I walked. I was not fast, but I was consistent. During one of the stages, I happened by an Italian competitor who had a giant turtle tattooed onto his calf. A perfect metaphor for what I was doing. It was my own “follow the white rabbit moment.”

Every day would be the same: most of the competitors would pass me in the morning and would fade during the remainder of the day. I, on the other hand, would get stronger during the day.  

Later I found out I was the third place American. 

The flying turtle became the logo of my consultancy practice and the lessons I learned became corner stone principles.

 

The Magical Three Year Strategy

“Most people overestimate what they can do in one year, and underestimate what they can do in ten years”
— Bill Gates
  • How long does it take to replace an antiquated system that has been around for decades? 3 Years
  • How long does it take to build a strategic system that could leap frog the competition? 3 Years
  • How long does it to take to transform your organization to Agile? 3 years
  • How long does it take to do anything that requires large strategic investment? You guessed it, 3 years.

What gets presented is a Gantt chart that looks something like this:

Phase 1: Will be delivered 9 months after the money is secured and will deliver something called the "framework"

Phase 2: Will be delivered 6 months after Phase and will delivery the first valuable delivery

Phase 3 (where the magic happens): Will get delivered at the end of the three years and will deliver all the value

What actually happens:

Phase 1 gets continuously delayed until a senior manager threatens that heads will roll.  In order to meet said manager’s expectations, Phase 1 gets rebranded to Phase 1a and the scope is cut by 30 percent.

After 2 years, Phase 1a eventually gets delivered and drinks are had.

Discussions about how this is not working and about how to wrap it up nicely begin to replace other discussions.

One or two PM casualties later the project is shelved and another system remains to be decommissioned by another 3 year strategy.

I understand now why the answer is always three years. It looks great on a deck, and is neat and tidy. That's not what interests me. What I find fascinating is how intelligent, well-paid managers can sign-on to something they know is not possible over and over again.

Do people really believe it? Does it take three years to forget? I know the people presenting the three year strategy don't really believe it. So what is their motivation? Simple: They want the money. They are not going to get millions in investment if they tell the simple truth: it will probably take about a decade to do what we promise on page one of the deck. So they promise the impossible.

My assertion is that major banks are part of a system that is beholden to share price and providing shareholder value. CxO’s don’t have a long shelf life, 3-5 years. Their attention span is, understandably, 3 years. They are not going to sign-off on a very expensive program that will last longer than their perceived tenure.

Don't get me wrong, you can build lots of stuff in three years. It just takes far longer to realize the benefit, which is often the reason you start the project to begin with.

If your plan is to replace many systems with one system, or build a platform that will leap frog your competitors, chances are it will take at least twice as long as you have quoted on paper.

“The tyranny of the waterfall; The illusion command and control; The belief in magic; and The era of opacity.”
— Ken Schawaber discussing the four obstacles

If any of the above rings true to you, your project is doomed to fail before you begin, and your time is better spent tidying up your existing infrastructure.

Make it last...Toilet paper financing

Money is like toilet paper, if you have too much you will waste your resources and run out very quickly. Give a person an allowance of one roll of toilet paper and they will make sure they use their limited resources appropriately. Give them too much (e.g. 30 million in the first year) and they will waste it on cleaning up spills in the kitchen.

Give the team as much toilet paper as they need and no more. Down the line, they may have Mexican and need twice as much toilet paper. That’s fine. But the key is to make it last the 5-10 years that will be required to actually execute on the strategy.

You can also avoid the above by going "tactical"...

Why do tactical projects live forever and strategic projects die young?

“A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system. ”
— Gall's Law

Tactical

  • They start with a well understood business problem. We need a system that allows us to enter market X or that can allocate via fix/swift or we need a way to see all our clients positions across many disparate systems.

  • Sense of urgency

  • They use existing infrastructure or buy something out of the box.

  • Because it’s tactical, you don’t spend a year building a future proof architecture or gathering requirements. These things are done on a JBGE (Just barely good enough) basis

  • They fly under the radar

All of the above means that the system is up and running very quickly and the feedback cycle is short.

So this solution, let’s call it, Back Office Reporting aGregator, or BORG for short is now in production and is used for equity client reporting.

What happens next is how BORG grows. Manager A is talking to Manager B about wanting to do a transaction store. Manager A says you should “check-out” BORG, it’s tactical, but it has aggregated client positions. All you have to do is extent the feed to include transactions and voila you have a transaction store. It’s tactical, but you can use it until that strategic solution is complete.

BORG now has aggregated client positions and allocations.

Next an operations manager says if we can get fails data and so on and so forth…

Before you know it BORG is being fed by every major system in the bank all while waiting to be replaced by the strategic system, which gets attempted many times but never ever succeeds.

Strategic Programs 

Now, let’s look at projects that fail. You can usually spot some of these doomed programs through the name alone. They usually begin with:  Cross asset class, Global or Strategic

Let’s make up a fictional project to highlight what usually happens. We’ll call this project EnterPrIse Cross Functional Asset Integration Layer (EPICFAIL).

EPICFAIL has many of the characteristics of large programs in investment banks that get started and stopped every day.

  • A weighty deck prepared by a reputable consultancy. Usually bound in one of those thick white binders

  • Lots of senior oversight and governance

  • Long requirements gathering process with lots and lots of sign-off in blood which of course leads to even longer sign-off processes because people know they only get one chance

  • Strong change control process

  • Big expectations and promises

  • Distributed and silo'd teams with some matrix management thrown in for good measure

  • Politics between technology and change management

  • Architecture oversight

  • Really good project manager/program manager to hold it all together

  • A three year deadline

I leave you to draw your own conclusions :) 

The Agile Mindset

During a retrospective with a client, we did an exercise called 5-whys to try and uncover the underlying reason behind the lack of focus on production. One enlightened developer provided a valuable piece of insight when he noted that we *may* still be in a “waterfall mind-set,” hence the lack of urgency.

This is natural after living under the tyranny of the waterfall deliveries for many decades.

Why does getting to production every sprint matter so much? Why won’t I just shut up about it?

In my experience, the greatest two barriers to a meaningful agile adoption are the waterfall mind-set and the belief that everything will magically come together at some point in the future.

Nothing has a more profound impact on changing the waterfall mind-set than actually getting to production at the end of every sprint. It will change the way you think and operate.

If the teams and the product owner do not insist on getting to PSPI (potentially shippable product increments) every sprint here is broadly what will happen. You basically end up with scrum-fall (scrum+waterfall) (devolopment sprints->line up environments-> integration test -> uat-> production). Estimates start to become meaningless as you will need an equally long time for the “release sprints”.

The net result will be a failure to deliver and ultimately blaming agile: e.g. “Agile does not work.” “We need to go back.” “If we stayed doing things the way were doing things, we would be live by now”.

As if to say that we delivered so wonderfully in the waterfall model.

But the product owner is not pushing for production

It is the job of everyone (feature team, scrum master, product owner). To date, the push to production has been coming from people outside these three groups. This should be discussed in PBR (product backlog refinement). The scrum master should keep the production tension alive. 

But there is no business value going to production every sprint

That is probably true during the first couple of sprints, but going to production every sprint will change the nature of PBR. The team/PO will start thinking about what useful things can be built to drive revenue. (e.g. if we do X can we start generating a subset of the revenue).


Nothing is getting done...

When agile/scrum is introduced into an organization one of the side effects is a perceived or real lack of urgency. I have seen this on a number of occasions, where teams seem to be losing the sense of urgency. Estimates feel too high, not enough "stuff" is getting built.

"enough of this hippy B.S., we need to crack the whip"

I want to share some of my observations regarding why this happens and some suggestions.

The traditional model of getting things done is referred to as the authoritarian model by Peter Senge (the 5th discipline). In this model, one person understands the problem and shoulders the sense of urgency and tells his “team” what to do. That person is the information bottleneck. He/she cracks the whip when he needs to be but many also reward a person for a job well done. The sense of urgency comes from the fear of this person and not from the “real problem. Let’s call this model, the Lewis model.

To a certain extent the Lewis model actually works and “stuff” will get delivered. Lewis will get rewarded. He works hard and shoulders most of the stress.  As a side effect of the stress and the whip cracking, few people want to work for Lewis.

Another model is one where the team feels and understands the problem. Rather than the sense of urgency stemming from the fear of a “person” it stems from understanding the real underlying problem or business opportunity. This will result far more creative solutions to the problem.  Teams working under this model will usually work harder/smarter than under the Lewis model. Let’s call this model the Harvey model. Everyone wants to work in this model.

A big part of the product team’s role is to translate the opportunity/problem to the team and protect the team from Lewis. The team in turn must seek to understand the problem/opportunity and deliver results.


Scrum meetings are a waste of time...

I hear that all the time...

The truth is scrum doesn’t actually have many meetings. There are four meetings (Sprint Planning, Backlog Refinement, Sprint Review & Retrospective) and a  15 minute daily standup. Added up, that’s roughly 8 hours over a three week period. Open your calendar and you will surely see far more meetings than that.

What makes it feel like wasted time is the fact that the whole team attends most of these meetings.

 I want to explain why the whole team dynamic is important:

  • Traditionally, one person understands the whole system and divides the work. This creates a key man risk. Only one person understands the whole system
  • When the team understands the system, the velocity also increases rapidly over time and bottlenecks are reduced
  • You get a better solution when the whole team understands the problem
  • You get better estimates when the whole team breaks down the tasks

 Over time, the team will get more efficient at these meetings.

The taxonomy of A-holes

A story

When I was 22, I read one of books that were meant to teach you how to get “ahead” in your career. In it, the author espouses the importance of having mentors. He recommended that when selecting a mentor you do not ask your manager but the person running the company or a captain of industry. The worst case scenario is they don’t respond or say “no”

So I did just that. From my lowly desk, in my cube at the bottom of the food chain, I emailed the guy running the day-to-day operations of this massive investment bank. I had only seen him on the corporate intranet or heard him speak on earnings calls. I hit send and had a brief moment of panic. 

Minutes later, I received a reply from him. “Sure, no problem, meet me tomorrow at 3:30.” The first thought I had was, “Crap, I need to buy a suit”
I spent that night wondering what to ask him and settled on three things: 1) What is the single most important piece of advice you can give me 2) What area of investment banking should I focus on 3) Can I get to your level and still have a happy marriage?

His answer to the first question has stuck with me for the past 14 years. He said,

 “Don’t be an asshole. You can be effective as an a-hole and get stuff done but one day you will screw up big time and all those people that you were an a-hole too will take a step back and let you fall. Work hard, help everyone you can, teach people what you know and don’t expect anything in return”

This single piece of advice has had tremendous impact on my career. A decade and a half later I’m ready to pay it forward and teach people what I have learned about a-holes.

I have met many different types of people in my career. Consulting has also put me into contact with many types of people. I began to see trends in the people I met. 

But first we have to create a ubiquitous quadrant to neatly classify people.

AQ (A-hole quadrant)

The most interesting quadrant to me is the upper left: the smart-ass

Some of the characteristics of the smart ass:

  • People would rather quit than work for them
  • Peers want that person to fail
  • Not a leader but can be a great manager
  • Tolerated for their intelligence but not liked. e.g. “good guy to have around”
  • Do not receive feedback well
  • Talks more than listens
  • Has limited career growth

Observations:

  •  Caution: There is a big difference between focus and being an a-hole. Many smart people get lost in thought when they are creating, aka the flow state. Don’t confuse this with being an a-hole
  • Smart a-holes can come in many forms:
  • The cocky developer
  • The pushy project manager
  • The manager that drives his people to the ground (Can also be an Idiot a-hole) Note: Organizations that promote intellectually lazy a-holes to management positions are those orgs you know need to leave
  • The guy/gal who went to an impressive sounding university and believes they are entitled to a certain level of respect
  • They often time don’t realize that people consider them to be a-holes. They are sometimes masking deep-seated insecurities
  • Current a-holes are many times future leaders, if they can make the switch (e.g. Steve Jobs < 30 & vs. Steve Jobs >30). Some of the best people I have worked with and have become some of my closest friends are recovering a-holes

Suggestions

The greatest gift you can do is give the SA private and candid feedback. In all likelihood, it will be a very uncomfortable experience. There may be a strong reaction, “Give me an example, I don’t agree, I just care about quality.” This is good, it means they will think about the feedback.

Give them a book. I sometimes buy people How to Win Friends and Influence People. Although the title leaves much to be desired, the chapter on how you make people feel is gold. Ask them to teach you something or teach the team something.

Many times when I show this quadrant to people one of two things seem to happen:

  1. They wonder where they fit on the quadrant
  2. They start classifying people they know

For the first. The easiest way to find out is to ask people. That’s what I did. For the second, give people the article and hope they ask you for feedback. At least they will begin thinking about it.

Awareness of being an A-hole is the first step to recovery...

On measurement

____ heads. South Kennsington

____ heads. South Kennsington

 

The “quantified self” movement is becoming all the rage these days. People measuring how much REM sleep they manage to achieve, weight, BMI, how many steps they walk, resting HR, etc. The net result is driving people to constantly improve, walk more, sit less, sleep more, etc. All great stuff.

People are even spending hundreds of dollars on this type of measurement. I have personally spent lots of money on lactate threshold tests, vo2 max, bodpod etc. I do this so I can track the effectiveness of my training and see how much I’m really improving.

As Gordon Weir (@gordweir) once told me, if I was *made* to do all of the above or if my wife purchased a Fitbit for “encouragement” and to “track” my weight loss progress; I would probably attach the Fitbit to a fan so I can game the system while eating a Snickers bar.

While the measurements may be the same and the instruments the same, the difference is profound.

Feature teams are meant to gather metrics (e.g. defects per release, burn down, velocity, etc) as a way to measure where they are and improve, *not* as a mechanism to get beat over the head with. The former is the only way to gather “real” metrics. The latter will lend itself to gaming the system. The sprint metrics are gathered by the team, for the team, and are discussed during retrospectives.

The same applies for the product team.  The product team should be gathering metrics around ROI, revenue etc. Metrics are the only way to validate assumptions. If we build (invest) X we assume we will get Y (return). Again these are ways to validate assumptions and continuously improve and not meant to be a noose.

Metrics are necessary and important but only when metrics are used as a means of improvement. Metrics that are forced on feature teams or product teams have a higher likelihood of being gamed to provide the “right” answer.

Where is that Smell Coming From?

Outside the Malt House in Fulham

Outside the Malt House in Fulham

If you have one or more of the following "odors" something is rotting somewhere:

  • Your outlook filing system is more air tight than a submarine
  • You have meetings to discuss meetings you have yet to have
  • You don't argue with your colleagues during team meetings
  • Nobody from your actual team does any talking during the "team" meetings
  • You can't tell your manager he is an idiot
  • You have no idea where you stand with your manager
  • Your power point slides are prettier and more uniform than the Queen's gardens
  • There are no white boards
  • Nobody has lunch together
  • There are layers and layers of fat between the team and real clients
  • There are no Nerf guns or flying helicopters