A good discussion by Steven J. Spear on how experimentation is useful when dealing with complex systems like markets and Mustangs. Spear explains how this technique led Toyota to the creation of Lexus.
Most often attributed to Taylor, this adage "You can't manage what you can't measure" is a product of the industrial revolution and the efficiency movement. The theme being we need to measure everything so we can maximize efficiency. While there is some truth to the statement with machines, the intent as it relates to people is flawed. People are not machines. A more modern set of ideas has been presented by W. Edwards Deming who stated "The most important things cannot be measured." Deming arms us with the continuous improvement tool and forces us to recognize that people are messy and complex. Deming also introduces us to System Thinking where localized measurement and efficiency maximization can have disastrous results. Deming used 14 key principles to help organizations embrace these ideas.
- "Create constancy of purpose towards improvement". Replace short-term reaction with long-term planning.
- "Adopt the new philosophy". The implication is that management should actually adopt his philosophy, rather than merely expect the workforce to do so.
- "Cease dependence on inspection". If variation is reduced, there is no need to inspect manufactured items for defects, because there won't be any.
- "Move towards a single supplier for any one item." Multiple suppliers mean variation between feedstocks.
- "Improve constantly and forever". Constantly strive to reduce variation.
- "Institute training on the job". If people are inadequately trained, they will not all work the same way, and this will introduce variation.
- "Institute leadership". Deming makes a distinction between leadership and mere supervision. The latter is quota- and target-based.
- "Drive out fear". Deming sees management by fear as counter- productive in the long term, because it prevents workers from acting in the organization's best interests.
- "Break down barriers between departments". Another idea central to TQM is the concept of the 'internal customer', that each department serves not the management, but the other departments that use its outputs.
- "Eliminate slogans". Another central TQM idea is that it's not people who make most mistakes - it's the process they are working within. Harassing the workforce without improving the processes they use is counter-productive.
- "Eliminate management by objectives". Deming saw production targets as encouraging the delivery of poor-quality goods.
- "Remove barriers to pride of workmanship". Many of the other problems outlined reduce worker satisfaction.
- "Institute education and self-improvement".
- "The transformation is everyone's job".
These points are discussed in his “Out of the Crisis” book (link below). He also discusses and organizations "Seven Deadly Diseases.”
- Lack of constancy of purpose
- Emphasis on short-term profits
- Evaluation by performance, merit rating, or annual review of performance
- Mobility of management
- Running a company on visible figures alone
- Excessive medical costs
- Excessive costs of warranty, fueled by lawyers who work for contingency fees
Most of Deming’s ideas represent a body of knowledge that is central to organizational agility. If you are in the process of trying to adopt Agile or just seeking to improve your company, read through some of Deming’s works. I think you’ll be surprised to find that many of our “modern” ideas aren’t so modern after all.
The W. Edwards Deming Institute
Book: Out of the Crisis
Deming's 1950 Lecture to Japanese Management
There seems to be a ton of willingness today for companies to modify their legal relationship with their clients. Maybe we are finally at a point where we realize that holding people’s feet to the fire doesn’t produce the kind of results we had hoped for. What I’m talking about here is commonly referred to as “Agile Contracts.” A legal arrangement with your client to deliver a product in iterative, incremental way. For starters, Agile contracts should have some basic components.
- Make clear that both parties are “co-invested” in the success of the project.
- While you will require a basic list of requirements to start, the contract should make clear that this list is subject to change after every Sprint. This will benefit both parties.
- Client is billed for the working software delivered as part of every Sprint. Some people have suggested using a pay-per-story model. I have found this to be problematic. Paying a fixed price for each Sprint seems to provide the most robust “tit for tat” relationship.
- The client may take delivery of the software (or not) and cancel the project at any time. (you may choose to use a pro-rating clause if necessary)
- Increased or decreased throughput (not velocity) will require an adjustment to the per Sprint compensation.
- Require client participation every 1-4 weeks as part of the Sprint Review. This is where the client will “inspect” the working software and help you think through what to do in the next Sprint.
You will have to work with your legal team to determine how you should phrase your acceptance, termination and warranty clauses as they require quite a bit of finesse due to the nature of shared risk.
Craig Larman has an excellent Agile Contracts primer here: http://agilecontracts.org/agile_contracts_primer.pdf
Some of Jeff Sutherland’s ideas here: http://scrum.jeffsutherland.com/2008/10/agile-contracts-money-for-nothing-and.html
There are other discussions on this that have happened at various conferences, talks and in chat rooms. However, I think the above is enough to get you started.
I thought I would give a shout out to Richard Hundhausen in anticipation of his new book. I’ve been helping to review the book as he is writing it and this is going to be a phenomenal piece of work! It will likely release in October and will surely be a staple for many of my coaching engagements. Pre-order yours today!
I just finished reading Deborah Mills-Scofield’s HBR article on bringing back corporate accountability. This is a great article in its own right. It lead me to an article she posted in April of this year on building Communities of Practice by Building Virtues into the Organization’s DNA. Her moonshots to fix problems we see in corporate culture in this article are:
- Focus the work of management on a higher purpose
- Rebuild management's philosophical foundations
- Enable communities of passion
What Mills-Scofield is describing here is that many of the problems we see today are not tactical or process in nature, but rather reflect of loss (at least in practice) of key social virtues. She focuses on Aristotle’s virtues of Courage, Faith, Hope, Justice, Love, Prudence and Temperance. This is a great article for all of us but especially those teams that are struggling with a toxic culture.
This is very cool! Flow of work across the team board with computer generated Burndown and column sums.
To quote the Scrum Guide, part of the Scrum Master’s role is to “ensuring Scrum is understood and enacted.” This is often interpreted as “enforcing” Scrum. I have found the use of "enforcement" to be challenging. I have seen it create adversarial environments. You will he Development Team members talk like this: (snotty tone) "The Scrum Master said we can't do that! (laugh)!” This is certainly not health behavior. But what should be done about it? Instead of enforcing Scrum, the Scrum Master should coach the team to follow the rules of Scrum. If the team wants to make a change to Scrum, use powerful questioning and dialog to discuss. If the team still wants to make changes even after the discussion, the Scrum Master may want to allow it as a learning experience. The Scrum Master will want to visibly track this as a team dysfunction (team whiteboard, wiki, sign in the team area, etc.). Then, during the next retrospective have the SM talk about the issues that arose by modifying Scrum. What does the team want to do to address these issues? Can we try bringing the Scrum concepts back in?
Certainly shuhari applies here, but sometimes keeping the team positive and talking is better than enforcing the rules.
I have done source code branching with a ton of teams. The pattern looks pretty much the same independent of what type of branching the team is doing. “We are doing some work that we don’t want other teams to see or get impacted by.” So it goes the team creates a branch to work on a PBI/feature, test some ideas in a Spike or begin the next version of the product. Work sails along swimmingly until the team has to merge the code with mainline (which happens 90% of the time). This is where all hell breaks loose. The team, working in isolation, has created a large amount of code that will no longer integrate with the changes that have happened along the way. At this point code is rewritten (not just refactored), new ideas are brought into the mix, tests are rewritten and so on. For those of you that have been through this, you know what I mean. Are there ways of dealing this this chaos? Sure!
- Work can minimized with regular forward integrations from the mainline.
- Keep the branch duration short.
- Use Design by Contract techniques coupled with unit and integration tests starting on day 1.
I posted at the beginning of last year that you should always branch with caution. Having given this topic a bit more retrospection, I believe branching to be dysfunctional. Here’s why. We know that as a product moves forward the knowledge about it moves forward as well. As two teams (or more) work in isolation, this knowledge diverges at what appears to be an exponential rate (you can even assume linear and get to the same place). When a branch is merged back to the mainline all the knowledge and assumptions are merged as well. This is where we have a problem. The teams need to “catch up” with each other’s knowledge. From observation, the trick here seems to be to keep the teams collaborating on ALL the code ALL the time. That way, knowledge and assumptions are shared and merge conflicts are eliminated. This is the basis of Continuous Integration (CI). The teams should work together on a single mainline with the code being built and tested in near real-time. Keep the builds fast and consider multi-stage CI or Build Pipeline techniques as the number and type of tests grow.
The question at this point is, “How do I keep unfinished work out of my releases?” There are a couple answers/approaches here. The first is to use Feature Toggles. The concept here is pretty simple, as you begin working on a feature include a config switch that allows you to turn that feature off or make it invisible. Other approaches include the use of authorization to include/exclude features in releases and in modular applications (portals) include/exclude the widget. Along with the ability to turn chunks of code on and off, you will want to make sure you have a comprehensive set of tests and the corresponding automation.
As you begin to walk down this path you will see that you are actually on your way to Continuous Delivery (CD). While a full CD approach is not for everyone, it does offer some really great ideas for keeping you product in a “always shippable” state.
UPDATE 8/27/2012: Fellow PST, Ryan Cromwell started a discussion on Scrum.org regarding this post. Check it out!
Here is a video of my ALM Chicago talk:
I spend a fair amount of time these days working with senior business leaders on some of the challenges they face. One of the things that both they and I are seeing is the impact of shorter business cycles on planning. While the use of the word “cycle” implies that these changes occur with some predictability, it is also clear from observation that they do not. In fact, many economist choose to use the term “fluctuation” over “cycle” to denote its chaotic nature. Many factors go into making our economy behave this way, globalization, decreasing consumer attention span, less brand affinity, increasing technology and government intervention to name a few. The real question many leaders face as it relates to these cycles is “How long do I have to get my product or service offering to market?” They want to understand how quickly they can take and idea to market without having the ground shift from underneath them. When I started in the technology space in the early nineties, project lengths of many years were not uncommon. For many companies, releasing a piece of software once a year was a challenge. If you had hardware to go with the software (think game console, cell phones, etc.) you could pretty much kiss the once a year thing goodbye. This was the way it was. Consumers didn’t expect more, competitors probably couldn’t do better and our detailed design specifications were as much work as the product itself. Over the last 20 years, this has all changed. Consumers demand the latest and greatest, our economy is wildly unpredictable, startup competition can build products from start to finish in months and many companies are now releasing software “continually.”
Many leaders are looking at these new conditions and realizing that the ways of the past are no longer suitable. These leaders look at their companies, consumers and competition and make thoughtful choices about where to go and what to do. They are not surprised by changes as this is now the norm. An example of this if Flickr which started as an online gaming company but quickly realized there was more of a demand for their photo sharing feature. This change in direction, also known as a “pivot,” is becoming a key piece of modern business practices. Making a significant change in the direction of an organization requires software development techniques that can readily deal with it. Enter Agile.
Agile development is a general term for many different techniques but the piece that is common to most of them is a focus on delivering done software frequently. In Scrum we do this every Sprint. In XP this is done every Iteration. With Continuous Delivery this is done…well continuously. When leaders have the confidence and understanding that the product they are building is always in a done state, they can “pivot” more readily and cost-effectively. It’s clear from the state of the market that and organization that can most readily respond to change is going to prevail. If you are leading an organization that produces a product, have you asked yourself “How able are we to respond to change?” An honest answer to that question will likely indicate the future success of your organization.