"Can Agile work for design?"
When designers ask me this, what they are often actually asking is, "no, seriously, how the f*#k can we design with Agile?" because many of them have gone through crappy experiences where they have felt like victims of an Agile process rollout rather than active participants and beneficiaries of it. Agile has often been a process or change that's engineering-driven rather than design-driven, so how designers feel about it have rarely been considered. This is unfortunate.
Despite Agile's noble beginnings as a philosophy and approach, in practice I have seen it boiled down to these commandments:
- Iterate often and fail fast.
- Deliver software as fast as possible.
- Aim for minimum viable product.
I know that they mean to say that you shouldn't be afraid to fail, move fast, and don't over-design or over-engineer. Unfortunately, in practice, I have seen it often devolve to the age-old practice of throwing crap on the wall to see what sticks. If you're writing code that does something, it must mean you're making progress, right?
"You're doing it wrong."
“In theory there is no difference between theory and practice. In practice there is.”
I see. I have gone back and reread the Agile Manifesto. I like it and what it has to say. Seriously. However, like many ideologies espoused by a manifesto, it sounds great and perfect in theory, but in practice, when it meets imperfect people and complex organizations, it tends to fall apart. You can say the same thing about any ideology like Capitalism, Socialism, Communism, Libertarianism... Objectivism... whatever.
All of us, whether working by ourselves or with others, would like to do things better, faster, and cheaper. However, Agile isn't the only way to do it. If you don't know who your customer is, what you should be building, and why, moving faster and iterating quickly will not help you. Instead of saving you time and money, it will end up costing you more in the long run.
•••••
I worked at Zynga, the social gaming company best known for Farmville, Poker, and Words with Friends. My team was responsible for creating the company's social platform on mobile – something like an Xbox Live or Gamecenter for the Zynga mobile portfolio. Our team believed in our charter and we accepted our responsibility with gusto. We practiced Agile. We took ownership of a live game – Chess With Friends – so that we could test and iterate with real users. We did daily scrums. We used Pivotal. We released MVPs.
Unfortunately, company leadership never really prioritized investing in building a mobile network, so there was no downwards pressure for the game studios to back our efforts. We had a difficult time getting their support because they wanted data to prove that it worked before they would integrate anything, so we were stuck in a Catch-22 trying to create network effects without a network of games and users. We also had significant technical challenges building something that could scale to dozens of games, both legacy and in development, that had completely different engines, architectures, and systems, and it would have required serious work and investment to overcome.
If you played Chess With Friends from 2011-2013, you may have experienced some of what we did.
What we had was a small, isolated game with users who were very different from the usual Zynga mobile customer, a legacy codebase, and no top-down pressure or bottoms-up support. We had enough support to build out a full team filled with skilled people across product management, design, development, and testing. We received a lot of encouragement. I would like to say we were able to do a lot in a short amount of time and that we were able to make significant progress given all these challenges, and it might even be true (my ego would feel better about it), but, unfortunately, it clearly wasn't enough.
Our problem wasn't something that Agile and all our iterations and data could fix. We had fundamental strategy and priority issues, and we weren't going to quickly MVP and incrementally A/B test our way out of it. I'm sure I made a lot of mistakes, especially since this was when I dove into the deep end of product management, but I learned a tremendous amount going through this process. Regardless, we clearly did not accomplish what we set out to do and I can't really point to a product at the end that made the kind of impact we wanted it to.
•••••
I don't believe that one should look at a process as a place to start. It dictates how without necessarily asking why and for whom. So before you go implement a process or methodology, try to think about it like this:
- Who are you, and what do you stand for?
- What is the impetus for change, and what is the desired outcome? How are you going to best achieve that change?
- Is the product coming out at the end of the process good? I don't mean MVP which tends to mean "mostly stable", "does what the PM/developer says it should do", "passes QA", or "didn't crash when the CEO/product owner played with it." What is your measure of success?
Product design and development is never as neat and clean as people plan for beforehand or remember after the fact, and anyone that promises a perfect process that involves people with thoughts, ambitions, feelings, and egos is either naive or selling something.
•••••
When we were designing the Xbox 360 in the early 2000's, there wasn't much talk about Agile quite yet. However, the Xbox team had a different culture and attitude from the Microsoft of the early aughts. We moved fast, experimented, tested often, and pretty much did what we could to design, build, and deliver a product at the end that we could all be proud of.
We understood and bought into the vision. We had a good sense of who we were, and we felt like we knew who we were designing for. We didn't have a step-by-step recipe book or set of guidelines to follow. We used our design judgment as a baseline, but we depended on dogfooding, heuristic evaluations, and in-lab usability testing to validate. It was almost a two year design and development schedule, and over that time we did dozens of heuristic evaluations and over 25 in-lab usability tests of 8-12 participants each using an iterative design-build-evaluate process. Some parts of the product had multiple rounds of testing and iteration, some had light validation testing, and some had none at all. It sometimes got messy, but we were giving it 110%.
The Xbox 360 console, controller, and dashboard user interface at its launch in 2005.
We knew we had a special culture that was enabled by everyone, from our leaders to the front line. Design was included and respected, and our processes were established with all the disciplines' involvement. We were physically separated from the rest of the Microsoft corporate behemoth which gave us not only physical buffer space, but philosophical and psychological space as well. It gave us license to do things a bit differently. We may not have created a perfect product, but we felt like we created a magical one.
To this day, I feel that we created a great product and brand because of it. Many of us who were part of this experience consider it an amazing accomplishment to be rightfully proud of.
•••••
So the next time someone says they have a new process they want you to implement, take a step back and think about it this way:
- Lead with culture.
- Enable with process.
- Prove with product.
By culture I mean the organization's people, their values, attitudes, and principles. Who are you, and why are you here? What do you want to stand for? Are all the disciplines (especially design!) involved and empowered?
Then figure out the right process that best enables the people in that culture. If the people know what their shared goal is and they are empowered to figure out how to get there, you maximize the chances of that process having the desired effect.
And lastly, prove it by delivering a great product. Make sure that how you're measuring success actually encourages people to make the right decisions. No matter how much you say that you have the best team and best process, if the product is crap, nobody cares. I've talked to too many people who tell me they've implemented Agile but can't show me a good product or result at the end. "Oh that's because management did this" or "marketing decided that" or blah blah blah. If any of that is true, then your development process wasn't the problem.
The goal shouldn't be to implement Agile or whatever process du jour that the manager has read about recently. If Agile is actually the right approach for your team, then go for it, but make sure that you're going into it with the right expectations and that you don't make the mistake of following the letter of the law but ignoring its spirit.
Your goal should be to enable your team to work together to create a great product and user experience. Create something good, but make sure that you're equally as proud of how you get there.