Agile Project Planning

Why Duplicating Effort on Software Projects Could be a Good Thing

2008-12-24T14:17:00.000-08:00

So one thing I never hear software people complaining about would be "We have too many people and too much money for this project."

In fact, this situation actually occurs more than you would think in venture funded companies. Once a small startup gets an infusion of cash, the expectation is that they will build out their services to a larger scale, hire more employees to do that, and become a huge success or die trying.

But as we think about the constraints of resources, time, and scope, what is the Agile approach when time and scope are fixed, but resources are not? What should a newly funded startup do to maximize their chances of success over a fixed timeframe?

One option that is rarely talked about (and I admit, possibly because it's not such a good idea) is to run parallel development efforts. This would mean duplicating effort, but also getting a couple of chances to innovate and create a better product.

For example, if you set out to build the next great social networking platform, how can you make it better, cooler, and more compelling? Possibly by creating two or even more teams within your company, and having them try different approaches.

Sound like madness? Maybe, but here are some possible benefits:

1. You'll probably get good ideas from one team that the other didn't think of
2. You'll probably get a better *implementation* of the same idea from one team than the others
3. With more teams, the chances of one coming up with a breakthrough idea is much higher.
4. There's nothing like a little healthy competition to get some serious productivity, creativity, and execution rolling. It's a powerful motivator.
5. You'll get the opportunity to use pieces from each team's effort to make an exponentially better product (not necessarily the code, but certainly the design concepts).

In a sense, this happened at Microsoft back in the 90s when Windows 95 was being created at the same time as Windows NT. The teams liberally "borrowed" ideas from each other, and both products wound up better off as a result.

There are some obvious challenges to this kind of approach - namely what to do with "losing" teams, and the effect of competition on company culture and harmony. But even applied in the small, this approach could have an impact.

Imagine if you applied this concept to specific features rather than a whole product. Maybe take just a week, and have 2 or 3 pairs or individuals flesh out ideas on the feature, then see how it plays out.

I can't imagine this would work in all kinds of situations, but in a venture funded startup looking to become the next big thing, it might be the simplest thing that could possibly work when resources are plentiful.

The End of Agility?

2008-08-07T12:38:00.001-07:00

So now that Agile software development, Scrum, Extreme Programming, and Lean thinking are all the rage, I have to wonder - is this where we thought it would all end up?

This puts me in mind of the early days of object-oriented programming, when Grady Booch first started drawing diagrams with fluffy clouds. It took about 5 years from the grassroots movement of developers finding that sort of modeling useful, to the Rational Unified Process being created, then mandated by organizations as best practice.

I see the same trend, for better or worse, with Agile methods. We now have certifications, big industry conferences, specialized tools and software (yes, my company included), consultants, trainers, and a few dozen books to help guide a fledgling agilist along the way.

Perhaps less encouraging, I also see more of a trend of mandates from upper management to the development organization that sound a bit like "We will use Scrum, whether you like it or not".

It's been about 10 years now since Agile methods (Scrum, XP, etc.) first took the stage. Ten years is usually about right for maturing a product, but what about an industry? Have we reached the peak of agility in organizations and the state of the practice?

If history is any indicator, the environment is ripe for the "next revolution". As the song goes, "Meet the new boss...same as the old boss".

Agile Project Collaboration and Restaurants

2008-03-12T14:20:00.000-07:00

The software development world keeps trying to come up with good metaphors for what a software project is like. "It's like building a bridge", some say, or "Like manufacturing a car", others say.

I think a much better analogy, especially for the dynamic between the customer and the development team, is ordering food at a restaurant.

As a customer, you know what kind of food you like, how hungry you are, and you might have something in mind to impress your date, whether it's your wife, a client, or your boss.

As a chef, you know what makes food taste good, what the best way to combine ingredients is, how quickly your staff can make a certain meal, what foods are freshest, and how much things cost to get.

Naturally, as restaurant customers, we tend to order what's on the menu, which the chef has thoughfully specified in advance. This would be analagous to certain types of systems that a software team has written before, or are available as an off-the-shelf component (e.g. a blog, user forum, poll, etc.).

If some software customers used the same approach in a restaurant as they did in trying to get systems developed, the converstation might go like this:

Customer: I'd like some chicken, but it needs to be the size of a turkey, and I want it to taste like beef. Don't make it too salty, and it should cost less than a can of tuna. Oh, and can that be cooked in 3 minutes?

Chef: Well, the largest chickens known to man are slightly smaller than a turkey, we could get you that, but they don't taste like beef. We could add some beef sauce, but it won't taste very good. Extra-large chickens cost double what normal chickens do, and take at least 20 minutes to bake. I guess we could chop it into tiny pieces and deep fry it in 3 minutes, but it won't look or taste good. Sorry, but it will cost you about 10 dollars for this, a can of tuna is 60 cents.

Customer: You incompetent fool! If you can't handle this, I'll find a chef who can! My 12-year old nephew cooks all the time, and he can make eggs in 3 minutes flat, and they're really cheap, too. A chicken is just a grown-up egg, right? Why can't you do better than my nephew with all of your experience and training? Are you trying to cheat me???

Sound familiar?

Now this might seem silly in a conversation about food, surely a chef knows more about how to best prepare something that we might like. A more typical request in a "made to order" restaurant might be:

Customer: I really like chicken, but not spicy or with heavy sauce. And I'm watching my health, so too much grease or salt is a problem. Can you make me something tasty?

Chef: Of course: I could make a fresh tomato and spinach pesto chicken with boneless, skinless chicken breast with a fabulous balsamic reduction that just hits the spot.

So what's the problem in software? Is it really that hard to express requirements and constraints, and to let the experts suggest options and approaches?

The main issue as I see it is a question of trust. In a restaurant, you'll know in about 20 minutes if the chef understands your needs and can deliver something tasty. If it works out, you'll gain trust, and certainly you'll want to order from him again.

In traditional software, it can take a lot longer than 20 minutes, or even 20 weeks to see the first results. If the outcome isn't pretty close to what you talked about, trust goes down, fear goes up, and you wind up with some serious issues.

Agile software approaches to project planning and collaboration operate more like the restaurant. Order something, try it, maybe ask for less salt or more cream next time, and repeat.

Before long, you'll develop a great rapport between development team and customer, and you can start talking about what's for dessert.

Agile Thinking Book now available

2008-02-25T20:36:00.000-08:00

Well, my new book is finally ready. It's called Agile Thinking: Leading Successful Software Projects and Teams.

It's a collection of over 40 articles that I've written over the past few years (many on this blog), organized by theme, and reworked and edited for a book format. Hard to believe how much work that turned out to be.

Regular readers of this blog will see a lot of familiar themes and content, and there is an all new introductory chapter that explains Agile methods in down to earth terms - maybe something to get your boss or new team member engaged.

What I really like about how it came out is that you can read it either sequentially, or just pick a random article when you've got only a few minutes to spare. You might not agree with everything in the book, but I think you'll find some useful ideas, some inspiration, and maybe even something that challenges your current perspective.

Have a look at the preview, and get your copy while it's hot (with on-demand printing, it might actually BE a little warm).

Agile Thinking

2007-12-21T10:52:00.000-08:00

In case you're wondering why it's been so long since my last post, there's actually a good reason.

I've been working on putting together a book that distills the stuff I've been writing about for the last three years into a coherent form. The working title is "Agile Thinking".

My wife is a professional editor, so we've been busy cleaning up, cutting down, and rewriting some of the better posts from here, along with some other articles I've written, and organizing them by theme. The goal is to create a guide for real-world Agile project managers, developers, and customers to better understand, challenge, and improve their process.

Hopefully it will be ready sometime in January.

Agile Open California: Wide Open Spaces

2007-09-21T11:34:00.000-07:00

About a year ago I participated in my first Open Space conference in Portland.

The idea of Open Space is that instead of a canned set of speakers and topics, the participants propose their own topics on the first day, and people vote with their feet in terms of which topics sound most compelling.

The Portland conference was the best conference I've ever attended. Imagine, always being engaged in a topic that you're interested in, rather than listening to yet another boring speaker with too many Powerpoint slides.

Open Space is about participation, and that makes it incredibly powerful. The combined intellect, ideas, and passion of a group of people can make for huge opportunities to learn and to share.

So now I'm a volunteer on the organizing committee for Agile Open California, which is coming up on October 22nd and 23rd in San Francisco, CA.

It's coming together quickly, and I'm getting excited about another opportunity to mingle, learn, and share with the Agile software development community.

If you're looking for a stimulating learning opportunity, check out the conference website here

Is Group Brainstorming Hurting Creativity?

2007-07-31T12:11:00.001-07:00

Marc Andressen writes about research that shows that group brainstorming produces fewer and lower quality solutions that "virtual" brainstorming where indviduals generate ideas independently, then put their results together.

One way to look at this is that brainstorming sessions with everyone in the same room trying to "be creative" at the same time might not be the most effective approach.

Applied to software development, the implication is that limiting creativity to "groupthink" can have a negative impact on the outcome. Teams may be more creative through harnessing individual expression.

In my own experience, I find that a healthy dose of conflict (with appropriate respect for others), leads to better solutions than friction-less agreement and watered down consensus.

Put differently, if everyone agrees that your idea is the clear way to go, you might have a problem.

Agile Project Management: What's In It For The Customers?

2007-07-24T14:38:00.000-07:00

One question I'm asked frequently is how Agile project management is different from traditional project management.

Normally I start talking about iterations, planning, user stories, and the like, but I get a decent number of blank stares in response.

I like to think I'm pretty good at explaining things, so I tried to figure out what was missing from my description. Is it the terminology? Do I need more examples? Is this something that non-techies just can't comprehend?

Then it hit me - like all other concepts, products, or services, Agile project management needs to be explained in terms of it's benefits, not it's attributes. The real question people were asking me was "How will this benefit me?", not "How does it work?"

So without further ado, here are the benefits of Agile project management for software teams in customer terms:

1. More Requirements Flexibility (Ability to Undo Screw ups) - because of the quick development cycles that produce working software, an agile approach keeps mistakes shallow, and let's you correct your mistakes or in company political terminology "refine your solution".

2. Reduced Project Risk (No Need to Explain Lengthy Delays and Cost Overruns) - because of the frequent planning and estimating sessions (at least once per month), you'll know very quickly if the project is off schedule, and you'll have control over what to do to get it back on. This leads to better predictability, less embarrassment, and happier stakeholders.

3. Transparent Project Management (Trust, But Verify) - having visibility into which features (stories) are being worked on, and being able to actually use the software after each iteration means that you can verify progress instead of relying on a set of lines on a Gantt chart. This helps with both internal teams and outside consultants.

4. Early Delivery of Value (Can I Have That Now?) - because Agile projects deliver the most important things first, you can decide to deploy a system much earlier than planned if business circumstances dictate that. Sometimes there is enough value in the top 10 features that the remaining 100 can wait. And delivering value is sort of the point of most of our jobs, after all.

Latest Carnival of the Agilists is up

2007-06-23T13:29:00.000-07:00

The latest Carnival of the Agilists is up.

If you haven't seen of these before, it's a collection of links to essays, blog entries and resources on various topics from some of the best minds in the Agile software development community.

The editor rotates, so there's always a fresh perspective on what's worth reading.

The High Cost of Management Indecision

2007-06-07T11:32:00.000-07:00

Rob Walling writes about the high cost of management indecision on software projects.

Essentially, the argument is that even wrong decisions allow developers to keep momentum and push a project forward. The cost of reworking areas winds up being less than the cost of delaying, doing nothing, or switching to other tasks. Here's an excerpt about the cost for a team of 10 developers:

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week. Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That's a difference of $6,540 per week.

It's actually a pretty powerful argument for doing everything possible to lower the perceived cost of making a decision for managers or customers. Perceived cost is that fear-driven idea that if you make a certain decision, you'll be stuck with the results forever if it doesn't work out, due to the high cost of changing it.

This is exactly the problem that Agile methods were designed to solve. By reducing the perceived cost, we encourage our customers to make more timely decisions, learn from them, and adjust as needed without incurring high costs.

Of course, this doesn't necessarily apply to technical decision making. "Should I use a database or direct file storage?" is a question that doesn't need a final answer right now. The right question for technical decision points is "How can I encapsulate that?" That lets developers move forward while keeping the cost of future change low.

If it truly does cost more to delay management decisions, wouldn't it be wonderfully freeing to start making some?

Even if you don't have all the possible information you'd like?

Even if you could be wrong?

Scrum Reference Card

2007-06-06T11:13:00.001-07:00

Ran across a useful (and free) quick reference PDF for the Scrum Agile method for managing software projects.

Scrum has really gained some momentum over the last few years, perhaps in part from the now ubiqiutous certification program (Certified Scrum Master). It's a deceptively simple framework for Agile project management, consisting mainly of a few rules around creating a product backlog, priotizing work into 30 day "sprints" or less, daily meetings or "scrums", self-organizing teams, and the key: inspecting and adapting continually to improve based on real-world feedback.

Anyway, here's the link, courtesty of Contrado in Australia:

Scrum Reference Card PDF

Agile Variations for Distributed Software Teams

2007-05-23T16:48:00.000-07:00

So you've read the latest article or book on Agile methods, and go forth eagerly to implement them in your organization.

One little problem: your team is distributed, but all of the books you've read mention something about "co-location". That's another word for "together", meaning everyone on the project is in the same place: customers, developers, product owners, testers, documenters, and even those guys who make boxes to put software in if you like that sort of thing.

What's an aspiring Agilist to do when the team isn't together?

First off, let's define "not together". There are three main types of distributed teams, each with its own unique challenges:

1. Type A: All developers are together, all customers are remote
2. Type B: Multiple development teams in different locations (but each team is together)
3. Type C: "Virtual" team where nearly everyone works remotely (e.g. from home, in various offices, etc.)

OK, now that we understand the different types, let's look at the challenges each one has, and how we can tackle them.

Type A projects (all developers together, remote customer) generally have to be aware of getting out of touch with the customer. Out of sight can mean out of mind. This is especially true on an outsourced project, where the customer might only be interested in talking once a month or so.

The biggest risk for Type A projects is that the team starts making major decisions without input from the customer, which can lead to software that is not aligned with the customer's needs. Going back to basic Agile principles, we decide that freqeuent communication is the best way to deal with this. A daily meeting to quickly disucss progress, obstacles, and goals for the day might be just the ticket.

But having a daily call might not be enough. How do we handle those little decisions that need to be made all day long? If you're building a blogging system and the customer asks for a way to schedule new posts for the future, did they want them to autopublish or just have a reminder sent? A remote team might build in support for both, just in case. An Agile team needs to ask the question, and only build what is needed for now, not waste the customer's money on a guess. So alternative communications channels become important. Instant messaging clients, email, and message boards can be good informal channels for extra communication throughout the day if phone calls aren't feasible.

On to Type B projects (multiple dev teams in different locations). Here, the main issue is that each team may be highly functionial, but may have trouble communicating well with the other development teams. An example would be an in house IT team working with an outsource vendor. Again, frequent communication is important, as with Type A projects, but there is usually something very simple that can dramatically improve working relationships. Ready for it?

Type B teams should all meet in person at the beginning of the project. As in physical proximity, having a beer or soda together, chatting about hobbies, technology, or which breed of cat is superior.

Why is a face to face so important? Without it, human nature drives us to an "us versus them" mentality, also known as "those guys in Nebraska screwed up again" (I have no direct knowledge of any Nebraskan development disasters, this is just an example.)

Type B teams should also consider rotating a member of each team to spend time with another team on a monthly basis. Cross-pollination doesn't just work for bees, it can improve human endeavors as well.

On to Type C teams - the new "virtual workforce" we've been hearing about. Unlike the first two types, these folks never see anybody. This turns out to be strangely beneficial. Because everyone is on the same level, these individuals are either lonely and isolated, or pretty happy with their arrangement. We can influence the outcome towards the latter by setting up frequent communication and having an initial in-person meeting as with the first two types. Virtual teams can suffer from poor quality of communication though, and may need to supplement with group collaboration tools like shared whiteboards to supplement daily calls, emails, IM, etc.

For Agile afficionados enamored with pair programming (developers working on a task together), it's possible to setup virtual desktop and keyboard sharing (using VNC or similar software) along with an Internet phone line (e.g. Skype) to do this. Some folks acutally prefer the physical separation so that the after-effects of Joe's garlic pizza binge from the night before aren't quite so...awakening.

Having a "virtual water cooler" like a chat room can also help provide informal channels for team cohesion and bonding that can make a big difference in the final outcome of a project.

Overall, distributed teams aren't an ideal way to work, but given their reality, we can apply Agile principles to work effectively. Perhaps not as effectively as with a co-located team, but isn't the goal to do the best we can with what we've got?

How's your distributed team bridging the gap?

Agile Project Management and Competitive Advantage

2007-04-15T16:20:00.000-07:00

I wrote earlier about what I consider to be the core of why Agile methods work - small wins and increasing momemtum.

Now I'd like to offer a rationale for why anyone managing a software project should at least consider using an Agile approach for managing releases, if not for the actual development itself.

Turns out it's the same rationale as above - small wins.

The primary job of management is to ensure that customers are getting outstanding value (this makes them cheerfully continue as customers), while controlling costs, and reducing risks to the business.

In software development, value mostly takes the form of features - things that help the customer make more revenue, reduce costs, or increase productivity.

Of course, until the features are actually delivered, put into production, and leveraged by the customer, no value can be realized.

This means that your management won't know if they're doing their job until you've delivered software to someone, and they tell you it's solving the problem they had.

So if you put on your management hat, would you like to know this sooner or later?

Looking at the risk side of the equation, the more features that are in development for an extended time period, the higher the risk that customer needs will change. Not to mention technology, market conditions, company budgets, and leadership.

Now, there's obviously a limit to how frequently you can deliver value, isn't there?

Your customers couldn't handle a new release every month, right? What about every week? Shocking!

On the other hand, what if you delivered just one important feature that didn't break anything? Or that didn't require re-training, extensive documentation, tedious software installations, database migrations, follow-on patches, and numerous support calls to take advantage of?

What would your customers think then?

If software vendors (or internal IT development teams) could deliver incremental value whose benefit far exceeded the cost of upgrading, what might customers say about your company or team?

And if your competitors couldn't do this as effectively (for internal teams, your competitors are outsourcing firms), would your customers accept them as substitutes?

Agile methods aren't just about making your programmers happy, they're also about delighting your customers, saving your CEO's job, and mkaing your less agile competitors very unhappy.

Is Your Software Team Sticky?

2007-03-20T10:25:00.000-07:00

One of the most challenging things on a software project is making sure that the core ideas and vision of the system are well understood by all of the team members.

Without that shared vision, the team is likely to pull in different directions, even with frequent communication. Extreme Programming calls this "Metaphor", but I think that doesn't go far enough.

What's needed is something "sticky". Something easy to remember, logical, and simple that can form the basis of the little decisions that we make every day when creating software. A Prime Directive, if you will.

An example might help here.

Susie Songstress has a vision of a new website that will put singers and songwriters together to create beautiful music. She sees this as her life's work, and is dedicated to improving the world through music.

Susie hires a team of Agile software developers and explains her vision. They set to work brainstorming stories, asking Susie lots of questions, having her prioritize the work, and away they go.

Meanwhile, Susie goes to put on a concert to end hunger for a week, and asks the team to continue working. How can the team make good decisions while she's temporarily unavailable?

Susie leaves the team with a core message:

We help create the simplest, most effective forum for singers and songwriters to find and work with each other. We are an online Woodstock, dudes.

Armed with this core idea (which could be boiled down to "Online Woodstock, dudes"), the team is ready to make decisions with Susie in mind.

Their first challenge - Susie never mentioned what fields the registration page should have.

Fred, one of the developers, thinks all registration pages should ask for name, address, phone number, email, and birth date.

Ursula, an interaction designer, remembers Susie's message, and says: "If we were at Woodstock, dude, would we want to be hassled by the man for all this information?"

Fred says "Hmmm, I see what you mean - how about just a first name and an email address for now, with the other fields optional?"

OK, this is a bit contrived, but the point is that with the right core idea, teams can be empowered to make the best decisions they can when the customer is not available.

This is not a license to forgo conversations whenever possible with the customer, but it is a useful tool for embedding the project vision and values into as many people as possible, especially new or distributed team members.

How do you spread your vision?

Small Wins: Agile Psychology

2007-03-05T15:04:00.000-08:00

There are many theories as to why Agile methods work.

I'd like to suggest that a very small core element is responsible for much of the energy and ultimately the success of Agile development projects:

Small wins create momentum. Continous small wins create tremendous momentum.

OK, but what kinds of small wins are important in software projects?

How about early positive feedback from customers?

Or early clarification of an important feature (that leads positive feedback later)

Early detection and resolution of defects before they lead to not-so-positive feedback.

Early proof that you can build and deploy the software somewhere other than your own machine

These types of small wins have a subtle, but critical effect on everyone on the project team. Developers feel valued and are motivated to continue satisfying the customer. Customers feel heard and in control, and begin to develop trust for the development team. Stakeholders see regular progress, and begin to feel less anxious about project outcomes. Testers get an early look at the software, and are able to add value much earlier than in typical projects.

I went on a hike a few months ago that was basically an entirely uphill climb. There were no real twists or turns, just a straight incline. After about an hour on continuous climbing, I just gave up. This was partly because I was exhausted, but also because I had no idea how much further it was to the top. There were no clear indicators of progress, nothing to feel good about, just more turns of the road, and nothing but up to look forward to.

Similarly, software projects that offer no short-term wins can be depressing. Even the best team can feel unmotivated and lose steam when the project drags on and on without feedback, interim releases, or other signs of progress.

Agile methods promote frequent delivery and rapid feedback. For me, this isn't just a nice-to-have side effect, it's the only sustainable way to create great software.

Managing Distributed Software Teams

2007-02-16T15:10:00.000-08:00

There seems to be a growing trend towards distributed software development.

Maybe it's just me, but lately everyone I talk to is working on a software project with developers and customers in different parts of the country or the world.

In particular, there seem to be more people working at home, even in large corporate"environments. From the reports I've heard, it's actually working pretty well, with some obvious drawbacks like no group lunches.

So the big question is how a project manager can coordinate this kind of virtual team, separated by geography, time zones, and sometimes even oceans.

Here are a few strategies that I've used with my own teams:

Have developers pair up for remote design/coding sessions. Although "pair programming" is often derided, for a virtual team, it's important that there is regular communication between developers.
You can use tools like VNC to share a computer or presentation tool for scribbling designs, and tools like Skype for voice conferencing.

Make project information visible online. Agile software teams can use a web-based planning and tracking tool like ExtremePlanner to plan releases, track progress through iterations, and to see what everyone is working on.

Get together in-person periodically. There's no substitute for in-person communication. Ideally your team can meet at the start of a project to get at least a little initial bonding. It's much easier to maintain relationships if the team is already familiar with one another.

Meet daily. Communication is the life blood of a successful project. Run a brief, structured daily meeting where team members can say what they did yesterday, what they plan to do today, and what obstacles are in their way.

Use alternative communication channels. Outside of pairing sessions and daily meetings, encourage frequent informal communication. By phone, using instant messaging, blogs, wikis, or whatever helps the team share information more frequently.

Distributed Agile Teams in Action

2007-02-01T16:42:00.000-08:00

Apparently there are quite a few Agile distributed teams doing quite well.

I just got back from the Agile Open Northwest conference in Portland, Oregon. It was an Open Space event, so there were no pre-planned sessions or speakers, but it turned out to be one of the best events I've ever been to. Many of the pioneers of the Agile movement were in attendance, along with over a hundred interested and energetic practitioners.

Back to the point.

I facilitated a session on Distributed Agile Development, where I wanted to hear what people were doing in situations with:

Distributed Customers (customers not co-located with developers)

Distributed Development Teams (more than one development team, each in a different location)

Dispersed Teams (no one on the team is in the same location)

The resulting discussion was very enlightening. Not only were people doing all three of the above, but they were making it work. We uncovered some general principles that attendees pointed to as critical in making a distributed effort successful.

Build Trust Early
There was wide consensus that personal connections were the most important piece to building trust. An initial investment in travel to get everyone on the team together to meet in person, learn a little about each other, and to start to bond seemed to be the critical step.

Maintain Regular Communications
Once the team had formed some initial connection, the next insight was maintaining that connection. While this wasn't always done in person, teams that reported success often had daily teleconferences, video conferences, or relied heavily on instant messaging.

One team that had some members onsite, and just one or two working remotely had a strategy of rotating a remote member every few weeks to have them work onsite to refresh their personal connections.

Communicate At the Lowest Common Denominator
One surprising insight was the idea that if part of the team is co-located, it was actually preferable for them to behave as if they were remote. Co-located teams called in individually rather than gather together in a conference room.

The counter-intuitive principle was to keep everyone on the same footing by using the lowest common form of communication. By not having some people enjoy face-to-face contact, while others were "just listening in" as second-class participants, teams were able to build more trust and feel more engaged.

There was much more said, but I found two themes most interesting. First, companies are continuing to move towards more distributed development through outsourcing, work-at-home initiatives, and using external resources. More importantly, the use of Agile methods is helping projects that do choose a distributed model to be more successful, both in terms of business outcome and team satisfaction.

Open Space Conferences - Self Organization In Action

2007-01-28T16:31:00.000-08:00

I'm going to my first Open Space conference - the Agile Open Northwest Conference in Portland, Oregon.

As I understand it, the idea with Open Space events is to let the attendees self-organize the sessions and topics by voting with their feet.

So if I wanted to talk about how to make Agile work with distributed teams or remote customers, I would propose that as a topic in the beginning, and others would indicate their interest in that (versus other proposed topics).

And even once sessions are scheduled, the idea is that people drift from session to session, staying if the content resonates with them, or moving on if it does not.

I'm pretty interested in seeing how it all works out.

Agile Project Metrics In One Easy Step

2007-01-03T16:21:00.000-08:00

So you've got the bright idea that you need to measure your software project productivity. Or maybe it was your bosses idea.

But what to measure? Remember that whatever you choose to focus on, your team will take seriously, and shift their behavior to perform well against that metric, for better or worse.

Let's take a look at some popular options:

1. Lines of code per developer (KLOC)? Bleh! That metric rewards verbose and duplicated code, and discourages reuse and leverage of third-party libraries. Not exactly what you were looking for, is it?

2. Function points? This tries to measure an abstraction of functionality in your system using a somewhat arcane analysis. You might need a consultant to help you sort through this one. Then you can debate the results.

3. Ah...how about the number of tasks completed? That's got to be a good metric, right? Except that you might wind up with lots of "filler" tasks created by the team in order to satisfy this metric. "Want more tasks completed boss? I'll get right on that!".

4. What about total time worked? This has the same problem as #3 - time worked has very little correlation to productivity. You might wind up with lots of overtime, but no progress. Ever have a boss that was more concerned with "how hard" everyone seemed to be working instead of what was getting done? Right.

OK, this is getting frustrating. It seems like whatever you try to measure will backfire, and give you a result you don't really want.

But what if there were a magic metric that would not only give you a clear picture of your project health, but would as a side effect encourage higher productivity?

Well, there is a good candidate for this, and it's called Running, Tested Features (RTF). Ron Jeffries has written about this here, and there is a video interview with Ron, complete with whiteboard scribbles available here.

In a nutshell, RTF is a measure of how many things of real business value got done, where "done" means that they actually work and are ready for deployment.

On a typical yearlong waterfall-style project, you might have several months of planning and analysis, during which the RTF count would be zero. At some point, work would start, but might work on framework development, infrastructure, etc., which would still produce an RTF value of zero.

In fact, you might get to within 3 months of the deadline before the first real feature is "done". That might the point at which the team discovers a serious technical challenge and explains that the project will be at least 6 months late.

Whoops.

A typical Agile project by contrast works in time-boxed iterations, no longer than 4 weeks in duration. The output of each one is a set of one or more RTFs, in order of customer priority. During the iteration, there is a little analysis, a little design, some development and testing, and a little documentation, if necessary.

Both projects might finish at the same time, but which one is more likely to find out about a technical risk sooner? Which one might be able to release if market conditions require the date to be moved up?

In terms of productivity, measuring RTF is a quick way to see the state of the team. A healthy Agile team should be able to consistently deliver a set of stories over time, with any unexpected challenges or risks averaging out against features that turn out to be easier than expected.

A sudden slowdown over a few iterations might be a warning sign of an internal or external quality problem (e.g. the team is spending more time fixing bugs than adding features, or the architecture is too brittle to readily accommodate change).

The key, though, is that this metric leaves enough time to react and address project problems before they impact the business.

So what are you measuring in your software projects?

(Tags: agile, project management)

YAGNI Revisited - Waste Not Want Not

2006-12-14T08:15:00.000-08:00

I first heard the term You Aren't Gonna Need It (YAGNI) in the book XP Explained about six years ago.

At the time, I understood it to mean that building overly flexible (and usually complex) frameworks and models in your software was A Bad Thing. The idea was that since the requirements might change suddenly, and you don't have a crystal ball to predict the future, the time was probably not well spent.

This seemed especially relevant to me in terms of blue sky architectures I had encountered on previous projects that tried to solve a whole host of problems that we didn't even know were problems yet.

Since then, I've heard others argue the point as if it were some sort of Commandment:

Thou Shalt Not Covet Frameworks Until Thou Absolutely Needest Them

The rise of Test Driven Development (TDD) and Refactoring has caused even more widespread adoption of YAGNI, and even caused endless debates along the lines of:

Developer 1: Well, we should just hardcode a return value of one here, since that will make the first test pass
Developer 2: Doh! That's ridiculous, we know that won't be the final solution, let's just calculate the answer!
Developer 1: But this book said to do the simplest thing that could work, and the other book I read yesterday said YAGNI! All of the cool thought leaders are saying it!
Developer 2: Sigh...yes, they said the same thing about pair programming.

Can we really take simplified phrases out of context and apply them to every detail of development work?

Maybe, but I'd prefer to look at the whole debate from a different viewpoint - the "Lean Thinking" one. Lean is a concept from the manufacturing world that has been slowly gaining traction in software development as the concepts are explored further. Tom and Mary Poppendieck's work is an excellent place to start.

So "Eliminate Waste" is the Lean principle that seems to apply to YAGNI and it's cousins.

What constitutes waste in software development? According to Lean proponents, it's:

Extra features: Things we build that no one asked for, and isn't likely to use. I see this happening all of the time in small ways. "Oh, we should add a calendar widget here in case the users want to see what day the holiday party is on while they are entering the invoice data".
Churn: Constant change in requirements (Make it blue...no, red...wait...green!), or constant test and fix cycles (Ok, we fixed the Calculation Bug...oh wait, we added a Storage Bug...ok, that's fixed...NO, not the Nuclear Bug!!!)
Crossing boundaries: Any "throw it over the wall" behavior, even if it's done nicely.

Lean also talks about "queues" and how anything that results in backups is considered waste. Until a customer gets a product in their hands, and it delivers the business value they are paying for, software development is just a cost without a payoff.

So, back to YAGNI. Looked at through a Lean lens, are the activities, features, frameworks and modeling you are doing adding immediate value? Or are they delaying delivery of that value?

Before I get carried away, I'll say this: waste cannot be completely eliminated. I'm not even sure that would be a good thing. I've had some of my best ideas while wasting time. But approaching software development with an eye towards reducing waste can have a profound positive effect on your process.

Unless you don't need one, that is.

For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, project management)

Scrum and XP from the Trenches

2006-11-29T09:03:00.000-08:00

Henrik Kniberg has published a PDF called Scrum and XP from the Trenches. It's a well written and engaging read on his experiments, successes, and challenges running a development team of about 40 people using Agile methods.

One thing I found quite interesting was the information that his team felt was most useful to document user stories (or backlog items). They used various tools, including a shared Excel spreadsheet, to track the following:

ID of the story
Name/description of the story
Importance/Priority of the story
Initial estimate (in points or ideal days)
How to Demo - a brief description of how the story will be demonstrated to stakeholders.
Notes

Of these fields, the "How to Demo" is one near and dear to me. It's basically a narrative around what exactly you would do to verify that the story is working in such a way as to communciate it clearly to the customer.

Perhaps even more critical, though, is that by writing out how they plan to demo a feature, the team is forced to write out their assumptions, which can then be quickly challenged by the customer.

For example, in a toy store application, a story might say "Add games to the catalog". The "How to Demo" might read: "Log in, select the Add Game menu, and enter the details in a form. Verify the information gets stored in the DB".

A customer might then see the estimate as 2 weeks, and say "No, no, I don't care if you enter the information manually in the database, we don't need a form and fancy input screens yet."

This is commonly referred to as an "acceptance test" in XP literature, but is often forgotten by teams just starting out with Agile. This simple tool can greatly improve your communication with the customer, and help avoid misunderstandings.

Henrik goes on to explore many different subjects such as dealing with multiple teams, splitting up stories, etc. He also makes it clear that many of his conclusions are preliminary, since his team is still learning and adapting, and that he might do things differently in a different context.

All in all, a great contribution to the body of Agile knowledge, and a fun read.

For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, project management)

Agile Estimating: How long is an ideal day?

2006-11-02T14:33:00.000-08:00

About seven years ago, my first attempt at doing an estimate using agile terminology went something like this:

Me: "OK, I estimate this functionality at about 3 ideal weeks of effort"
Boss: "Uh...what is that in calendar time?"
Me: "Well, er, it's complicated, it depends on team velocity and planetary motion"
Boss: "Great, can you tell me by tomorrow?"

After doing some reading and thinking, I decided an ideal week was something like a "man-week", adjusting for daily distractions. For most people I've worked with, this adjustment factor (called a "load factor" in the original XP books...yikes) is somewhere between 0.5 and 0.7.

In fact, some studies suggest that the maximum productive time for most workers is five hours, regardless of how much time they spend in the office. Work that requires intense concentration, like say, software development, is more prone to productivity loss from distractions, phone calls, etc.

In other words, an ideal week for a single developer looks a lot like half of a "man-week". Looked at differently, a developer has a capacity (or velocity) of 0.5 ideal weeks per calendar week, or for a two-week iteration, about one week of ideal effort.

So a team of four developers of roughly equal capability would be able to implement about two ideal weeks worth of estimated effort in an iteration (of 2 weeks).

Another popular method of estimating agile user stories is to use a point system to measure the relative size. By using points, a team can estimate the size of a story relative to other user stories.

A 2-point story is twice as difficult to implement as a one point story, and a 4-point story is twice as hard again.

Personally, I tend to prefer the ideal time units, since it's easier to explain to customers, but I have heard reports that point systems have had good results as well after the initial confusion.

How do you estimate and why?

For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, project management)

How Big Should Your User Stories Be?

2006-10-16T12:14:00.000-07:00

How big should your user stories be?

Although the answer should be "it depends", I'm going to be a bit more opinionated than that.

User stories should be small enough that the team and the customer can see and feel the forward momentum. This creates tremendous positive energy and keeps everyone engaged in the project.

So if the team is just a couple of developers, the story size is probably best measured in hours or a couple of days of effort at most. For a two-week iteration, you might then have 8 or 10 stories.

When the team size is larger, you might lean towards the larger end of the story size scale with measurements in days, but less than a week of effort. In my experience, estimates that are beyond about a week of ideal effort are often substantially less accurate.

But who gets to control this story size? Aren't customers supposed to be writing storeis? How can they be trained to control the size when they don't have the ability to estimate the effort?

In reality, story writing is best performed as a collaborative exercise. A typical interaction might look like this:

Customer: "I'd like our movie website to have a new user reviews feature"

Developer: "Great, let's talk about what you'd like the users to be able to do"

Customer: "For starters, when they view a movie listing, there should be a rating thingy that shows how many stars other viewers think it deserves. And you should be able to see other user comments. But we can't have any profanity on the site!"

Developer: "Ok, so you'd need a way to add ratings, and a way to show them to the users, ability to add and show comments, and a profanity filter. Why don't we split those into four separate items, and you can tell me which one you want first?"

Customer: "Well, we could start with just the ratings for now, then we wouldn't need to worry about profanity."

Developer: "OK, great, we'll estimate what it would take to add ratings, and to show them for each movie".

The developer here has to be sufficiently savvy to try to break out stories that have value, but are small enough to be managable. This isn't always possible, but on average you'll wind up with bite-size chunks instead of a Biggie-Sized story.

One caveat with smaller stories is that if you wind up with a great deal of them, it can be difficult for your customer to prioritize them effectively (it's tough to rank more than about 10 things). You may wind up with categories or "themes" that group together a set of small stories. The customer can then prioritize around themes like "Security", "User Reviews", or "Reporting" first, then later determine which smaller items are most important.

Let me know what size stories you use, and how it's working out for you.

For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, project management)

Google's New Motto: Don't Be Agile?

2006-09-28T09:17:00.000-07:00

Steve Yegge of Google has an epic rant about Agile methods and why they are evil.

This article is sometimes rambling, and often grossly unfair in many ways, but let's take a closer look.

Steve talks about "good agile" vs. "bad agile", and generally lumps anything that requires consultants, training, or books as "bad agile".

Google, where he works, is apparently using "good agile" which as best I can figure means that no one is forcing anyone to do anything, there is no defined process, no deadlines, no explicit pressure, and everyone just sort of figures it out. His ultimate weapon is a priority queue.

Certainly Google operates differently than many businesses (as Steve puts it "Somewhere between a startup and grad school"), but since when did poorly defined projects, no deadlines, and chaos make a solid development process?

OK, I admit a got a chuckle out of it, even as I was thinking, "Wow, this guy really doesn't get it". But then I thought, "Millions of people who also don't get it will accept his arguments without ever reading about or trying Agile".

He goes so far as to suggest that even trying Agile is "Dangerous", and that you should throw out your XP or Scrum books immediately.

I was half expecting him to say "Burn her! She's a witch!"

What's really dangerous is letting someone else do your thinking for you and telling you what you can and can't read or try.

He warns of Agile proponents "being slippery" by taking credit for any good effects of an implementation, but explaining away bad effects as "you didn't do it right". I do see this far too often on Agile mailing lists and in other writings, but it's also sometimes accurate. I can wave my arms around and make "Ha!" noises, but that doesn't mean I'm doing karate.

And finally...the one point I agree with in the entire rant: If a process is attempted by 100 groups, and 90% of them fail, maybe it's not a good process (or well documented, or easy to follow, etc.).

But in my opinion, Agile is not about process, it's about philosophy.

Philosophy is difficult to standardize and implement. So we as humans create specific rules and practices that are easy to digest. For example (apologies to my fellow Agilists):

"Do pair-programming all of the time, except when your alone, then put
your cat on the keyboard."

"Write everything test first, especially test code."

"Use index cards, they are magical and will grow into rectangular trees if
you plant them."

"Don't let chickens talk, they make an awful noise." (from Scrum's "Chickens and Pigs" metaphor)

"Four legs good. Two legs bad." (Hmm...maybe that's not from an Agile method)

And because many people don't "get" the philosophy behind the practices, they either become unthinking zealots or fierce, er, "insurgents", leading to a project's demise.

Is it fair to blame Agile for this? Of course not. But what did fair ever have to do with anything in our world?

So how can an Agilist combat this viewpoint without looking "slippery"? Maybe everyone should do what Steve suggests, and stop worrying about standardizing process, and just work on instilling philosophy. Let good practices emerge from smart, capable people trying things, seeing what works for them, and adapting.

But then you'd be doing Scrum, and we already know that's "dangerous", right?

I do worry when I think about how few people actually read original sources and make independent decisions based on their own experiences, versus going whichever way the latest pundit blows.

So do yourself a favor: listen to me for a change and make up your own mind.

For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, project management)

How Agile Is Your Development Process?

2006-09-22T10:28:00.000-07:00

How agile are we? I've started to see this question appear more and more in mailing lists and discussions.

In truth, it doesn't matter in the least how "agile" your process is, only how effective it is.

The assumption in the question is that being more agile is a good thing, and that if we could only measure it objectively, we could guarantee improved "goodness". I don't think this is true.

Hear me out. I'm not saying that being more agile is a *bad* thing, only that it's not the right thing to measure. Everything in software development (and business for that matter) is dependent on context.

So try things and measure them to see if your effectiveness improves. If it does, do more of that thing until something breaks. Then turn your attention to another factor.

For example, many people come to agile development after experiencing a "death march" type of project where the delivery is late, buggy, and over budget. They are looking for a better way. They adopt an Agile method like Scrum, and expect miracles. When things aren't going well, they say "We must not be Agile enough, let's measure our agility so we can improve it!"

Instead they should be asking questions like:

1. Are we meeting the requirements of our customer, or are there constant misunderstandings?
2. Are we able to make changes to our software efficiently or is it painful?
3. Are developers energized and excited about their work or burned out and unmotivated?

The road to agility is one of trial and error. Yes, you can blindly follow certain practices and if you're very lucky, your team will reach development Nirvana with no changes.

In most other realities, you'll need to inspect and adapt.

Developers are burned out? Try shorter working hours, training, time for pet projects, more collaboration (or less collaboration).

Miscommunicating with customers? Try in-person meetings, more freqeuent releases, weekly demonstrations, onsite customers and so on.

Software difficult to change? Try continuous integration with automated builds, test-first development, pair-programming, peer review, shorter iterations, or add some new talent to the team.

There is no silver bullet. Really.

But there is a secret weapon. Want to know what it is?

Wait for it...

Here's the big secret...

USE YOUR BRAIN!!!! (It's really an amazing thing)

For more on agile tools and techniques: http://www.extremeplanner.com
(Tags: agile, project management,
extremeplanner)