Tuesday, July 22, 2014

Agile Means Get Rid of Test Teams!

Microsoft got agile years ago in tools development. You can read about that in Agile Software Development with Visual Studio where they describe how 3000 developers cut their bugs from 30,000 down to 3,000. They now deliver a new release of all development tools every three week sprint and bugs are down 90% because they got rid of test teams. Testing becomes part of the development process. It is not something you do at the end with a separate team. Both Ken Schwaber and I were consultants on that project.

The next problem is Windows. At Agile 2013 last summer, Microsoft reported on a companywide initiative to get agile. 85% of every development dollar was spent on fixing bugs in the nonagile groups of over 20,000 developers. To fix that requires a major reorganization at Microsoft. And the Wall Street Journal is reporting on how it is going down.

Microsoft Plots ‘Agile’ Development Course as Talk on Job Cuts Loom

Microsoft Corp. CEO Satya Nadella is preaching a more nimble approach to building software as part of the company’s transformation to “reinvent productivity” in a “mobile-first and cloud-first world.” The effort, known as agile software development, is designed to lower costs and hone operations as the company focuses on building cloud and mobile software, say analysts. Microsoft’s new approach may also make redundant certain app development positions, a result that could prove beneficial should reports on upcoming job cuts, which could top 5,800 positions and be the largest in the software giant’s history, prove to be true.
Jin Lee/Bloomberg
Satya Nadella, chief executive officer of Microsoft Corp.
Following a July 10 memo in which he promised to “develop leaner business processes,” Mr. Nadella told Bloomberg Thursday that it makes more sense to have developers test and fix bugs instead of a separate team of testers to build cloud software. Such an approach, a departure from the company’s traditional practice of dividing engineering teams comprised of program managers, developers and testers, would make Microsoft more efficient, enabling it to cut costs while building software faster, experts say. Read more ...

Wednesday, June 25, 2014

Key Books on Innovation - Updating My Library

Before starting Scrum in 1993, I was involved in multiple technology companies, as well as a non-profit in California led by successful founders of start-ups. We studied carefully several editions of Everett Rogers, "Diffusion of Innovations," and  I just downloaded the fifth edition on my Kindle to read again. I was a fan of Joseph Schumpeter's, "Capitalism, Socialism, and Democracy," and even wrote a paper competing for the Schumpeter Prize during my time working with artificial intelligence in MIT Technology Square, the home of the original "Hackers." When I proposed the paper for publication in the Harvard Business Review at a Beacon Hill cocktail party, the editor of this illustrious journal was so offended he refused to talk with me. But those were the days before the internet and even HBR changed after publication of Clayton Christensen's, "The Innovator's Dilemma."

Recently, I watched a fascinating interview with Marc Andreesen at Stanford Business School where he mentioned a book he felt was equally important with Christensen's work. Carlota Perez's "Technological Revolutions and Financial Capital" is basic reading for any technology investor and updates Schumpeter's ideas to the internet era. The book holds that the sequence technological revolution-financial bubble-collapse-golden age-political unrest recurs about every half century. 

We are in the golden age of the information technology era with political unrest starting to bubble up. And in my latest book "Scrum: The Art of Doing Twice the Work in Half the Time" we describe how Scrum was used by National Public Radio for their award winning work on the Egyptian Revolution. One of my colleagues sent me a note last week suggesting that some of the Arabs he trained in Scrum might have used it to engineer the Arab Spring. But I digress ... My work on the Schumpeter paper illustrates how innovations take about 20 years to mature, whether it is eyeglasses in the 11th century or TV in the 20th century. So we knew it would take about 20 years for Scrum to revolutionize our way of working. We thought it was for software but now, everything is becoming software. See the Wall Street Journal interview with Marc Andreesen where he describes how "software is eating the world!" (subscription required)

We are even going mainstream in HBO's hilarious new TV series, "Silicon Valley," where the Googles of the world are competing with little start-ups (and losing) each using Scrum as a competitive weapon. It will be interesting to ride the wave as this 50 year technology cycle unfolds. 

Sunday, June 22, 2014

Recording the Audio Version of the New Book

The last page of Scrum: The Art of Doing Twice the Work in Half the Time read for the audio version. It took three days of reading to get here:

Scrum: The Art of Doing Twice the Work in Half the Time Cover

Pre order now! Available 9/30 from Crown Business.

Tuesday, June 17, 2014

How Management Can Help Team Performance

Team autonomy is an essential characteristic of cross-functional teams engaged in concurrent engineering. At the same time it is a characteristic that North American firms have considerable difficulty in successfully implementing. Delegating a good deal of decision making to teams is often counteracted by processes that during a new product program withdraw some of a team's autonomy or discretion. Data from 53 cross-functional product development teams in 14 firms indicated that withdrawing autonomy is negatively correlated with both task and process aspects of team performance. The determinants of withdrawing discretion include lack of a shared understanding of the development process, environmental change, and lack of managerial “buy-in” to team autonomy. Consequently, successful implementation of team autonomy, through mitigating withdrawal of discretion, requires a clear well-communicated model of the development process, a freezing of design revisions, and policies that encourage managers to support the team rather than interfere in its decision making.

Monday, April 21, 2014

Latest News on DOD Goes Agile

Since I briefed the Coordinating Task Force at the Pentagon on how to report back to the Congress on progess, we've talked a lot about how the US Department of Defense (DoD) is going Agile. We've also shared some ideas on how to do it from SEI. Here is some real concrete guidance about how to do it from the DoD.

We've also been corresponding with four-star General Barry McCaffrey, my former classmate at West Point. He was very clear in his comments on our new book, Scrum: The Art of Doing Twice the Work in Half the Time.

“Scrum is mandatory reading for any leader, whether they’re leading troops on the battlefield or in the marketplace. The challenges of today’s world don’t permit the luxury of slow, inefficient work. Success requires tremendous speed, enormous productivity, and an unwavering commitment to achieving results. In other words success requires Scrum.”

In the process of writing our online course Agile Defense we read with great interest the Interim DoD Instruction 5000.02. This document shows at least one way the DoD is thinking about doing, Agile development in software. 

Here are their two models of software acquisition. The first reflects a certain amount of waterfall thinking:

"Figure 4 is a model of a program that is dominated by the need to develop a complex, usually defense unique, software program that will not be deployed until several software builds have been completed. The central feature of this model is the planned software builds – a series of testable, integrated subsets of the overall capability – which together with clearly defined decision criteria, ensure adequate progress is being made before fully committing to subsequent builds."

Here's a new, more Agile model of deployment:

"This model is distinguished from the previous model by the rapid delivery of capability through several limited fieldings in lieu of single Milestones B and C and a single full deployment. Each limited fielding results from a specific build, and provides the user with mature and tested sub-elements of the overall capability. Several builds and fieldings will typically be necessary to satisfy approved requirements for an increment of capability. The identification and development of technical solutions necessary for follow-on capabilities have some degree of concurrency, allowing subsequent increments to be initiated and executed more rapidly."

The new model moves the DOD closer to the second value in the Agile Manifesto - working product over comprehensive documentation. They may not meet the Agile Manifesto principle of delivering product increments in a few weeks to a few months. Yet it is a definite step forward.

At the Pentagon I emphasized that DOD purchasing should require "Change for Free" in all their contracts as it could save them hundreds of billions of dollar a year. The F-35 contract alone is $143B dollars over budget mainly due to software testing!

Sign up for our online course next Wednesday from 11-12 for more on how Scrum, Agile, and the military work together.

Thursday, April 17, 2014

Leadership Dashboards: Post 2

This is the second post in a series about creating effective leadership dashboards.  You can catch the first post in the series on the goals of an effective agile dashboard here.

This post focuses on how to organize the creation of a great dashboard.  How the dashboard is created is often overlooked in favor of diving directly into what metrics to include, and the look and feel of a complete dashboard; but being deliberate in the process can dramatically improve the finished product and prevent the alarmingly frequent incidents of total failure.  For example, a client I am currently supporting in dashboard creation had previously worked with a large accounting firm to create an executive dashboard for their development group…six months and hundreds of thousands of dollars later, the project was cancelled without the leaders ever having seen a single working metric!

There are three main pillars for how to create a successful leadership dashboard:
  •      Use Scrum to develop the dashboard
  •      Develop a prioritized backlog of metrics and deliver incrementally
  •      Leverage an “interactive” interface and drill down hierarchy

Use Scrum
It should come as no surprise that I recommend using a Scrum team to develop and deploy the leadership dashboard. (After all, we use it for everything here at Scrum Inc.)  But interestingly enough, when most companies embark on developing a dashboard, they tend to treat it like an internal side project and not give it the full focus, attention and agile discipline that they apply to their customer-facing work.  With unclear roles and objectives, and competing with a dozen other projects for employee attention these informal efforts often go nowhere. 

If you are serious about developing a useful dashboard, designate a dedicated and cross-functional team to build it.  Maintain the discipline of working off a backlog of metrics to deploy and identify a product owner to incorporate user feedback. Leverage the structure provided by a regular sprint cadence with demo and retrospective meetings.  It may feel like a lot of overhead, but you will be glad you made the investment when enjoying your completed dashboard.

Deliver Incrementally
What caused the failed dashboard effort mentioned above, and countless others before it, was the attempt to deliver a working dashboard in a single “big bang.”  The hallmarks of this approach are to “mock up” the look and feel of all of the metrics in a dashboard, get buy in from leadership on that design, then build the dashboard.  Unfortunately, this waterfall approach is no more effective for dashboard creation than it is for software development, and for exactly the same reasons: 1) leadership doesn’t really know what they need to see to make effective decisions until they see it, leading to a “moving target” that can consume years of back and forth mock-up revision; 2) too often, teams agree on a mock-up only to discover that it is impossible to pull the data required to make it a reality; and 3) company data and systems are complex and interdependent…small changes to one element of the dashboard have ripple effects throughout the tool, making after the fact changes a nightmare.

Fortunately, dashboards lend themselves extremely well to iterative and incremental delivery. Each combination of metric and business unit within the company is a useful feature that can be delivered and refined independent of the other metrics.  Integration, summary views and second-order metrics can then be layered on.  A savvy product owner in dialogue with the dashboard’s end users can easily prioritize which metrics and which business units are of greatest concern and prioritize the backlog of metrics appropriately to deliver the greatest value as early as possible.  Ensuring that there is an easy way for users to provide feedback within the first iteration of the dashboard makes this process even more straightforward.

The biggest challenge here is to set appropriate expectations with leaders in advance about what incremental development looks like and get a commitment to providing feedback.  They might be resistant at first to a partially completed product or the effort of feedback, but it is imperative that they provide actionable guidance to produce an effective dashboard.  “It isn’t good enough yet” is a common response, but not sufficiently engaged and actionable to help the team. 

In the past, I have positioned the value proposition for incremental delivery as, “The initial version will be rough, and I can almost guarantee that you won’t like it; however: you will have something in your hands within x days, it will be REAL data that will improve your visibility over what you have now, and we will implement any actionable feedback you have over the subsequent iterations to make the dashboard exactly what you want it to be.”  This usually works, though it is worth getting agreement in writing for the inevitable retrenchment later.

Leverage an Interactive Tool
The default expectation in the business world is that a dashboard is a single page or PowerPoint file that contains summary metrics and can be transported around for easy reference.  While this is fine in practice, the advent of cloud computing and ubiquity of mobile devices have opened up significant new possibilities for interactive metrics reporting.  Here again, a little up front expectation setting is essential to leveraging this potential.

A single flat dashboard can only show top-level metrics and tends to get very cluttered as more information is added.  By contrast, an interactive data visualization tool like Tableau or Domo can have a clean and simple top-level design, but allow the decision-maker to click-down into disaggregated views as needed (stay tuned for more detail on tools in a future post).  It provides more data, but gives the user control over how much detail to show.  The data can be updated at different cadences or even in real time, rather than a single monthly update to a PowerPoint slide. Finally, with dashboards fed to mobile apps, the information is even more readily available than the printed dashboard page.

That said, remember that the dashboard’s ultimate purpose is to help leaders make decisions, so particularly in the early iterations it may be helpful to build a dashboard that looks familiar and comfortable to leadership.  Having built credibility in the process and team, you can then flex your interactive muscles and deliver value-adding capabilities.

In the next post, we will cover what information leaders typically want updates on a regular basis, and how to achieve those objective with compelling agile metrics. If you want a sneak peek at some of these metrics, they are covered in our online course on The Scrum Leader’s Dashboard.

AlexBrown is Scrum Inc’s Chief Product Owner and Chief Operating Officer.  He set up the company’s internal metrics dashboard to automatically consolidate and share agile metrics and support better decision-making.  He also trains senior leaders and consults to companies on how to succeed strategically in an agile business environment.

Thursday, April 10, 2014

Yet Another $163B Waterfall Disaster

The F-35 Is Worse Than HealthCare.gov

The $400 billion jet project is the most expensive weapon the Pentagon has ever purchased. It's also seven years behind schedule and $163 billion over budget ...

And here’s the kicker: According to a 41-page Government Accountability Office (GAO) report released yesterday, the F-35, which has yet to fly a single official mission, will stay grounded for at least another 13 months because of “problems completing software testing.”

What GAO Found 
Delays in developmental flight testing of the F-35’s critical software may hinder delivery of the warfighting capabilities the military services expect. F-35 developmental flight testing comprises two key areas: mission systems and flight sciences. Mission systems testing verifies that the software-intensive systems that provide critical warfighting capabilities function properly and meet requirements, while flight sciences testing verifies the aircraft’s basic flying capabilities. Challenges in development and testing of mission systems software continued through 2013, due largely to delays in software delivery, limited capability in the software when delivered, and the need to fix problems and retest multiple software versions. The Director of Operational Test and Evaluation (DOT&E) predicts delivery of warfighting capabilities could be delayed by as much as 13 months.

Tuesday, April 08, 2014

Happiness Metric - The Wave of the Future

The Happiness Online Course archive is available.
Nöjd Crispare Historik

... any investor should be able to measure its return, and now a group of U.K. researchers say they've provided the first scientifically-controlled evidence of the link between human happiness and productivity: Happier people are about 12% more productive, the study found.

The results, to be published in the Journal of Labor Economics, are based on four different experiments that employed a variety of tactics on a total of 713 subjects at an elite British university. See article ...
ScrumInc used the happiness metric to help increase velocity over 500% in 2011. Net revenue doubled. The way to do this is now part of a formal pattern at ScrumPlop.org called "Scrumming the Scrum." Traveling around the world, the happiness metric keeps bubbling up as a topic of interest. 

Books are starting to hit the charts at Amazon by business leaders (Zappos CEO, Joie de Vivre CEO) and psychologists. Managers and consultants are telling me that people are getting fed up with being unhappy at work. Younger people in particular are refusing to work in command and control environments based on punishment and blame. Major change is emerging (see The Leaders Guide to Radical Management by Stephen Denning). The Harvard Business Review devoted a recent issue to Happiness because happy employees lead to happy customers and better business. However, never underestimate the human capacity for screwing things up. See HBR blog on "Happiness is Overrated." You might need to "Pop the Happy Bubble," a pattern designed to straighten things out when your team is oblivious to impediments.

The Scrum Papers documents some of the early influences on Scrum and Nobel Laureate Professor Yunus at the Grameen Bank in Bangledesh provided key insights on how to bootstrap teams into a better life. Practical work on these issues on the President's Council at Accion helped me put these insights into practice just prior to the creation of Scrum in 1993. I saw how to bootstrap developers out of an environment where they were always late and under pressure into a team experience that could change their life.

One of the most innovative companies in the world of Scrum is a consultancy in Stockholm called Crisp. Henrik Kniberg is the founder and we have worked together on Scrum and Lean for many years. He recently introduced the "happiness index" as the primary metric to drive his company and found it works better than any other metric as a forward indicator of revenue.

Henrik outlines on his blog how he used the A3 process to set the direction for his company and how that led to measuring company performance by the "Happy Crisper Index."

Now a days one our primary metric is "Nöjd Crispare Index" (in english: "Happy Crisper Index" or "Crisp happiness index"). Scale is 1-5. We measure this continuously through a live Google Spreadsheet. People update it approximately once per month.

Nöjd Crispare Index

 Here are the columns:

  • Name
  • How happy are you with Crisp? (scale 1-5)
  • Last update of this row (timestamp)
  • What feels best right now?
  • What feels worst right now?
  • What would increase your happiness index?
  • Other comments
We chart the history and how it correlates to specific events and bring this data to our conference.

Nöjd Crispare HistorikWhenever the average changes significantly we talk about why, and what we can do to make everybody happier. If we see a 1 or 2 on any row, that acts as an effective call for help. People go out of their way to find out how they can help that person, which often results in some kind of process improvement in the company. This happened last week, one person dropped to a 1 due to confusion and frustration with our internal invoicing routines. Within a week we did a workshop and figured out a better process. The company improved and the Crisp Happiness Index increased.

Crisp Happiness Index is more important than any financial metric, not only because it visualizes the aspect that matters most to us, but also because it is a leading indicator, which makes us agile. Most financial metrics are trailing indicators, making it hard to react to change in time.


As Dan Pink points out in his RSA talk, people are motivated by autonomy, purpose, and mastery. Takeuchi and Nonaka observed in the paper that launched Scrum that great teams exhibit autonomy, transcendence, and cross-fertilization. The "happiness metric" along with some A3 thinking helped flush out these issues at Crisp and it can work for your company.

At the core of the creation of Scrum was a daily meditation based on 30 years of practice beginning as a fighter pilot during the Vietnamese war. It is a good practice for a warrior and for Scrum as changing the way of working in companies all over the world is a mighty struggle. May all your projects be early, may all your customers be happy, and may all your teams be free of impediments!

"May all beings be well, may all beings be happy, may all beings be free from suffering."
- Compassion Meditation for a Time of War

Six Signs your Team’s Acceleration is Too Good to be True

Let me say right from the beginning that I am a huge fan of tracking velocity in Scrum…it is an amazingly powerful concept. 
  • The ability to measure team output from sprint to sprint allows a team to systematically experiment with different process improvements and consistently get better over time. 
  • A clear sense of how much output the team actually produces within a sprint also drives better decision-making about when to expect project completion without slave-driving the team developing it. 
  • As an agile leader, I like to know whether my teams are accelerating, decelerating or staying stable over time. If they are accelerating, it gives me confidence that our projected completion dates are relatively safe; whereas if they are stable or decelerating, it implies greater risk in current projections. 
But metrics are only as good as the integrity of the data that feed them. The traits that makes estimating velocity in points so powerful (speed, ease for the teams, intuitive accuracy of estimation) also mean that, in the wrong conditions, velocity can be manipulated to produce misleading conclusions.  To be clear, this is not the terrible scourge that proponents of measuring in hours often claim it is…a few simple guidelines such as “NEVER tie incentives to velocity” and “don’t use declining velocity as a reason to beat up your teams” generally suffice to eliminate any deliberate gaming of the system. 

However, seeing velocity increase over time just feels good and teams often thrive on the sense of accomplishment that comes from getting more done in less time.  Even without overt pressure to increase velocity, the collective will to go faster can create upward velocity drift that isn’t necessarily driven by increases in underlying output.  Since only the team suffering from velocity drift is impacted, this need not be a major problem. But for Scrum Masters, Product Owners and teams concerned with maintaining the integrity of their velocity metric, I humbly offer…

The 6 signs that your beautiful velocity growth trajectory may just be bad data:
  1. Velocity always increases – Even the highest-performing Scrum teams suffer setbacks or encounter new impediments.  In general, scrum teams that set challenging goals should expect to fail about 20% of their sprints, meaning that velocity should decline from the previous sprint about the same percent of time (if you are using “yesterday’s weather” to pull stories into the sprint). If your team has been through a dozen sprints without a single backslide in velocity, it suggests that stately upward trend is being managed more deliberately than it should.
  2. Inexplicable Acceleration – Velocity can go up in short bursts for no particular reason, but it is difficult to sustain structural velocity improvement without systematically removing team impediments.  So if a team’s velocity has been increasing consistently but they can’t point to specific impediments that they have removed, that is a red flag that the acceleration may not be real.  At best, the team is not conducting healthy process experiments to deliver repeatable and sustainable acceleration.  At worst, they may be undermining the meaningfulness of their velocity.
  3. The same story now receives a higher point estimation than it used to – This is the definition of “point inflation” that opponents of measuring velocity in points are always pointing to.  In practice, we rarely see egregious cases of point inflation where the exact same story that was 3 points in a previous sprint is now 5 points in the current one.  Instead, we typically encounter more nuanced forms of inflation, such as when an additional quality check is added to correct for past issues and points are added to complete this additional work.  The amount of effort needed to complete the work may have increased, but the amount of output has not, so these added points represent a subtle form of point inflation.
  4. Backlog stuffing with “filler stories” – Teams that are striving to increase velocity often become obsessed with ensuring that everything they do is reflected in the backlog.  In general, you don’t want to do tons of off-backlog work and do want to stay focused on completing the goals of the sprint. However, some level of housekeeping and team hygiene work is a natural part of the group process.  If including these items in the backlog was always a team norm…that is fine. If that wasn’t always the norm, then including these filler stories with associated points gives the false impression that the team is accelerating when it is not actually producing more output.
  5. Lots of separate minimum-sized stories – We often say that smaller user stories are better, and that ultimately teams should strive to work with uniformly small stories in the sprint.  This is a great goal, but it can be taken too far.  If work is broken into many stories that are smaller than the smallest sizing increment used by the team (“xs”, “1-point”, “Chihuahua”, etc.) then the rounding error of adding all these fractional stories together starts to exert a strong upward influence on velocity.  If these precisely divided stories are still good user stories reflecting incremental functionality, then it is time to reset your reference story to accommodate smaller divisions.  More often than not, however, these tiny stories are really tasks and are hurting the team’s ability to work together to produce quality product.
  6. Excessive “normalization” of velocity – Tracking team strength in each sprint is helpful for knowing the context the team is operating within. There are a number of compelling reasons to apply a lightweight level of normalization to a team’s raw velocity number to get a better predictor of actual team output: it provides a more stable measure of output in the face of major illness, vacations, family leave and other significant shifts in team capacity.  However, it also introduces one more lever that can artificially increase apparent velocity, so teams need to be careful to only reserve normalization adjustments for major capacity impacts, and not try to adjust for every perceived shift in team strength.  If you notice that the team has not been at full capacity for a long time, it is time to questioning if over-normalization may be occurring.
I    Feel free to share your own experiences with velocity in the comments section below, or check out other musings on the value of good metrics in Scrum, including a thread on leadership dashboards here.


Alex Brown is Scrum Inc’s Chief Product Owner and Chief Operating Officer.  He set up the company’s internal metrics dashboard to automatically consolidate & share agile metrics and support better decision-making.  He also trains senior leaders and consults to companies on how to succeed strategically in an agile business environment.