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.