Authortkamens@guidance-technology.com

What the Customer Wanted

How many times have you been on a project where you delivered something that wasn’t what the customer wanted? Maybe you came close, and maybe the customer was OK with releasing the product, but it wasn’t exactly 100% what they wanted. Sound familiar? Maybe you have even seen this picture depicting the world we live in today?

Join me for a short video that goes a bit deeper into the Subject.

What is your Highest Priority?

Consumer Reports Withdraws Its Tesla Model S Recommendation

At first glance, people see the headline from Consumer Reports above and think that Tesla has some really big problems.  Their car was just downgraded by Consumers Reports and their stock took a hit.  In their survey, Consumer Reports found a wide range of issues, and some of the areas of the car actually got worse from 2014 to 2015.

What is your Highest Priority?

For most businesses, a public report like this, could have the potential for a major impact on the company’s very own survival.  That being said, Tesla is not “most businesses”.  You see, Elon Musk, the company’s founder, made his fortunes in the software industry.  One thing you quickly learn when building software is to listen to your customer and involve your customer in the building of the product.  In fact, according to the Agile Manifesto’s 12 Principles, the number 1 Principle is:  “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”  Clearly, Musk took notice.

I know what you’re saying.  That sounds like a great idea for building software, but how can it possible work for building a car?  How could you get close to the customer and even if you did, how could your manufacturing process support feedback for something fast enough to make a difference?

Well, Musk didn’t just build a car company, he built a Brand that just happens to build cars.  What do you think of when you think of a Tesla?  Do you think of the Horsepower the car delivers?  Do you think of the navigation system or the stereo?   More than likely, you are aware of the technical specifications of a Tesla car, but you are more aware of the experience of owning one of theses electric cars.  If you don’t believe me, then take this for example.

According to a Techcrunch article about the Consumer Reports recent downgrade:

Asked for comment, a Tesla spokesperson emailed us the following statement: “Consumer Reports also found that customers rate Tesla service and loyalty as the best in the world. Close communication with our customers enables Tesla to receive input, proactively address issues, and quickly fix problems. Over-the-air software updates allow Tesla to diagnose and fix most bugs without the need to come in for service. In instances when hardware needs to be fixed, we strive to make it painless.”   http://techcrunch.com/2015/10/20/in-shocking-turnaround-consumer-reports-withdraws-its-tesla-model-s-recommendation

The Agile Manifesto, Principle number 1 in action:  “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Were it not for the close communication Tesla has with their customers, they would not be able to address issues and proactively fix problems.  Think for a moment how this story could have turned out differently had Tesla not built a system to enable close communication that helped them continuously delivery value?  Think about your own car ownership experience and the last time you had a problem.  Would you rate your service and loyalty as “best in the world”?

In reading the recent Tesla story, I couldn’t help but think of Tony Hsieh, the CEO of Zappos, and his attention to delivering more than just a product.  Tony figured out early on that the secret to his company’s success was in “Delivering Happiness“, which is also the title of his recent book.  At Zappos, he created a culture that is focused on employee happiness, which transcends into providing amazing customer service to make their customers happy, which then results in happy customers spending more money at Zappos.  Tony made happiness the centerpiece of Zappo’s strategy and it is working.

Tony’s focus on happiness is a part of everything Zappos does.  In fact, as noted in the book, Search Inside Yourself, by Chade-Meng Tan, Tony describes three types of happiness:

  1. Pleasure: This type of happiness is about always chasing the next high.  It is the rock-star type of happiness because it is very hard to maintain unless you are living the lifestyle of a rock star.
  2. Passion: Also known as “flow”, where peak performance meets peak engagement, and time flies by.
  3. Higher Purpose: This is about being part of something bigger than yourself that has meaning to you.

Tony Hsieh and Elon Musk have both created companies that are focused on a Higher Purpose.  It is this Higher Purpose that allows them to have setbacks and continuously learn and adapt to make their products that much better.  What is your Higher Purpose?  Let’s not loose sight of the Agile Manifesto and the 12 Principles when building our own products.  How you address each Principle will show you what your highest priority is and whether or not you are delivering the highest business value to your customers.

When does 25 – 8 not equal 17?

Just Noticing

Saturday morning I was on my bicycle, training for the Pan-Mass Challenge.  We were making our way through some back roads and I realized how out of shape I was as I struggled to keep up with by friends.  I had fallen a bit behind and was peddling hard to make my way up a short hill when I started noticing.  Yes, that’s all.  Just noticing.

I was noticing my breathing and my peddling when this beautiful farm appeared to my right.  It was early morning, and there were workers out in the field.  The farm was a horse farm and it looked like they were letting the horses out into a large field to run.  I continued riding past the farm and noticed a perfectly manicured home across the street.

I noticed how the lawn must have just been mowed and how the lines in the grass created a pattern.  As I continued my ride, I continued to notice…

  • I saw a rock that fell out from a stone retaining wallMailbox-ride
  • Flowers lining a picket fence
  • House numbers on mailboxes on the side of the road
  • Spray paint on the street from the town public works
  • An owl flying overheard
  • A small boy riding his big wheel while his grandfather walked behind him on the sidewalk
  • The wind in my ears
  • Other bicyclists riding towards us
  • My breathing
  • A Dad fishing with his son by the waters edge

All of these images came into focus so clearly as I made my way through these beautiful back streets and that’s when I noticed something else: my speed.  My speedometer said I was going 17 mph.

Slowing down

I have driven on some of these roads before, but usually at the speed limit of 25 mph, and I never noticed the scenery like this.  Was it really possible that 8 mph could change the landscape this dramatically?  When you are driving in your car, even on these same roads, you are focused on driving. When you step outside and slow down, that’s when the magic happens.  That’s when you slow down and notice the world around you and stop thinking about the past or about the future.  You are only focused on right now.

I have been meditating (thanks Andy Kelley and www.Bostonbuddha.com) for about 4 years now, and here I was out on the road gaining the same clarity of mind as if I was sitting at home in my chair with my eyes closed.  It was an amazing feeling on this early Saturday morning.

As I caught up to my friends and started talking, I was brought back to the present moment of the conversation.  I was able to see the road ahead and some of the cars coming up as we neared the main street, but it wasn’t as clear.  My focus had changed.

Connecting the Dots

At work, my focus is to coach people on how to successfully deliver Software using the Scrum Framework.  I couldn’t help but draw correlations with what I was feeling on my bike ride and what I was teaching at work.  Is Scrum teaching us to slow down and notice?

If you are familiar with Scrum, you know that we focus on time-boxed events.  We focus on keeping change out of the Sprint so we can focus on what the team needs to accomplish.  Just like cycling, we have a roadmap that we follow, but for say, 2 weeks, we are just going to focus on what’s right in front of us and nothing else.  We are capable of driving 25 mph, but for this Sprint, we are going to slow down to 17 mph.

I have found that it is in these short, time-boxed, windows where the greatest productivity comes out.  Maybe slowing down is what we all need so that we can focus on the important things right in front of us.  Maybe, slowing down from the speed limit of 25 mph to 17 mph is much more than just 8.  Maybe it’s a whole lot more.

When was the last time you slowed down?  What did you notice?

From Shock to Acceptance – Where do you and your team fall on the Grief cycle?

Tuesday, 8:30am – Scrum Training

You see it on your calendar – “Tuesday, 8:30am – Scrum Training” and you get pangs in your stomach.

You have been creating software for a few years now and things have been going OK.  Your team has been able to deliver what the customer wants (to an extent), and so what if you had to burn the midnight oil once a month to make it all happen.  After all, doesn’t everyone put in a little extra effort to hit a goal now and then?  The team was performing well and everyone understands the Change Control process by now.  You work closely with the Business Analyst making sure he had all of your questions presented to the Business owner in his weekly check-in meeting.  Now management wants to switch things up and they think Scrum is the answer?  Yeah, right…

Change is a pretty powerful thing

Whether it is a situation as described above, a new job, house, marriage or child, we have all experienced changes in our lives.  What is critical is how we react to these changes and how we learn to become better people by what we learn from these events.  In each Scrum training class we deliver, we perform an exercise to help the class focus on the things which are going to cause the biggest obstacles to implementing Scrum.  The exercise has been performed countless times and yet each class comes to the same top obstacle:  Change it self.

Elizabeth Kübler-Ross was a doctor in Switzerland who was very unhappy about how doctors were treating their terminally ill patients.  She began studying these patients and wrote a book called “On Death and Dying” which documented a cycle of emotional status that is often referred to as the Grief Cycle.

As years passed, people noticed that the emotional cycle was not just applicable to the terminally ill, but to others where we affected by bad news (Implementing Scrum, to some).  The key take away was not that the change was good or bad, but that they perceived it as a significantly negative event.

The Extended Grief Cycle

The Extended Grief Cycle can be shown as in the chart below, indicating the roller-coaster ride of activity and passivity as the person wriggles and turns in their desperate efforts to avoid the change.

kubler_ross

http://changingminds.org/disciplines/change_management/kubler_ross/kubler_ross.htm

The important factor is not that the change is good or bad, but that they perceive it as a significantly negative event.

What can we learn from the Extended Grief Cycle today when discussing organizational change, like adopting Scrum? How can you work with your team or company when they first hear about a change and show classic change resistance symptoms?  Let’s look at the details of the Grief Cycle and how they apply to change in an Organization.

Shock

Your first reaction on hearing about the Scrum adoption can be closely associated to classic shock.  You may hear the news and have no reaction at all, or appear to accept the news without showing any sign of trouble.  Internally, you may not have fully processed the news just yet and you may need to be told several times.

People react differently to news in many ways and it is important to show them sympathy and acceptance.

Denial

Once the initial Shock has worn off and taken its course, the next step in the cycle is Denial where a person can often pretend that the news has not even been given.  Some people will ignore the news and pretend as if nothing has happened and will try to continue with their jobs as before.

To help these people move out of denial, it often takes a deliberate action to provoke them into Anger.  The change announced is going to happen and they need to understand that there is no way around it.  You can tell them that it’s not fair and that you have concerns of your own, but there can be no illusions as to what is coming down the road next.

Anger

The next step in the cycle is Anger, which can often occur in an explosion of emotion.  In this stage, the blame game begins and people start to ask “Why me?” or “Why do we have to do this?”.

At this point in the cycle, it is best to give people space and allow them to process the change.  It is OK to let people direct their anger at you and you should support their anger and accept it.  Clearly, change is not easy and the sooner you can help people move past being angry, the sooner we can get back to being productive.

Bargaining

After Anger has dissipated, the next stage in the cycle is Bargaining.  People will start to look for ways our of the change and will hope that this is a short term situation and that the change can be undone.

It is critical at this stage to not offer any false hope.  The change is going to occur and while there are some areas for bargaining, it is critical that any deal created results in a win-win situation.  Everyone should know that things will be different and that the quicker we move ahead, the faster we will see results.

Depression

After Denial, Anger and Bargaining, the inevitable sets in:  This is really happening.  In the workplace, people may be more prone to being absent or accepting of just OK work results.  In this stage of the cycle, people can also start to blame themselves for things that have gone wrong, where previously they had been blaming other people for the change event.

In this critical stage of the cycle, it is important to help people understand that you accept their un-happiness and that it is very common.  It is important to remind people that they have your support and even coaching available to them and to remind them of the positive road that lays ahead.  They need to know that the longer they stay in this phase of the cycle, the harder it is to break out into the positive areas.

Testing

In the Testing phase, while not completely out of the Depression phase, people start to realize the reality that the change is going to take place and that they can’t remain in the Depression phase for ever.  People start to “test” the situation and see if there are areas where they can participate, but still hold back.

While testing the “change”, it is important to continue to convey the positive outcomes that will be gained from the change event.   As Chip and Dan Health convey in their book, “Made to Stick”, “A sticky idea is understood, it’s remembered, and it changes something.”

What can you do to show your team why they should adopt this change?  Is there a success story you can share?  Is there something you are able to do today that you weren’t able to do before because of the change?  Are your competitors doing it?  Think about how you can make this change understood, memorable and why the change is worth the risk.

Acceptance

The final phase in the Grief Cycle is Acceptance.  The change is now adopted into the culture of your team and people are ready and focused on moving forward in a new way.  People show excitement for their work and the new process and they will appear happier and more content as time moves forward.

To keep the positive attitude in the fabric of the company, you need to show off your success and reiterate that this is the New way forward.  Breaking through to this stage should be celebrated!  It is only now that you can begin to refine and improve upon the change and increase productivity.

“Some people don’t like change, but you need to embrace change if the alternative is disaster.” Elon Musk

As you navigate your own implementation of Scrum, I encourage you to keep the Grief Cycle in mind to determine where your team is today to better understand how to move your team into Acceptance.

Measuring Agile Success

Measuring Agile Success:  A look at Metrics

In the just released VersionOne 9th Annual State of Agile Survey,  they asked how people measure success on a day-to-day basis. Respondents provided 23 different answers, and the number one selection was Velocity (59%) followed by Iteration burndown (51%) and Release burndown (39%).

Half way down the list, at number 11,  Budget vs Actual cost is listed at 22%.  It is not surprising to see that people value success using non-monetary criteria.   After all,  the Agile Manifesto focuses on Working Softare as one of its values, and yet the respondents still listed the Ability to change Organizational Culture (with 44%) as the highest barrier to furtherAgile adoption.

Copyright 2015 VersionOne

Copyright 2015 VersionOne

Observing this key metric, it became apparent to me that the Manifesto’s 7th Principle, “Working software is the primary measure of progress” was really coming through on the survey even while people were saying that they are struggling culturally with change.

 A closer look at Budget vs. Actual

In a recent client interaction, a consultant of ours was invited to a meeting with a Project Manager to discuss project status and reporting.  It was explained that the Comptroller was expecting a monthly update of budget vs. actual dollars spent for the project.  What seemed like a straight forward request, turned out to generate a lot of discussion due to one key row on the report:  Phase.

You see, this report wanted the project phases listed by where the money was being spent:  Analysis, Design, Build, Test or Deploy.  These phases work perfectly when the project is following a Waterfall methodology, but when adhering to Agile, what do you put in the Phase column?

After considerable time spent discussing this reporting issue, we decided to go to the source and we scheduled a call with the Comptroller.  Again, taking a cue from the Manifesto by valuing Individuals and Interactions over Process and Tools.  We wanted to ask him directly what he was looking for from our project.

He explained the report to us and then we explained how our project was adhering to Scrum and what that meant.  After explaining to him that we would most likely list all of the phases in one month of budget vs. actual’s, the conference call got quiet as we waited for questions.

 The real question

“What I need to understand is, are we on track from a budget perspective and is the business getting what they are paying for?”  Now we were talking.

We suggested a burndown that would show how the project was spending the budget each month.  We also explained Story Points and agreed that what was important for this report was a summary of software delivered based on business value.  While a Story Point burndown would have been the best indicator of delivery, in the end, it was decided that a summary of progress would suffice.

One meeting was all it took.

What started as a tense discussion as we unsuccessfully tired to communicate an Agile project using a Waterfall template, led to a clear understanding of expectations on all sides.  As we were finalizing the details, the Comptroller had one more question for us.

“So, if I understand this correctly, the business will continue to feed Stories to the team and the team will continue to deliver until the budget has been spent?  This puts it in the businesses hands to decide what they want for the money they have been allocated.”

Exactly!

Commit. You’ll figure it Out!

Commit.  You’ll Figure it out

This past weekend, August 4th and 5th, I rode in the Pan Mass Challenge along with 3 friends.  The Pan-Mass Challenge raises money for life-saving cancer research and treatment at Dana-Farber Cancer Institute through an annual bike-a-thon that crosses the Commonwealth of Massachusetts. Since its founding in 1980, the PMC has successfully melded support from committed cyclists, volunteers, corporate sponsors and individual contributors. All are essential to the PMC’s goal and model: to attain maximum fundraising efficiency while increasing its annual gift.

What started as a challenge one night among friends to actually complete the 190 mile bike ride from Sturbridge, MA to Provincetown, MA ended in something far different.  We started training in June\July, going on long weekend bike rides and the focus was all on ourselves.  We bought bikes, riding gear and started learning the lingo as well as our own body’s endurance.  Right up until the start of the race, I was focused on how I was going to finish this long ride and then something hit me.

Committed. PMC Start in Sturbridge, MA

Committed. PMC Start in Sturbridge, MA

It was 5:15am on Saturday, and we were standing at the starting line.  It was really exciting to be surrounded by so many people and I took a picture to post to Facebook.  The comment said, “Only 190 miles to go” and that is when I realized that this ride was no longer about me.

It’s not about me

Seeing so many committed riders and volunteers up so early made me realize that this ride was about so much more than the individual riders.  As we made our way across the starting line, there were about 100 or so people standing on the sideline with signs thanking us for helping them.  As we said Thank You to them for cheering us on, they said Thank You for riding and raising money for Cancer research.  This was only the beginning.

As we slowly made our way through the streets of Western Massachusetts, people were standing on the streets thanking us.  There were people with their children still in their pajama’s at 6am ringing cow bells cheering the riders on.  There were people in wheel chairs holding signs thanking us and letting us know they were survivors.  We saw a man playing the Trumpet at the top of a hill trying to encourage us; a Calypso band, a group of girls playing the Bag Pipes, huge gatherings of people in front lawns and individual adults and children standing on the sides of the street.  Again and again, as we thanked everyone for cheering us on, they thanked us for our commitment.

109 Miles to Bourne

After riding for over 8 hours, we finally made it to Bourne, MA and the “half way” point of the ride.  After storing our bikes and getting changed, I spotted a T-Shirt that truly summed it all up.  The shirt was a PMC shirt from a year or two back and it said:  Commit.  You’ll figure it out.  This simple statement made a big impact on me which brings me to this blog entry.

Commit. You'll figure it out

Commit. You’ll figure it out

I started the PMC by registering for a 190 bike ride where I had to raise $5,000.  The ride was about 3 months away, I didn’t know the first thing about cycling other than what I did as a kid and I didn’t have a single donation.  I signed up and committed to riding and thought that I would figure it out.  As of today, not only did I complete the ride, but I raised more than the $5,000 commitment and hope to continue raising until the October deadline.  The simple slogan was so true.

What does this have to do with Agile?

Of course, being an Agile coach, trainer and consultant, the PMC slogan had another meaning to me altogether.  “Commit.  You’ll figure it out” epitomized to me the Self-Organizing team more than any slogan I have heard.  Working with a team of people towards a common goal with lots of uncertainty, there must be a sense that you will figure it out somehow or you would never start in the first place.

It brought me to a client of mine that is nearing the end of a long project and things are starting to heat up and focus on deployment.  Each Sprint is packed with complex tasks and activities that the team is committing to that push the boundaries of what is possible in a 3 week time period.  Not once in our Sprint planning meeting did we stop to discuss “How” the work would be done.  People signed up for tasks and made a commitment to the team that they would “Figure it out”.

Comparing the commitment I made to ride in the 2013 PMC to what an Agile team does for each Sprint may seem like comparing Apples to Oranges.  We are talking about a 190 mile bike ride to raise money for Cancer research being compared to building some feature\product that a company will sell for a profit, however, neither will succeed without a Commitment.

If there is one thing I would like to leave you with from my experience doing something that truly wasn’t about myself, it is this slogan,  “Commit.  You’ll figure it out”.  This simple slogan is so powerful in so many ways and yet it brings out what makes people so remarkable in what can be done when you are all focused on the same goal.

Commit.  Even if you make mistakes

I couldn’t resist writing about one more thing.  After learning that the day 2 start from Bourne to Provincetown wasn’t a formal start, we planned our day.  We would get up at 5am, leave Falmouth by 5:30am and get going on the last leg of the ride with everyone leaving that morning for Provincetown.  Only one problem:  Everyone left at 5:30am.

Late for Breakfast

Late for Breakfast

What should have been a field filled with 2,000 or so bikes, looked more like the end of a concert.  There were 4 bikes remaining on the racks.  Everyone had started the ride and it was only our bikes that remained.

After getting over the comedy of the situation, we quickly jumped on our bikes and started the last leg just as we started the first. The 4 of us were committed to finish.

Riding over the Bourne Bridge as a team of 4 and seeing no-one in sight reminded me that even though mistakes will happen, once you commit to something, nothing will prevent you from accomplishing your goal.

If you are interested in making your own Commitment and would like to make a donation to the 2013 PMC, please click here.  You’ll figure it out.

Feeling the Pain

Do they Know It’s Christmas?

In 1984 Band Aid released the song “Do they Know It’s Christmas?” to raise money for anti-poverty efforts in Ethiopia. The song went on to become a huge hit that year and was instrumental in raising awareness of what was going on in Ethiopia. On 12/12/12, a fundraising concert to aid the victims of Hurricane Sandy was held at Madison Square Garden. Many artists took the stage to sing their hits and help raise awareness of what was going on in the aftermath of Hurricane Sandy.

In both instances, people came together to perform in hopes of getting a message out to the world: People need your help. But why did these events prove to be effective? The world was certainly aware of what was going on prior to these events. Certainly in 2012, with Twitter, Facebook and Instagram, you couldn’t escape the images and stories of the destruction and suffering caused by the Hurricane. Why did a concert make people pause and donate to these causes?

Maybe it’s all about Slowing down to think

One could say that we live in a fast paced world and that the concert slowed things down for a little while to open our minds to the issues, but I disagree. I think that the reason these events are so successful is because they cause us to feel the pain. In each event, you can’t help but sense a deep feeling of helplessness for the people affected. You probably had this feeling before the song or concert, when first learning of, or seeing the starving people in Ethiopia or the destruction in New Jersey, but that feeling was fleeting. You felt sorry for the people you saw on TV or read about through your Social Media connections, but it wasn’t directed to a cause.

On 12/12/12, as well as in 1984, the musical event brought you back to the pain and made you really feel the suffering. As humans we are programmed to react in one of two ways: Fight or Flight, and in these cases we used our Fight response and opened up our wallets and donated to the cause. These concerts appealed to our Emotional side which then told our Rational side it better take action.

Can a feeling be applied to building software?

If helping people feel these painful events evokes a response so easily, can it be applied to a team at work building software? Silly as it sounds, could you truly change a team’s behavior and empower them to deliver amazing results by getting them to feel pain as well? This may seem easy to prove, but then again, maybe not.

Faced with tight budgets and high expectations to increase revenue, today’s companies must become more efficient in how they build software but also, they must be better at delivering what the customer wants. Competition shows us that if you are too slow to release a product or new feature you quickly become yesterday’s news. Everyone knows this as more and more people interact with software. People know what a good user experience feels like. Recent polls show that more than 70% of smartphone users use an app on their device and yet most of these app’s have little to no user documentation. App creators are building software that is easy to use, meets a unique need and requires very little learning to make the applications useful. Where is this drive when it comes to software used inside an organization?

It’s time to change – here’s the Challenge

In spite of what most people know about budgets, revenue expectations and a users experience, we are still relying on old techniques to build software. Requirements that take 3 months to be elaborated before a design can be started will not support the Marketing and Sales departments that are looking to delivery quickly to a changing marketplace. Spending an exorbitant amount of time creating documentation for the sake of creating documentation will not support the technical team that wants to build a solution to deliver value to the business. And testing the solution after it has been completed will not deliver a high quality, low cost solution resulting in minimal rework. Yet we do this every day and don’t seem to have any problem with continuing this process.

So, I have a challenge. I challenge you to get your team to feel what being Agile is like and let me know. One sentence on your experience? Your teams, Company’s, Management? What did working in an Agile manner really feel like and did that feeling make you want to continue in this fashion. I challenge you! What exactly are you worried might happen?

*****
1/24/13 Update

I wanted to provide additional information related to my story above and how feeling something really is part of who we are as humans. I recently watched a video created by Dr. Paul Zak where he discusses a case study in how the human brain responds to effective storytelling. I could help but find the connection with Dr. Zak’s case study any my recent blog post. See for yourself here: http://youtu.be/q1a7tiA1Qzo and thanks Dr. Zak (@pauljzak)
*****

How will you use your 20 seconds?

I recently started working out. I would say again, but when the last time you worked out was more than 10 years ago, I think you just go with “started”. One of the routines I did yesterday on the bike was a 15 minute workout where you would peddle hard for 20 seconds and then ease back for 40 seconds and repeat this process for the full 15 minutes.

At first, I thought it was going to kill me, but after a few minutes it started to become a challenge. Each 20 second ramp up, I tried to beat my last speed. During the 40 second ease down period, I spent my time thinking about the next 20 seconds. In the end, it turned into a great exercise and I can’t wait to do it again.

Waking up this morning, I was thinking about that routine as I made my way to my client and wondered how many times I felt that “20 seconds” each day. Going through a day on the “40 second” side would be pretty boring, especially if you had a few of those day’s backed up in a row, but how many times do you actually get that “20 seconds”?

Is it possible to get that feeling, that productive feeling, every day in everything you do? The more I thought about this, the more I realized the answer was YES, you can get that “20 seconds” everyday in everything you do, but you have to know the secret.

  1. Driving home from a client on a Friday afternoon with the sunroof open. It wasn’t quite warm enough to open the windows just yet. Bruce Springsteen was on the radio singing a live version of Thunder Road. Volume at 10. Enjoying the drive home, even if I was sitting in gridlock traffic.
  2. Coaching my son’s baseball team on a warm sunny Saturday. Pop fly to 2nd based. Johnny (name changed to protect the innocent) gets right under the ball and makes a catch for the 1st out of the inning. So, no big deal, right? No, HUGE DEAL. You see, at the start of the season, Johnny had never even owned a baseball glove, never mind caught a ball. He showed up to practice and the first ball I threw to him gave him a bloody nose. Here we are a few weeks later and Johnny makes a catch. In a game no less.
  3. Preparing in my hotel room the night before a big lecture. Charging my video camera to make sure I could capture the event. Reviewing my slides, reading about the client. Went down to the bar to watch the Phillies playing in the World Series. The day of the lecture, I made sure to get there early and prepare for the unknown. That day, I spoke to about 20 people for over 2 hours and had a good feeling about the day. Unfortunately for me, my lecture started right at 1pm – snooze time. I knew I was going to lose everyone into food coma hell, so I had planned an exercise to get everyone out of their seats for 20 minutes. I had them! By the end of the lecture, I had a line of people waiting to talk to me. I found out a week later that my speech had been given the highest rating of the 2 day event.

Figure it out yet?

That 20 seconds that we all chase comes from the ability to do just one thing. Too often we spend our days or lives doing the “40 second” thing.

The “20 second” thing is doing something YOU want to do. Something you have ownership in and can take pride in. It is dealing with the “40 seconds” because we know the reward we will receive at the end. It is having the courage to speak out. It is having the patience to teach someone a new skill. It is having the confidence in your abilities. And, it is knowing how to fail and fail fast. If you find yourself spending too many day’s doing those “40 second” things then maybe you are focused on the wrong ideas. Maybe you are not empowered in your job?

Have you ever listened to, or read, the transcript of the Steve Jobs Stamford Graduation speech? He takes you through his life from birth to the creation of Apple and at one point in the story, it sort of hits you. The more Jobs did the things HE wanted to do or learn, the more time he spent integrating those ideas into what is now Apple. Maybe that is the reason so may great companies are founded by leaders who dropped out of college to pursue their dream. The thing THEY wanted to do.

I am not saying that spending your time focused on the “40 seconds” won’t have great results. I am saying that if you don’t experience those “20 seconds”, you are truly missing out on a great experience.

In my day to day actions, I am certainly guilty of spending too much time on the wrong end of the clock, but with some planning and focus, I know I can turn things around. Why shouldn’t every day feel like that drive home from work with Bruce blaring from the car on a sunny day? Life is too short.

Think about how much fun you have when you work on something YOU WANT TO? Think about the last time you overcame an obstacle when it was something YOU WANTED TO DO?

I hope I got you thinking? I know it certainly got my mind going and re-focusing on what is important.

In ending, I wanted to leave you with one final story I read a while back. To paraphrase below:

There were two tribes living in a remote region. One tribe lived at the bottom of this great mountain and the other lived up high on the mountain top. The bottom tribe couldn’t climb.

One day, the upper tribe came down in the middle of the night and kidnapped a young boy. When the bottom tribe woke up in the morning and realized that the boy was missing they called all of the men together and planned their attack.

Two days went by and nothing. Nothing they did worked. They just could not climb the mountain. In the midst of their third day of trying to get up the mountain, a lone woman walked up to the group of men. Without saying a word, she slowly kept on walking straight up the mountain to the disbelief of the men. They had been working so hard and along comes this woman who makes it look so easy.

After waiting for a day, the woman came walking down the mountain holding the young boy. When asked how she did it, how she managed to do what all of the tribes’ men failed to do, she had but a simple response. “It wasn’t your baby.”

It’s too Hard

As an Agile Consultant, one of the hardest parts of my job is in helping others realize that there is a better way to build software. The Scrum methodology speaks for itself, but getting others to change is one of the most difficult parts of the job. Recently I read a book by Chip and Dan Health called Switch, where the brothers provided insight on “how to change things when change is hard”. At the end of the book, they outlined twelve common problems that people encounter when fighting for change along with advice about how to overcome the problems. What struck me as interesting after reading the obstacles is how easily they could be applied to anything in your life that requires a change.

As an Agile Consultant constantly working with others to educate and coach them on the benefits of the Agile/Scrum methodology, I decided to see how the twelve common problems could be adapted to the adoption of a new methodology like Scrum.

  1. People don’t see the need to change
    Projects have a set flow to themselves that people find comfortable. People overlook the painful aspects of the project like having others make commitments on their behalf that are not attainable or the long hours put in to meet a delivery date just because it was communicated on a project plan. To show the need for change, you need to show a success, even if it is a small one. You need to communicate the impact of not changing and create an environment where changing is accepted and possible.
  2. People resist the idea because they say “We’ve never done it like that before”
    Building software is not an easy job and relying on process, checklists and habit help a team accomplish what otherwise seemed too complex. To change the behavior of people that are accustomed to a certain process, you need to “focus on the bright spots” as the Heath brothers say. Show an example of a project or process that is different from the norm and the success it has had and clone it.

  3. We should be doing something, but we’re getting bogged down in analysis
    The initial reaction I often see when talking about the Agile/Scrum methodology is people’s request for documentation to see how the Scrum process is different from today’s non-Agile process. People tend to spend a lot of time analyzing the methodology, deliverable’s and roles and responsibilities. To get past this analysis paralysis, you need to paint a picture of where we want to go and what it will feel like when we get there. People need to feel what it would be like if their employees were happier at work, more productive, delivered higher quality software faster to market and in turn created more satisfied customers. Once they feel what it would be like, you need to then create a path for them to achieve this feeling.

  4. The environment has shifted, and we need to overcome our old patterns of behavior
    People like habits. They make things easy even if the habit prevents you from achieving great success. To truly change a habit takes time, and without a path it can not be achieved. You need to constantly communicate where you are going and what it will feel like once we are there to instill change. Something as simple as putting the team together in a new location, away from the old environment can be instrumental in making change happen. Another concept I have found helpful is to play a game that allows people to learn the Agile methodology without the tie to their actual work relieving the stress of having to deliver something.

  5. People simply aren’t motivated to change
    To help motivate people, there are several small pieces of the Scrum methodology that can be easily implemented. Simple things as incorporating the Daily Stand Up meeting, monthly demos of working functionality, breaking existing Business Requirements into User Stories and reducing the size of your iterations (or creating iterations for that matter). Again, people need to know what it will feel like when they get to a new place and sometimes, lowering the bar can help you attain quick wins. Another method to help coach people to change is by using social pressure and show what others in the field or industry are doing.

  6. I’ll change tomorrow
    After the presentations are over and people have been trained on what it means to use the Agile/Scrum methodology, I often see strong reluctance to start using the methodology on a project. Whether it is the fear of change or the fear of failure, taking the first step is quite difficult. To help with the transition, the Health brothers recommendations could not be more true. They advocate that you need to 1. “shrink the change so you can start today”, 2. if not today, set an action trigger for tomorrow or 3. try making yourself accountable to someone and let their peer pressure be on you to make the change.

  7. People keep saying, “It will never work.”
    “What the mind dwells upon, the body acts upon” according to Denis Waitley in his book, The Psychology of Winning. How many times can you find where you already told yourself it wasn’t work and of course, it didn’t work. You need to find the bright spot that can show it can work. A team needs to see small victories and leverage the people who believe in the change as catalysts to the others.
  8. I know what I should be doing, but I’m not doing it
    To help contain the magnitude of changes that the Agile process brings to an organization, you need to start small. You need to get the team to think of small things that they can easily implement now and create an environment so that people have to change. Another way recommended by the Heath brothers that I have seen work extremely well is to get someone else involved in the change so that you can reinforce the initiative with each other and the behavior becomes contagious.
  9. You don’t know my people. They absolutely hate change
    People react differently to change. If you have a team that is very set in their ways, it is critical that they understand why the change must happen. You can also point out things that have happened that introduced change and how they have embraced those changes. How many of you have parents on Facebook?

  10. People were excited at first, but then we hit some rough patches and lost momentum
    Once people begin to see success with the new process, momentum builds and more people want to be a part of the “new way” but invariably, the excitement wears off. One way to keep this excitement is by building habits that reinforce the new behavior, reminding everyone of past successes and letting everyone know that rough patches are part of the process. I have seen the Daily Stand up meeting alone help to establish and reinforce the Agile methodology as well as communicating and celebrating the teams success. All of these things help to build that feeling of what it is like now that we have made a change and why you should stay in this state.

  11. It’s just too much
    Once again, you need to shrink the change into small successes that will, over time, lead to the larger change you are trying to adopt. Teams need to continue following the Agile methodology and constantly find ways to fit it into the culture of the organization until the process becomes the only way to get things done. People need to know that failure is a part of the change process and that they need to embrace the failure and learn from it for future actions.

  12. Everyone seems to agree that we need to change, but nothing’s happening
    Continue to educate and coach people on the process to ensure there are no questions and if there are, there is a place to go to get answers. Don’t allow anyone to have the excuse that they didn’t understand how things worked. Remind and reinforce the feeling of success and if possible, use past successes as examples to show that it can happen.

Even when faced with the benefits that adopting Scrum provides like Higher Productivity and Lower Costs, Increased Employee Job Satisfaction, Faster Time to Market, Higher Quality, Improved Customer Satisfaction and the removal of the “always done it this way” habits, people are still reluctant to change their old ways and habits. Hard work, education and examples will help people get to that new feeling and they will never look back once they get there.

Breaking the Dysfunctional Team

I recently read the book “The FIVE Dysfunctions of a Team” written by Patrick Lencioni. The author provides insight into the workings of a Team and what has to be done to ensure that the Team works together towards it’s success. In the book, Patrick creates a fictional company and walks you through some very familiar and common dysfunctions that could apply to any team, or for that matter, any relationship. The FIVE Dysfunctions discussed in the book are:

  1. Inattention to Results
  2. Avoidance of Accountability
  3. Lack of Commitment
  4. Fear of Conflict
  5. Absence of Trust

As I was reading this book, I couldn’t help but tie each of the dysfunctions to a real world example from my own career. I have seen all of these play out in some way and when they did, it didn’t provide for a very productive environment. Imagine working in an environment where everyone worked together towards a common goal? Imagine what that must feel like? “If you could get all the people in an organization rowing in the same direction, you could dominate any industry, in any market, against any competition, at any time”, say’s a good friend of the author.

That quote got me thinking.

I am working with a few clients now in their transition to an Agile Software Development methodology. This isn’t an easy task and introduces a lot of change to an organization which, for the most part, people try to avoid. The transition to Agile introduces the Team to a new way of thinking about their work and how they work together, and what became crystal clear after ready this book is how well Agile eliminates these FIVE Dysfunctions. Imagine if you could create a company like the one quoted above? Let’s take a closer look.

Absence of Trust

In an Agile environment, the Team works together to leverage everyone’s skills to accomplish the goal of the Monthly Sprint (Iteration) and knows that failing becomes a very public event. The Agile team is fully transparent and you can sense tension or issues from immediately. Since everyone involved (the Team, Product Owner and Scrum Master) created the goal for the Sprint and the Team agreed, or committed, themselves that they could do the work, the sense of meeting the goal is elevated. If someone gets stuck, there is no time to discuss why they are stuck (skill set issue, under estimated, computer issues, etc…). The team pulls together to help each other out so that they can meet the objective and deliver working software that meets the business expectations.

I have personally seen many times a Team new to Agile come together quickly to accomplish what was thought not possible. The level of excitement, awareness and appreciation for one another allows the team to focus the time and energy on the important tasks at hand rather than politics and makes meeting and working together fun.

Fear of Conflict

In an Agile environment, the Team works together to produce working software that meets customer expectations in short intervals. The very nature of building complex software introduces varying opinions and approaches and if not discussed, result in software that will only last a short life span. Healthy debate and discussion is encouraged by the whole team to ensure what is built is functional, but also that it can grow with each iteration. The team needs to be mindful of the future of the product while remaining focused on the task at hand. On an Agile team, there is nothing wrong with having to re-engineer something from a previous release because the agreed upon solution no longer supported the requirements form the business.

Lack of Commitment

In an Agile environment, each Sprint or Iteration begins with a clear Goal as well as a Sprint Backlog detailing tasks that must be completed by the end of an iteration to consider the iteration done and the goal met. The team is aligned to a common goal from the beginning and understands what it will take to get there. The Team and Product Owner meet daily in the Daily Stand up meeting to discuss status and impediments. If a task is unclear, the Product Owner and team member have immediate access to each other to resolve the impediment.

The Sprint Backlog is made visible for all to see and tasks can be added or removed by anyone as long as the Goal of the Sprint is met. Anyone can see who is assigned to a task and their progress and by attending the Daily Stand up, knows how the team member is progressing towards completion. Working closely with the Product owner allows the Team to respond immediately to change and ensures that the final deliverable meets expectations.

Lack of Accountability

In an Agile environment, the Team makes a commitment to each other to accomplish the Sprint Goal. If they fail to meet the goal, they all fail together. The Team is empowered to self-organize to get the work done in the best way possible and has a Scrum Master (Project Manager) to help remove any impediments that arise along the way. The Daily Stand up meeting is unlike a status meeting in that rather than reporting status and impediments to the Project Manager, each Team member reports status and impediments to each other. The Team in affect is micromanaging themselves. At the end of each Sprint, or Iteration, the team holds a Review meeting to demonstrate the functioning software that was completed and to elicit feedback from the Product Owner and other Stakeholders.

Inattention to Results

In an Agile environment, the attention is all about results! While the Team works together to deliver working software at the end of each Sprint or Iteration, they are extremely focused on the Goal of the Sprint. Using the status and impediments communicated by the Team, the Scrum Master uses a Burndown Chart to track progress towards the Sprint goal making the results transparent to everyone. If a task that was expected to take 4 hours is now in it’s 7th hour, everyone knows. If the Sprint Goal can not be met, then the Sprint is terminated and a new one is started from scratch. Every Team member is committed to the Goal and only works on tasks that will help achieve success.

I highly recommend reading Patrick Lencioni’s book and seeing for yourself how he proposes to remove these dysfunctions. It is clear that when teams don’t work together, they won’t achieve great results. What I have found in Agile is that the methodology, by it’s very nature, forces these dysfunctions out of the system and allows everyone to focus on meeting the same goal. It may not happen over night, but a once the team begins to focus on the end result and the best way to achieve that result, they work together and communicate how best to deliver. Communication and Transparency are key to creating a highly functional team as well as having a clearly defined goal. You can have a team of the most talented people in the world and fail if they can’t function as a team towards a common goal.