Wednesday, July 18, 2012

Executive Guide to Transformation Coaching


Coaching is one of the hardest skills for an executive to learn.

Why?

The answer I believe is revealing. Most executives are convinced they know what they are doing. In his or her mind, it is the rest of organization that needs to change. Given that executives excel at building relationships and managing perceptions perhaps most executives believe their own spin.

This state of denial is a blind spot that blocks many an agile and lean transformation. Isn’t the first step to change, recognition of the problems?

By believing it is someone elses problem, the executive overlooks an important part of the transformation, the transformation of oneself. Subsequently, such an executive also ignores the transformation of one’s peers.

Think of the discontinuity that will arise. You are asking your staff to change their behavior. You invest in their training and teach them key concepts like how to be self-directed .Not only will this impact your organization, it will impact neighboring organizations. What is being done to prepare the leadership of the coming changes?

Remember, the culture that is in place, the one you are trying to transform, was put in place by the leaders (i.e., you or your predecessors).  The current system (i.e., the way work is done) is primarily responsible for the organizations struggles. It is the leaders that are primarily responsible for the state of the current system.

Understanding agile and lean leads one to understand the importance continuous improvement via root cause analysis. Too many organizations are driven by a culture of blame. If something goes wrong, someone is to blame. An executive must recognize it is the current system that is the root cause of most of the current dysfunction. To move from a culture of blame to a culture of continuous improvement requires the elimination of fear. Removing the fear from ones organization does not happen overnight and will not happen at all if the executive does not change. Teaching leaders that fear is not a tool but part of the problem will be a challenge.

OK, so you are an executive and you have come to understand that the current system is the main contributor to poor productivity and or poor quality. What next? You need to coach your peers!

Too many executives attempt transformation and look to their subordinates to drive the change. When their staff hits against the existing corporate system, the executive is nowhere to be found. When an executive from a neighboring organization complains or blames any person attempting to drive transformation the executive’s backing is critical. Backing your people as they execute the transformation shows you have skin in the game. By not to supporting your people you are placing your people in harms way and many will fall victim to the corporate immune system. This will bring the transformation to a halt.

Your role as coach is to first coach your peers. This is essential if the transformation is to succeed. Your peers need to be educated about the transformation. They need to know what to expect, why the change is necessary and the results and benefits the transformation will bring. Collectively, you can determine the impact to the neighboring organizations and what if any coaching is required. When things go wrong, the leadership needs to bring an end to blame. Instead the leadership needs to coach how to drive continuous improvement via root cause analysis.

As you can see the best transformation starts from the head. The executive educates oneself then learns to coach one’s peers. Collectively, the leaders of the organization can then begin to coach their organizations.

It is a rare executive that has the insight and courage to first transform oneself then become an agent of change by coaching one’s peers. Transformation is hard. Transformation without support from the top is impossible. It will have limited success at best and any progress made is likely to be short lived.

Transformation from the top brings about sustainable transformation. What kind of executive are you?


Friday, June 8, 2012

Agile De-transformation


You have a high performing organization. The teams are self-directed. They can take business goals and work with the product owner to build a backlog, plan iterations and using pairing and test driven development deliver working software. They often delight the business.
Once you have transformed an organization into a high performing organization, how do you stop it? How do you de-transform it?

Why would you want too you ask? If we can identify what would bring an end to a high performing organization, we may gain some insight into what not to do. We may learn that the “don’ts” we identify are exactly what many managers do today unaware of the consequences.

So what is the master plan? In priority order, what would you do to bring a high performing organization to a halt? Here is a short list:.

  •        Commit the team to deliver software that was estimated and planned by someone other than the team
  •        When the team provides estimates that are higher you tell them to waive their practices so they can commit to the budget, schedule and scope as it stands


Is that all you have to do? Is it that simple? Let’s examine the impact of the above two steps.

By committing a team to a schedule, budget and scope you have taken away the team’s ability to be self-organizing and self-directing. The team not only does not have buy-in, they don’t have knowledge of the solution nor any confidence that it can be done.  What knowledge they do have says it can’t be done yet their feedback is ignored.

By the above actions, you have moved the team from emerging design and iterative and incremental delivery to big up front design with big bang development. Planning not only is a one-time event, it was done by someone other than the team. The ability to deliver working software every two weeks, receive and incorporate feedback and update the plan is now lost.


How about the second bullet point, what impact does it have. You have told the team that their practices are the reason the estimate was wrong. That the practices of agile utilized by the team are the reason their estimate is high and the estimate done by someone else is right.

Never mind that the “other” estimate was done by one or two architects and was very high level. You can ignore that the team took the original estimates and decomposed them into story cards. Discussed proposed solutions with the product owner and used planning poker to bring about shared understanding.

You are telling the team that they cannot leverage the skills they have learned and utilized to deliver successfully many time previously. Instead, the lower estimated is picked, not because it is nearer to the truth but because expectations with the business have already been set and no one wants to bring about the bad news.

Management has now set up the team for failure. If the teams resists, they are told they are wrong. You can imagine how demotivating such an experience would be.


As you can see, it does not take much to destroy a high functioning team and organization. A few simple directives and you no longer have a team but a group of hostages being held accountable to deliver something they don’t understand or believe is possible. The final insult is you have taken away the very tools that have brought them success.

How many leaders put their organization or teams in this very position? When given a high level estimate, instead of bringing the truth to the business, they relent and commit the team to failure. Instead of coaching their peers and the business they throw the team under the bus.

Is there a shorter list than the one above that can destroy a high performing team? I say yes. It is, remove the product owner.

Really? Remove the product owner? Is the product owner that important?

Absolutely! How many organizations attempt agile without a product owner? The product owner is the one that provides feedback as working software is delivered incrementally. Without feedback, how is the team to know if they are on the right path. If the business does not have skin in the game (see http://www.agileandleanatscale.com/2012/03/skin-in-game.html) they are not vested. They have no ownership for what is being built. They are dis-engaged by standers. What chance does a team have to build the “right thing”? What chance does the team have to “delight the business”?

As you can see, it does not take much to destroy engaged, self-directed and productive teams. All it takes is a leader that has little to no understanding of how agile works.

Thursday, May 10, 2012

Water in the Boat, Leaks in the Boat

How do you get to zero defects?

Divide and conquer.

We took the following approach. We established a run team. The run team handled customer support issues and fixed existing production defects. Members from other teams would rotate through the run team every iteration. Thus, no one was stuck supporting production perpetually and everyone had an opportunity to learn what our production support issues were.

By having a few developers focused on production issues per iteration, the run team’s productivity would increase as they did not have to switch between new feature development and defect fixes. The run team also provided a firewall to the teams focused on new feature development. By protecting the feature teams from interruptions, the feature teams’ productivity also increased thus protecting our product roadmap.

We created the following metaphor.  We would call defects in production “water in the boat”. The run team would fix defects in priority order. By taking this approach the run team was able to empty the “water in the boat” i.e., fix all production defects over a sequence of iterations. We developed a zero tolerance policy regarding defects and we did not cut corners. We would have entry an exist meetings for each defect, just like we did for features and we would test drive our fixes. This helped ensure that we fixed defects right the first time and with test wrapped around the fixes they would squeak should some future change break what had been fixed.

Meanwhile, the feature teams were busy adding new features to our product. Initially, we did not have our regression tests automated. Thus, after an iteration, we would find that we introduced new defects into our product. The introduction of new defects was called “leaks in the boat”. These leaks existed in spite of pairing, TDD and ATDD. All of these practices did contribute significantly to the quality of our product but did not get us to zero defects. Only when we put in place an automated regression suite that ran daily against all customer configurations were we able to plug the “leaks in the boat”.

The metaphor of “water in the boat” and “leaks in the boat” was a powerful one. It helped everyone visualize an important goal for the run team and the feature teams. Developing a zero tolerance policy for defects did much to reduce our cost and increase our velocity. By having practices in place that ensured what was built today would not need to be fixed tomorrow, it enabled the teams to remain focused on new features and not be distracted by fixes.

We still have a run team, and it does handle the occasional production support issues. However, it now spends the majority of its time working on small enhancements that improve our product and customer experience but by themselves would never make it to the product backlog, which highlights another point. We have learned there is a benefit to providing some limited capacity for those small features which by themselves never make it to the backlog but in aggregate improves our product and brings benefit to our customers. It has made the difference between a good product and a great product.


Tuesday, May 8, 2012

Cucumber

Am reading "The Cucumber Book". I like concise statements like this one:

"Acceptance test ensures you build the right thing while unit test ensure you build the thing right".

While developers write unit test to drive their designs, it is essential that the business (or product owner or business analyst acting as proxies for the business) write feature files to describe the software's behavior. Developers then automate the step definitions. Following the principles of Outside-In, the scenarios tell the developers what unit tests to write. TDD helps the developers "build the thing right".

Given that some business people are unable to write feature files, the business can work in collaboration with cross-functional teams to write the Gherkin. What cannot be delegated to developers by the business is the behavior expressed by the scenarios in the feature files. Before the feature files can be automated by the developers, the business must ensure that the scenarios define the behavior of the software from their perspective. Only then has the business properly defined what it means to "build the right thing".


Monday, May 7, 2012

Five Whys of the Agile Disconnect

Let’s use the five whys. To what end? As a CEO or CIO you need to determine the root cause of the confusion regarding agile. You have sensed significant disconnects between what organizations and their leaders say about agile.

Let’s set the stage. Let’s assume that leaders have good intentions. Their goal is to grow or operate the business well. Let’s also assume that teams have the same goals. They want to contribute to the success of the business.
To further set the stage, agile has emerged from the bottom up. Agile’s origin came from software developers who gathered to determine how to improve software development and delivery. From their historic gathering came the Agile Manifesto – www.agilemanifesto.org. A quick view of the agile manifesto makes it apparent that agile has changed the software development and delivery paradigm significantly.
Finally, most, if not all of your leaders in your organization rose through the ranks understanding traditional project management. They navigated its pitfalls and managed the organizational politics to either become effective leaders, or manage the perception of effective leadership. In either case, the prevalent mental model of the leaders in your organization is waterfall.
With the stage set, let’s begin asking the five whys.
First why: Why do leaders and teams have a different understanding of agile?
First response: Teams received training, either by an external source or through self-education. Many leaders believe they understand software development; after all, they have leveraged project management in their organization for years. Their past successes are testimony to their knowledge and skill.

Second why: Why have only teams received agile training and not the leaders?
Second response: Teams are interested and motivated to learn agile and are likely to have been the instigators to brining agile to the enterprise in the first place. Leaders either believe they understand all there is to know about software delivery or that agile is only for developers thus there is little motivation for them to learn something new.

Third why: Why are only the teams motivated to learn agile?
Third response: Teams are frustrated by failed projects, they want to find a better way and have learned that agile, done well, is having success. They are motivated to grow their skills and want to make a difference. Executives have had success as evidenced by their position. For them, the pain of failed projects is not as evident.

Fourth why: Why aren’t leaders motivated to find a better way to deliver projects. Aren’t they tired of failed projects and don’t they want to improve the system?
Fourth response: Information is frequently filtered by the layers of the organization before it gets to the senior leaders. Most leaders would be surprised to learn of the issues experienced by teams. The impression of team and organizations is often shaped by the filtering and perception management rather than reality.

Fifth why: Why are the problems experienced by teams filtered prior to reaching the leaders? Don’t leaders need to understand the systemic issues of their organizations?
Fifth response: Competition at the top of the pyramid is intense. Presenting problems to your boss is often viewed negatively. You are perceived as not being able to manage your organization. Thus only information that convinces your boss that you are good manager makes it to the top of the organization.

Wow, the root cause is identified by the response to the fifth question. It is significantly different than what you might conclude from the response to the first question. Each question uncovers another layer of the problem. The first layers, while somewhat true, are only superficial. Typically, it takes about five questions to uncover root cause.
If you stopped at the first question, you might conclude that all you have to do is provide leaders with agile training. If such a class was offered, how many leaders would attend? Of those that attended, how many would focus on the training? If you stopped at the first question you might not understand why executives don’t have an understanding of agile.
If you stopped at the second question, you might see that agile is often introduced by the teams and not the leaders. That often leaders are so disengaged that they don’t realize that agile is even part of their organization. For those that do know their teams are doing agile, they are likely to conclude that agile is for developers not executives. If you took the steps to inform leaders about agile, how many leaders might stop agile before it could blossom? If you stopped at the second question you might not learn why executives are not motivated to learn about agile.
If you stopped at the third question, you might think that all you have to do is make executive aware of the issues experienced by failed projects. If they knew of the systemic issues experienced by their organizations they would be able to address the issues given their position. If you stopped at the third questions you might not learn why executives don’t know about their systemic organizational issues.
 If you stopped at the fourth question, you might think that all you have to do is stop the filtering of information. This would provide visibility into fundamental challenges faced by software developers. If you stopped at the fourth question, you might not learn why the filtering is taking place to begin with.
By asking the fifth question, you learn that it is the system that is at the root of the problem. As a leader, you have inherited and perpetuated a system where relationships and perceptions matters more than fact. Real data doesn’t matter and is consequently lost. Systemic issues of the of the organization are hidden by the organization. Rewards go to those that manage perceptions, not facts, to those that build relationships not value.
Image a leadership meeting where executives were expected to bring system issues to the executive team. The executive team would then review the issues and attempt to identify root cause. They as leaders would take accountability for the failures brought about by the system and would be invested in identifying and eliminating root cause.
How are you executive meeting run? Do your peers spend time demonstrating their skills as a successful senior leader? Are real issues of the enterprise ever identified? If they are, do your peers look for root cause within the system for which they are accountable or do they look elsewhere to pin the blame?
Try the five whys sometime. Not as an exercise to pin blame, but to identify root cause. Once root cause has been identified, use your leadership to remove barriers and measure results. Become a leader driven by data. Use the five whys to uncover root cause. Improve productivity by utilizing continuous improvement. Bring an end to the self-serving leaders focused on the thin veneer of relationship and perception management.
The top of the pyramid is narrow. You want effective leaders that drive organization continuous improvement. Change the culture by asking for data. If you don’t believe the data, go to the source. You may have inherited a dysfunctional system, but it does not mean you have to sustain it.

Wednesday, May 2, 2012

Enterprise Agile-Lean Transformation Case Study

The Leans Software and System Consortium has an excellent presentation of an Agile and Lean Transformation caried out by Premier, a health care provider.

Some key points
  • start with the leadership, without executive buyin, the transformation will eventual stall or fail
  • select the right coach and/ or embedded coaches
  • create an internal champion
  • start with a pilot team
  • trasparency, make it visibile
  • business engagement; top-down portfolio of prioritized work
  • PMO ensured consistent use of visual controls for all teams
  • enterprise dashboard for entire portfolio
  • dashboard summaries available by browser
  • visibility lead to success
Audio is here : http://www.leanssc.org/files/201004/powerpoint/4.23%2011.45am%20Horton%20ThePowerOfVisibility.pdf

Slides are here : http://www.leanssc.org/files/201004/powerpoint/4.23%2011.45am%20Horton%20ThePowerOfVisibility.pdf

Executives, it is time to lead. If you can't coach you can't lead. If you can't lead you can't transform the enterprise.

Thursday, April 26, 2012

I want to run an agile project

http://www.youtube.com/watch?v=4u5N00ApR_k

Executive Guide to Peer Coaching

You have decided to go agile. You have delegated the responsibility to your staff. What should you do now?

A peer (fellow executive) approaches you from the business. They are upset. They have been told the team is doing their development is pairs. Your peer says, “Do I have to pay for pairing”?

Your organization has been doing agile for 6 months. Teams are functioning well and software is releasing quickly with high quality. Your peer says, “Your quality is too high, I would like to pay less and am willing to lower quality”.

Another peer approaches you and says, “Your teams are too ridged, they insist on using the agile practices, I need teams that are willing to compromise”.

How do you respond to these comments? More importantly, why are your peers making these statements to begin with?

Some companies subscribe to the myth that anyone can be a good executive if they know how to manage relationships, have executive presence and shape perceptions. Knowledge of your domain, practices, skills or technology isn’t necessary. Such organizations have a difficult time with excellence. Projects and transformations are frequently started but many stall and fail. Such companies are littered with projects that never completed successfully. It can be very difficult to lead what you don’t understand.

In the previous post, I identified a number of reason’s executives don’t coach their peers. In this post we will focus on what will happen if you don’t coach and more importantly, what sort of coaching you should provide to your peers.

Looking at the first comment, the misperception is that it will take a pair just as long to complete a card as one person. Having two developers complete a card means they have to pay more for development.  The person who made the comment is revealing his or her lack of knowledge of pairing. It is also an indication that the person making the comment has received insufficient, if any coaching.

A properly coached peer will know that a pair will complete a card in nearly half the time. That is because the bottleneck to development isn’t the number of keyboards or the typing speed of developers, it is problem solving. Two heads will solve a problem faster than one. The solution will be cleaner and require less lines of code. Given that two eyes have reviewed the code in real-time, the code will have significantly less defects. Thus, the pair is more likely to work on a new feature tomorrow instead of fixing what they broke today.

In addition, the knowledge transfer between team members will spread like a virus. This relates to the product, business domain, source code, practices and use of the tools. A new person in a pair can be effective nearly immediately instead of the six months it takes a person sitting in a cube.

Thus, an informed peer instead of expressing fear over additional costs should be pleased with the money and time saved because the team is effectively pairing. This is a much more enjoyable conversation to have.

As you can see, there is sufficient coaching that needs to take place to prepare your peers for the transformation to agile. If this is not done, the misunderstanding will lead to significant waste. It may also make your staff gun-shy. No one wants to make enemies in the executive ranks.

The second comment is amusing. We have learned that defects add to cost. The later you find defects, the more it costs to fix them. To lower cost you find and fix defects sooner or prevent them to begin with. The practices that are used to bring about a reduction in defects reduce cost and ensure that the team can spend all of its capacity delivering new features and not fixing yesterday’s mistakes.  I am unaware of any test methodology that allows one to filter on defects by severity or impact when developing software.  Mistaking proofing development is an effective way to reduce cost and increase a team’s productivity.

The person making the comment has revealed his or her lack of understanding of quality. They visualize and extended period of time to do additional testing. It is visualized that every defect on the list found late in the process much be fixed. For this reason, it is determined that it cost more to have high quality.

Such a person has never been coached with regards to the impact of pairing, test driven development, acceptance criteria and acceptance test drive development. It is unlikely your peer is aware of the automation of regression test thus regression tests are run daily. These practices enable software to be delivered with quality, faster and at a lower cost. But how are they to know if you did not provide coaching?

Are you prepared to coach your peer past these misconceptions? Better yet, are you able to anticipate this type of confusion and provide the coaching needed prior to the transformation?

The last comment is code for, “I don’t want to have to change the way we work. Can’t your agile team follow our process”?

Such a request is rooted in ignorance. Understanding agile and the benefits it brings has never been presented to your peer. If executives don’t understand agile, they will take such a comment at face value. They will decide that compromise is good and that the agile teams are being ridged. Such feedback can bring an agile transformation to a halt or destroy the effectiveness of teams that are already highly functioning.

Why would you want to compromise on cost, schedule, scope and quality? All should be motivated to bring the most value to the business at the lowest coast, shortest time, with the most features and highest quality. It is not about compromise, it is about continuous improvement. It has to be led by effective coaching.

Perhaps the most important coach in an agile and lean transformation is the executive coach. An enterprise agile and lean transformation needs a champion that has the clout to bring his or her peers up to speed to ensure the transformation occurs and is sustainable. Such coaching must come from at least one executive champion. Organizations are dynamic. Leaders come and go. Until the transformation becomes part of the organizations DNA, it requires an executive coach. An executive coach’s job is finished when his or her coaching is no longer needed. It is no longer needed when the system is in place and staffed by an organization where everyone coaches.

Friday, April 20, 2012

Executive Guide to Transformation Coaching

Coaching is one of the hardest skills for an executive to learn.

Why?


The answer I believe is revealing. Most executives are convinced they know what they are doing. In his or her mind, it is the rest of organization that needs to change.


Given that executives excel at building relationships and managing perceptions perhaps most executives believe their own spin.


This state of denial is a blind spot that blocks many an agile and lean transformation. Isn’t the first step to change, recognition of the problems?


By believing it is “their” problem, the executive overlooks an important part of the transformation, the transformation of oneself.  Subsequently, such an executive also ignores the transformation of one’s peers.


Think of the discontinuity that will arise. You are asking your staff to change their behavior. Not only will this impact your organization, it will impact neighboring organizations.


Remember, the culture that is in place, the one you are trying to transform, was put in place by the leaders (i.e., you or your predecessors).  The current system (i.e., the way work is done) is primarily responsible for the organizations struggles. It is the leaders that are primarily responsible for the state of the current system.


Understanding agile and lean leads one to understand the importance continuous improvement via root cause analysis. Too many organizations are driven by a culture of blame. If something goes wrong, someone is to blame. An executive must recognize it is the current system that is the root cause of most of the current dysfunction. To move from a culture of blame to a culture of continuous improvement requires the elimination of fear. Removing the fear from ones organization does not happen overnight and will not happen at all if the executive does not change.


OK, so you are an executive and you have come to understand that the current system is the main contributor to poor productivity and or quality. What next? You need to coach your peers!


Too many executives attempt transformation and look to their subordinates to drive the change. When their staff hits against the existing corporate system, the executive is nowhere to be found. When an executive from a neighboring organization complains or blames any person attempting to drive transformation the executive’s backing is critical. Backing your people as they execute the transformation shows you have skin in the game. Not to support your people is to bring the transformation to a screeching halt.


Your role as coach is to first coach your peers. This is essential if the transformation is to succeed. Your peers need to be educated about the transformation. They need to know what to expect, why the change is necessary and the results and benefits the transformation will bring. Collectively, you can determine the impact to the neighboring organizations and what if any coaching is required. When things go wrong, the leadership needs to bring an end to blame. Instead the leadership needs to coach how to drive continuous improvement via root cause analysis.


As you can see the best transformation starts from the head. The executive educates oneself then learns to coach one’s peers. Collectively, the leaders of the organization can then begin to coach their organizations.


It is a rare executive that has the insight and courage to first transform oneself then become an agent of change by coaching one’s peers. Transformation is hard. Transformation without support from the top is impossible. It will have limited success at best and any progress made is likely to be short lived.


Transformation from the top brings about sustainable transformation. What kind of executive are you?

Tuesday, April 17, 2012

Executive Guide to Removing Blockers

With all the success and benefits demonstrated by companies with effective agile and lean teams, why do executives understand so very little about either? The question has puzzled me.


In an earlier post, I reviewed how Toyota had great success at General Motors. With Toyota’s help, what was GM’s poorest performing plant became GM’s highest performing plant inside of a year. Did the GM leadership race to implement the Toyota Product System at other plants? No! Why?
In the mid twentieth century, Deming attempted to convince American executives of the benefits of what became the foundation of lean. Frustrated by the lack of traction in the US, he took his message to Japan. Deming’s teaching became the foundation of the Toyota Product System otherwise known as lean. Are Japan executives smarter than American executives? No! Why then the difference in response?

Agile was born by software development engineers who gathered to find a better way. Many of the defined agile values and principles moved away from centralized control to collaboration and self-empowered teams. Agile gathered the best management and engineer practices and packaged them in such a way that the benefits of the whole were greater than the sum of the individual practices. While well executed agile has brought great benefit to many businesses and customers, it is still thought of by some executive and middle managers as a “developer thing”. There appears to be so little motivation by management to understand and leverage the practices that have transformed numerous organizations. Is it a question of motivation? Perhaps!

Who are the leaders of our corporations? What is the mindset of the canonical executive? What drives their behavior?

I have never been good at mindreading. However, perhaps if we contrast the values between agile and lean principles and executive incentives we will gain some insight into behavior.
Executives are often incented by results tied to the performance of the company. Measure tied closely to customer and business benefits are essential. Effective measures are hard to game and take the whole value stream into account. Good metrics drive good behavior.

The inverse is also true. Arbitrary measures have large disconnects between the measures and the benefits to the customer and business. Metrics that are easy to fudge and tied to financial rewards are likely to be gamed. Poor metrics also drive local optimization. Local optimization occurs when a metric incents one organization to complete their work at the expense of another organization within the enterprise.

The more arbitrary a measure becomes and the greater the financial reward, the more likely bad behavior results. Human nature being what it is, tying financial gain to arbitrary metrics drives the organization to focus on the wrong behavior, invites the gaming of metrics and to practice local optimization
Earlier I contrasted Japan companies with American companies. To summarize, “Short term thinking companies are in business to make money while long term thinking companies make money to remain in business”. Who is more focused on long term and short term thinking? Which companies are likely to sustain profitability?

Why are executives so short term focused? To answer the question, we have to look to how we incentivize our leaders.  Incentives are tied to what is valued. Are values the core reason for the gulf between executives and agile and lean teams? Let’s compare.
Agile and lean principles value the following
  • Deliver working software – measure what matters to the customer and the business vs. an arbitrary metrics
  • Sustainable pace – sustained performance vs. meeting a short term goal
  • Test first development and pairing – system thinking (understand the whole) by eliminating problems at the source vs. local optimization (don’t care what happens down the value stream)
  • Self-directed teams – accountability vs. avoiding blame
  • Transparency – providing a clear pictures of the issues vs. manipulating perceptions
  • Collaboration – team work and shared goals vs. making one look better at the expense of another
  • Courage – do what is needed to make things better vs. fear of taking risks
  • Continuous improvement – recognize what is not working, identify root cause and improve vs. burying ones head in the sand or redirecting blame
I have seen organization succeed with agile. I have also seen organization with functioning agile team impaired or rendered ineffective by executes suffering from the value discontinuity that often exists between agile and lean teams and executives incented by arbitrary measures which drive bad behavior.

How does this get fixed? This is a hard conversation to have with an executive. Besides the obvious risk to one’s career, the message is likely to be missed.
Think of it this way. Many successful executives are good and figuring out the unspoken rules. The better they can navigate the hidden rules, the more likely they are to rise. What are the rules? They can be different from company to company but I have seen the following.

For successful companies, it is a matter of riding the wave. Such companies are typically very profitable and in a stable market. Because of the company’s market dominance, maintaining the status quo is what is valued. So, building relationships and managing perceptions are on the critical path to success. If your strengths are relationship building and perception management, you will likely do well in such a company. Such a company typically frustrates and drives away those that are results oriented.

For new or growing companies, it is about fighting for day to day survival or improving market position. Such companies typically value results. They look for people that can make a difference. The difference is measured as impact to survival or growth. A skilled and results oriented person will typically find such a company a rewarding experience. While it is important to have a good working relationship, the relationship is valued more for results they bring and not for gaining favor.

The former companies are likely, at one point, to lose market dominance. Given that relationships matter more than results, the skills of the company and consequently it ability to respond to market threats are greatly diminished. We have seen this time and time again when well established market leaders lose position to upstarts. Remember, change is constant and the rate of change is accelerating.
The later example is also has its risk. Once a growing company establishes its position in the market, it can lose the values that helped it succeed.

Agile and lean values are about results now and for the long term. It is about continuous improvement and rewarding behavior that connects to the customers and the business. Agile and lean enables the executives and the staff to align to the same goals and share a common set of values. This leads to sustainable success. There is nothing more demoralizing to strong performing teams then to see rewards parceled out by club membership or perception manipulation instead of adding value.
Who has the brighter future, GM or Toyota? Which company declared bankruptcy? Which company required government bailouts to survive? Which company continues to grow and is admired for the quality of its product by its customers?

Executives, it is time to remove the blockers to your company’s present day and long term success. It is time to align what you measure to the value you deliver. Yes, it is hard to rock the boat. Your chance of implementing change is small; the risk to your club membership is high. Consequently, we don’t see many established companies transform themselves. There is too much executive self-interest to overcome.

On the other hand, leaders with courage and vision have been able to transform organizations. Companies fortunate to have such leaders are companies that have a long history of success and have the ability to learn from failure and pivot towards success. If you are such a leader, look to agile and lean. I believe both reflect the values and provide the practices that will help you identify and remove the blockers to sustained business success.

Thursday, April 12, 2012

Executive Guide to Agile and Lean Transformation

First rule, transform oneself!


Typically, leaders see the signs of dysfunction. The business is not happy. They complain about cost and schedule and quality. The developers blame the business. “They don’t know what they want” or “They are always changing their minds”. You hear these comments in spite of the years of effort and training to implement project management.


The most common reactions are “What or who do I need to change to fix this?” “Do I need to provide better training?” “Is it the staff we have?” “Is the organization not following the processes?” Do you notice a pattern here?
It is everyone else’s fault but the leaders! The focus is elsewhere and not with the root cause.
This reaction is a long standing one and widely shared. Deming encountered it when he began to teach his principles behind “Lean Management”. In fact, after executives in the US turned a deaf ear to his principles, he traveled to Japan. The Toyota Product System (TPS) is largely built on his teachings. As a result, Toyota has gone from a small insignificant player to a global leader of transportation engineering and manufacturing.
How did this happen? Were the Toyota leaders focused on what changes the staff needed to make or did they first transform themselves? Deming stated that 85% of the dysfunction of an organization is rooted in the processes of the organization. He called it the system. It is the leaders that have primarily put the system in place.
Lean Management is fine for Japan but it will never work here. That was General Motors response to Toyota when they offered to help GM. With American culture and unions it is not possible they said. Toyota asked GM to give them their poorest performing plant. They did. One year later, Toyota turned GMs worse performing plant to their best. Did General Motors rush to convert their other plants? No! Instead they ignored the results and continued with their ways. Change is hard. It is even harder when you are the one that has to change.
In recent years a movement called Agile has emerged. It has primarily been a bottom up movement. Engineers, frustrated with the way corporation built software decided to take action. They were tired of the frequent failures encountered with traditional project management. They gathered to find a better way.
From their efforts, the agile movement was born. It has literally transformed the way software is being built today. This is in spite of the majority of executives not grasping why it works or their role in leveraging Agile effectively.
Agile and Lean work well together. Agile flourishes where Lean is understood and practiced. Lean, unlike Agile, started from the top. It’s about executives taking ownership for the system. Once accountability is properly placed, the leadership can teach themselves how to monitor the system, establish feedback loops, plan change and measure its impact. This is the “Plan, Do, Check, Act” pattern of continuous improvement. The focus is on improving the system, not blaming individuals.
Today, organizational transformations are underway. It starts with leadership taking accountability for the organization’s effectiveness. It is about leadership investing in their understanding of the lean and agile principles. Only through personal transformation can they become effectively leaders. They must lead by doing. They share accountability in results. There are invested.
Common principles shared across Agile and Lean:
  • Self-directed teams – Lean recognizes that those closest to the work are the one best to define how to do the work. Agile is an advocate of self-organizing teams. Both require clear goals set by the leadership. Not objectives but goals. Effective organizations are not hamstrung by micromanagers.
  • Pull based scheduling – Lean uses Kanban to ensure work is only done when needed; there is no sense building inventory upstream when there is no demand downstream. That is waste. Agile has teams pull cards from the backlog, one per pair, only when they finish the work they have. Pull based schedule maximizes the flow of work through the team consequently it is much more effect than push based scheduling practiced by traditional project management.
  • Continuous improvement – Lean uses the shewhart cycle of “Plan, Do, Check, Act” via Kaizen to continually tune the system to maximize the quality and flow of work through the system. Agile uses a number of feedback loops included in Daily Standups, Retrospectives, Show and Tells and Test Driven Development (TDD) to continually improve the workflow and quality of the product.
  • Visual Management – Lean use Andon boards to signal when an abnormal condition is recognized and help is needed. Agile uses Big Visible Charts (BVC) to make transparent the current state of the work for a team. Calling out issues brings support not blame from management thus issues are never hidden.
  • Mistake Proofing The Work – Lean uses Continuous Improvement to identify how to eliminate mistakes in the process to begin with. Agile uses Pairing and Test First or Test Driven Development. By pushing defects to the left (i.e., find them earlier or eliminate them altogether) waste is eliminated and high quality emerges.
  • Root Cause Analysis – Lean uses techniques such as the “Five Whys” and Fishbone Diagrams to identify the root cause of issues. Only when root cause is identified and the cause remedied does the system improve. Agile teams are encouraged to do the same via retrospectives.
By now, it should be clear that unless a leader understand why lean and agile work, they are likely to cause harm. For most, it requires a fundamental change in the way they manage and incent their organizations.


Ask yourself, do you manage by using Management by Objective. If so, what evidence do you have that the targets you put in place can be achieved by your current system? Instead, provide clear high level goals and monitor the trends for your organization. Is your organization trending in the right direction?
What do you use to measure the effectiveness of your business? Do you use Key Performance Indicators? They are point in time. What do they mean? Compared to what? Instead use trends. It is the direction of the trends and not a point in time snap shot that provides you the better insight.
How do you respond when an issue is brought to you? Do you look for someone to blame? Do you micromanage by adding weight to a bloated process? Instead determine root cause not blame. Once root cause has been identified and fixed, monitor trends for impact.
These are but a few examples of why it is essential for a leader to transform first before attempting to transform an organization. One of your biggest challenges will be to gain trust of your organization. Don’t expect the organization to become open quickly. After all, for years they have been trained to game the system. They have been given targets that were often arbitrary and tied to their compensation. This is an open invitation to “fudge the numbers”. You gain neither insight nor provide motivation.
They will watch your response. When issues arise will you blame or will you address the root cause. Will you support the organization by removing blockers or will you use the carrot and stick?
As you can see, you have many old habits to change. The first step to transforming your organization is to transform yourself. The change is well worth it. The impact will be larger and longer lasting than you could have imagined.

Tuesday, March 27, 2012

Skin in the Game

You have seen it before. After months of defining and redefining the requirements, the business signs off. Development and testing occurs. The software is delivered and the response is often, “That is not what I asked for!” Each side “lawyers-up” and the battle rages on.

This is not a rare occurrence. Anyone who has done development has at least one similar story to share. Why does this happen?
This is frequently the results of “contract development”. Developers are tired of being blamed. They demand detailed requirements. They demand from the business all the details before beginning the development. By having all the requirements defined, signed off and locked down, they reason, they can deliver what was asked for and not end up in hot water.
The problem is developers have painted the business into a corner. While the business may know in a broad sense what they want, they are not sure of what is possible let alone all the details. The business is fearful of signing the requirements document. Given the hoops that one much jump through to make a change, is it any wonder they have nightmares of what they might have missed. Consequently, the requirements become a catch all of everything under the sun. The gathering takes longer than necessary. Even after much time the requirements are vague, confusing and cumbersome. It is only when the project manager says the project is behind schedule and over budget that the requirements are signed.
This is all about avoiding blame instead of delivering value. Not a good place to be. What are the chances of delivering business value with such a start?
Many of the agile practices are put in place to prevent the failure brought about by “contract development”. It is collaboration and tight feedback loops that enable the developers and business to quickly and iteratively discover what is needed.
What is needed is for the business to have “skin in the game”. The business has to be as responsible for deliver as the developers. How do you accomplish business accountability? This is primarily possible via the role of the product owner. The product owner owns
  • determining what is in the product backlog
  • setting priorities for the items in the backlog
  • changing the items in the backlog or adjusting the priorities each iteration
  • determining when an item in the backlog is done
Talk about “skin in the game”. The business, via the product owner, plays a critical role in the success of the team. They are continually involved in making key decisions and trade-offs. The product owner is aware the budget is fixed and the need to deliver ASAP. After all, the ultimate business need is that “it takes no time and cost no money”.
The product owner helps the team to focus on delivering as many backlog items as possible for the dollars and time budgeted. The product owner soon comes to realize when he or she makes changes it often comes at the expense of completing other items on the backlog.  Thus, the product owner weighs changes carefully and deliberately, yet the business makes changes when justified by business value.
The wall that existed between development and the business soon disappears. It is no longer two groups with arched backs and defensive postures. Instead, the two organizations are working in close tandem attempting to complete as much as possible under the current constraints. Little time is wasted arguing about requirements or what is a defect. Everyone is focused on the solution and maximizing what can be delivered. It is soon recognized by everyone that during development, issues are uncovered and trade-offs must be made. Given the team wants the best solution possible, there is little time spent covering ones backside or arguing about the original spec., project schedules or budget. Everyone is focused on what is the best solution. Talk about eliminating waste.
All on the team are accountable for the time and dollars spent and the value delivered. It is the team taking accountability and credit for the results. It is the recognition by the developers that not all requirements are knowable to begin with. It is the recognition by the business that they will change their minds and priorities as they see the solution unfold and that the scope needs to be adjusted with the new reality. It is only when both sides recognize that everyone on the team is accountable that the two sides become a single team and high performing.
By the way, a funny thing happens to the project manager. When the project manager sees the business involved with the team and proud of what the team has accomplished, the project managers become less ridged about the plan and begins to understand the difference between being “plan driven” and “value driven”. They watch as everyone becomes more focused and excited about the solution and less concerned about a plan that was built when the least was known about what was possible.
It is all about shared focus and accountability, about breaking down the walls built by self-preservation. The product owner is the catalyst that brings the business and the developers together. The product owner responsibilities ensure the business has as much “skin in the game” as the development organization. The product owner brings two sides to the same side. Contracts disappear and value emerges.
Bottom line is to never skip on the product owner. Do with one less pair of developers or tester or business analyst. However, never ever go without a product owner. Without a product owner, the business has no “skin in the game”.