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


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

Triple wins. How we create family resolutions.

I am not one of those super organized people. But the one thing I have done religiously since 2008 is plan my year in advance. I get the question all the time about how I manage these crazy races, travel, have a career, and spend time with my kids. This is how I do it. 

Prior to doing this, I would just go with the flow. what ever screamed loudest, I followed. I just went through the motions with regards to work, family, and kids. 

Since I have started planning out my year in advance, I've noticed an interesting side effect, I get a lot done, but i'm not really that busy. 

Caution: this whole process takes a lot of time but it helps not waste a whole year.

1. What did you do the previous year?

I start with a simple brain dump of what I have accomplished the year before. You might be surprised by what you have accomplished or *not* accomplished. What trends do you notice? I usually do this exercise with my wife and kids. We try to find trends or interesting patterns that can shape the coming year. 

For example?

  • Where did we travel
  • What did my kids accomplish
  • How much money did I save/state of my investments
  • Major accomplishments at work/business
  • Books I read, things I've learned

I personally use Google sheets for this. Finally, we finish with the question, "what is this the year of"? When you look back 20 years from now, what will you remember 2017 for? "2017 is the year of having a new baby and moving to a new country" 

2. Ideas for the following year

Do a "brain dump" of things you want to accomplish next year. Just sit down and write anything that comes to mind. Just let the ideas flow. 

I do the same exercise with my wife and kids. My wife usually doesn't want to do this and rolls her eyes, but eventually she will start telling me what she wants the children to achieve and eventually what she wants to achieve. The kids rattle off their own lists too.

I spend a couple of days on these lists, adding, and removing.

Major themes will start to emerge. They will form the major "rocks" for the year. For example

  • Run an 'X' mile ultramarathon
  • Increase the revenue for my company by X%
  • Travel to 'X' new cities
  • Publish my first book
  • Children become proficient mandarin speakers 
  • Children become better swimmers
  • Actively help out a charity

I take the goals and make them scary/exciting. I am not sure why this works for me, but it does. It triggers something within me that makes me more likely to achieve the goal. Sometimes it will take more than a year to accomplish them. E.g.

  • Rather than run 50 miles-> run 100 miles.
  • Rather than learn Hindi-> give an entire lecture in Hindi
  • Rather than my son learn to swim -> do his first triathlon

3. Look for triple "wins" 

My goals used to be all about me. What I have been doing recently is trying to find goals that overlap with my wife and kids. That  increase the chances of my actually achieving the goals and it brings the family together. 

Once my family and I have the lists and they are sufficiently scary and exciting, I start looking for synergies.

For example, the kids need to practice their Arabic next year and she wants to visit her sister in Jordan and I want to do a multi-stage running race. So I started "googling" and found a one week desert Ultra in Jordan in March. A triple win.


We arrive at these but talking, talking and more talking. 

This is the secret sauce of the whole process. If my wife is part of the planning and I take her wants into consideration she will be my support system. This is one of the main reasons my wife supports what I do.

4. Categorize things into months

I start putting things onto the yearly calender like that. I put major events like major holidays, work commitments, travel commitments. I find out what gaps in my calendar I can play with. My wife wants to visit Japan, I want to do an Ironman and my son wants to do his first Iron Kids. So Ironman Japan in August goes up on the calendar.

5. Put "it" up or shut up

Once I'm done with my goals, I put them up on the wall where I can see them everyday. I also have a yearly calendar where I can see the major events I have planned. It's the first thing I see when I turn on my phone. 

Visualization is the second secret ingredient. 

6. Get started

I will make things real by booking races or holidays. I start right away. I don't wait or put it off.

Race resources that I use

  • Marathons around the world: http://www.marathonguide.com/
  • Ultramarathons around the world: http://www.ultramarathonrunning.com/
  • Triathlons around the world: http://trimapper.com/
  • Ironman.com, Challenge.com, Rev3tri.com

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.

(Guest Post) Be a butler *not* a developer

Advice for developers working with traders

By Jibreel Hussain

The perfect butler knows what the master of the house needs before he even knows he needs it himself. The same principle applies for developers working on the desk. In other words, he is empathetic.

Recognizing and implementing the needs of the traders is the difference between a good develop and a great developer.

Don’t ask for permission, JFDI.

If the trader is mandated to use a particular utility and is forced to book the trade in two places, automate it.

If a trader is doing a redundant task, automate it. 


My father's 80/20 rule to parenting (Un-edited)

My father once gave a piece of parenting advice that has always stuck with me. His advice was to ignore 80% of what your children do wrong and admonish the important 20%.

He said not to be one of those parents that always tell his children "not to do that, be quiet, don't pick that up, etc"

But for the 20% that matters, not to budge. You need to figure out what those non-negotiables are?

For me, its lying, disrespecting parents or elders, etc.

(Guest Post) How I Started Running Fast(er)

Guest post by Issa Abbasi (@IssaAhmadAbbasi)

When I began to enjoy running, I immediately listed all of the popular marathons I wanted to one day race.  Of course, any serious runner would make sure to include the Boston Marathon on such a "bucket list" of races as I made sure to do.  I knew that I had to qualify for the Boston Marathon but what I didn't know was that the qualifying time for my age group (18-34) would require me to run a marathon a year before I planned to register to run the Boston Marathon in 3:05. This qualifying race for the Boston Marathon (also known as a "BQ") has to also be certified by the Boston Athletic Association (BAA), so it can't just be "any" marathon that you run to qualify for Boston.

While I am not running a 7 minute pace yet, I knew I had to get faster at running if I wished to one day qualify for the Boston Marathon.

But how does a runner simply run fast or faster?  Below are some methods and techniques I used to improve not only my speed but also my endurance in a matter of 8 weeks.

I joined a running club

Running can be extremely fun, especially when you have a large support group in a running club. When you run with others around you, you will have no choice but to run faster if you want to keep up with the group.  Naturally, you'll discover here what actual "running" is and feels like.

Furthermore, clubs tend to offer group workouts that include speed drills done by a coach. These speed drills are especially helpful to getting faster. With my experience, I cut almost three minutes off my 5K PR with weekly speed drills for six weeks (11/28/13 5K was 29:34 and 1/26/14 5K was 26:39).

I hired a running coach 
As discussed in my previous post, even as a beginner, can pay dividends very quickly. A good coach's approach will get you to realize gains very quickly but also sustained gains for your long term racing career. Coaches will also give you advice you won't find in a running magazine, book, or on a Facebook page about everything running related.  
 

I slowed down
This may seem counter intuitive but it works; slow down!  Runners need to realize that not every run has to be at your all out 5k race pace.  Runners need to embrace training at various paces on a weekly basis if they want to run fast(er). For more information about slowing down, see Ahmad's post about zone 2 training (hyperlink "zone 2 training" to your post on the subject). Remember, it's not the fastest runner who wins the race but the one who slows down the least.

I stopped comparing myself to others
Once I stopped comparing myself to others and focused on my running, my mental wall of "getting faster" vanished.  This is especially key when you are running a race. I passed plenty of people in a recent 5K and 10K who were ahead me for the majority of the race and never looked back.  How? Because I paced myself based on my training of slowing down and became a more efficient runner.  When the time was right, I turned on the jets and motored past those who were in front of me for most of the race and ended up finishing before them.  Remember, in a race, it's not about where you start but rather where you finish that matters.

I let it come naturally

Don't rush to get faster, let things come naturally.  I've heard of the "running faster vs. longer" argument and I believe that a runner should focus on running longer first rather than speed.  It doesn't help if you are a fast runner trying to run a half marathon but are not able to finish one. Furthermore, running longer will enable you to slowly become more efficient and thus faster runner, so don't chase speed.