Medication

Dan Mezick
I'm pleased to add this content to Jeff's blog regarding pain medication and the Agile Manifesto.

Delivering software as a team is a highly intentional act. If we say we want working software, the results are by no means assured. Confronting reality, at the level of group, is the name of the game in software development. The alternative is pain medication...


Medication

If you check out the Agile Manifesto, you find that we often medicate with the things listed on the right in the Values section.
Medication is usually in the form of a pain killer of some kind. The whole right side of the Agile Manifesto lists various forms of medication that enterprises, departments and teams use to relieve various forms of pain.
Examples of pain-killing medications:

• Processes and Tools
• Comprehensive Documentation
• Contract Negotiation
• Following a Plan

Lets look at each in turn:

Process and Tools

We medicate away from facing [Individual and Interactions] by focusing on processes and tools. We focus on these, and away from [Individual and Interactions] because we might have to get real and face the reality of people and interacting with them. We might have to get some new social skills! Ouch, that smarts. Where are my pills?

Comprehensive Documentation
This usually manifests as the need for “perfect” and “comprehensive” requirements. We medicate with these, and avoid dealing in the reality that what we must create is [Working Software]. We focus on perfection in requirements, and away from STARTING. Starting is risky and who knows what might happen? The reality is we cannot learn till we pay attention, and we do not pay attention till we start. Got that? OK, so START NOW with your imperfect non-comprehensive requirements. It’s going to be (perfectly) OK.

Contract Negotiation

OK, OK we need to know what to build. I agree. Let’s also agree that it is unreasonable to expect everyone to know exactly what they want, 100%, at the start of the process. We focus on contracts instead of [Customer Collaboration] because this stuff is hard. So, we medicate with the contract. It gives a sense of control, see? That stops the pain of dealing with what is in fact an uncontrollable, increasing complex, high-change world.

Following a Plan

“Planning” usually shows up as “prediction-in-drag”: in effect, a wild-ass guess masquerading as planning. If prediction is so very easy, why isn’t everyone a stock market winner? See it? Prediction is difficult… and way over-rated. Plans are great and we need a direction … and a general way to move in that direction. But let’s not pretend we can predict very much at all. Instead, let’s [Respond to Change]. Ouch, that hurts because I might have to question my beliefs, to address any really unusual changes. I might have to re-factor my model of reality.
That’s a whole lot of hard work, making painful edits to what I currently believe.
Ouch, that smarts. Where are my pills?

Dan Mezick is the author of The Culture Game , teaches and coaches Agile at New Technology Solutions, and helps create community (and events) via the Agile Boston and Agile Connecticut user groups. Reach him at dan@newtechusa.net, via the Blog, or Twitter.

Powerful Strategy for Defect Prevention: Improve the Quality of Your Product

A classic paper from IBM shows how they systematically reduced defects by analyzing root cause. The cost of implementing this practice is less than the cost of fixing defects that you will have if you do not implement it so it should always be implemented.

1. First understand your architecture and where the bugs are coming from by type, severity, component, and point of injection during the development life cycle.

2. You will find 80% of the bugs come from 20% of the code. Mapping these defects on a component architecture will show swarms of bugs around specific components.

3. Apply bug spray through a carefully prioritized automated testing strategy. Find the biggest problem that occurs when doing final regression testing prior to deployment. Implement an automated test that makes this problem impossible to happen again using the detailed knowledge developed about bug infestation in your product. Write a single test that can prevent 100 common problems. Then go to the next highest priority problem and repeat. Doing a few automated tests a week will eventually make your build bullet proof with remarkably few tests.

In three months, one of our venture companies cut a 4-6 week deployment cycle to 2 weeks with only 120 tests. It took one person three weeks to write the test and eliminated several weeks of work by an entire team. It reduced defeats, radically reduced support calls, and the customers liked the new release enough to buy more product, raising revenue.

Everyone should implement this. The return on investment is astronomical. I thought this was basic stuff but our investors say almost none of their companies have implemented it until we invested in them. The developers are often junior, right out of university, and the managers are domain experts, not engineering experts. We have to teach them the basics.

Experiences with Defect Prevention

by R. G. Mays, C. L. Jones, G. J. Holloway, D. P. Studinski

IBM SYSTEMS JOURNAL. VOL 29, NO 1, 1990

Defect Prevention is the process of improving quality and productivity by preventing the injection of defects into a product. It consists of four elements integrated into the development process(: 1) causal analysis meetings to identify the root cause of defects and suggest preventive actions; (2) an action team to implement the preventive actions; (3) kickoff meetings to increase awareness of quality issues specific to each development stage; and (4) data collection and tracking of associated data. The Defect Prevention Process has been successfully implemented in a variety of organizations within IBM, some for more than six years. This paper discusses the steps needed to implement this process and the results that may be obtained. Data on quality, process costs, benefits, and practical experiences are also presented. Insights into the nature of programming errors and the application of this process to a variety of working environments are discussed.

How to Use Scrum in Hardware Development

Many hardware designers ask how they can do Scrum for hardware development. This is the future for hardware. Software will be a key component and the hardware design will need to change every sprint. The winner will be number one and probably not be Toyota. Their software development is antiquated and they already have 12M lines of code in the Lexus. Trying to even maintain that without Scrum will cause significant delays.

Joe Justice built a 100mpg car using principles of agile, lean and scrum. How did he do it?

Posted on December 2, 2011 

First of all let me tell you that your STG01 (the 100mpg car) looks great. I am tempted to buy it now, what a great model. There is so much I want to talk to you about; we’ll see how much we can fit into this one hour. You want to start with telling us about your career so far and your touch points to project management. And then tell us how you got started on the agile concept.

Agile for me was the de facto standard. When I graduated college the first job I took was with an agile software development group. I didn’t even know it was agile, it was just the way business was done there. At that time I was writing one of the first web services for .NET 1.0. Then I was poached by a consulting firm that did Microsoft enterprise software. Agile was becoming hotter and hotter, and customers were requesting agile more and more. So for several years I never worked with anything except agile software development, I didn’t know any other method!

Some of these teams were quite large, maybe more than 50 team members, and sometimes these were distributed teams working from multiple countries at once. Again I didn’t know any other method than agile software delivery – working with the principles and values of agile, lean and scrum we found ways to co-ordinate multiple teams during larger and larger project deliveries. As these deliveries grew to multiple teams, I began to interface with more teams with hand-off points and joint deliveries. They were using some other method; it turned out to be waterfall. It was so painful, so much time was caught up in change request and a lot of it came to rely on the theatrics of the project manager to convince the client that they needed a change request. And none of the teams I was on needed to do that, the client was just aware of the current state of the project and able to re priortorize. It was very much less dramatic and as a result far more efficient.

I started studying this other method, trying to figure out what it was and why it seemed so painful. And why the people on the team I was with were excited, eager, and creative. Contrastingly, the folks on these other teams were often very depressed, quite literally, and looking forward to going home. They often needed to work week nights and weekends to meet some goal that a project manager had mentioned in passing and the client had taken to be gospel. Again I was struck by this, which didn’t happen on the teams I had been working with because it was continuously iterative and work was completed in priority order. So I began studying this in earnest. And really only discovered what agile was once I learned what waterfall was. To me again agile was just the way you did work, I was lucky enough to be born right into it. I began to become very passionate about it once I saw how concrete these differences were. And the difference wasn’t that you had a high performing, creative team just magically. But there was a creative high performing team because of a specific type of project methodology and project management approach. Once I found that it was repeatable, with different teams, and there were these set of principles that could be applied again and again to avoid teams becoming so disheartened, so 9 to 5, so pathetic, so uncreative. It became something like a personal mission for me, and I become very passionate about it.

Now at WIKISPEED, again I did not know any other way to run a project. When I was on the automotive design project and then on the ultra efficient automotive challenge the only delivery method I knew was agile, lean and scrum. It came to be incredibly effective for us. It developed a very different type of car than what is on the road now. It became a very efficient car, a very quick to develop car and a very inexpensive to maintain car. Again it is not that I set out to build an agile, lean or scrum car, I set out to make an ultra efficient car with this whole team of volunteers all over the world. As the team lead who determines the project methodology, it enabled us to have this high energy high performing team, high creativity, high velocity team, and to do so much in so much less time.

Don't miss the rest of this article. It is incredible!