Project handoff is often compared to throwing your work over the fence for the next team to catch. Handoff is a near-universally loathed period of inefficiency and frustration baked into the waterfall method. Agile has made revolutionary strides towards better integrated teams and more frequent communication. However in practice I find that the divisions between certain disciplines (design, code, security, accessibility, and others) still persist.
In my teams I am innovating an agile method of building websites I simply call no-handoff. It builds on the fundamentals of Lean UX and Dual-Track agile, with a focus on further integrating multiple web disciplines, concurrently, under the UX umbrella. In particular the no-handoff method offers greater integration of design and development, a persistent pain point in agile projects.
Read a full introduction to no-handoff here. I wanted to add to the conversation with additional examples of how no-handoff works IRL.
If you have the opportunity to try out this method please contribute your knowledge and let me know your experiences via email or comments. We can progress and improve this method together and make our lives a bit easier and our projects a bit better.
In the no-handoff approach “design” is not a team, a function, a task, or a project. Most importantly design is not someone else’s problem. Design is one of the shared team goals that the entire project and all its members are aiming to reach.
No-handoff teams take 3 basic steps to improve shared vocabulary, shared goals, and a shared interface.
I see the no-handoff method as the next logical step on the path that dual-track agile and lean UX are already forging.
I follow Scrum as my working process, but no-handoff will complement any agile process. The no-handoff method complements and builds on the work we already do to integrate teams and blur lines based on agile techniques.
Below is a diagram of a recent project and the relative work load of different disciplines across phases. Exact levels of involvement will shift depending on the project, but all teams are involved from start to finish.
Important note: Unless a compelling reason is identified then all disciplines should be present at all meetings.
Daily standups — these meetings have a dual goal: evaluate how each discipline’s work is advancing us towards our user-centered goals, and if needed generate new backlog items. “What are you doing today” becomes “What are you doing today, and how does it get us closer to our user-centered goals?”. The UX guardian’s job is to facilitate discussion and continually orient it towards user experience and the working wireframe. In a no-handoff project starting multiple phases earlier and concurrently is the norm and happens organically due to the early full group involvement.
Sprint planning — This is the perfect time to ask questions like “how are the security goals affecting the UI team” or “how is the programming team advancing the project towards the design goal”. Each member can draw on their past experiences and pain points with the “throw over the fence” model and how problems were passed on to them, or how they passed problems on to others. With all disciplines in the room these frank conversations will lead to better sprint planning and avoiding attempts at handoff.
Retrospectives — This is a time to evaluate what got us closer reaching our shared user-centered goals and what didnt. Backlog items are generated at each reflection meeting, and as disciplines work concurrently, and because each discipline affects the others backlog items may be cross-generated — developers can suggest a backlog item for UI, security can propose backlog items for dev, and so on.
The skills to create, edit, and read lo-fi wireframes is a requirement for all team members. A nuanced shared language will develop this way, one that all team members will understand. Color, for example, can be used by the entire team in to indicate when elements are in still flux vs. approved. Tooltips and other methods of notetaking right in the wireframe are also incorporated. Minimizing multiple communication interfaces and funneling consultations and decisions into the budding website itself is extremely efficient.
The UX team will be the first to initialize the wireframe build, gather business criteria, and evaluate functional requirements against them. During planning UX solicits input from all teams, rapidly iterates new wireframe changes as their body of knowledge grows, and disseminates that knowledge to the wider team through the lens of a working (though initially very lo-fi) website.
Developers in a no-handoff project are challenged to think about and provide clear reasoning for how backend choices will affect user behavior. This is a critical component to avoiding the trap of simply adding in more and more functions because we can or because they have been requested. There are no physical limitations in a website to the amount of functionality that can be added and the programming team is a critical line of defense. Developers love what they do and I see every day how hard it is to say no, but in no-handoff this responsibility cant be ‘thrown over the fence’ for someone else to deal with later. Coders must also identify elements that will need to be addressed visually and make sure they display in the wireframe.
UI specialists in a no-handoff project are challenged to vocalize the reasoning behind and programming implications of their front-end choices. The question of how each decision will affect user behavior must be considered during design and by all teams during meetings. UI specialists must also challenge themselves to evaluate programming implications and provide user-centered reasoning for any changes.
Your feedback is important. Let me know what you think about no-handoff and its practical implications. Together lets make our lives a bit easier and our projects a bit better.