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.
This is very cool! Flow of work across the team board with computer generated Burndown and column sums.
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.
There are a ton of ways to handle retrospectives. Esther Derby and Diana Larsen discuss a bunch of them in their book “Agile Retrospectives” published in 2006. While many of the techniques that the authors mention in the book are good for creating dialog (Force Field Analysis, Five Whys, Circle of Questions, etc.), they can often produce a hefty set of action items. I have seen teams walk away with 70 action items that they wanted to work on in coming Sprints. Inevitably, teams with this many items to work on feel like they are trying to eat and elephant all at once. In these cases, and with new teams that I coach, I suggest borrowing an idea from the Theory of Constraints (ToC) and limit your Work in Progress (WIP). To make this simple, I suggest limiting the number of action items you take away from your retrospective to one. While it may seem like a small amount of things to work on, it gets teams in the habit of improving at least one thing every Sprint. Many teams find that fixing the highest priority items will often make lower priority items moot. If you are struggling with creating a culture of continuous improvement, try a KISS retrospective and pick only one thing to work on in the next Sprint.
I will be presenting my “Agile Economics” deck at ALM Chicago on February 23rd. Here is a summary of the talk:
The software development industry in embracing Agile in a big way. But why? Most certainly it allows a higher rate of success, encourages better collaboration, use of tools and does a better job embracing change. But why do the techniques work from a economics and finance standpoint? A number of people have tried to provide an answer to this question, but they often come in the form of complex equations and long discussions of finance models. In this presentation, Chad Albrecht will provide some very easy to understand economic models that provide a basis for why Agile outperforms traditional techniques. Additionally, Chad will demonstrate a side-by-side cost model of an Agile vs. Traditional project. If you are considering Agile in your organization and have partial or full P&L responsibility, this presentation will provide you with many valuable tools.
UPDATE 4/15/12: Here is a link to a video of the presentation.
I’ve been using and experimenting with Scrum, XP and other Agile ideas since the late 90’s. One pattern I’ve seen at least a few times is the idea of the “weak team.” This happens when a manager takes a larger group of people (20-30), throws a problem at them and says, “Self-organize!” While many times this works well, other times you will find the talented team-members pooling together and abandoning the less skilled or more junior team members to form the “weak team.” As a leader, what should you do? First, you have to ascertain if the members of the “weak team” simply lack skill or if there are interpersonal issues which are getting in the way. As I mentioned in my last post, if the issue is simply skill you can choose to train them. If the issues are intrapersonal, throw your coach hat on and get busy. Once you have a plan of attack to address the issue of the “weak team,” you have to decide how to turn the “weak team” into the “strong team!” You can do this by adding stronger team members to the existing team or redistributing team members to other teams. This should be done in cooperation with the Product Owner to ensure that you have the right cross-functional talent on each team.
There is a misunderstanding of Scrum and other processes and frameworks that anyone that follows the “rules” will be successful. Simply write some code in a two week Sprint and show it at the Sprint Review and magically all problems disappear. The people that believe this are missing a few key points. 1) Creation of complex software takes skilled people. 2) Leadership is required (notice I am not saying management is required). 3) Both the leaders and team members must be willing to admit they were wrong for continuous improvement to take hold. I used to make the assumption as it relates to the first one that leaders understood they needed talented people to build software. I was wrong. To go back to my opening premise, many leaders think process can replace skill. This is like taking a group of high-school students, putting them in a hospital operating room and saying, “OK, self-organize and perform brain surgery on this patient!” Try as they might, without the proper training, experience, coaching and knowledge all you will end up with is dead bodies. The moral of the story is put skill before process. If you have a team member or members that lack the skill to write loosely coupled, refactorable, unit-testable code you have three options, train them, move them to another team where they have skill alignment or fire them. Don’t kid yourself into thinking there are other options.