Manage Learn to apply best practices and optimize your operations.

Keys for Agile development: Planning and team collaboration on large or small projects

Whether a small Web application or a large-scale enterprise application, planning is essential. Agile expert Lisa Crispin describes the balance between "big design up front" and diving in without a design by using "just enough" planning to ensure your project is a success.

If you’re just starting out with Agile development, you may be puzzled by how planning gets done on an Agile project. You’ve heard that “big design up front” is bad, but diving right into the coding with no forethought seems foolish. How does an Agile team achieve the right balance of “just enough” planning in order to maintain a steady pace and deliver business value frequently? Whether you're working on a large-scale enterprise project or a small Web application, planning cannot be overlooked in an Agile environment. Here are some key practices that I've found are essential to success in planning in an Agile environment.

“Just-enough” preparation

When you have a complex new project (or “epic,” as some Scrum teams call them) coming up, schedule one or more brainstorming meetings one or two iterations in advance. Time-box the meetings to an hour each. If an hour isn’t enough, schedule another meeting. It’s essential to have time in between brainstorming meetings to think about the business problems to be solved, and mull over the pros and cons of various design approaches.

During the brainstorming meeting, have the product owner explain the purpose of the new project. Invite other stakeholders as needed. Help the business experts focus on the business challenges -- they should refrain from proposing a technical implementation. Talk through design options, diagram them on a whiteboard, and think about how they could be tested. Ask the domain experts for examples, and work through them on the whiteboard. Propose ways to slice the project into manageable stories, and how those stories would be prioritized.

You may decide to spike a design solution, writing just enough code so that you can test to see if your approach will work. This can provide information to plan and estimate user stories for your project. On my team’s current project, performance of the code was paramount and we needed a spike to tell us if the design would perform well enough in production.

Make sure that all team members can participate in this advance planning. Since our team has a senior programmer (and manager) in India, plus other team members who work remotely some of the time, we plan brainstorming meetings for a time when everyone in every location can be present. A virtual tele-presence device with a good webcam and microphone allows remote attendees to interact as if they were in the room with us.

We take advantage of time zone differences by having the team member who’s half a day ahead do research and preparation to help us speed up our brainstorming, estimating and planning meetings. For example, we recently planned a major project to rewrite a core part of our system. Before the first brainstorming meeting, the programmer in India studied the old code that would be replaced. The morning of the first meeting, we had an email from him with a write-up explaining the legacy code’s design. This information gave our meeting a jump-start.

On large, multi-team projects, it usually makes more sense to have each cross-functional team meet for brainstorming, then share information and coordinate dependencies by having representatives from each team get together to work through each team’s design ideas and plans.

Planning for collaboration

Whether you decide to spike a design solution, or are planning the first sprint of a new project, you have to balance collective code ownership and pairing with the realities of having remote team members. You must accept the limitations of a distributed team: sometimes it’s counter-productive to have a remote team member work on a particular story and you must find ways to divide the work up sensibly while keeping everyone informed about all stories. Other times, remote pairing works well and the whole team can work on one theme. It’s all about experimenting. My team will try an approach for a particular theme, and if it doesn’t seem to be working well, we adjust.

Use technology that promotes collaboration, such as wikis, video and audio. This keeps everyone on the same page, regardless of location. If my team has planning or design discussions when the remote person isn’t available, we take notes and draw pictures on the whiteboard and post those on the team wiki, and bring everyone up to date during or after the daily Scrum. These technologies are critical for teams in disparate time zones, where it’s impossible for every team member to participate in every meeting. Larger projects, especially those with distributed teams, may need more sophisticated online project tracking tools that give people in every location the most up-to-date information.

Be wary of organizing your project by expertise. For example, having programmers in one location and testers in another impedes communication and results in lots of wasted time. Cross-functional teams with a diversity of roles and viewpoints have the best chance at finding a good design solution and anticipating future needs. For example, if no testers are present in the design sessions, the team may neglect to plan for essential resources such as realistic test data, adequate test environments, and the need for different types of testing such as stability, security and usability.

Planning the work

When we planned the first sprint in our most recent project, we discussed the results of our design spike, diagrammed flows on the whiteboard, and talked about the best approach to various coding and testing challenges that surfaced. There were still unknowns, which made it hard to write detailed task cards. Instead, we wrote general cards with big chunks of hours, planning to break those down into specific task cards as we learned more.

Don’t waste time trying to map out the whole iteration in the planning meeting if your team is venturing into new territory. Plan time to learn and experiment with coding and testing solutions. As you learn more, you can plan more.

Even if you’re doing Agile development, business deadlines are a fact of life. Work with business stakeholders to manage scope and prioritize user stories. Keep everyone grounded in reality. If the project seems too big for the specified drop-dead date, the business experts will have to prioritize the “must-haves” and postpone some business value for later.

Agile planning success

Don’t get bogged down in long planning meetings, but don’t forge ahead without any thought either. Make sure you understand the needs of all your stakeholders. If your team includes people in different locations, put some extra thought into your planning process. Experiment with different approaches, and use retrospectives to evaluate whether the experiment is working. Remember that what works at one stage in your team’s journey may not work later on. Make sure your team has all the roles it needs to anticipate different types of risk. Find the right balance for planning and collaborating that keeps your team feeling productive and communicating well.


Dig Deeper on Topics Archive

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

We've been doing Agile development for 6 years, and we're STILL apparently still puzzled at how planning gets done! Ha! 

We had a recent project that just finished up last month. Planning was a bit of a mess. A couple of dev managers brainstormed the project by talking through the implementation and jotting diagrams on a napkin. The thing was, this project didn't meet a business need. It was a bit of a pet project, done to improve the system architecture. Because the rest of the team and the users were not involved in planning, the project was never really viewed from that perspective, and some important pieces were missed. 

The result was that the team had a lot of trouble understanding the overall design and goals of the project. Every time we went to pull a new story, there was confusion, misunderstandings, and design discussions that sometimes delayed the story for a couple of days. 

It was frustrating, to say the least. We are beginning a new project and so far we are doing a better job of planning.