Agile Zone is brought to you in partnership with:

Jared Richardson works at Logos Technologies As a recognized expert in the software industry, Jared has worked with both start-ups and software giants. He's been involved with various open source projects, with roles from contributor to founder. Jared co-authored the best selling book Ship It! and Career 2.0, and founded the Agile RTP user group as a local outlet for the agile community in North Carolina. His personal blog is Agile Artisans Jared has posted 52 posts at DZone. You can read more from them at their website. View Full User Profile

Planning Meetings Are Essential

08.18.2010
| 13362 views |
  • submit to reddit
Planning meetings, done right, are one of the best communication tools your team can use. It gets the right people in the room and forces the discussion down the right paths. If you skip this meeting, you're asking for trouble.

What does it mean to do a planning meeting "right"?

First, it must be a frequent event. If you try to run a planning meeting for six months worth of work, you'll end up spending weeks together, and you'll still miss the target. Instead try to have shorter work iterations, and plan for each one. I like the Scrum iteration lengths, which run from one to four weeks.

One of the benefits of having shorter iterations is a more regular planning meeting, but it also provides a smaller amount of work to cover. Discussing a week's worth of work doesn't take very long. It allows the team to give each feature or bug the attention it deserves. If you bring in months and month's worth of work the team will quickly start glossing over details. All too often those details are what pop up later and cause problems.

Second, the planning meeting needs the right people in the room.

The product owner (or equivalent) is responsible for collecting and prioritizing the work. They bring enough work to keep the team busy for the entire iteration. They're responsible for bringing the right work to the team, for doing the proper research before the meeting, and creating the acceptance criteria.

The developers are also present. Again, a Scrum sized team works well here. From four to eight developers are on a single team. The team looks at each feature or fix and make a few determinations. They decide if they understand the issue well enough to do the work. If they don't, they'll choose to not accept the work. It then goes back to the product owner who does more research before the next planning meeting.

Finally, the testers are in the room. As the developers are trying to decide if they understand how to code a feature (or fix a bug), the testers are trying to decide if they understand the acceptance criteria. If the testers can't agree on how to test a task, it goes back to the product owner again for more research.

The goal for each of the tasks is also important. Each task must be done within the upcoming iteration. A smaller iteration will force the team to commit to smaller units of work. If the task is an entire API for a database, the team might only commit to a dozen of the specific APIs instead of the entire system.

The discussion between the developers and testers during this meeting is also invaluable. It allows both points of view to be considered before the work is started. The alternative is to allow the developers to write the code as they understand the feature, then let the QA staff fail a feature because they think it should have been implemented differently. It's much better to iron out these differences early in the cycle, before any development or tester time has been wasted in a communication mismatch.

The product owner, our proxy for the customer, is also in this meeting, and hearing the discussion. If the team is heading down the wrong path, the PO can jump in now and keep the team on track. If you can get a "real" customer in the room, that's always a bonus, but the PO gathers opinions from a wide variety of stakeholders and prioritizes based on a big picture view. They should be talking to marketing, sales, support, executives, as well as the company's paying customers. The PO always gets the final say on what features go in and what the priority is. Their aggregated viewpoint is vital for any team that supports multiple stakeholders or customers. The idealized view of pulling in the one canonical customer into the room is rarely possible for any product company. The PO fills a vital role in the team's direction.

Once the team agrees on what a task is, what it will take to implement it, and how to test it when it's done, they then accept the task for the next iteration. This upfront communication replaces a great deal of after the fact arguments. If there's any confusion about the details, then the product owner didn't get enough information from stakeholders, and the task is rejected.

Today I sat in a client's planning meeting and heard developer's question each other's assumptions about implementation details. I heard testers question the level of testing effort a feature would require. The product owner took back some tasks for more research, and others were accepted and tackled by the team. It was a lot of fun watching the interactions and seeing how much time was being saved.

Use an effective planning meeting for short iterations, be sure you've got the right people in the room, and you'll build the right product the first time, while saving a great deal of thrashing and debate between team members. It's another great tool in your toolbox.
Published at DZone with permission of its author, Jared Richardson.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Eran Harel replied on Fri, 2010/08/20 - 8:39am

I used to work in an organization that worshipped the gods of Scrum. We'd spend hours to a whole day in a planing meeting arguing about what a scrum point is, or whether a task should take 3 or 5 days. What a total waste of time and money if you ask me.

At the end of the day nothing got done any faster than before, and developers would hide behind their tasks board when an unexpected refactoring was needed instead of just doing their job.

The end result was a slower clerical organization, where inovation died altogether.

 

Today I work in a new company where things are simply agile, but in a natural way:

  • Nobody paid any consultant for Scrum / Kanban / name-your-god assimilation
  • We actually care about quality - our CI is green 24/7
  • We get things done and fast!
  • Releases are regular - about every 2 weeks and we are working on making that constant (i.e. become lean).
  • We have only 2 QA dudes, and developers test their own product, and write automated tests.
  • Developers / POs / clients talk to each other directly instead of calling in a 6 hours meeting.
Please don't tell me these meetings are essential. They are just an excuse for the weak management to seat around the conference room table for hours looking all busy.

Jared Richardson replied on Fri, 2010/08/20 - 2:13pm in response to: Eran Harel

If your team spent 6 hours planning for a 2 week iteration, you weren't doing it remotely right. Especially if you wasted the time arguing over what a point is or isn't, or didn't "talk to each other directly" during the meeting.

 

For a 2 week iteration, once the team has learned what they are doing, a planning meeting should take about an hour.

 

However, I like what your current team is doing... everyone is talking. The planning meeting can drive those conversations, but if you can make them happen without one, go for it!  I've seen far too many shops that need a mechanism to drive the communication though. Until I consider a shop to be very advanced, I make this a priority.

Eran Harel replied on Sat, 2010/08/21 - 7:50am

I agree, it shouldn't be the way I described it. It just turned out this way. The problem is it just turns out this way in many organizations.

My main point is that you don't need no cult religious process, or costly consultant to become agile, and you should never ever follow these rules fanatically and blindly. The key to become successfully agile starts from the way the entire organization behaves, and no religion and no bi-meeting meeting will ever change that.

The only 'truth' I see in following these rigidly dictated processes is that it helps pushing change into an organization. Still you are left with many process followers who have no idea why they do what they do, and how it actually makes them perform better if at all.

Jared Richardson replied on Tue, 2010/08/24 - 10:27am in response to: Eran Harel

It sounds like you've been burned by some pretty expensive, and not very good, consultants! I'm sorry to hear it.

I agree with you that "going Agile" requires a fundamental change in thinking, but I also strongly believe that it's difficult to know what or how to do it all on your own. Books, blogs, and conferences are all great, but I see the most success when teams have experienced people working beside them. Whether you can afford to hire them or just want to bring in consultants is a different discussion.

I think of software teams like Olympic athletes. No one would dream of going after a track and field medal without a full time coach. Coaches have years of experience and (hopefully) have a great many tips and tricks that can accelerate your training and help you win more quickly. They help you maximize your training time, know what competitions to target, and so on. Can you be great without a coach? Sure. Can you really hit your potential in the least amount of time by working alone? I don't think so... perhaps a few truly exceptional people can, but most of us need help. That's where consultants can help your team.

Consultants are also like car salesmen. There are good ones, and there are really, really bad ones. Don't let a bad experience (or two) turn you off to the entire idea. Like everything else, there's a place for ~reasonably~ priced consultants. ;)

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.