Is something missing in the Agile Manifesto?

Brian Marick believes so. His post, "Six years later: What the Agile Manifesto left out" explores some missing values that aren't readily apparent by reading the Manifesto but are essential to have to be successful in Agile. Here's a summary of it (I've made bold the values that he believes is missing):

Now Agile is more respectable, a safer choice. The challenge isn’t so much getting a chance at Agile as it is executing once you’ve gotten the chance. There, the values of the Manifesto are not so helpful. Except for “individuals and interactions”, they face outward from the team. They don’t strongly apply to the relationships between team members, between the teams and their environments, and between the teams and their code. That’s a problem, because it seems to me that many new Agile teams are not executing. They’re floundering.

What should teams do with the time they’re not spending going too fast? They should invest in one of the four values I want to talk about: skill. Two skills that apply to pretty much any software project are refactoring and programmer testing (test-driven design). Those are skills that require a great deal of discipline. It’s awfully tempting not to write a test when it’s harder than writing the code, or to refactor some icky code you stumble on when that would mean blowing your estimate. Some of XP’s practices help with discipline. Pair programming turns what could be a solitary vice into a social act: you and your pair have to look at each other and acknowledge that you’re about to cheat. Peer pressure comes into play, as it does because of collective code ownership. Someone will notice the missing tests someday, and they might know it was your fault. Maybe the key driver of discipline is the practice of creating working software—running, tested features—at frequent intervals. If you’re doing that, you just don’t have time for sloppiness. You have to execute well.

I’ve observed that a characteristic of a good code base is that it’s habitable, that changes are comfortable, that the process of programming is one of ease. Agile teams suffer because they don’t think that wanting to make their lives easy is a relevant value, but it should be. There’s absolutely nothing wrong with finishing up a story by spending a half hour or so tinkering with code you’ve touched, just improving it—doing the software equivalent of hanging power within easy reach because the power strip on the desk is always annoying you.

I think Agile is suffering today because these fundamental values didn’t get written down and are too easily forgotten. As Agile moves into bigger companies and into less adventurous ones, those undocumented values are getting watered down. If that continues, I’m afraid Agile will be this decade’s fad that changes nothing. That would be sad.

Read more in his post.

What does it mean to be Lean?

Note: I wrote this post originally on my first blog, Random Thoughts from a CTO, but thought it was good enough to share with the readers here.

Lean can mean different things to different people.

For some, lean can refer to how you maintain your physical shape through dieting and exercise. For those that have been successful in staying lean, they will say that it takes a paradigm shift of how you take care of your body through what you eat and how you exercise. When you start the process of becoming lean, you begin to cut out those things that are unhealthy and make you fat. You begin to eat better. You begin to feel better. You start seeing results in the mirror. You also are constantly monitoring your weight, heartbeat, blood pressure, calories, etc through the process. For some of us, myself included, we get lazy once we reach this point and start falling back to bad habits -- at first, a mistake here and there on what we eat, or missing a workout or two. Then, you stop getting on the scale and recording your results. Then, before you know it you are not lean again!

For others, lean can refer to how you maintain your financial status through budgeting and tracking your expenses. For those that have been successful in saving money and making more through investing, they will say that it takes a paradigm shift of what you do with your money and where it goes. When you start the process of saving money, you begin to determine where your expenses are going and which of those expenses you can eliminate that takes you from your goals. You also look at ways to increase your income with those savings through investments. You also look to remove your debt. You begin to save money. You begin to feel better. You start seeing results in your portfolio. You also are constantly monitoring your income flow, expenses and net worth through the process. For some of us, in this case myself not included, we get lazy once we reach this point and start falling back to bad habits of spending excess money, getting into debt, and eventually not saving money. Then, before you know it you are not financially set again!

In the software engineering industry, lean is now referring to your cycle time - how quickly you get to a working solution for the end customer without losing quality. For those that have been successful with this approach, they will say that it takes a paradigm shift of how you development and manage your software solutions. When you start the process of reducing cycle times, you begin to determine where communication and collaboration need to happen, what activities or processes take away from reducing cycle times, how we do our jobs and the way we interact with other areas. You will begin to see results. You will see the customer is more satisfied. You will find better ways to get your work done. You also are constantly monitoring your estimates, work completed, costs, quality much better. For some of us, myself a little bit, it is very easy to fall back into old habits of traditional and formal processes because you are so familiar with them and may get discouraged early on in not seeing immediate results you are hoping. You then begin to see things slip, take longer and less of a feeling of accomplishment either by the team or the end customer. Then, before you know it you are feeling that things aren't getting done as they should!

There are many other scenarios that this lean approach can take - time management, stress management, strategy, project management, the list goes on and on. What is getting in the way of your goals? How do you improve on those goals? What do you do to maintain those goals? How do you measure the process of those goals?

Focus on the goals and maintain discipline to see it through! This is what lean should mean!

What Value should be

A common theme that you will see throughout Agile and Lean is this concept of customer value. The order that you do the work should reflect the highest value to the customer. This really isn't a new idea, I have known over the last 20 years that I need to produce something that the customer wants. However, the problem is that even though I knew that was the right thing to do, I didn't always think about my work in the shoes of the customer. As a developer, I remember thinking that if I put this cool new function in using some cool new technology that the customer would love it. I mean why wouldn't they, I thought. But many times I found that by not checking with the customer I wasted time implementing something they didn't really want or ask for. This resulted in either rework or leaving in functionality that was never or rarely used. Neither of those scenarios are good, because I could be spending my time on things that the customer really wants. If only I had asked them (or somebody that represented them)...

So, with Agile and Lean, this is one of the "prime directives" - to make sure that what you are doing has value to the customer. This is a good thing, a REALLY good thing. You need to have a customer representative always available to the team. Not just when they determine requirements, but through the whole process - design, testing, and especially demos of the working software as it is being developed iteratively. It's all about feedback and checkpoints along the way that you aren't wasting your time. In the end, it translates to functionality the customer will use more often. This translates obviously to happy customers, which translates to good word of mouth, which translates to more customers...well, you see the point.

But since we have adopted Agile (and looking at Lean), there has been a little problem with this. You see, we have over 2500 customers that are using our products. While it is good to know what they want in the product, EVERY customer may have different ideas of what is important to them. So, isn't this customer value? Shouldn't we be doing the things that matter to them? Of course, but there are too many things coming through the pipeline and it's difficult to know which customer request is more important than others. So, what have we done? We prioritize by the size of our customers. After all, they represent a larger percentage of our customer base right? While that's true, it doesn't give the little guy much of a chance to offer good ideas. And, those ideas might be the best thing for all other customers.

So, while sitting in the Lean class this week I realized that we are focusing on only a small part of value - Customers. What we need to focus on is Business Value. What is Business Value? Well, customer value is definitely part of the equation but it also looks at what is good for the overall business. Does this request support the majority of our customers? Does it support our long-term goals? Do we have the capacity (people, skills) to fulfill the request? Does it fit our business model? Does it align with where we are taking our products? Is it something that our company should do? I believe that if we ask those questions we will have a much better idea of how to prioritize requests as well as know which requests we should take on. How do we measure that? Return on Investment (ROI)!

Values, Principles and Practices

When I was creating this blog, I wanted to make sure I had a tag line that accurately reflected what the focus and goals of this blog were to be. Here's what I came up with:

A manager's quest to improve his organization through Lean and Agile development values, principles and practices.


Technoetic had a post awhile back that I found to be a great representation of the overall goals - values, principles and practices. While some use these terms somewhat interchangably, I truly believed that each of them represented a particular piece of the whole. The author of this post apparently agreed with me and came up with perfect definitions of each of the parts. Here they are:

Values - A description of preference between alternatives. Often the alternatives represent candidate courses of action and the value guides the selection among the alternatives. Sometimes values are basically axioms. They can be irrational in the sense that we might not be able to explain them intellectually or they might be primarily based on emotions.

Principles - Statements describing a model. A scientific principle is a statement describing an aspect of physical reality. Principles might also describe a model of social activity, for example. Principles can be fundamental or logically derived from fundamental principles. It’s commonly believed that principles are derived from values, but sometimes people have certain values because of specific principles. For example, the “value” of communication can be derived from the principle that communication improves cooperation and coordination effectiveness. This circularity between values and principles can be confusing at times.

Practices - A pattern of activity that can be repeated to achieve goals within a context. A person defining a practice is applying principles within a framework of their values (preferences). A related collection of practices might be called a process or methodology.

To make it even simpler, I could summarize the difference between these as:

Values are the feelings of what the right things are for us to do.

Principles are the guidelines of how we are to demonstrate those values.

Practices are the actions of what we do to support those principles.

As I write future posts, I will refer to these terms frequently to describe the parts of both Lean and Agile. Before I went there, I thought it would be good for us to have the same context going forward.