Comments (0)

By tkamens, March 10, 2010 6:06 pm

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.

Comments (0)

By tkamens, February 11, 2010 7:40 pm

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 Committment

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.

Comments Off

By tkamens, January 11, 2010 9:08 pm

How many projects have you been on where you knew there was a better way, but found yourself talking about it at the end of the Project?  If there was a better way, why wasn’t that way being followed?

There is a simple answer:  People don’t like to change.

Change is hard, complicated and involves lots of communication and it is a lot easier to just “do it the same way”.   There is no better proof in understanding the lesson of Edwards Deming and the impact he had on Japan Post WWII.  At a time when Japan was completely knocked down and looking to rebuild their lives and their businesses,  Deming brought that “Better Way” and the Japanese listened.  Who was Deming and why did people listen?

“William Edwards Deming (October 14, 1900 – December 20, 1993) was an American statistician, professor, author, lecturer, and consultant.   Deming is widely credited with improving production in the United States during the Cold War, although he is perhaps best known for his work in Japan. There, from 1950 onward he taught top management how to improve design (and thus service), product quality, testing and sales (the last through global markets) through various methods, including the application of statistical methods.

Deming made a significant contribution to Japan’s later reputation for innovative high-quality products and its economic power. He is regarded as having had more impact upon Japanese manufacturing and business than any other individual not of Japanese heritage. Despite being considered something of a hero in Japan, he was only just beginning to win widespread recognition in the U.S. at the time of his death.”     W. Edwards Deming, Wikipedia

If you own a Toyota and not a Ford, you can understand the impact Deming made on the Japanese culture, but why?  Why did the Japanese businesses listen while the American businesses didn’t?  I believe the answer was simple:  The fear of failure was gone.

As Niccolo Machiavelli said in The Price:

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

For the Japanese, what did they have to loose that they hadn’t already?  Incorporating Deming’s teachings into business processes made sense, they just had to be implemented and adhered to.  Once implemented, these processes became the standard and would only improve.

While in College, my Operations Management class had the opportunity to visit the Honda Manufacturing plant in Marysville, Ohio.  As we watched a Honda Accord take shape from the delivery truck’s arrival to the cars driving off the line, one thing was very evident to our class.  There were no bugs! The cars coming off the line didn’t enter a “re-work” section where a part that broke during the manufacturing process would be fixed.  If a part broke during the building process, it was fixed right there so it never happened again.  No Bugs! Here, in-front of my eyes, Deming’s teaching was in full display and it was truly amazing.

As we look to 2010, I believe we will see the same level of efficiency that was brought to the manufacturing industry immerse itself into the software industry.  The companies that succeed in the future will be focused on delivering the Highest Business Value and doing so without Bugs! Companies will no longer be able to afford to build things that the customer doesn’t want if they want to stay in business they certainly cannot afford to deliver inferior quality.  The recession in the American economy has in some ways removed the fear of failure from businesses and companies  that change and continue to improve will be the Toyota’s of tomorrow.

The companies that can build a sustained competitive advantage will outpace all other businesses by setting expectations so high, they will be the new norm in tomorrow’s economy.