We just returned from Agile 2009. I tried to blog from the show though my login wasn’t working… This is probably a good thing for you. I’m completely exhausted from the week and now I have to pickup my daughter from school. So I’ll be brief…

My summary from Agile 2009 is: “Agility is an Enterprise Noun not a Technology Adjective.” It’s critical that our work really affect the Enterprise. And I’m not just talking about for-profit institutions. This includes the government and not-for-profits. Ladies and gentleman <rant mode=”on”>, the mission of Agile is to give the Enterprise agility not, necessarily, to make the Technology guys & gals Agile. It’s critical that we stay focused on the problem at hand. It takes too long and costs too much to solve enterprise problems. Case in point, ERP. I think we could build a new ERP for 100M. This is just crazy! We (the technology community) have a reputation for failing to deliver on time, on budget, and within scope. And, if you poll most executives, they think it costs too much. Many CIO’s have been marginalized and are again reporting to their CFO. This is (obviously) a backward step. The primary reason – in my opinion? We failed to be great businessmen and stewards of the company’s resources. Now that we’re beginning to regain the trust of the business, with Agile, we need to re-establish ourselves as the business leaders we are. We make our clients (the enterprise) more competitive, more efficient, and more responsive (agile) than they were before we had this great Agile revelation/innovation. I own a for-profit business. What I care about, first and foremost, are my people. To keep them happy I must first keep them employed, which requires the company to stay afloat, generate profits and the like. To keep them happy (financially and in their careers) I must improve sales and operations, margins, profits, and the like. The same goes for any other enterprise, just add in the stockholder, voter, taxpayer, etc. If Agile turns into another technical methodology, it will die a slow death with every other methodology in the technology graveyard. We must stay focused on Business Value, question everything, and ensure it solves a business problem. It must make or save the company money. Reduce taxes, increase voter confidence, the list goes on. Be excellent business men and women who happen to deliver value through systems and technology. If we do this we’ll most certainly win and we’ll mainstream our dream.

Mega Kudos to Pollyanna Pixton – Your stuff absolutely rocks!

David Hussman – You are one of the most practical and wise consultants I’ve met, and I really love the hair. I have been in the industry for a long time and met a ton of very, very expensive consultants. You are one of the most valuable. If you ever want a job, want to merge, please call, I will do it on the spot. You rock!

Mike Cottmeyer – Your Agile PMI bridging is huge. You are an excellent communicator and blogger. I think you are the future of “Icon” Agile Leadership. Keep up the great work.

Alistair Cockburn – Thank you very, very much for challenging the Agile word. Your keynote did what it was supposed to do, help us advance the cause…

Ron and Chet – The quintessential pair’ers, wrestle this certification problem down. We really trust you.

Patrick Welsh – I love you man… I have a new idea for you that you’ll love…

I could go on for hours but I just got another text. My daughter is waiting. Later…

Here are the slides from my Agile 2009 talk earlier today “Five Symptoms of Mechanical Agile…And Some Good Advice on Becoming Change-Ready.”

What a great time here at Agile2009. We have been busy collecting some video from the show.

A funny but true thought about how developers act when solving problems

Lunch at Agile2009 Part 1 of 2

Lunch at Agile2009 Part 2 of 2

Agile2009 Developer Jam: Ugly Code vs Clean Code

Leadership in an agile world is something that I’m always very passionate about. So when I saw a presentation list at Agile 2009 by Gilles Brouillette called “Developing Agile Leaders & Teams”, it grabbed my attention. Since the room was overflowing to the point where threats of a fire marshal were invoked, the topic is apparently on the minds of a lot of other folks, too!

When I work with an organization that wants to transform, I like to tell them about what impact they’ll see in their culture and the rate which roles will adapt to the change. The business is always first to get on board. They’ve been asking for more involvement and more collaboration in delivering IT projects for years, so that’s kind of a no-brainer. The next are usually the developers. Suddenly people are focused on helping them to become craftsmen and to get first-hand feedback from the people using their products. That’s a pretty easy sell, too. Third are those that I’ll lump together in the BA and QA space. Their roles change, but become more relevant and meaningful to the team. Fourth are the IT managers, directors and VP types. They need to make the shift from “controlling” resources to “enabling” teams. The last role to adapt is always the PM and PMO. Describing why is probably a blog entry in and of itself.

It’s always been my position that managers, directors and VPs in the organization are the 2nd most important group to transform (the first, if you were wondering, is the business). Management can do more to kill an agile transformation than any other role in the organization. On the flip side, they can also do more to make the initiative successful than any other role in the organization. Sadly, I tend to find more in the former category than the latter. Brouillette’s presentation suggested that about 90% of leaders fall into a mindset that fosters heroics, focuses on self and pretty much embodies everything that would make them a poor leader in an agile organization. They’re tactical, reactive, competitive and generally resistant to change. Think about it; that means only 10% of the leaders are carrying the mindset that would allow them to foster agile growth in their organizations.

It certainly explains the root cause of most agile transformations that I’ve seen fail. Hearing some actual data around it just made me sad.

The good news is that it is possible to move from the 90% group to the 10% group. It’s more than training, it’s transforming. It becomes about moving people from our typical “command and control” style of management to one of servant-leadership. It’s a focus on listening more than telling. It’s about fostering collaboration more than competition. So how do we do that?

How about this. What would a leadership team look like if typical quarterly objectives and bonus plans rewarded how much you helped a peer succeed versus your own achievement? Or how many peers you helped to succeed? Or a score on a 360-degree evaluation that puts an emphasis on listening, transparency and collaboration? These are all things that most of us would agree are valuable assets in an agile leader. Unfortunately, most of would have to admit that the goals we set continue to be around hitting dates, generating revenue, meeting a schedule, etc. Don’t get me wrong; those things are important. The problem is they don’t drive the behavior we want in our agile leaders and, in fact, drive the exact opposite behavior.

Although I still don’t have a magic answer of how to transform leaders, mainly because that answer will different for each individual, I do have better awareness of scope of the issue that I keep encountering again and again. From the attendance, a lot of people have that awareness, too. It’s a step.

Mary Poppendieck’s presentation this morning at Agile 2009 has prompted me to write a short rant. Her presentation was called “Workflow is Orthogonal to Schedule.” My rant is called “Software Ain’t Manufacturing.”

Mary really is a good presenter, very engaging and keeps your interest. But the content of her talk this morning was focused on a) how software is like the construction of the Empire State Building, and b) how software is like manufacturing.

There may be some benefit from comparing activities that are as different as manufacturing and software creation, but I think there are more negatives than positives. Most of the trouble we get into with software is when we try to “mechanize” the process and the people, wedging what is truly a creative process, building software, into a manufacturing mindset.

With manufacturing, you have discrete parts that you put together. Your “inventory” consists of multiple parts that are alike; the parts are similar in size, weight and amount of time to integrate. We simply don’t have that unit in software. Stories or storypoints tend to blow up far beyond our estimates, not just by a factor of double or triple but exponentially. With her Empire State Building example, she said that it was similar because the steel beams were different sizes, just like stories. But that example doesn’t hold up. With software, we begin building a steel beam and then realize it is actually a window. We don’t discover its actual character until we’ve started building it. The conceptual nature of software (no laws of physics here) leads to these kinds of radical changes that don’t occur in the physical world.

The increasing drumbeat of Kanban and Lean is a distraction. We are taking the “lean practices,” which were extracted from the Toyota Production System (TPS) without bringing along the context of the TPS systems thinking and culture. From what Toyota people say, the TPS system is much more important than the practices. With Lean, we use the practices but ignore the system. If we wanted better results, we should use the systems thinking and ignore the practices. Lean has it backwards.

Lean advocates say that it does have a systems thinking basis, and that is true. But the systems thinking within Lean is “hard systems thinking,” which is most useful for simple systems that do not include people. Have you encountered software systems that aren’t developed by people, or that are not meant for usage by people? Instead, we need a basis in “soft systems thinking,” which is helpful when we have people with differing viewpoints and complexity.

I hate to be so negative about Mary’s talk, but I do want to point out a dangerous road we seem to be traveling, which I think is leading us to “mechanical Agile,” where we view our teams as machines and our people as a kind of robot. This type of team can only follow orders and cannot innovate or adapt. I don’t want that type of team for my business systems, nor do I want to work on that type of team.

Summary: A major difference between Agile and waterfall is something that often gets missed. The progress of each lifecycle is understood by asking very different questions. With waterfall, you ask “When will it be done?” With Agile, the question becomes “How much can you get done by this date?”

If you’ve been following debate on the healthcare issues in the United States, Canada or Europe, you may agree with me that things are off-course. I’ve noticed that, in many cases, the entire discussion revolves around the wrong question. It seems like all coverage, analysis and chit-chat is about the healthcare question “How will we pay for all this healthcare?” But I think the question to be answered is actually “Why does healthcare cost so much?” It is simultaneously very interesting and very distressing that healthcare is so expensive. Wouldn’t we be better off understanding why it costs so much and looking for ways to reduce costs than just laying out one plan after another to pay for these giant expenditures?

I think the same thing can happen in software development. If we don’t ask the right question at the beginning of the project, then no matter how well we answer, it won’t be helpful.

What’s the Question?

When I ask people the difference between Agile and waterfall, I get lots of answers. Some say “Agile is a mindshift where businesspeople and technologists work as partners.” Others say “Agile is nothing but mini-waterfalls.” Still others say that “Agile is about a human-oriented process.”

But I’ve come to realize that perhaps the biggest difference between Agile and waterfall is the question being asked. The scope of the project and any judgments of progress are related to this very fundamental question.

In this article, I’d like to examine the basis of the waterfall question and the Agile question and hopefully provide some good reasoning to show why Agile can be a more productive way to approach software development.

The Waterfall Question – “When Will It Be Done?”

If you’ve ever been on a waterfall project, you’ve heard this question. It is the most typical question for a project manager to ask a developer, business analyst or tester. “When will that service be coded?” “When will that test script be executed?” “When will that use case be written?”

But I’m actually not talking about those questions. I’m talking about the more macro question. “When will this project be done?” This big question gets asked less often but it is on everyone’s minds. “When will we get it done?” It is a question that can provide great focus. But it is also a flawed question. It is flawed because it has a hole – a hole big enough to drive a cement truck through it.

The offending hole in the question is “What is ‘it‘?”

Sure, you can say “‘It’ is the project, defined by the scope,” but this is a huge problem. Even with abundantly clear requirements and scope, there is plenty of room for different interpretations. The executive reads one thing between the lines. The project manager reads another. And the end user reads yet another. You can never get enough detail written down to assure that all misunderstandings are rendered impossible.

And that’s assuming that requirements were documented fastidiously, that the team had time to do that. On most projects I’ve seen, teams have had to make compromises in their detail level of requirements, and so different perspectives run rampant.

“I’ll know what I want when I see it.”

Business users are somewhat famous for this remark. By saying this, they are committing to nothing until they can see the result and only then will they make a judgment as to whether “it” will work or not. In a waterfall project, the moment when a user can get their hands on the actual “it” is very late in the lifecycle and many decisions have already been written in stone. Too late to incorporate feedback! Sorry!

There is another problematic aspect to “it.” Part of a project is the scope of what is required to be in the product for completion. But another part is how your team will accomplish “it” – the workplan. How many perspectives are possible on that? Again, the team will build a workplan together that reflects what they think needs to be done for the product they think the business needs. Can you see a few possible pitfalls here??

The team might be wrong about the tasks, they might have misunderstandings about the work to be done, even amongst the team, and, they might underestimate the effort involved. All of which will cause headaches later on for the technical team and the businesspeople.

So, predicting the answer to the waterfall question (the big question) becomes so very difficult.

And, I’m sorry, but I must add yet another complexity to “it.” The “it” at the end of the project is a different “it” that at the beginning. As a very smart businessperson I once knew stated “Don’t give me what I wanted at the beginning of the project, give me what I want at the end!”

Business changes. It is very likely, if not downright guaranteed, that the business needs will change during a six month project. It’s a different “it.” How do you plan for that? Change control?? Phase two?? That doesn’t help anyone.

The Agile Question – How Much Can You Do By This Date?

Okay, so we need a new question. And it would be nice if the nasty “it” word was not in the question!

In Agile, we change the question to “How much can you do by this date?”

Let’s look at the implications of this question. Now we are fixing the date and saying “Do what you can before then.” Is it possible that I’ll have one perspective on the definition of March 29th and you will have another? Not really. There is a slight danger that we could misinterpret what it means to be “done” something, but that can be worked out pretty easily. This new question lets us work on building the scope of the product together and figuring “it” out over time. This becomes a very exploratory process where the definition of scope is allowed to wander around a bit before it comes to rest just before the application goes live.

Am I scaring you? Are you thinking “Scope creep!” Are you thinking the businesspeople will keep changing their minds back and forth (and back…and forth) forever keeping the project from ever reaching a conclusion? Sure, these things are possible under Agile. They need to be managed. A good Agile project manager watches for these symptoms and jumps on them to avoid serious consequences. There are specific Agile practices to keep a team from falling into these traps, and to notice them quickly.

But, is the Agile question actually a motivational goal, the same way the waterfall question is? After all, couldn’t your team just doddle along and then declare themselves done when they bump up against the date? Yes, of course, nothing stops any team from being irresponsible. But, in my experience, teams want to do a good job, and if they want to do the wrong thing, no set of lifecycle rules will stop them.
In my experience, here is what happens when you ask the Agile question “How much can you do by this date?” The team looks carefully at the set of requirements, in Agile terms this is called a “backlog,” and they take the highest priority items and commit to fulfilling those in the time period. Plus, the team breaks up the overall time period (let’s call that the “release”) into smaller time periods (“sprints”). Then, for each of the sprints, they do the same thing – they decide how much they can do by the sprint end date, and commit to that. Commit a little, accomplish a little. Then they whittle away at the overall goal for the release end date by making smaller goals within the sprints.

Yes, it does happen that the team accomplishes less than they originally committed to for the release. But ask almost any businessperson in almost any situation “Which would you rather have, all the features delivered late or most of the features delivered on-time??” The businessperson will choose the second option most of the time. Business runs on budgets and dates. The people most concerned about the exact feature set are usually the technical people. Of course, businesspeople will insist “I want all those features delivered by this date and within this budget!!” But you know what that’s called? It’s called negotiation. Make your initial demands and then see what the other guy does. Trouble is, most of us technical people are terrible negotiators. So we give in too often. But that’s another story…

All in all, the Agile question “How much can you do by this date?” is the better question. It does involve a certain level of trust of your project team. But it provides a better resolution of what “it” is but not assuming anything up-front, and by exploring “it” together until “it” comes together at release time. And, the Agile question also provides much, much better value to the business, by playing on their terms of fixed schedule and budget with a flexible set of features.