Archive for the “Agile Practices” Category

Estimates are a fact of life for most of us. And often – while not always – they are a necessity. If I weren’t using some form of estimation on my current projects, they would be twisted up like Sherman bow ties. And on fire.

This brings us to an apparent paradox. The larger and more novel something is, the more we need to put some estimates around it – lest it end up a railroad-side barbecue. Yet the larger and more novel something is, the tougher it is to devise meaningful estimates.

But this isn’t a real paradox. It’s just a starting point.

At the very inception of a project or product we don’t need a thorough estimate of everything. We just need a simple set of estimates that tell us what to label the tick marks on our deliverable-level cost graph. Were we to cost out our initial estimates, would we be measuring project deliverable in increments of one thousand dollars, or ten thousand, or a hundred thousand? This lets the organization and team know what league they are playing in and how much to invest in upfront estimation and project tracking.

Most things we need to do should not be difficult to estimate. Anyone who’s been around the organization long enough should know how long it takes to spin up a shared development environment, the average time to build out a screen, and the usual duration of system and acceptance testing. For the rest we use development spikes.

We use a development spike to tell us whether some technical activity is feasible and/or to tell us how long it could take to complete.

Here are some examples of development activities (and questions) that learn more about with a development spike:

  • Can we implement two-way SMS in our current infrastructure?
  • Can we reduce costs and time by using an open source charting package (or is it better to roll our own)?
  • How difficult will it be to upgrade to Ruby on Rails 3?
  • Can we do multiple file uploads without flash?
  • Will it handle the load?
  • How do we make these two systems talk to one another?

A spike is typically throw-away code. It’s only purpose (at least in this case) Is to give us enough knowledge to state a fuzzy estimate with confidence.

Comments No Comments »

Have you been put in charge of a development team but you don’t know what you’re doing? Do you want to get ahead in your organization and don’t care about the price others have to pay? If so, the Best Practice Carpet Bomb might be just the thing for you.

You only need two things to execute this Anti-Practice. First, you must to select a handful of time-intensive best practices. Second, you will need time – enough time to drop one best practice on your team each month.

Try checklists in the first month. They’re in fashion right now. Checklists save lives in the operating room. And anything that helps guys with starting salaries of three hundred thousand dollars has got to provide some boost to your team. Right? Pass the word down that over the next month every member of your team needs to compile five checklists. No, it doesn’t matter that we don’t have a plan for where to put them or how to use them. It doesn’t matter that a forty person department times five checklists equals two hundred new documents that need to be organized and maintained. They’re checklists and they save lives. The more the merrier. And, because this is the new best practice that everyone’s talking about, this just makes us more agile.

Try something completely different the second month.

How about frequent demos? No, not the end of sprint demos to present our shippable product. We DO need to do those, but they’re so 2002. What we need to start doing – because it’s an up-and-coming best practice – is demo to each other so we can show off how cool we are. Team to team. Individual to team. Team to office manager. Whatever audience we can get. And we need to consider our audience and our presentation posture. We don’t demo real applications because they can break during the demo and make us look bad. Screenshots, scripted talks, and multiple rehearsals – that’s the way to do it. No, it can’t be more relaxed just because you work daily with these people. This is about putting the time and effort into effective communication. And that is SO agile.

On to month three. How about mandatory and standardized incident reporting whenever anything breaks? Or let’s mandate that every new idea gets the A3 and paper prototyping treatment. Yes, every new idea. Wait wait I’ve got a better one. Let’s all start internal blogs and we can spend our evenings blogging at each other. Well, no, that’s not an established best practice. That’s ok. We’ve adopted enough best practices from other teams. It’s time to start making our own. We’re gonna be the next Google.

Now, remember, in month three your teams must also sustain the best practices from months one and two. Otherwise, what would be the point of adopting best practices? They are, after all, best practices, which makes them crucial to our success.

The same rules hold true for months four, five and thereafter … until your team crumbles into a pile of malfunctioning bits that have adapted to satisfy a succession of noisy organizational mandates in the place of quality delivery.

And you know the best part about using best practices to wreck teams? You can blame those very teams for their failure. Had they done as you had instructed them, and implemented the best practices correctly, they would have succeeded in their delivery goals. Time your exit right and you’ll be promoted because of your ability to lead and innovate using best practices. You’ll be off to bigger, better opportunities while some poor sap gets conscripted to clean up behind you.

Comments No Comments »

Agile teams use the retrospective to collect a set of start, stop, and continue actions at the end of each iteration. The point of this technique is to collect feedback as a team and focus it (through one of the above verbs) into actionable steps toward improvement.

But retrospectives often produce a dozen or more actionable steps, and teams can grow nauseous from seeing the same things show up retrospective after retrospective with little or no progress made. So, how does a team break this cycle?

By prioritizing only one or two activities as goals for the next iteration.

It’s hard to remember to work on a dozen (or even half a dozen) things at once, even when you don’t have an iteration of work to complete at the same time. Remembering to focus on one or two goals is much easier, especially when your entire team is also thinking about those same goals.

Finally, the team needs to close the loop by discussing the outcome of each goal in the next retrospective.

  • Did everyone really take the agreed-to steps to meet the goal?
  • Was there a beneficial outcome?
  • Should the team focus on the same goal in the next iteration?
  • Was the outcome different than expected?
  • Should the team take different steps to achieve the goal?

And there you have it: continuous improvement.

Comments No Comments »

Okay, what I’ve done here is taken a practice that is necessary but lame and have tried to make it new and cool by slapping the word agile in front of it. You know, like agile modeling, agile development, agile analysis and agile DBA. But, really, this is more than just that … really.

Sometimes you have important meetings — such as department meetings or one-on-ones — that really can defy any form of standard agenda. One way to deal with these meetings is to run them in an organic, ad hoc fashion. The manager marks the start and end points of the meeting and people throw out and devour topics in between. That’s a bit chaotic and, in my opinion, inefficient. Another approach is to compile an agenda in advance of each meeting, where someone collects each discussion item via email, IM, hallway conversation or carrier pigeon and posts the agenda prior to each meeting. That’s a bit cumbersome and, quite frankly, medieval.

The agile agenda provides a simpler option, in just three steps:

  1. Prior to the start of the meeting, the manager writes “Agenda” on the whiteboard and adds underneath it any discussion items of which he or she is aware
  2. Meeting members call out any additional discussion items and those get added to the agenda. This can also be done more informally, where individuals add their own discussion items as they come in the door.
  3. The meeting starts. The manager or the group decides the order in which the items are discussed. People can add additional items to the agile agenda if they think of them during the meeting.

The meeting is over either when the group is through the agenda or the team has run out of time.

Comments No Comments »

In my last post I mentioned the Iteration Zero technique in passing. I’m going to tackle it head-on today.

Agile teams strive to deliver functionality that can be touched or even used by the customer at the end of the first iteration. Sometimes, however, it does make sense for the team to focus on building its foundation before delivering functionality. This may be the case for larger applications, for teams new to agile development, or for projects where the the features are still extremely fuzzy. These are perfect opportunities to execute an iteration zero.

Read the rest of this entry »

Comments 9 Comments »

“Where do user stories come from?”

This is a question that I hear constantly from people new to agile development. Lots of places, is the stock answer. User stories — or features — really can come from everywhere, as anyone on the team may have a good idea and propose it. Another common answer to this question is the Story-Writing Workshop, which is a good technique for quickly collecting a diverse set of stories from many people. But when the team’s customer already has a decent idea of what he or she wants built, and no user stories have yet been collected, the Feature-Building Workshop becomes the sharpest tool in the shed.

This is also a great Iteration Zero activity. Read the rest of this entry »

Comments 2 Comments »