I shared some thoughts on Design and Agile yesterday, and got some fantastic replies. Let’s take a deep dive together. Here is the original post:
*Note: Webflow doesn't support scaling embeds from twitter yet. Try viewing on a larger screen (I know, I'm sorry) if they are cut off.
I spend a lot of time thinking about and helping teams do their best work together. Something that comes up often is how design fits in with Agile teams. There is a lot of great thinking on this in recent years from folks like Jeff Gothelf, Josh Seiden, and John Cutler, only to mention a few, but it is something I still see many teams struggling to make work. One conversation I hear consistently is how can we speed up design and start development earlier. Most of the time these companies are using a flavor of Agile for development, something else for design, and something completely different for the business.
Companies want to solve how to speed up design and start development earlier in the process.
In order to understand where Design and Agile process don’t line up, I looked at the Double Diamond model commonly used by design teams to plan thier work. My assumption here was that the orgs/teams I hear this problem from most tend to use traditional roadmaps to plan work as projects to complete within a given quarter. This work is thought of roughly in phases (if not explicitly) and most of where design’s value is seen tends to fall into the second diamond, Development and Delivery. This is also where a lot of Dev teams using Agile practice tend focus their work, leaving discovery to other functional roles.
These product teams will do some discovery work (though not all do and not always much)which includes design in a small capacity, but the value of design is still largely seen belonging to Develop/Diverge in the right diamond. In this case I can see where the problem starts to come up. It goes something like this… We are done discovering, why the long up-front time before we start building? After all we are literally in development here.
I believe design has great value across the entire spectrum, and if anything ignoring the necessary work of design as part of discovery misses out on vital business value. I would even move Ideation into the first diamond of this model. But now I’m breaking things and messing up the framework. It’s here I’m starting to see limits of this model.
Many replies later and I’m figuring out the DD model is not a great way for product development teams to align. The DD is largely a waterfall way of thinking and working, which I really wasn’t considering at this point. Partially because it’s how many orgs I work with do things, but largely because I’ve mentally mapped it over a kind of Build, Measure, Learn cycle, which I didn’t even realize until halfway into this conversation. In my mind I see the loops and iterations that have come from doing the work and adapting process over the years, what I forgot was that everyone else just sees the linear diagram. This reply especially clarified things for me.
Adopting this framework which is largely waterfall surfaces problems and makes some ways of working difficult. Why? Even looking at the structure of the diagram we see silos, breaking down of explicit tasks to be done by specific roles and teams. It reinforces linear thinking, which may have worked well (and perhaps still does) for manufacturing and physical products, but makes a mess of things when it comes to digital products and services. Especially when trying to make it work with Agile.
Everyone’s feedback helped me think through and frame the problem in a different way. Part of the challenge is shifting the models we use to think about and do our work. I’ve had the best success with this by doing the work, and helping teams do the work, in new ways that don’t require a lot of upfront learning. I find if people can experience a better work day, they are more excited and encouraged to do things differently.
Part of what I do for my clients is to help their teams do their best work. I help them make better decisions, remove wasted time and work, and make progress together that they didn’t think was possible.
I use Design Sprints to bring the whole team across functions and departments into discovery in order to align on big business problems. This speeds up learning by removing all the time spent waiting on decisions, misaligned goals and misunderstandings. Teams are thrilled at how far they can get in a few days without all the baggage and they are able to speed up the time to market and time to money as a result. They often even get to what would typically be iteration 2 or 3 of a product that normally would mean work assigned few quarters down the road.
After working in this way, almost every team I talk with wants to know how to continue working this way and how to bring the spirit of the sprint into the development cycle. I don’t have the perfect answer, I doubt there ever is one, but talking and thinking through this idea in public has been a huge help for me and I hope for you as well. I’d love to continue the conversation here so please let me know what you think!
Some of the many ideas that came up:
I’d love to see design and management move away from siloed Waterfall models, bringing the whole team in earlier to do discovery work. Until we do companies are going to keep facing similar problems when it comes to cross functional collaboration and getting great work done together.