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/

How I Accidentally Eliminated Brain Fog and Became a Morning Person...

I generally hate the morning. I usually wake up later than I want, feeling foggy, chest full of mucus, and joints aching.

“I’m just not a morning person.” Is what I have always told others and myself.

I have long desired to become a morning person though. Waking up at 4 am, working out, journaling, meditating, etc. has always been an elusive dream. I tried watching inspirational YouTube videos, internet how-to’s, usually at 1 am, to help me become a morning person, but it never sticks.

Now that I control my schedule even more, things have gotten worse.

That is, until about 2 months ago.

I was visiting family in New Jersey and had a string of caffeine-fueled days and late nights that resulted in pretty crappy mornings.

The crappier I felt, the more caffeine I would consume.

On a night out with my wife, I decided to have a quick double espresso to start the night off right. We were discussing something, when my heart started to beat uncontrollably. She looked at me and told me that I should sit down and that my face was getting pale.

My terrible sleep habits, roughly 1200 mg of caffeine a day, and dehydration had resulted in that.

“That’s it! I’m quitting coffee.” I told her.

“I don’t think that is possible,” she replied.

We have been together for 20 years and I have been addicted to coffee the entire time.

Doing the Impossible

But that is exactly what I did. I quit coffee.

The following week is what can only be described as hell week. I was tired all the time, irritable, and just not myself.

After a week, I started to feel better, I stayed hydrated and exercised which seemed to help.

During this time, I started to read about what was happening with my body that resulted in the strange heart pounding incident. I learned about adrenal fatigue, inflammation, & circadian rhythms.

I calculated that I had been alive over 14,000 days and I didn’t want to waste any more. I didn’t want to wake up feeling like crap and going to sleep struggling to actually sleep.

Stopping caffeine was my critical first step. What I noticed as my body started to detox was that rather than going between 2 and 10, I was at a steady 6 or 7.

During this time we made a long trip back from New York to Istanbul with a stopover in Amsterdam. Doing an overnight with 4 kids and a layover is not a lot of fun, but to my surprise I was very zen the whole time. Even when we had issues with one of the kids papers, I was still at a 6.

During the following weeks, I started to sleep earlier and earlier. My body would get tired and I would just sleep. As someone who tracks their sleep habitually, my deep sleep went from 1 hour a night to 3 hours. I found myself sleeping less and waking up earlier.

I started waking up clear and feeling great. I became over-protective of maintaining that feeling. My nervous energy and excitability was replaced with a more mellow personally.

“Are you ok? Is everything ok?” Was something I heard a lot. I was perfectly fine.

Waking up at 4 or 5 AM poses a major issue: What do I do with that quiet time?

Rather than wasting the time on the internet or YouTube, I created an ever-evolving protocol:

The night before:

  1. No electronics after 8 PM & keep the phone outside the room

  2. Golden milk (This turmeric-based drink is a magical potion and has eliminated virtually all morning mucous)

  3. Go to bed around 9 PM but not sleep

    1. Journal (What did I do that day and what I want to do the next day)

    2. Read a physical book

    3. Talk to wife etc.

The morning:

  1. Wake-up naturally between 4-5

  2. Make a large peppermint tea, I prefer this to a large glass of water

  3. Spiritual practices (30 min)

  4. 60 minutes on the stationary bike (Check email, WhatsApp, etc)

  5. Hot/Cold shower

  6. High protein breakfast & 500 ml of water

  7. Wake-up the kids and make them breakfast

The sacrifice

This new protocol is not without it’s scarifies. 9-1 AM was when I would hang out most with my wife.  We have replaced this with having breakfast together or going for a walk together in the morning. The lack of caffeine has also meant that it’s harder to get to a high when I’m feeling sluggish. I am also finding myself saying no to any social gathering that will force me to stay out too late.

 

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.

No lunch but plenty of food for thought...

Artefacts

  • Class deck (Link)
  • Class mind map(Link)
    Note: Requires XMIND 
  • Metrics Spreadsheet(Link)
  • Printable Scrum Mindmap (Link)

Articles I mentioned

  • Unfreezing an organization (Link)
  • How to form teams at scale (Link)
  • The taxonomy of A-Holes (Link)
  • Running an impact mapping session (Link)

Books I mentioned

Hacks

  • Become a faster reader using RSVP (e.g. Spreader)
  • Prepare your speaking voice via repeating: " I slit the sheet, the sheet is slit, on the slitted sheet I sit" (Video)
  • Mindmapping as a tool to retain and correlate information. (Video by Creator)
  • Pomodoro technique (Video)
  • Glucose Transporter type 4 (Link)

Class soundtrack

  • Led Zepplin 
  • Cat Stevens
  • Bruce Springsteen
  • Grateful Dead
  • Brian Adams
  • My Saxobeat
  • James Taylor

Class blog posts

LeSS – Day 1

By Scott and Abishek

Over the course of Day 1 in our 3 day LESS training which is designed to scale scrum across larger teams/projects in BNY.  We adopted a repetitive learning approach where we covered high level the principles, people, process and adoption on day one and then will explore these concepts in much more detail on day 2 and day 3.

We utilized techniques like mind mapping, classroom exercise and instructor lead learning. Each methods of these yielded real-life examples of application and successes. One of the key evaluation was the queueing theory at Starbucks- separate queues for the people who wanted regular coffee vs special orders to expedite the delivery. Automating the orders through smartphone apps. At the same time, barista was limited to not more than 2 orders of coffee maintain the high quality. Similar technique can be applied in software processes by reducing the queueing of requirements by letting the team work in collaborative manner with product owners to create the requirement themselves. It also explains that by limiting the work queue hence increasing the throughput.

Also reviewing the principles outlined in the program allowed us to visualize or better understand where we at BNY could make significant strides for a better agile adoption. Specifically, a single product owner across x number of teams, co-location and dedicated scrum masters to help serve and support the value generating development teams.  Product owner, location strategy and scrum master expertise are all quite immature in practice amongst many of the teams.

As a group we discussed the concept of waste within a system specifically how we may invest a lot of time in unnecessary waste tasks (like the beautification of communications and ppt) vs necessary waste like crafting  wiki for teams to consume information.

We also learnt about an example of finding the root cause of the delay in delivery through the 5Whys and “Go See” technique. After some hesitation, senior Management (CIO/CTO) committed to meeting the team at different geographical locations with diverse culture, understanding the technical issue by casual conversation. It revealed the root cause as the non-realistic timeline given to the development team to build a feature that resulted in technical debt creating the overall code to become complex to change.

Looking forward to day 2!

LeSS Is More

By Ciara, Brian & Laureen

Today we attended the LeSS is More Agile Training for product development. This is the first day of a three-day training. Can you imagine changing the culture within your organization where someone with total understanding of the product is working with the team to add purpose and priority to your work? Well… it can happen to you as we learned today! How would you do this? By being part of a smaller team where labels do not exist. You have to trust one another to gain knowledge of the product together and learn the process.

 All the while the customer is the primary focus as you are developing and working on the product.  Increasing customer satisfaction by having your customer at the table and having accountability along with the team.

Working towards perfection helps to continuously learn and constantly apply what you’ve learned the day before. Infinite Improvement! Imagine spending 85 of your years perfecting the art of sushi and still not feeling satisfied with your work and ready to retire. A sushi chef in NYC works every day to continuously improve his work. He is not content with mediocrity and every day he is working towards perfection. Now take this lesson and apply it to your product development. 

The TEAM….. small, no labels, no manager.  What no MANAGER!! Teams will rely on each other to get the job done!  

And, last but not least you deliver something viable after 2 weeks instead of waiting several months before testing and delivering what the customer does not want! Even though it may be smaller, it is something of value to the customer that can be applied to the system much quicker.

 

Click to download

Click to download

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)

Choosing to be miserable

Caution: uNeDiTed

Example 1 -- Food

Scenario 1

“kids, what would you like to eat” Parent
“I want pizza!” Child 1
“I want burgers!” Child 2
“You have to decide for yourselves.” Parent
“It's not fair.” “you got to pick you last time.” “I hate this.” Children
“Forget it! I will pick. we are having Thai food.” Parent
“I don't want Thai” “I hate Thai” “you always have Thai” children
“These kids are so spoiled and don't deserve going out” angry parent

Conclusion: Parents and children are miserable.

Alternate scenario 

“Hey kids gets get dressed, we are taking you out for Thai food”
“Oh cool. thanks” 

Example 2 -- Movies

Scenario 1

“Kids, what movie do you want to watch”
“Frozen!” child 1
“Frozen sucks, I want the Lego Movie!” Child 2
“I hate the lego movie, it's so boring.” Child 1
“It's not fair.” “You got to pick you last time.” “I hate this” “Waaaaaa!” Children
“Forget it! I will pick. We are watching Starwars.” Parent
“No! we always watch star wars!”
“These kids are so spoiled and don't deserve watching  movies” Angry parent

Conclusion: Parents and children are miserable.

Alternate Scenario 

“Hey kids, do you want to watch Starwars with me? I'm making popcorn!”
“Oh cool. thanks” 

Conclusion

When did I surrender decision making to the kids? Am I being intellectually lazy? I’m going to stop giving my kids choices. 

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).