This chapter is from the book
This chapter is from the book
This chapter is from the book
Agile project communication
Communication, as with design, doesn’t just happen by chance. Agile places emphasis on verbal communication and interaction rather than documentation. Therefore it’s essential that everyone on the team understands the communication objectives and protocols. It’s important to be clear about how each function and individual is expected to interact, and deliver and communicate outputs to the team and the wider business.
Agile takes a no-surprises approach. The general principle is when something needs to be said, say it. It’s better to say it when you see it, rather than potentially compounding an issue by ignoring it and hoping it will go away. The earlier a possible issue is dealt with, the better the chances of recovering from the situation with minimal impact. As a result, there are a number of communication protocols that agile project teams use to provide ample opportunity for insight into the team and individual progress:
- Feedback is a way of communicating with individuals on the team to help them improve competency or social interaction. The structure is based on Pendleton’s rules3—what was done well, what was not done so well, and what could be improved. The main objective is to provide the opportunity for growth in a positive and constructive manner.
- Stand-ups are a team communication protocol used within the development phase. They are short, succinct daily meetings that keep the team informed of progress being made, current and intended activities, and any roadblocks.
- Showcases provide the opportunity to demonstrate and get feedback on the working software at the end of an iteration or sprint. Showcases are often attended by stakeholders from beyond the core project team.
- Retrospectives are the team version of feedback. They provide a measured forum for looking at aspects of the project that went well, those that didn’t go so well, and those that might be improved.
Team communication and setting expectations about design and agile
Designer’s perspective: If you’re a designer who has never worked on an agile project before, it’s worthwhile getting to know the project manager before you start. This is your opportunity to let the project manager (PM) know that you’re new to the agile environment and that you’d like to know generally what’s expected of the project team members. You might discover that you’re not the only newbie. Often, a project team consists of members with varying degrees of agile experience and that should be of little concern. If the PM is aware there are agile newbies on the team, then he can dedicate some time to covering the process and the protocols. He may choose to run informal agile coaching sessions, or even assign an agile coach to the project to help the newbies get up to speed.
While you’re getting to know the PM it’s also worth asking what experience he has with agile projects with a design component and how he has integrated design with development. If the PM has only worked on delivery projects that did not have an integrated design, ask if he already has a plan for integrating design activities and design tasks and, if not, if he would be willing to work with you to make a plan. If the PM does have design and agile project experience, ask him how he intends to include design activities and tasks in the plan. Allow him time to explain the process and make notes about any areas of concern. At the end of his explanation relay any concerns you might have about the process, pointing out the possible impact to the project if the concerns are not addressed. Again, ask if he would be willing to work with you to address the concerns and adjust the plan accordingly.
Project manager’s perspective: If you’re a project manager, spend some time getting to know your designers and understand what their agile experience is. As with all functional team members, if the designers have only worked in a waterfall-style project environment, the agile framework for design might take some getting used to. You make need to make provisions for agile training or for an agile coach to work with the team.
If you haven’t had experience with design on an agile project, ask if your designers have. If they have agile experience, take the time to understand what they need and what specific design tasks and activities they need to do, but also look out for the other project activities that will either affect design or that will be affected by design.
If neither you nor the designers have had agile design experience, take some time to understand the tasks and activities that the designers consider critical and invite them to help you plan how to incorporate them into the project.
Obviously you have bigger concerns than just the designers on the team, but it’s certainly worth canvassing the other roles to see who else has worked with designers on an agile project. Run a mini-retrospective with the designers to uncover what worked well in the past and what didn’t work well. By identifying pains early on hopefully you can avoid problems and functional conflict biased by a poor prior experience. Look for opportunities to get cross-functional team members working closely together to improve collaboration. It’s essential that business analysts work closely with the designers to uncover the user stories and the narratives.
At the beginning of the project you’ll need to communicate with the entire team about everyone’s roles and expected responsibilities. Let them all know how you expect design to be integrated and how collaboration is everyone’s responsibility. The project will suffer if even one of the functional representatives doesn’t pull his weight. Let the project team know how design tasks will be tracked and how they will feed into development.
Also communicate the project plan, highlighting to the entire team where functional activities should occur so that the whole team can decide what is relevant to them and what they need to do about it. So, for example, a lead developer might decide that he doesn’t need to attend the wider business design review meetings, but he might want to attend the customer-review planning sessions so that he can agree to the scope of development work for customer testing.