Introduction
This is a tale of two product development teams, each supporting a suite of Human Resource benefit services. Neither product line was profitable. Corporate patience and seed money was coming to an end.
One product line was seen to be a differentiator and provided a service clients wanted and valued. It provided a uniquely better solution than its competitors. The other product line was a commodity service, a “must have” in the full suite of services. But no matter how much money was invested in the product line, it was judged that we could maintain only a “parity” position with its competitors.
The two teams worked side by side within the same division of a large corporate giant. Each team provided all business solution services necessary to address both the strategic and tactical needs of their suite of application services. Work requests came to the teams from several channels, but could be generalized as project work, maintenance and enhancements, and production break/fix. All work requests, however, were projectized (Project Management Leadership Group [PMLG], 2006).
Each team had a project manager who managed all projectized work for their project line. One work team worked one project at a time; the other team, due to its particular circumstances, worked a stream of work requests, with several in process at the same time.
Each team had a really big problem to overcome. The project managers were both project management professional (PMP)® certified, seasoned and had many prior successes. Their personal experiences, however, were different, with one subscribing to the view that project managers are directive and should manage the project with a firm hand. The other viewed himself as a nondomain expert with “border collie” skills capable of keeping his flock safely focused and together. These two project managers exhibited significantly different behaviors and attitudes. One team ended in a tragedy and the other in a triumph.
The “Eagle Team”
The Big Problem
The federal government had mandated a rules change that had a broad-reaching impact for the product suite. This would require significant modification to the product line software and how the client would interact with the product. Failure to meet the government-mandated deadline would result in penalties.
The team was given just 8 weeks to deliver a solution.
Some Critical Facts
The Eagle Team's product line was soaring! It was an industry leader in providing new creative services.
But the product was buggy. The product releases were inconsistent and some functionality didn't work. Additionally, the product line's architect had just recently left the company and the remaining team was viewed by many to lack discipline.
Beliefs and Behaviors
The Eagle Team's project manager had formulated strong beliefs over his career and was firmly committed to a strong matrix organization approach as found in projectized organizations (Project Management Institute [PMI], 2008, p. 30). He believed work was best performed when led by a confident and decisive leader. He felt certain that teams perform their best when someone has high expectations of them and there is a sense of urgency (Parkinson's Law) (Ferriss, 2007, p. 80). His behavior was consistent and predictable. He was decisive, authoritative, task oriented, action oriented. He was passionate, judgmental, and clearly in command and in control. He operated “by the book.”
Actions Taken
The project manager took command and researched the rules change. He worked closely with client representation and a product suite delivery manager to determine the best approach. He created a detailed scope statement, a precise requirements list, a specified solution, a work breakdown structure, and a timeline. And then he called an all-hands kick-off meeting.
At the kick-off meeting, the project manager skillfully laid out the plan and announced that the scope was fixed, all requirements were “must-haves,” the dates were firm, and the approach and deliverables were not negotiable.
The team, however, was an XP/Agile solutions delivery team, who followed the Agile set of values and principles (agilemanifesto, 2001) and used a set of proven techniques that have been documented to greatly improve team focus, deliver rates, and customer satisfaction.
The Agile team asked numerous questions, and quickly created a product backlog (list) of stories that the team judged to equal the scope of the project work. Using simple relative sizing techniques, the team sized all of the stories and used the sum of the sizing to quantify the development effort. The team estimation was 16 weeks, twice as long as the allotted 8 weeks.
The project manager stated that that was unacceptable, and that the scope and deliverables and deadline were firm.
The team accepted the mandate, requested additional resources, and then applied the prescribed project management approach to take all work and chunk it into eight sprints, one for each of the eight allotted weeks. They immediately scrapped all of the existing work in progress and began the work on this project's first batch.
The Impact and Consequence
The team attempted to complete their weekly quota of work assignments. Each week they fell further behind, errors crept into their product and mistakes began to multiply. A key developer was reprimanded for buggy code. He quit. The deadline was missed. The project was judged a failure and the senior vice president requested the all-too-familiar customary project review.
The project review was led by the project manager of the “Ant Team.” He just went through his own big problem, which led him to learn a whole new set of project management tools. Using these new tools helped him uncover very surprising results about the Eagle Team's real issues.
The “Ant Team”
The Big Problem
Having heavily subsidized the Ant Team for the past 6 years, corporate decided that the product line was not profitable and began searching for alternative solutions. The team was informed; their services cost too much, took too long, and received poor grades from the customer. During the upcoming year, a decision was to be made to shelve the product line, outsource the service to India, or partner with a competitor. Two thirds of the team was immediately laid-off, and the remaining team was instructed to focus on maintenance work.
If, however, the team could find a way to “do measurably more with less,” then the corporate planning team would reconsider any decision to shelve, outsource or sell-off the product line..
Some Critical Facts
The Ant Team's product line was viewed as a commodity. Corporate was looking simply to maintain parity with their competitors and so they underfunded the team for 6 years. This led to a massive backlog of bug fixes, small enhancements, and technical debt.
On the other hand, the team had been working together for 8 years. The project manager just finished studying for his Project Management Professional (PMP)® certification under A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Third edition (PMI, 2004), and this edition called for project managers to not only be concerned with project management but also product and process management as stipulated under the Project Quality Management and Communication's Management Knowledge Areas (PMI, 2004).
Beliefs and Behaviors
The Ant Team project manager believed that work was best performed when results were empirically demonstrated and that teams performed their best when empowered to self-manage, self-organize, and adapt (agilemanifesto, 2001). The project manager felt his role was to shepherd work requests through the process. He did not see himself as a domain expert, a process owner, or task master.
Consequently, his behavior was collaborative, process oriented, result oriented, realistic, and reflective. He saw himself as being like a “border collie” and others found him to be pragmatic.
Actions Taken
The Ant Tea, project manager reflected on the circumstance of the team and on the guidance of the PMBOK® Guide—Third edition decided to include in his plans a Process Improvement Plan and to include run charts and control charts to demonstrate the team's progress in improving their productivity and efficiency.
His goal was to demonstrate that the team can improve and show their progress on a frequent basis.
To this end, he engaged the business managers and identified the process owners who provided the details of a plan to lean out and speed up the team using the Lean Six Sigma DMAIC process improvement methodology (George, 2005).
They gathered the Voice of the Customer (VOC), completed a Critical-to-Quality (CTQ) Requirements tree and a Kano Analysis. This led to the creation of a “vital few” set of carefully defined metrics that the team was to collect (Exhibit 1).
Exhibit 1: Lean Agile performance metrics
Critical to improving Customer's Satisfaction were the mapping and then radical improvement of cycle times (Exhibit 2). Goals were to dramatically reduce the CCT and TTM cycle times by attacking waste and realigning the team to focus on activities that created customer valued products and services. He learned to his surprise that cognitive processes, such as product development, are generally less than 5% efficient and that world class cognitive processes should strive for a minimum of 25% process cycle efficiency (PCE) (George, 2003, p. 36).
Exhibit 2: “Ant Team” cycle time metrics.
Using the Agile scrum approach, the team performed work in batches called “sprints” or “iterations.” In each sprint, the team recorded how much product they completed (measured in “story points”) and also recorded what obstacles they were having in getting their value creation work completed. The project manager working with the Lean Six Sigma process owner looked for chronic obstacles and using quality analysis tools, including control charts, Ishikawa fishbone diagrams, and Pareto curves, began to uncover a list of root causes. Next, small teams were formed to devise simple yet quick process improvements (a.k.a. Kaizens) (George, 2005; Quick Improvements p. 5). Quantitative data, hard evidence, was collected and validated. The project manager guided the team based on the trends exhibited in the run charts as to which improvements did indeed affect the team's productivity.
With these actions taken, for the first time, the project manager had compelling evidence as to the team's effectiveness and efficiency. He could confidently respond with reliable data to the demands of the customer and to management, “Do you have a process improvement plan?”, “How effective and efficient is the team?”, “Are they improving or backsliding?”, and “What is the teams' potential?”
The Ant project manager now had proof of the team's ability to “do measurably more with less.” He shifted his way of thinking. He saw himself owning the process, and he learned to quickly recognize what work created value and what work did not. He shifted his management style to make decisions based on quantitative data; he looked to keep the value creation flowing, he could now see the waste, ceremony, and complexity and recommend ways to lean it out. As the process accelerated, he saw bottlenecks occur and stresses build, and he worked to rebalance the workload. As a by-product of his efforts, the whole product suite's quality improved.
The Impact and Consequence
The impact of the project manager's effort was he now had a clear understanding of what his customers' valued (Voice of the Customer, or VOC), what the business and management expected (Voice of the Business, or VOB), and how the process was performing (Voice of the Process, or VOP). He had a verifiable baseline of productivity, customer satisfaction, and team efficiency, and was collecting timely data as to the trends of the team's performance.
As time progressed, in addition to the traditional project measurements, such as, SPI, CPI, earned value, etc., he now could report on product and process measurements. When reporting to customers, management, and oversight groups, he used quantitative data presented in charts. This allowed one to see trends and to discuss pertinent information in an objective rather than subjective manner. It is these new product and process metrics that made all the difference in addressing the project team's really big problems.
Project Close-Out Reviews
The Results
The Ant Team
There were four significant finding from the Ant Team project reviews:
- Agile works
- Agile alone was not enough
- Subtle changes have big impacts
It is not all about Agile
Agile Works
Everyone involved felt the team was more productive and would give witness to being at least twice as productive, but Agile does not provide any hard verifiable proof, no facts, and no data—just opinion.
Agile Alone is Not Enough
Agile does not provide quantitative data. You must apply lean principles and tools to fill this gap. Lean provided the solution to meeting the guideline set down in the PMBOK® Guide Project Quality Management Knowledge Area for a Process Improvement Plan and the use of the seven Quality Analysis tools, as well as the performance measures stipulated in the Communications Management Knowledge Area.
Subtle Changes Have Big Impacts
A Lean premise is that over time, all processes accumulate a significant amount of waste, ceremony, and complexity.
Lean Thinking uncovers the waste, improves the flow of the process, and delivers more product in less time. Cognitive processes are considered world class if they reach 25% efficiency. Some cognitive processes, such as IT Solution Delivery processes can reach 35% to even 50% efficiency. IT Solution Delivery processes typically are found to be untouched when less than 10% efficient.
So consider this: If you happen to be 10% efficient today and you lean out and reach 35% efficiency, then you would have attained a two and a half times improvement. You will be able to create two and half times more product within the same time and be two and a half times faster in delivering your product or service.
The Eagle Team
There were four significant findings from the Eagle Team Review:
- People vs. Process
- BUFD vs. Emerging Design
- Parkinson's Law
- Sustainable vs. Extraordinary Effort
People vs. Process
The Developer that was reprimanded for buggy code and subsequently resigned was actually one of the team's best performers. He was merely trying to save the project. He is what CMMI Level One coins as a hero, someone who will take extraordinary efforts to save a project. Other team members were coming to him and asking for his help to remove defects found in their code. His being a team player and being determined not to let the project fail would quickly check-out the other person's code, apply fixes, and check the code back into the version control library. The project manager did not adhere to the agile principles of team collocation or collaboration (agilemanifesto, 2001), and so he was totally unaware of this admirable effort.
The project manager also did not adopt the Lean principle that metrics are to be precisely defined for a stated purpose and only used for the stated purpose. Therefore he erroneously used bad data to conclude the developer was the cause of the defects.
He did this because he believed he had a people problem—namely, that the team lacked discipline and a strong hand.
So he surreptitiously requested from the quality manager a report that listed defects by developer. The report was easily generated from the defect management tool, which collected that data by going to the version control library and listing out those who were checking in and out the code with defects.
His problem was not a people problem, but rather, as Lean thinkers are aware, a process problem.
BUFD vs. Emerging Design
The Agile team members believed in the concept of emerging design and knew from experience that their collaborative approach often came up with better simpler solutions that could be met within the time constraints. The team did not view the loss of the product architect as a critical risk.
The project manager preferred traditional waterfall approaches where the requirements and design are contractually locked down prior to the build team's involvement. So when faced with a broad-reaching government mandated change, he chose to perform this role himself and locked down the solution prior to the kick-off meeting. During the kick-off meeting and for several weeks thereafter, following the team “adaptively” pointed out simpler better solutions, but since the requirements, design, and deliverables will be stipulated and locked down, they were repeatedly rejected.
Later, after much time was lost, the team's emerging design was selected over the original “Big Up Front Design (BUFD).”
Parkinson's Law
The project manager felt that the team lacked discipline, and therefore to help address this issue, he planned in the use of Parkinson's law. Parkinson's law simply states that you should “shorten schedules and deadlines to force action and prevent procrastination” (Ferriss, p. 2007).
While the team was given only 8 weeks to develop the solution, the actual amount of time needed was 9 months!
The project manager had withheld from the team 2 contingency months at the end of the team process and he chose not to engage the team for 5 months prior to the team kick-off meeting.
If the project manager had been aware of the Lean concepts of Customer Cycle Time and Process Cycle Time and the Agile notion of a collaborative approach, the team would have had far more time than they would have needed.
Sustainable vs. Extraordinary Effort
The findings also indicated that the team in good faith attempted an extraordinary pace, but after three iterations (3 weeks), the team began to falter and make increasingly sloppier mistakes.
This led to a management norm that when the need does arise for a team to work extra hours, the project manager can request them to do so but not for more than two sprints at a time.
Analysis
In his book The Goal, Eli Goldratt says “Tell me how you will measure me and I will tell you how I will behave” (Goldratt, 2004).
The Eagle Team project manager was seasoned and known to be successful. He preferred working with project measurements focused around the triple constraints.
He could confidently tell you the team's cost performance index, schedule performance index, earned value, and estimate to complete. He used quality histograms and pie charts, Gantt charts, resource leveling, and status reports. He had a firm control of risks, issues, and change management. But he could not tell you whether his team was effective or efficient. He in fact had no quantifiable data on the management of the process or the product.
Because his focus was on the triple constraints and delivering to plan, he emphasized delivering to scope, on time, and on budget. His goals were to resist scope creep, drive resources to stay on track, and deliver what was promised. He saw no need to share with the team that they had 2 additional months after their deadline to actually deliver.
The Ant team project manager was also seasoned, but because he was placed into a position to adapt or die, he accepted that the Lean Agile team may have a better way.
Having just finished his PMP® certification studies, he was aware of the additional obligations of product management and process management, as evidenced by the inclusion of the process improvement plan and quality sections.
He measured productivity, and he measured customer satisfaction, and he measured process efficiency. He had in place quantitative data, kept trend (run) charts, and managed by data and by empirical evidence. His team learned that not all work was equal and began to focus greater effort on customer value creation and less effort on business value add and non-value add. He knew his team's velocity, lead time, process efficiency, and potential. His tool set expanded to include fishbone diagrams, Pareto curve histograms, run charts, and control charts. He spoke in terms of trends and not single data points. He discarded progress and status reports in favor of empirical demonstration of work complete. He was able to report with the use of real data that the customer's satisfaction had increased, the team had to-date more than doubled their productivity, and their potential indicated they have room for even more productivity gains.
Key Findings
A Triumph
The Ant Team was not shelved nor sold off nor outsourced, and exists today.
A Tragedy
The Eagle Team had, as it turned out, plenty of time in which to deliver, and the team's talented former team member need not have been unnecessarily reprimanded nor to have resigned.