A service designer in Agile land
If you are a service designer working in Agile land, then you are probably living a dual designer life. You probably find yourself having to juggle between delivering in a scrum team and shaping the big picture as part of a broader team. Yes, your mind will need to operate in two very different modes. Yes, almost simultaneously. On the one hand, you will need to be fully embedded in the delivery process and provide your scrum team with all the design assets and support they need. On the other hand, you would almost certainly want to ensure design acts as a catalyst long before delivery starts. Even if you do not feel particularly inclined to take an active part in shaping, you would most certainly want to have a say in decision making as this has a direct impact on what and how gets delivered. The constant switch between the micro and macro picture is part of anything a designer does anyway, but the difference here is that in Agile land this happens very quickly. It is not always an easy task but it is certainly a fulfilling part of being Agile.
The bite-size puzzle
Service designers love ‘the big picture’. We know that no design solution works in isolation and that every interaction we design for is part of a greater journey. We love exploring how things relate to one another, across time, across different journeys, between different stakeholders and customers. Indeed, we love the intangible stuff that makes the touchpoints we design come to life. Now imagine you are sitting in a sprint refinement meeting with your scrum team and witness a journey being chunked out into function-based UI pieces and translated into Agile user stories which are then scored with team points and need to be delivered by the end of next week. If you are new to Agile and Scrum, your inner designer would most likely sulk in bitter disappointment. What about the cool features that get left out? What about the seamless customer experience? We have an inherent urge to constantly assess and reassess how things connect and morph into a meaningful experience for the customer. And one of the most common frustrations that both myself and other designers I work with experience in Agile land is the fact that we don’t have time to think about the end-to-end experience as much and as often as we would like to. We work a sprint ahead of development work and focus only on a sprint’s worth of design work at any given time. So inevitably we feel that although we give it our best we still lag a step behind where we think our designs should be.
Agile as a software development methodology works brilliantly for iterating on programming code. Code can be bite-size. It can be cut into snippets, reshuffled, packaged into design patterns and reused. Customer experience cannot. But the truth is, that is okay. In Agile land everything we design is an experiment. It is a lightweight version of the real thing. We design Minimum Viable Products through minimally viable services and minimally viable experiences. As long as we ensure that we design the right experiment and the right minimum to be user-tested and validated, we can trust that any assumptions we have made about the customer experience will have surfaced when the right time for enhancements comes. That is, if our inner designer has not already given up and left the scene full of disillusionment.
Just enough design
Paradoxically, when it comes to actual design artefacts such as roughly sketched interactions and wireframes, the idea of getting our designs only to a stage where they are good enough to get feedback and progress a concept further is not new. Good enough has become the new perfect. We’ve learned to feel comfortable with that. We’ve learned to feel comfortable with showing unfinished design ideas with the sole purpose of validating a hypothesis. What we are still learning to do is own the design process to a degree that is ‘just enough’. Not only designers design. Design does not happen only within the design team. In our work we’ve seen business analysts pair up with developers to play out and film a use case. We’ve seen IT architecture team members create Excel click-through prototypes (yes, Microsoft Excel for prototyping!) to validate a concept. These rare occurrences need to be celebrated and continuously nurtured by designers as they are symptoms of a design-led culture taking hold. Our job as designers is not only to do design but also to spark a design-aware, if not design-led, mindset and to pass the baton of design thinking forward. As a designer in Agile land you might not always see yourself as someone passing the baton, especially when you try to get design work signed off ten minutes before sprint refinement or when frantically closing JIRA tickets an hour before sprint planning. Nevertheless, in the long run each of us is part of this process of propagating a design-inspired culture. And the practicality of things is that whilst being perhaps too rigorous a framework, Agile is a very suitable approach to harness the collective creativity of an Agile team. It is a good way for us to learn to do just enough design.
Collaboration is everything. Really.
In Agile land collaboration is the one force that ties everything together. The idea of one team in one collaborative effort towards one unified vision is fundamental to Agile. We work in cross-functional teams. We make sure we have enough checkpoints throughout the day with team members from different capabilities, Amigo meetings as we sometimes call them. And it is amazing to see how an idea comes to life during the discussions we have. Developers give different ideas about how a specific design solution can be implemented, which prompts more ideas about what the design of that concept could look like. Business analysts assess the concept in the context of the different business scenarios and raise more questions around what this concept could mean. And as a result the concept becomes richer and gains depth and versatility. As much as you would hear designers including myself complain about having too many meetings during the day that eat away their actual design time, arguably most of those meetings are design in the making. And this is both inspiring and rewarding.
A great deal of the work happens as a manifestation of the “grabbing” culture that thrives in Agile land. If you seek feedback, have just raised a question you need an answer to or need product owner validation, there is no quicker and more efficient way to get this than to grab the person you need and have a chat while sketching on a piece of paper. All this is great, but once you are embedded in this environment the whole co-location aspect of working in Agile land becomes a bit more controversial and much less loved by designers. We naturally tend to seek the opportunity to bounce ideas off like-minded designers. If we get plucked out of our creative environment and find ourselves being the sole designer in a scrum team, this can feel lonely. It doesn’t need to be lonely though. Just think of your role as being a conductor of creative energy. You feed this energy into the team and the team can respond with the same. It is an opportunity, not a disadvantage. There really is no more efficient way of doing Agile than being in the same workspace with the entire development team. Only then progress becomes almost palpable.
There is a subtle flip side to this notion of One Team. We sometimes tend to blend too much with the rest of the team. Think of this example – if you put ten people in a room and ask them the same question, by the tenth reply you might notice that people start echoing each other and you receive progressively similar answers. Similarly to this group think phenomenon, in an agile team it is easy to blend in. Because the whole team accelerates together in two-week sprint cycles and team members spend so much time together planning and coming up with solutions, there comes a point where the team starts operating in its own bubble and loses some of its agility. The various capabilities lose some of their edge. We start conforming. Just like when you run a marathon and subconsciously pace yourself in relation to people running next to you, in an agile team people tend to conform. We conform with others’ ideas, with their pace of work and working style. At that point the designer needs to maintain a certain level of design-focused awareness to keep questioning the work from design perspective and to keep identifying the assumptions the team might have fallen for. Remember your disillusioned inner designer? Keep her inspired and she’ll come to the rescue in moments like these.
What do we really design
If you think of design as a powerhouse for radical ideas, then design in Agile delivery projects will be hardly as exciting as you might expect. Design in Agile land works differently. We work with myriad of constraints, which sometimes arise from the businesses’ own internal structures and the painfully slow transformation (or the lack thereof) the business is undergoing. We are time-poor in refining design ideas to the level we would love to see them reach. We are sometimes more reactive than proactive in the designs we produce while still learning to be comfortable with ‘just enough’. We try to craft the best possible customer experience while knowing that for various reasons there are limitations to how much control we can place in the hands of the end user. We design content-heavy forms and copy that needs to respond to a customer’s emotions around something as big as remortgaging their home. Therefore as designers in Agile land we don’t do radical design. Agile for digital transformation is hardly the vehicle for radical innovation. We design for impact first and for delight second. And that is innovative.
There’s a certain almost schizophrenic duality in being a service designer in Agile land. In a good way. Beyond the effort it takes just to do Agile, for example all the practicalities of tracking tickets and making sure the rest of the team is aware of what the progress is, even greater effort is required to learn to be Agile. You’d need to learn to switch between different thinking and acting design modes. You’d need to be able to stay resilient and do ‘what it takes’ as well as ‘what is needed’. If we manage to strike a balance in this almost contradictory environment, then we’ll be good for Agile and Agile will be good to us. There’s much to gain. And there’s much to learn. Upon leaving one Agile project I received the loveliest message from a colleague who said the work we did together inspired her and showed her what being customer-centric really means. In the end what counts is the impact you create for co-workers and end users alike.