Mar 282012
A scrum

A scrum (Photo credit: Wikipedia)

EDIT: Changed some language so as to not give the impression the Manifesto came before all Agile methodologies.

Before the wide adoption of Scrum, there were a group of very smart developer types who discussed values and principles that, if observed and implemented, would lead to delivering high-quality software more quickly than most approaches that were dominant at the time. These people created an Agile Manifesto and articulated the principles that drove it. It is this body of values and principles that is meant when we talk about being Agile, using Agile, etc.

It is important to note that those writings do not specify any specific practices, implementations, or methodologies. It basically says, “As long as you are pursuing these goals and relying on these principles to help you achieve those goals, that’s being Agile.” By and large, this defined itself over and against Waterfall – a process articulated by Winston W. Royce in 1970 as a hypothetical example of a flawed model that would not work for software development but inexplicably became the dominant model for software development and the undergirding of project management for software projects.

If you look at the Manifesto and the principles behind it, you will find nothing about time boxed iterations, sprint planning meetings, or anything that is a specific technique or methodology. Agile is something that is back of, transcends, and critiques methodologies.

This body of principles is reflected in people taking a crack at implementing these things in their software development. In fact, many of the things reflected in the Manifesto came out of some of these attempts. XP attempts to embody these principles. Lean / Kanban also does. Scrum also does.

That last bit bears repeating: Agile is a set of values and principles. Scrum is one particular methodology among others built around those values and principles.

For reasons that I suppose boil down to excellent marketing, it is both widespread and regrettable that Agile is used as a synonym for Scrum. Sometimes, this leads to very entertaining claims made by people who ought to know better such as Agile being invented seven years ago or “Agile projects always operate within a ‘Time-Box.’”

The cause has not been helped by the fact that when Microsoft uses the word “Agile” for their TFS templates, they inevitably mean “Scrum.” Even the Scrum Alliance shows what it really cares about by frequently using Agile as a synonym for their own methodology in their articles and materials (NOTE: This is borderline reprehensible, because they really do know better, which means this is deliberately deceptive in order to snag more Scrumbots who won’t know any better).

This isn’t just some pedantic issue.

For me, personally, one of the things I bring to the table is – as a developer, a mentor, and an instructor – a belief in Agile principles. I used to do this with Scrum. These days, it’s more the Lean / Kanban variety. Someday, it’ll probably be something totally different. But the principles will be pretty much the same; it’ll just be about finding more effective ways to implement those principles.

As a professional, it’s very annoying when people assume that everything I say or do or put on a profile regarding Agile is actually about Scrum. It’s very annoying to try to market myself to companies that say, “Oh, we tried Agile, and it didn’t work here,” when what they mean is they tried Scrum. This distinction becoming hazy in the marketplace has an economic impact on those of us who are very pro-Agile but do not practice Scrum trying to market our services and expertise to a world that no longer knows the difference and may have antipathies toward Scrum.

The other issue is that the equation of Scrum with Agile means a whole lot of ignoramuses are coming in under the Agile banner.

That is not to say that every Scrum advocate is an ignoramus. There are extremely intelligent people implementing, using, and coaching teams on Scrum and they are kicking butt. However, a phenomenon occurring in the marketplace today is that people learn Scrum and they become Agile Coaches, which is somewhat akin to me learning the recipe for clam chowder and going around telling restaurants the best way to make soup (which, invariably, is clam chowder). These people will comment and blog freely and often, filling the Information Superhighway with epistemological roadkill. They write articles. They give conference talks.

All these things reveal to anyone who knows better that these people have no clue, but this is the public face of Agile, now. Learning Scrum gave them a license to be Agile experts, so that’s how they see themselves, that’s how they market themselves, and that’s how the market encounters them. For every one Agile coach who knows what they’re doing, there are twenty who became Certified Scrum Masters, and their ability to sit in a room for two days has now given them Authority (I am a Certified Scrum Master, incidentally).

I feel bad for anyone who is a real Agile Coach trying to market themselves as an Agile Coach, because 90% of the time, Agile Coach is a nice way to say Clueless Scrum Master. And whenever I read a blog or hear a presentation or see an online discussion that is full of Agile fail, I know the person who wrote it is coming from the Scrum camp. The equivocation of Scrum and Agile has given them a license and a platform to address issues they do not fully understand, which has produced awesome advice such as some things I’ve seen in Agile Coaching blogs the past couple of months: “Don’t have too much interaction with the client because it interrupts the team,” “Make sure you’re updating the Scrum Master in your stand up and not the Product Owner,” and “Don’t use TDD on small projects.”

Any Scrum person who truly understands Agile probably cringes at those statements as much as I do, and that just proves there’s a problem.

Scrum may be Agile, but Agile is not Scrum. If you are going to claim to talk about being Agile, make sure you know the difference.

Feb 292012
Book of Answers

Book of Answers (Photo credit: Caro’s Lines)

Is there a word for feeling amused and frustrated by the same phenomenon? There has to be. Maybe some German word.

I am often frustramused by the various “Agile” groups on LinkedIn because they often show just how much people will cling to the presuppositions of Waterfall but try to make them operate in an Agile manner. No wonder people get so confused and frustrated trying to make Agile work in their environment! It’s like putting a Ferrari chassis on Ford Escort guts and wondering why you aren’t going any faster.

Recently, someone asked a group that I’m in how many user stories a seven person team should be able to release in three to six months.

If you’re still waiting for the punch line, then we have a lot of work to do.

The reality is that this question borders on being nonsensical. It’s like asking, “How many websites can a team of seven produce in three to six months?” There’s no way to answer that question. How big are these websites? What kind of websites are these? What skills does your team have? There’s lots of things you need to know to even begin to make a wild guess at an answer.

The only thing you do know are a person’s biological limitations, so it’s probably safe to say that a team can’t complete ten million websites in three months. But I think we can all agree there is no way to generate a numerical answer to that question that would have any value. It would be the world’s most random guess.

Well, several people tried to explain that he’d asked an impossible question – some of them more politely than others – and he accused them of being unhelpful. Finally, someone just said, “Fifty to a hundred.” Absolutely no explanation or anything. The question asker held this up as a helpful response.

No, it’s the worst possible response, because it is a lie. The truth is that the question can’t be answered in any useful way. A number here is just (sorry web filters) bullshit that is good for nothing but bad practices and poor expectations. A misleading answer is much worse than no answer.

A helpful answer is, “No one can answer your question, because there is no standard size for user stories, no universal measure of skill for your team, and no rationale behind how many stories go into a release. What you want to do is complete some stories, measure that time, and use that for your projections, because Reality is the most useful thing you can use.”

This particular question may seem egregious, and it is, but the same drivers behind that question drive all kinds of questions that go unchallenged on a regular basis in an Agile environment. Numerical answers are given, and they are just as unhelpful.

Any of this sound familiar?

  • How long will it take to complete a project like this?
  • How much will it cost to build this web application?
  • When can we finalize the requirements?
  • How much work will you be able to get done this sprint?

(That last one hit a little close to home, Agile folks?)

Ok, so one of those questions probably means you aren’t agile at all (finalized requirements?), but the others are legitimate questions that come up on a regular basis, and the correct answer is, “I don’t know.” You know why it’s the correct answer? Because it’s the truth.

A numerical answer is unhelpful, because it’s a lie.  “Oh, this project will probably take four developers about six months.” What a load of crap. You didn’t do anything more accurate than the dude who said that a team of seven should be able to complete about 50 to 100 user stories in a three to six month release.

What you want to do is say, “Let’s get a few features done and measure how long that took. We can use that as a basis to project out future feature times, costs, iteration content, etc. They’ll still be guesses, because our averages are only averages, but they will be based on our team’s actual work and output and not guesses as to what our team’s work and output might be, and they’ll be based on real work done on the actual project, not a theoretical project described in a document.”

Some people will tell you that’s unhelpful. They want the number. The number is helpful. Sadly, giving them that number for planning purposes is one of the most destructive things you can do to them, because it’s arbitrary. It’s wrong. It’s a guaranteed fail.

Get Waterfall out of your head. Be Agile. Measure the truth, tell the truth, refuse to let your clients run their businesses on well-intentioned fiction. Deliver value. Be real.

Feb 212012
Ed Sumerfield and Chris Nelson of Gaslight Sof...

Ed Sumerfield and Chris Nelson of Gaslight Software presenting "Why Agile Fails" (Photo credit: RubyNuby)

The other day, Travis (@tdietz) and I were talking about how, in the Kansas City market, there are several software outsourcing/staffing companies that claim to be agile. However, upon examination, one finds that they’re about as agile as an iceberg and with similar long-term effects. At the same time, these companies are not being disingenuous; they honestly believe they are “agile,” it’s just that agile to them denotes things that their company does that they consider to be agile.

“We don’t document anything! We’re agile!”

“We don’t have middle managers! We’re agile!”

“We work overtime to get the project done before deadline! We’re agile!”

“We have a well-defined change management process! We’re agile!”

Businesses, of course, have no real way of knowing if the company they choose to work with is actually agile or not, unless they just happen to have someone on staff who knows what’s up. Companies that latch on to this buzzword inevitably deliver an experience roughly the same as every other software company – bad. The business finds another “agile” company, and the same thing happens.

Eventually, being “agile” ceases to mean anything. It appears to businesses to deliver no qualitative difference, because software companies are basically doing what they’ve always done (although maybe real real fast) and calling it agile. This problem is pervasive in the Kansas City market, and it makes it a hard sell for the select few companies actually doing agile development, because it’s very hard to convince a business owner that the reason Agile Company X failed was because they weren’t doing it right.  Oh, and neither were Agile Companies Y or Z. But we’ll do it right. Trust us. Seventh time’s a charm, etc.

Compounding the problem is the mantra that being agile is about principles, not practices. This is 100% true, but the problem is that people assume “agile principles” covers every vague notion they have about improving efficiency. You might do Waterfall, but you limit the Requirements Phase to two weeks, maximum, so now you’re agile, because agile is about principles, not practices, and you just… you know… went faster.  This is also where you refer to the Agile Manifesto, which you have not read, because if you had, you would realize that there are some fairly specific ideas what does and does not count as a principle of agile development, and you’re not evaluating your practices by those principles.

“Principles” becomes a blanket that you pull and stretch, trying to cover all sorts of practices. This article in Forbes demonstrates that you can call just about any company agile if you play with your semantics enough and have no real concept of what you’re evaluating against.

It has been suggested more than once at my company that perhaps the term “agile” has outlived its usefulness in distinguishing our company, and I have often argued that it is still useful. I don’t know, though; I think I might be ready to wave the white flag and just come up with some other term.

I’m thinking: Punctual.

Jan 232012
Oil latch on Cessna 152

Image by FrancoisRoche via Flickr

Imagine, for a moment, that you are explaining how to change the oil in your car to someone else.  If that’s a stretch for you, just substitute some other activity and change the analogy, accordingly.

After you finish your explanation, your oil-changing padawan says, “What do you do with the old oil after you’ve drained it?”

This is a very good question as it comes out of ignorance – the very issue questions were invented to address.  She obviously understands the basic idea of what you were saying, but is unclear on or missing some of the particulars.  Where should the old oil go?  What tools are the best to use?  Did you say every 3,000 or every 30,000 miles?  There is a lack of knowledge, and this person is going to fill it.

Now, imagine that same scenario, except the person asks, “What do you with the cat after you’ve drained the oil?”

You might blink a few times, then ask for clarification, yourself.

“What do you do with the cat?  I have a cat, and the cat might get oil on himself, so what do I do when that happens?  How can I best use the cat in the oil changing process?  What breed of cat is best to own if I’m going to be changing the oil a lot?”

These kinds of questions betray the fact that the person really has very little clue about what you just said.  At best, such questions reflect mismatched priorities.  What you do with a cat who gets oil on their fur is not particularly relevant or important to the oil-changing process (although I’m sure cats would disagree).  At worst, they reflect a fundamentally incorrect idea of what the whole enterprise of oil-changing is about.  You would probably start to wonder where you went wrong and how much ground you need to retread to straighten this whole cat thing out.

Now, imagine that this person yells across the yard to your neighbor, “Hey!  When you change your oil, what do you do about the cat?”

To your astonishment, your neighbor yells back, “Not sure I have a great answer, but let me tell you some things I’ve tried!”

You realize with growing horror that you are, in fact, in the minority on this one.  With a handful of exceptions, most people around you struggle with the whole issue of how cats relate to oil changing and the various cat-centric problems that arise as a result.  Books are written on the issue.  People ask about it on discussion forums.  Conferences are arranged around the issue of cats and oil changing.

Imagine your feelings at being in such a world.  Some part of you is just frustrated, wanting to scream at everyone, “What the hell is wrong with you people?  Cats have nothing to do with oil changing!  What are you guys doing out there?  What do you think oil changing is?”

But encompassing the creamy center of your anger is the much larger mass of the chocolate coating of mystification.  You are honestly staggered at how anyone could possibly have come up with this understanding of oil changing, and you are genuinely mystified that people as a whole don’t just go, “Hey, have you noticed that we keep asking about cats, but if you think about it, cats don’t really factor in to changing oil that much, if at all.”

This is how I feel 90% of the time when I read agile books, articles, or discussion boards.

Jan 172012
Waterfall Model

Image via Wikipedia

In recent discussions with groups of agile coaches, mentors, Scrumbots, etc., I’ve noticed a sort of ad hoc dividing line between people who really know what they’re doing and people who are still struggling with it.  It’s not the only line, but it’s one of them, and that line (how many times can I use the word “line” in the opening paragraph?) is this:

Does this person confuse processes with principles and/or value processes over principles?

Businesses love processes because they are comforting.  You can document them, replicate them, measure them, and enforce them.  You don’t have to rely on people thinking very much, because there’s a process.  As much as people might try to deny it, the overwhelming majority of people actually like being told what to do.  It takes a lot of pressure off.  So, I do get the attraction and, for some of the reasons above, I’m not anti-process.

However, a process should always be built around certain principles or goals and critiqued by their effectiveness in maintaining those principles / achieving those goals.  It is never ok to stop asking the question: Is our current process still the best way to accomplish what we’re trying to accomplish?  Once you stop asking that question, the process then becomes an end unto itself.  It is now inherently good to follow the process.

Remember the story about the goose who laid the golden eggs?  The reason you valued the goose wasn’t because geese rock; it was because it laid golden eggs.  What you really valued were the golden eggs, and if the goose ever stopped laying golden eggs, you wouldn’t think anything more about that goose than any other.

This is similar to processes and principles.  What you really value are the principles.  Processes only have value if they effectively deliver on those principles.

This applies to many, many aspects of life, but in software development, it applies a lot to companies putting implicit faith in a process rather than critically examining if the process is actually accomplishing what they wanted in the first place.

A commitment to Waterfall obviously comes to mind, but far more insidious is a commitment to old school, textbook Scrum.

Companies want to be more agile.  Scrum is a process that purports to bring you agility, so companies trade blind dedication to one process for blind dedication to another – something Scrum tends to encourage, incidentally.  You even have a person (the Scrum Master) whose entire mission in life is to make sure everyone is following the process.

Companies don’t want to critically think about why they aren’t agile and what things they might need to correct to get them there – they want someone to tell them what to do.  “Do this stuff, and you will be agile.  You will deliver working software faster.  You will value people over processes, with the possible exception of this one.  You will be able to call your team agile.  All you have to do is follow this process to the letter, and magic will happen.”

Unfortunately, that’s not how it goes.  Enforcing Scrum to become agile is like trying to cure all sickness with penicillin.  You can’t just follow the process and assume faster, higher quality software will be the inevitable result.

I’m not anti-Scrum per se, but I am very much anti-making Scrum the new Waterfall.  Don’t stress about your process.  Don’t stress about the integrity of your process.  Think about your actual goals for your team and constantly correct your course to get there.  Change often.  Improve constantly.  There is no textbook procedure that will guarantee a cornucopia of agility just by virtue of being implemented.

Dec 072011
Armlock shown is a straight arm bar (juji-gatame)

Image via Wikipedia

I practiced several different martial arts in my lifetime before finding a home in silat, and one thing that came up in virtually all of them was how joint locks work, which is kind of a fascinating study of the way people react.

A joint lock basically involves bending someone’s joints in a way that they’re not supposed to go or to a degree they were never meant to bend, such as the infamous “chicken wing” with the arm bent up behind the back, or the “gooseneck” with the elbow immobilized and the wrist pulled down. This creates pain and a degree of immobility in your opponent, hence the “lock.”

Here’s the funny part: almost any lock can be escaped relatively easily, and the vast majority of them can be reversed – locking the locker – without much more trouble.  A joint lock works because, when a person feels that pressure and pain, they think, “Crap, I’m locked,” and generally struggle against the locking pressure, which generally just makes the pain worse. They don’t think of a way they can move that would relieve that pressure; they become fixated on trying to push or pull their way out of it.

In essence, people lock themselves; the person executing the lock has just created the circumstances that allow you to lock yourself.

Across the wide world of software development, developers and their clients have locked themselves.

We have all assumed that giving an up front time and cost estimate for a project is the only way to measure progress, control cost, and compare companies.

We have all assumed that we have to get all our requirements before we begin work.

We have all assumed that testing and debugging is something you do after completion.

We have all assumed that deadlines have inherent value and meaning, even if there’s no business rules driving it.

As a result, we have come to accept that changes are painful and expensive, projects will virtually always miss deadlines (or require a lot of overtime crunch to get them done on time), and that every release will have bugs.

We don’t stop to think about ways we might move to relieve these pressures – we just push and pull against them, accepting the “reality” that we are locked into this way of thinking and doing things. This is just the way you do software development. Estimate – Requirements – Design – Build – Test – Deploy.

Believe it or not, software does not have to be built in this way. This is not your only option. This is not the only workflow that makes sense. Missed deadlines, expensive changes, 12 hour work days the week before a release, and bug filled releases do not have to be just “how things are.”

The way you get out of a joint lock is by being relaxed, fluid, and moving with and around an opposing force. Folks: welcome to Agile.

Nov 302011
The Six Million Dollar Man

Image via Wikipedia

Read Part 1 here.

Problem 6: Lack of developer motivation to use agile methods

There are a few things that create this very real problem.

One is that many advocates for agile don’t fully understand the benefits, themselves. They may have a general idea of the benefits, but only in vague terms, so it makes for a hard sell.

I find this happens a lot with TDD advocates, for example. When developers complain about the extra effort in writing tests, they go, “Well, just think of all the time saved from debugging!” When the developers counter that debugging doesn’t take them as long as writing tests, or they could just as easily get the same benefit writing the tests after coding, these advocates have very little to say, because they didn’t really understand the value of the practice to begin with.

Another issue is inertia. You’d think that someone who voluntarily entered a career field that changes almost monthly would be up for constantly re-inventing themselves to be better, Six Million Dollar Man style. There are developers like this, and if you have them on your team, you should do whatever it takes to keep them.

Just as many developers, however, are highly resistant to change. Maybe it’s because they feel like their practices are the only thing they can control. Maybe it’s because Waterfall has been so pervasive, it’s become synonymous with “how to develop software.” Maybe they’ve had bad experiences (see Problem 0).

There’s not a lot you can do about people unwilling to change except get rid of them, but many developers can be open to change if you can make a really good case for it and put points on the scoreboard in your implementations of these methodologies. I’ve consistently had the experience of other developers wanting to join teams I’ve started agile implementations on, but you have to be familiar with the benefits, objections, and how to set people’s minds at ease regarding the things they fear about it.

Problem 7: Implications of devolved decision making

In other words, there are issues that come up when developers make their own decisions instead of being told what to do. According to the paper, one issue is “developers taking tasks that they shouldn’t.” I’m not entirely sure what that means, as I seriously doubt developers started trying to balance their department’s budget or started randomly firing team members. The paper doesn’t really explain it, either, so I can only guess that this probably came from managers who felt that developers should just be coding and doing as they’re told instead of actually communicating directly with business users and helping prioritize and implement what they asked for. In fact, the paper cites one manager as saying they had anxiety about losing their traditional power.

But the other concern was that project managers became uncertain of their role. To me, this is not a problem per se. It is a problem if you assume that you need project managers and they must fulfill their traditionally-defined role, because eventually, companies figure out that a team that’s cruising along under an agile process just doesn’t need a project manager in a traditional sense.

In these cases, a project manager in an agile environment can go a number of ways. What they do not need to do is stay on top of whether or not everyone is on schedule and continually get predicted end dates and revised predicted end dates. What they can start doing is facilitating coordination and communication between groups working on the project, chasing down impediments that are holding the project back, helping the team maintain their metrics tracking, and helping the organization coordinate their projects at a higher level.

Basically, this “problem” boils down to the fact that agile teams need less oversight, and a lot of people have built careers out of oversight.

Problem 8: The need for agile-compliant performance evaluation

The deal here is that agile teams coordinate and produce as a team. They succeed or fail as a team. Individual contributions sort of become subsumed into the team’s overall output – kind of like “group projects” in school where you were graded as a team.

This can be a problem when most companies evaluate performance at an individual level. If I’m a senior developer, and I spend virtually all my time pairing up with junior developers to help them, doing code reviews, etc. to keep the project moving along, and a junior developer is just slamming out code getting tasks done, how do you evaluate these things against each other or even know that they occurred?

There’s not really an easy answer for this.

One is to incorporate team feedback into the evaluation process. Have the team members evaluate each other and use that as a tool in the overall performance evaluation.

But one thing that struck me in the paper is that it seems like managers knew who was contributing and who wasn’t. A case cited was that there was a developer who got passed over for promotion because he churned out very little code. He spent most of his time mentoring developers on the team, and he felt that wasn’t being rewarded and, according to the paper, “as his manager, I had to agree.”


So, as his manager, you knew he was providing  great value to the team that deserved reward and you… did… what?

I’ve told organizations before that most of the “problems” that surface when trying agile for the first time are often organizational problems that have always been there, but have been obscured by the current process.

Problem 9: Lack of agile-specific recruitment policies and suitably trained IT graduates

The “suitably trained” part, I agree with. This is an ongoing problem with educational institutions that have people teaching who haven’t been active in the work force for years and, in some cases, have never been in the work force (EDITOR’S NOTE: This is especially true of private “technical training” companies, most of whom would be totally depopulated if they had to fire all the instructors who had no real work experience in their field outside of their own side projects.). Often, educators are not up on current practices, market trends, or even their own industry standards.

I once went over the official CIW courseware and, in the first manual alone, generated a 28k plain text file full of errors. This was a certifying agency writing this curriculum. So, yeah, I get it, and I don’t really know what to do about it as long as people keep hiring with low standards.

The recruitment policies are a different story. As part of the interview, there’s no reason why you can’t ask people about their experiences with agile practices, their thoughts on various agile issues, and examples of their own practice. There’s no reason why you can’t have them solve a simple coding problem as part of your hiring process. Heck, pull a ThoughtWorks and bring your primary candidates in to pair up with one of your programmers for a day and see how it goes.

However you do it, there are all kinds of things you can do to get a feel for someone’s “agility.”

In summary, I’m not trying to say there are no problems implementing agile processes. I’ve done this too long to think that. I have no stars in my eyes. Agile and I are past our honeymoon and have now engaged in the much less romantic process of trying to make life work, together.

However, these challenges are navigable, the benefits are worth it, and I think you’ll find that some of these “problems” are actually strengths once you get over the initial discomfort.

Nov 292011
TALLADEGA, AL - OCTOBER 30:  Ron Hornaday Jr.,...

Image by Getty Images via @daylife

A group of people smarter than I am put together a great little research paper on the top nine problems that companies experience with Agile processes and some suggested solutions. It’s short and very readable, so I highly recommend it.

It’s a good reminder to all would-be Agile pundits (like myself) that the real world is not a book or a blog article and that there can be a difference from what should work and what does work.

I’d like to offer a little of my own comments on the problems outlined in the paper, starting with the first five in this post, and I’m going to start with one that isn’t in the paper but is probably a contributing factor to all of them.

Problem 0: Nobody knows what the heck they’re doing.

I can’t tell you how many companies and teams I’m personally acquainted with who have read about all kinds of agile practices, decide to try it, screw it up beyond all recognition, and declare agile too problematic. Most companies “go agile” in roughly the same fashion that I “go breakdancing” – we all have a picture in our head of what’s supposed to happen, but the odds are pretty good the whole endeavor will end in embarrassment, injury, and property damage.

If you are interested in giving agile a go, please get someone to help mentor your team/organization through the process – someone who has experienced the difficulties and knows how to see you through in practical ways.

Problem 1: Developer fear caused by transparency of skill deficiencies

After several agile implementations of my own, I’d actually just make this problem straight up, “Fear caused by transparency,” because I’ve seen way more managers be afraid of the transparency agility brings than developers.

It all comes down to whether or not you prefer to make your business decisions based on ugly reality or beautiful illusion.

That aside, a lot of this fear comes from developers personalizing issues that really aren’t personal – they’re team issues and need to be tackled as a team. If, in the process, we all learn that Cathy is a better developer than Joe, well, suck it up, Joe. People are better than you at stuff. Deal with it.

Sometimes, the answer to agile “problems” is just for everyone to put their Man Pants on.

Problem 2: The need for developers to be a “master of all trades”

I guess this presupposes that developers are currently masters of one trade, but I digress.

There is a sense in which, on an agile team, developers can find themselves working outside their “niche,” but that’s sort of why you have a team. If you aren’t strong in writing tests, then you lean over to the guy or gal who is and ask them for help or a code review. Rely on the expertise of other people on your team – something which should not be an undue burden on them if you are doing the entire project in an agile fashion.

Problem 3: Increased reliance on social skills

*gasp* Developers now have to interact with other human beings, sometimes in person!

Yes, it’s true. Agile forces developers to crawl out from under their pile of empty Cheetos bags and Mountain Dew cans, take all their Babylon 5 t-shirts to the laundry, and keep the anime references to a minimum in casual conversation.

I realize this is uncomfortable for certain developer archetypes. They like staying in their cave dealing with machines instead of other people. Working together on a team or interacting with users are right up there with rolling around naked in a room full of thumbtacks followed by an iodine shower.

Not everyone needs to be a master communicator, though, and I’m pretty sure most companies don’t expect developers to be that. Working with people and speaking their language, however, is something that will help everyone in the long run, as uncomfortable as it might be at first.

Problem 4: A lack of business knowledge among developers

Unlike some of the other problems which are just going to happen as a result of the process, this problem has all the signs of Doing It Wrong.

Of course developers don’t understand your business. That’s why you put the feature list together… um… together. That’s why you tell them about priorities and they tell you about relative effort. That’s why developers talk through feature details with you instead of trying to work off a requirements document. That’s why they have you go over their stuff on a regular basis.

Incidentally, this is also why trying to offshore agile projects can be a Sisyphian task.

To me, this problem reeks of trying to do a few things in an “agile” manner in the context of a very Waterfallish way of doing projects.

Problem 5: The need to understand and learn values and principles of agile, not just the practices

True, understanding why you’re doing what you’re doing is a serious problem. Oh, wait.  No, it’s not.

Understanding agile principles and values is way, way more important than understanding specific practices.

I practice martial arts, and you can always tell the difference between someone who knows how to fight and someone who doesn’t. The first person understands the principles that work, the second person has memorized a lot of techniques. Combat is about as agile a process as you can get, and the person who knows principles can adapt to changes with lightning speed; the person who knows techniques finds themselves stalled and frustrated when the reality of fighting doesn’t seem to match up with the controlled sequence of events they’ve been drilling.

The truth is that you need both. Principles without effective execution are useless. But the person who understands agile principles can work in a wide variety of environments, constraints, practices, and tools. A person who has learned a list of “agile practices” is going to struggle in the trenches.

Read Part 2 here.

Nov 182011

Image by janek030 via Flickr

This post is mostly a notepad for myself for a series of posts I’d like to do over time. I want to take an application – real or hypothetical – and go through the process of building it out, starting with requirements and going through the first release, or at least the first feature.

What follows is a list of the steps I typically follow in an ideal development process:

  1. Developers meet with users/stakeholders to create list of features, including business reason for each requested feature. Developers relatively size features. Stakeholders prioritize at least the first seven to ten features.
  2. Features go up on a Kanban-style board in priority order.
  3. Devs get any necessary details about first feature from stakeholders. Document where helpful.
  4. Devs break feature into small tasks.
  5. Devs write acceptance tests in plain English that define when the feature will be done. Use acceptance tests to ask stakeholders if they’ve missed or misunderstood anything. Can be done in conjunction with QA testers if you have them.
  6. Build UI around making first acceptance test pass. Ask stakeholder to look at UI and confirm you’re on the right track.
  7. Write unit test(s) around first bit of code to make UI “work” for the first feature. Tests should define what that layer of code needs to do to support feature.
  8. Write code to make test pass.
  9. Write unit test around layer of code to make previous layer of code work.
  10. Write code to make test pass. Repeat this process until all tests pass for your feature.
  11. Get stakeholder to review what’s been done and suggest changes if necessary.
  12. Measure time feature spends in each Kanban column. Use this data to project timeline for other features.
  13. Repeat steps from “get any necessary details” for next prioritized feature.
  14. Release/deploy as often as you possibly can without being stupid.
Oct 062011

What most of you don’t know about me is that I love to make advertisements.  I was heavily inspired by the movie “Crazy People,” and I try to bring that same and much-needed philosophy to my own marketing materials.  No one ever uses the advertisements I make, but I love it.

Not too long ago, I made a couple of advertisements for The AdventureTech Group using statements that people made during our meeting with Sean Stormes, and I wanted to share them with you, because I’m a huge egotist.


This ad reflects the fact that a truly agile development team transfers control of the project to the business.  The business decides the features.  The business sets the priorities.  The business provides regular feedback.  The business can make most changes at will with no effect to the timeline.  The business has 100% visibility into the work flow.  The business has accurate project timelines.

Some businesses don’t want this.  They’d rather just give a firm money and have them go away and never bother them until the project’s done.  That’s fine; that’s just not the kinds of clients we can work with very easily.


This one is just self-explanatory.