This chapter is from the book
This chapter is from the book
This chapter is from the book
Agile project management
There are many books and training courses on agile project management, but to our knowledge there are none that address the management of design and design activities on an agile project. This is a major oversight in our opinion, because good design does not happen by accident. Design needs to be baked into the process, thought through, planned, and managed.
Traditionally, the designer or design team takes care of the design management, where design activities are contained in a design phase. When design is tightly integrated with delivery, as it should be on an agile project, then the agile project manager must be much more actively involved with design management. Where this is not the case and design is treated separately to the rest of the team, design can become a bottleneck because design and development are working to different priorities and schedules.
Agile is quite a different way of working for designers, and integrating design with delivery on agile projects is a fairly immature process for agile project management. Therefore, there needs to be a bit of give and take on both sides for it to work.
Managing design and designers: tips for agile project managers
If you’re an agile project manager, or even a lead designer on a team of multiple designers, you’ll need to help the designers and other team members understand the collaborative design approach, collocation, and communication methods. Expect some resistance to start with, as humans by nature are opposed to change. However, the key to successful adoption of this new way of working is to offer it as a flexible framework, then any good, self-organised team can adopt and adapt the approach that is best suited to them and to the project.
To determine whether you have the correct design resources for your team, you need to consider a number of factors, including:
- Is the user interface/customer experience critical to the success of the project or organisation?
- Is the product or service well-established in the marketplace?
- Is the brand well-established in the marketplace?
- Will the product/service attract high traffic?
- Is the product being released into a mature market, with lots of competition?
The more questions that you answer with yes, the more you need to increase the volume of design effort. You also need to understand what kind of designers you need on your team.
You’ll need to ascertain what the designers know about the agile process, tools, and techniques, and, if necessary, run some introductory sessions. You’ll need to help them understand how they fit into and feed the development life cycle.
More importantly, you’ll need to help them understand that design is no longer all done up front. This may well be one of the biggest challenges for the designers: working out how to create a design vision and then letting the design vision emerge throughout the development process.
Supply and demand
Once you’ve determined what kind of designers you need, you need to think about when to get them involved and for what duration. As a general rule, you’ll probably need more design involvement at the beginning of the project than you will at the end. This is not to be confused with big, up-front design. The difference is that there will be a finite number of design challenges on any project, and once the solutions for the design patterns have been established, the details can be applied by the business analysts and developers as the user stories are played out (4.8).
)
4.8. Experience design involvement on an agile project.
Ideally, the lead experience designer should be on the project from the start, especially where customer experience is critical to success. However, you probably won’t need to introduce some of the other design resources until later on. Visual designers may not need to get involved until the general experience design direction has been set. Equally, front-end developers may not be needed until after some of the initial visual design work. Although the front-end developers can start the HTML structure in advance of any CSS and visual presentation layer work, and they can also help test design concepts in presentation layer code, so it can be fruitful having front-end developers around earlier.
When you need to bring in design help
Cross-functional teams are all well and good, but what do you do when you’re lacking capability in a particular functional area that is essential? As with all projects you have to beg, borrow, steal, or buy it. However, agile is such a different way of working that it can be difficult to plug people and resources into the process. Most of the agile project pains we hear about involve agile teams having to work with service providers who are not agile. Incompatible methods and processes can create a world of hurt for everyone.
If there’s no design capability within the project team and you need to outsource it, choose a design organisation or individual who is flexible. It doesn’t matter if they don’t have agile project experience, but they must be willing to work on-site with the project team, collaborate to develop the design throughout the process, and produce design artefacts that are lightweight and facilitate conversation, rather than rely on heavy documentation. Determining the design credentials of your design supplier is essential, but you also need to consider the process and cultural fit. Here are some things to consider:
- Talk to the designers/design manager before they start on the project to get an understanding of how they like to work.
- Ask them if they are willing to collocate; if not, think very hard about whether they are the right supplier.
- Ask if they intend to work on your project full time, and if not, how they will ensure their availability during critical decision-making points.
- Ask about their experience collaborating with business stakeholders and developers throughout the process. If they have no experience, probe deeper about their willingness to collaborate.
Don’t be convinced by suppliers who tell you that they need to work at their offices because they have the kit and the support they need. No matter how great the intent at the start of the project, the relationship will break down over time. Designers who work off-site tend to want to produce pixel-perfect designs before revealing anything. No matter how quick they are, it’s still wasted effort producing pixel-perfect designs if they are wrong. It is much more efficient to work in a low-fidelity way to start with and to get frequent feedback about work in progress so that the designer can adjust and adapt as he goes. Also, it takes much longer and much more effort to send an e-mail with attachments and words to explain the design intent than to have a quick face-to-face conversation.
The same can be said when you source design capability from within your organisation. You really need the designers to collocate with the project team for the duration of their involvement. If you get any resistance, remind them that you’re not asking them to make a permanent move away from their department. Most designers understand the benefits within a very short period of time.
Managing design and designers: tips for designers on an agile project
Agile project managers are not the taskmasters and shepherds that other project managers need to be; they are more like leaders. Agile projects are much more self-directed and agile teams are self-organising. An agile project manager does not need to assign tasks to team members because they can do that for themselves when they are ready to work on the next thing. Instead, the role of the project manager on an agile project is to:
- Inspire and motivate the team and to help them focus on the project vision.
- Remove blockers or anything that is impeding the progress of the project.
- Ensure that communication is free-flowing.
- Promote the use of the agile principles, tools, and techniques.
As a designer, the project manager should become your new best friend because he can help you communicate to the rest of the team about the value of design and how it affects the success of the project. But before he can do this, he needs to understand the value, the activities, and the effort required, and you need to help him with this. Get to know your project manager and understand what experience he has had in managing agile projects with a design component.
If you’re new to agile and the PM has experience managing design on agile projects, talk to him about his previous projects to understand where design activities fit in and how to work collaboratively with analysts and developers.
If you’re new to agile and the PM has no experience managing design on an agile project, talk to the PM about what you aim to achieve with design and how you have worked previously. With his agile experience and your design experience, you should be able to come up with a plan that will work for you both. You’ll have to adjust and adapt; try to be flexible and think creatively about the design process. Remember, you don’t have to compromise on design quality because you’re changing your approach. The more you can help him understand about design and what you need, the more he can help you and help the rest of the team help you.
If you’re experienced in design on agile projects but the PM is not, then simply help him understand what has worked well in the past and what did not work well. Tell him about some of the problems you had that blocked your progress so that he knows what to look out for. If the project manager is aware of potential issues like this he can make it happen, which takes some of the pressure off you.
If both you and the PM have experience with design on an agile project, then happy days. Well almost—it’s still worthwhile having a conversation and making sure that you have matching expectations because, as we’ve mentioned, there is no one-size-fits-all agile process. Compare notes about what worked well in the past, what you would like to keep doing, and what that caused problems.
Design activities to build into the plan
These are design-orientated activities that you may wish to build into the project process and planned for:
- Regular end-customer feedback is about engaging with end customers to find out what’s not working in the design so that designs can be adjusted before they are developed. Techniques range from “guerrilla testing” to formal lab-based testing, and the time and effort increase accordingly. Ideally, feedback should happen as frequently as possible, such as once an iteration for one to two cycles, or multiple times an iteration where the iterations are longer.
- Regular feedback from business stakeholders who may or may not be directly involved in the project team. This gives everyone who has a stake in the design the opportunity to give input and feedback about the designs. These meetings will likely need to happen once or twice within an iteration.
- Frequent interaction with developers to ensure that the design ideas are feasible and also to get input about what the technology can do to enhance the designs. These need not be formal meetings but the conversations need to happen frequently.
- Frequent interaction with business analysts (BAs) to ensure that the designs cover all the user stories and that the user stories describe the full extent of the design. Again, this is not a formal session, but conversations need to happen regularly—multiple times a day.
- Interaction with QAs on the project to make sure that the tests reflect important interaction, visual design, and usability criteria too.
- Cross-functional conversations can encompass all the points listed above. When BAs, designers, and developers all need to have conversations with the business, it makes sense to have these conversations once and have cross-functional input. Discuss with a representative from each functional area to find out the most efficient way of discussing areas of common ground.