Building Experiences in an Agile World
Leave your Feature-Based Mindset at the Door with Design Thinking
Early in my career, someone in sales came up to the dev team and said “… wouldn’t it be cool if…” That phrase now scares me to death whenever it’s uttered.
Our application had a feature where you could customize your screens — it would let you add, remove, or rename fields for various functions as the clients desired. The proposed feature from sales was the idea that we could combine multiple screens together to enter data in a single place, but process all the actions at once. On the surface this sounded reasonable so the dev team set to work. A few months and a lot of complicated engineering later, we had achieved the desired result. However, over a decade later, I’m not aware of any customer actually using this feature. We went about building a thing, hoping someone would use it, and that someone never materialized. Instead, we should have talked to our customers.
Today most people would agree that agile development is better than traditional waterfall. Faster delivery, iterative development, small functional teams, and many more buzzwords to help fill out your buzzword bingo card. But I would argue doing agile and delivering agile are not the same thing.
From Waterfall to Agile — The Promise
My first job in IT leveraged the traditional waterfall delivery cycle. Generally it was three months of requirements, three months of development, and three months of testing/release followed by another three months of basically doing nothing while waiting for the cycle to start over. As an engineer, it was extremely frustrating. It felt like I was idle 75% of the time because I wasn’t doing what I really enjoyed doing, writing code! In the mid-2000s, I took a new job at a small software development company and got my first exposure to this thing called “agile”.
Like a lot of people at the time, at this company we were rewriting a legacy green-screen COBOL application into a Java web app. Our job was to convert 30+ years of features into a new system, which certainly felt like a daunting task coming from my previous work experiences. To better enable the team to accomplish this goal, we used agile instead of waterfall methodology. My initial reaction was that agile seemed cool; I can build a piece of a thing and keep adding to it week after week. Compared to my prior job, where there was a lot of downtime and waiting to see results, this seemed great!
Agile helped us to focus on smaller portions of the applications we were building. But it also meant we could be building things that were only useful from a technical standpoint. With this new agile framework, I found that development completed within an iteration was often “worthless” to the end user until you had completed a lot more work. The team may have delivered working software (one of the items covered in the Agile Manifesto), however we were not delivering user/business value; that would be shippable at a later date when more code was completed.
Soon the team started adding new roles like a scrum master, and our business analysts became product owners. A better concept of a functional, independent team was evolving. But one thing was still missing — we still weren’t sure if we were building things that anyone actually wanted. This is where some newer principles like design thinking started coming into play within our process.
Agile Meets Design Thinking
Soon after I joined Capital One in the early 2010s, I had my first exposure to a new role in the development ecosystem: designers. Prior to joining Capital One, design was just something we did “on the fly” by whomever happened to have the best eye for constructing pages. Initially, I misunderstood their role on the team. A designer is someone who composes beautiful Photoshop images, throws them over the wall to the engineering team, and says, “Build a web page that looks like this!”, right? But the role couldn’t be more different. Designers are an integral piece of our agile teams, focusing on the full UX of what’s being built.
One way they accomplish this is by leveraging design thinking, which is defined as “… a human-centered, iterative design process consisting of 5 steps — Empathize, Define, Ideate, Prototype and Test.” Using this process, designers help drive what a feature looks like, how it interacts and is interacted with, and improves its efficiency by grounding the work in the knowledge that real value is being provided to the user. This is accomplished by working with the engineering team and our actual users to develop that value. Much as a product owner helps drive what work the team is doing, designers help create why the team is doing that work.
But how is this a helpful addition to agile processes? Even with agile, you might spend three months (or longer) building a feature for your system; however, with design thinking added in, we focus more on delivering an experience that improves the users’ interactions with the product. Otherwise, if your users don’t care about it, you’ve wasted a lot of time and money developing unnecessary features. Since we can’t read minds, we have to iterate in quick feedback loops to determine exactly what users want and need. This is accomplished by creating one or more hypothesis of what work should be done, before constructing and prototyping those hypothesis by interacting with real people and gathering feedback.
This lets us determine what works, what doesn’t, and repeat this until you reach the desired outcome. You’ll often hear the term “fail fast” mentioned here. The sooner you find out if something works, the sooner you can get to building it (or moving on to the next thing).
Balancing Speed vs Satisfaction
So what does that mean for agile and building software? Traditionally agile is about building the big picture, one sprint at a time. However, just because something is built, doesn’t mean it’s usable. So how we do get feedback on what has been completed and use that to adjust what is built next. Let’s use the following illustration as an example.
This image contains a number of elements:
- It shows how both processes build something (a treehouse) a piece at a time.
- It tracks customer satisfaction through the process.
- It shows what gets delivered with each iteration.
- Reuse over starting from scratch
At first glance, you might say, “But both paths ended up with a treehouse. Success!” Yes, while the end results were similar, the total customer satisfaction was lower both over time and with the final results. Let’s think about it this way. Let’s convert the faces to numbers representing the amount of happiness each represents. So our angry face becomes a 0, and our big smile becomes a 4.
Then, let’s add those numbers up over the stages shown for both processes to reach final state. You get:
- Path 1 : 0 + 0 + 0 + 2 = 2
- Path 2 : 1 + 2 + 3 + 4 = 10
With Path 2, customers get much more cumulative value over the same period of time, and a better end product. You’ll notice while both paths created a treehouse, Path 2 found out users liked also wanted some swings and a railing. Path 1 has completed a task, but it is not necessarily closer to delivering what the customer desires. By working agilely, they could pivot the work based on feedback from prior releases and deliver more to what the customer wants, and not what we may think they want. It also points to something we sometimes fail at in the engineering space, reuse existing services (a tree) instead of building it all from scratch (start with an acorn).
This simple example demonstrates the advantages of both incremental development and incremental delivery. You should aim to release small parts as often as possible to find out if your bets are correct or not.
Building Better Experiences
While you don’t need a Design/UX lead on your team to achieve this, it’s important to consider how their mindset and skills can help your process, especially when it comes to developing hypothesis early on and testing them as quickly as possible. A failed hypothesis is not a bad thing, it means you now know what not to do, which lets you focus on what to try next. This means focusing on delivering the right experience for your users, instead of delivering a single feature that users may or may not care about.
Looking back at my story about my intro to agile, it would have been immensely powerful to schedule time with our customers to talk about how they worked and what they needed. At the very least, we should have shown them early prototypes of what we were building to get their feedback on the work. If we had, we might have learned how to change our direction early on. While I may still fear the phrase “… wouldn’t it be cool if…”, I now look forward to hearing “Check out the customer feedback on…” because I know we’re that much closer to delivering a great experience.
Related:
DISCLOSURE STATEMENT: These opinions are those of the author. Unless noted otherwise in this post, Capital One is not affiliated with, nor is it endorsed by, any of the companies mentioned. All trademarks and other intellectual property used or displayed are the ownership of their respective owners. This article is © 2019 Capital One.
