Agile Project Planning

ExtremePlanner: Agile Project Management for Distributed Software Teams
Click For Your Free Online Trial

Saturday, December 31, 2005

How to Make Customers Unhappy on an Agile Software Project

Sometimes your customers get grumpy. This makes them do unfortunate things like canceling your projects, refusing to pay you, or just not smiling when they bump into you in the halls. This isn't because they're mean people. It's often because we do things that make them grumpy, even on agile projects.

But how could this be? You've invited them onsite, given them free access to your development cubicles, and forced them to attend all of your design meetings? What could be better?

Turns out that the best onsite customers are actually good at their day jobs, which means they are actually needed at them much of the time. So as much as they're excited about participating on the team, reality keeps intruding. They can't spend very much time sitting around, waiting to be pestered by developers.

So what's an agile software team to do? Don't you need an onsite customer to make things go smoothly?

The reality is that sometimes you can't have a dedicated customer onsite at all times. Questions about which way to take Feature X might have to wait a few hours, or even a few days while you compose an email or schedule a conference call to discuss.

But ever the optimists, you plunge ahead, hopeful that the reduced communication won't create any problems. And it doesn't, until your very next software delivery.

"What happened to the Whatsit component that was supposed to be here?" asks your Customer. "We talked about this a month ago! And what is this new Easter Egg in the upper left hand corner - that's unacceptable!"

"I told you so!" says the ever helpful Tactless Tester, lurking just behind your chair. "You developers wouldn't listen to me, and now you've messed it up good!"

OK, something is clearly wrong with this situation. And it's not just that annoying tester who likes to humiliate you in public. What could it be?

Aha, you think, no one bothered to communicate with the customer before delivery of the software. Planning went well, and the priorities were pretty clear a couple of months ago. But then development started, the team wanted to use the new Insta-egg(TM) Easter Egg Maker, and decided that the customer was just mistaken when they said they needed a Whatsit.

Your problems started well before the Egg Incident. The moment the team took control over what features to build and disregarded the customer should have been a warning sign. It got worse when you didn't have any regular communication with the customer until delivery, a few months later.

Even well-run agile teams can make this mistake when the customer is not frequently available. Complacency sets in when you think you know the customer well enough to decide things for them. And you get burned by adding things you thought would be well received, and leaving out things you didn't really want to build and thought were a bad idea. Uh, whose money are you spending, anyway?

One strategy for keeping your team in check is to have regular status meetings, at least every few weeks (probably at the end of each iteration), where you communicate with your customer about progress. Not with a Powerpoint presentation or pyrotechnics, but a simple demonstration of working features since the last meeting.

This will keep your customer engaged, even if they're offsite (Web and telephone conferencing can work pretty well in this situation). There's nothing like working features to elicit clear feedback on what's right and what's wrong. And it just might keep your team from committing project suicide.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Sunday, December 18, 2005

How J2EE Killed Object-oriented Programming

First off, let me say that I've been using Java and J2EE technologies since 1996. I'm a fan. But the combination of Web technologies and EJB components threatens to squeeze the last vestiges of OO out of enterprise Java development.

"Come on, you're overstating the case," I can already hear you saying. But am I? Consider this: a state of the art enterprise architecture for a basic Java web-based application typically consists of:
  • A business services layer, consisting of a collection of procedural methods. Things like "transferBalance( AccountVO, AmountVO)" are the norm. These are often session beans, and they have more in common with database stored procedures than those polymorphic, data hiding, inheritance-loving mixtures of data and behavior of yesteryear.
  • An object-relational mapping layer, either Entity Beans, Hibernate, or a custom Data Access Object layer. Again, not much in the way of first class objects, these are really just mechanisms for mapping to the database. They are often auto-generated, and rarely exhibit any significant behavior. You know, the non-data part of OOP.
  • A presentation layer, usually some sort of MVC framework like Struts. Wait, there might be some objects here...except for the lack of reusability, portability, and the exposure of implementation details of the Web environment like HttpSession objects. Objects in name, but not in spirit.
  • A whole bunch of Value Objects - data structures with getters and setters that do nothing else.
  • And with the advent of AJAX, there's even less componentization, as bits of JavaScript make a play for first-class status in the development stack.
Now, to be fair, there are some technologies such as the Spring framework, maybe Tapestry, that encourage traditional OO development instead of exposing implementation details all over the show. And yes, Hibernate and EJB 3.0 might improve the "objectness" of domain objects a little bit.

But for many Java developers, their world is a sea of acronyms, frameworks, and layers that have nary a classic Object in sight. What ever happened to "smart" objects that actually did something useful, had interesting behavior, and didn't expose their implementation details to the whole world?

So whose fault is this, you ask? It's a bit like a frog being boiled, I'm afraid. These "best practices" and "patterns" in the J2EE space have slowly moved us from skilled objected-oriented developers to code-generating, 20-minute-Ant-build-running, WAR-file-deploying shells of humanity, desperate for a real object to sink our teeth into.

But maybe these practices are the right way, and OOP was overrated? Maybe, but something smells funny about that. Are we any more productive than we were 5 years ago when the bulk of Java enterprise technologies came on the scene? Is it easier to write applications in Java? Are they more maintainable than a few years back?

I'm not saying Java stinks, it's not the language or the platform that's the problem here. There are plenty of tools in the tool bucket to create robust, scalable, and performant applications in "classic" object-oriented fashion.

But I fear that the last 5 years has produced a pile of brittle, over-engineered applications whose internals are exposed. Today's J2EE applications might look a lot like yesterday's procedural COBOL applications that were so derided by upstart Java developers 10 years ago.

The way forward is to go backwards to the first principles of development. Keep it simple. Don't repeat yourself. Don't build complexity you're not sure you'll need. Don't expose implementation details outside the components that rely on them. Patterns are not how-to guides, they're just documentation of things that occur in the wild, along with the forces and consequences of their existence.

This isn't about attacking Java or Java developers - the same can be said for .Net, PHP, Perl, and a whole host of other approaches. It is a challenge to creators of the next generation of applications, frameworks, and tools. We can do better. It's time to start.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Wednesday, December 07, 2005

Crossing the Agile Chasm

With companies like Yahoo and Microsoft embracing agile processes like Scrum and XP, maybe Agile is finally crossing the chasm between early adopters and the mainstream development world.

Geoffrey Moore's classic about technology adoptions cycles suggests that after the hype from enthusiastic early adopters, there is a lull or even a backlash while the mainstream decides whether the technology fits into existing business practices.

For agile methods, this suggests that the way forward isn't revolutionary change. Early adopters are usually looking to shake things up, but mainstream users are looking to apply technology to improve current practices.

There is some recent evidence of this, with large companies like Microsoft embracing agile methods (Scrum in particular). Perhaps the project management focus and less prescriptive practices of Scrum were the tipping point. XP has been more of the "radical" method, with practice like "pair programming" often the source of controversy.

So what's next? Will IBM Global Services start singing the praises of XP? Not likely. From a process standpoint, IBM could be what Moore's book calls a "laggard" - they'll wait until everyone else has been using the methods successfully for a decade or so before adopting it.

This is an interesting time for those of us who have been using agile methods since the early days. Now that the early majority seems to be catching on, I'd expect to see use of agile techniques as a commonplace thing, no longer newsworthy or remarkable.

One possible side effect of the "mainstreaming" of Agile is that the more radical elements may be jettisoned as corporations assimilate the new ideas into their existing practices.

But isn't that what agility is all about? Experiment, adapt, repeat? Whether the original spirit and ideas of the early methods persist remains to be seen. I'd like to think that the best ideas will flourish and be enhanced, while the weaker concepts will fade away.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams

Thursday, December 01, 2005

Agile Requirements Gathering is Not Just About Stories

Just read a good article by James Shore on what he calls Agile Requirements Collaboration.

In it, he talks about the use and misuse of Story Cards to capture requirements. To sum up, Story Cards are not 3x5 requirements documents. They are placeholders for a more detailed discussion about the business requirements.

But how and where are these requirements ultimately captured? According to XP literature, this is the role of the Acceptance Test. A Story has one or more Acceptance Tests, created by the stakeholders, that define the correct behavior from their viewpoint. Ideally, these can be automated.

I've seen a lot of discussion on Unit Testing, Test-driven Development (TDD), and other developer-oriented testing, but there is a much smaller body of work for what is arguably a much more important activity - Acceptance testing. This is the Agile equivalent of a functional specification, regression test suite, requirements document and safety net all rolled into one.

Why are acceptance tests so important? There isn't any other artifact in an Agile process that captures the details of a Story in an unambiguous way. It's a way of recording customer intentions and decisions for posterity. Unit tests are great for module level verification of code, but they don't address business functionality. How do I know if I'm breaking an important feature if I don't know how the end-users are using it?

Part of the discussion in the James Shore article is around FIT (Framework for Integrated Test) as a tool for facilitating the creation of these tests. FIT supports documents in HTML (that can be written using Word, for example) with a mix of prose and test tables. The idea is that you can wind up with an human-readable specification, created by customers, along with an executable set of test examples in table form. Programmers then write test fixtures to make the tables run and pass or fail.

This stuff isn't exactly new, but in many of the organizations I've worked with, very little of this is going on in practice. In organizations with QA teams, some acceptance testing occurs naturally, but is still not entirely from the customer viewpoint, it's from a tester's perspective. Stakeholders often don't see creating acceptance tests as part of their job - "What are we paying you developers for?"

The idea of FIT is to remove some of those objections by making test creation easier, instead of making customers work harder. As more tools like FIT become available, they can only help improve the outcomes of Agile projects.

And as practitioners, we need to remember the fundamentals: Discover, Design, Implement, Verify, Repeat. The "verify" part isn't just at the code level, it has to be at the business level too.

For more on agile tools and techniques:

Get your copy of the new book! Agile Thinking: Leading Successful Software Project and Teams