What does "Agile" mean for design?

There is still a lot of confusion around what "Agile" means in terms of software development. There is even more confusion now that Lean has been popularised. Agile is really not a complex thing to define, in fact the Agile Manifesto does it perfectly: Principles behind the Agile Manifesto:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Business people and developers must work together daily throughout the project.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Continuous attention to technical excellence and good design enhances agility.

Simplicity--the art of maximizing the amount of work not done--is essential.

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Things to debunk when you hear them:

• "We don't do the full Agile thing, we pick the bits that work for us" - the Manifesto is non-negotiable. If you're not following these principles, you are not being Agile. You might have very good reasons for doing so, but it's still not Agile. There are degrees of Agility though...

• "We are Agile we use Scrum and Kanban and <insert tool here>" - Using tools developed for the Agile team does not make you Agile, in the same way that buying a Chris Boardman bike does not make you a world class cyclist.

• "Agile is a process/method/framework" - Agile is a philosophy

• "You start with the backlog" - You start with creating the backlog

• "Agile is faster" - Not necessarily, it takes the time it takes

• "Agile scales naturally" - Not necessarily, in some cases it can be very hard to scale

• "If you use heavyweight tools, you can't be Agile" - You can still be Agile and use Prince2 for example

• "You're either Agile or waterfall" - It's not a binary choice, there are degrees in between

• "It's always the same Agile environment from project to project" - Needs will change according to the team so let them structure their environment

• "You can't do Agile with remote teams" - Yes you can, you need to create a working environment (even if it's virtual) that works

• "Agile means you never have to write documentation." - You will need to sometimes, it's about having just enough

• "Agile is simple" - It seems deceptively simple when you read the manifesto, but it takes time (and patience) to put in place

• "You can learn Agile from a book" - Nothing teaches you better than being part of a truly Agile team

What about Design then?

The Agile manifesto mentions design once, around self-organising teams. Having design as an integral part of a software delivery team is new to a lot of companies, and there are still a lot of problems in teams around how to work with the designer. Designers are not all the same: they have different strengths, come from varied backgrounds, and have more or less experience with software teams. While some of them will be a good cultural fit for software, others will struggle. If you have been trained to have ego about your work, and to never show anything until it is perfect for critique...then Agile is going to be a big change.

Lindsay Ratcliffe wrote a manifesto in her book "Agile Experience Design".

Agile Experience design is:

Inclusive rather than elitist

Emergent with direction rather than upfront

Integrated and collaborative rather than handed of the fence

Considerate of customer, business and technology needs rather than biased toward a single factor

I see this manifesto as supplementing the original Agile manifesto. Striving to uphold these values and ironing out the creases is all part of the fun, all part of learning what works and what doesn't. Different teams need different tools, processes and people. What works for one may not work for another even if the circumstances are similar. These manifestos help us stay true to Agile, when we have decided to adopt it. How you go about that is another matter entirely!

 photo credit: jakuza via photopin

5 common "lean" misconceptions

Eric Ries wrote "The Lean Start-up", a book that has hugely inspired people from all sorts of industries and backgrounds. His Lean Start-up methodology is pretty much world famous by now. "Do one important thing: make better, faster business decisions. Vastly better, faster business decisions. Bringing principles from lean manufacturing and agile development to the process of innovation, the Lean Start-up helps companies succeed in a business landscape riddled with risk." (Eric Ries)

There are however a lot of things that get misunderstood, so I decided to list here the top 5 that I encounter most commonly (not necessarily at work, but also with friends).

1. "Lean" means "cheap"

Lean is about reducing waste and being super efficient, it has nothing to do with your budget. If you have $50 to invest in your new product, then it might not be enough depending on what the problem is that you're trying to solve. Then again $500,000 might not be enough either! This is far more about learning quickly what works and what fails. If you hire a cheaper, inexperienced team to build your MVP, it will cost you more later down the road. It might be cheaper in the long run to hire in a very experienced, much more expensive team to do the work. You're more likely to get something you can test much faster with them, plus it'll be high quality and this is important.

2. Lean is only for software start-ups

You can apply this methodology to any industry and any size of company. The bigger your company is and the more history it has, the more you are going to have to think about change management of course. People love a fresh idea and usually get very excited about thinking about a new way of working. What tends to happen is when the reality of it sets in, there can be resistance. This is only natural, change is described as the root of all human suffering after all. Don't underestimate the change that your organisation may have to go through. Factor that in early and use lean to figure out a way to proceed.

3. Minimum viable product (MVP) is quick and dirty

It is simply a product with the minimum features required for it to function as intended. It needs to provide enough value to users/customers, and your code needs to be good enough to maintain and build upon. Otherwise you are setting yourself up for problems and high costs later on (i.e. you'll need to rebuild the entire codebase.) You are not going to be able to test hypothesis in a timely manner if it takes 2 weeks to make a change. This will slow down the whole process and before you know it you'll be in an unhappy place. You are still going to need to think about branding, SEO, communications and all that stuff too, or whatever is applicable to your solution. It is not a case of "build something crappy and they will come". Think high-quality and high-discipline, but only on the minimum features required for you need to test your idea out. There's a whole bunch of stuff that will still need to get done that has nothing to do with features too.

4. "Customer Development" is just feedback

If you are going to use Lean, then you need to get on top of proper user testing methodologies, and apply them effectively. You can't invite 3 people in every week and just ask them what they think. You have to test by seeing how they interact with the solution. You will also need verbal and emotive feedback. There are a lot of ways to do this well. Throwing down some poorly thought through questions in an email and calling it a survey is not going to fly. The point here is not always to validate your hypothesis, but also to find out what you don't know. A user interview is not a chat. You need to plan and prepare for this so that you can rely on the information that you are getting out of it.  A focus group is not usually the most effective way of getting information. Get users in regularly to work with the team on what a good solution looks like from the beginning, and vary the types of users you invite. See extreme users as well as those who fall in the middle and those who don't see the point in your invention. Don't spend all your time talking, get them to draw, prototype, role play the solution and watch and listen attentively. If you have never done this, either step onto that learning curve or hire someone in who knows how to do this.

N.B: It's also not just about what the user wants, but also about what's viable financially for you, and what's feasible technically too.

5. "pivot" means throw the baby out with the bathwater

You need to validate your idea properly and accurately. You should do everything you can to check your assumptions, and if they prove to be wrong, you need to drop the bits that are not working…not the whole thing. If you decide to abandon the entire project and start an entirely different one…that's not a pivot. It may be exactly what you need to do, but it's  new start. An important bi-product of lean efforts is learnings. Make sure that you use your new knowledge effectively, this is valuable stuff. Ensure that your analytics are set up properly before using them to make business decisions, and ensure that you are not misunderstanding what they are showing you. As a rule of thumb, I think that you should always make business decisions based on at least 2 different sources of data (e.g. your web analytics and also real user testing).

6. Bonus number 6: "Just start and we'll figure it out later"

A lot of people are eager to jump in and start laying down code or drawing up  solution straight away. In some cases there's nothing wrong with this (in fact in one case it was the only right thing to do), but for most of those I have witnessed, it was not the right thing to do at all. You need to make sure that you understand the problem space as much as possible before investing further. Resist coming up with solutions until you have thoroughly understood the entire problem. This is going to either save you time and effort, lead to an even better idea, or/and save you a lot of unnecessary expenditure.

What you are trying to understand is whether the problem is worth fixing or not. It takes as much time to solve a bad problem as it does a good one. Don't waste your time.

Take the pain out of failing

A lot of us have the joy of working in Agile environments and have all read, heard and learned that you should "Fail fast and often". The idea is basically that if something isn't going to work, it's better to find out as soon as possible, and learn as much as we can from it so that we can move on and focus our energy on something that will work. It doesn't mean that we set ourselves up for failure, quite the contrary, we try to do everything we can to ensure success. The problem is that if you are working in an innovative space, or say, in a well defined space that you're looking to disrupt, it's hard to guarantee success off the bat. What's interesting to me, is that we don't like to fail. I have yet to meet someone who really relished in this. I know a lot of people who can see the value in failing, and are comfortable with the fact that it will happen and that we will learn good stuff from it. I don't see anyone celebrating when it does though. People swear, wring their hands, shake their heads, some even cry. But  I think we should celebrate. That we didn't get to where we intended to be is not important. We may well have been striving for the wrong things, or looking at it the wrong way. It was not going to work and we found out early. Surely this is good news.

The idea I think, is to focus on going forwards, without being attached to the outcome. The pain, the anger, the fear, the emotions that are so often felt during failure are those that come from that.

If we can be excited about the journey, about what we are actually doing rather than where we are expecting to end up, then we can really let go of the attachment to the outcome and enjoy this unique process. The beauty in this is that when we do succeed, the outcome is a true celebration rather than an expected situation that we take for granted.

Pairing for designers (Agile)

  It's important to collaborate because it allows the team to become a powerful unit, full of common knowledge and questions. Each individual has a clear view of what is going on and has the power to affect the product direction and evolution. If as a designer you do not collaborate with the rest of the product team, you essentially deny yourself this right. By pairing with the QA, (front and back end) developers, BA, PM and anyone else who is part of your team, you gain all of the necessary perspectives on the project to really understand the product you are making. You should ideally always be working with another person and never alone. This allows the team to cut out a lot of time draining and uninspiring inter-team formal communication, and actually focus on the product.

More importantly, the design then belongs to the whole team, and is no longer treated like a sacred cow.

How to pair with a developer:

You will need a whiteboard and a few whiteboard pens, a shared screen and a mouse and keyboard between you. Use the whiteboard to communicate your design ideas, and work together on solving design problems that crop up and technical problems that you encounter as well. This way you are designing that is feasible technically, every single time. You don't have to have meetings about the design, where you show wireframes or photoshop files. You don't have to have talk about possibly trying this or that to get over a hurdle....you can just do it right now, together. Experience design needs to be user-centered but also technology centered. Weirdly enough, a lot of designers forget the latter. If you need you need to make something in photoshop to go into the design, then do it together and then make it into working code right away. Working this way is a LOT of fun and the product that you are making comes to life quickly. Your client will be super happy because you have made something tangible in record time, and you now have something that works to put in front of users. Yey!

It is tough though. Be prepared to sweat. As a designer you have to know your job well enough to do it on the fly with little preparation. You have to let go of perfectionism and aim for a minimum viable product that still fulfills your user needs. Remember that you will iterate. Better still, because you have a working product to put in front of users really quickly, you can include solid feedback in the next iteration and not make all those features that nobody ends up using.

Why you shouldn't code (even if you can):

The whole point of pairing is that you can share the load together, and bring a wealth of expertise and experience to the product. Imagine that you are designing a login screen. It's always useful to start with the action, so tell your programmer pair to make a login button. While s/he is focused on the button, and on the minutia, you are focused on how the entire design hangs together across the whole product...all the other screens that you know about, and all the design decisions that you are about to have to make. You are the big picture person and the other is the small picture person. If you are coding, you will pretty much only be focused on that button. While that button is being made, maybe you are drawing out the login interaction on the whiteboard and the next screen.

Where to start?

"Build what you can with what you know" is the slogan I like to use. It is tempting to want to get all of the information about everything up-front, but the reality is that by actually making something you put yourself in a better position. You can modify, start again or carry on the next day. Iterate. remember that there is never really such a thing as an "End product" because if it's any good, it evolves and there is no end. The more you think about it, the more the whole team thinks about it...the more it is misunderstood by the team. Everyone forms their own assumptions and ideas of what it is and how it works and what it looks like. It all becomes more like a field of dreams. Sometimes we even agree as a team, whilst all thinking we are agreeing to whatever we each have in our heads. Actually we are more confused than ever before. Keep it tangible. Make the product now and keep making it. When you talk about it, point to it. Everyone can see what it is, what colour it is, what shape it is and how it works. It couldn't be clearer. All of your focus should be on your product and not on your process. Show your work often to your client, and let them use what you have made so far. It makes for a better conversation than a meeting that refers you to wireframe 180(a).

But what if it's all wrong?

Throw it away and start again. You are throwing away some code, that's all. This is far preferable than the potentially huge cost of  a design lead time (where developers are twiddling their thumbs waiting for you to come up with a design). You may have made some mistakes or maybe yes, t is all wrong, but by collaborating you now have shared experience as a team, you have learned to make something together, and you have probably alos won client trust because you have shown that you can make something that works in a morning rather than a week or month. Even if it is wrong, you have failed fast and learned something valuable from that experience. The team will be a lot closer. You will share your valuable design knowledge with team members and learn things from them as well. You all win. A lot is to be gained from jumping in and making something that is wrong rather than spending a lot of time making nothing, trying to fill in all those gaps (we talked about those in the last post). At the end of the day, you might find that you have pursued 3 different approaches and made all of them in the same time it would take to go away and wireframe everything meticulously on your own.

What if you have layers of management to get approval from before you can make anything? 

Working in an Agile way requires the client to work closely with you, so that you can make decisions quickly. If your client is very removed from your project, then it will be hard to be Agile. You will have to make documentation that gets sent up the management chain for approval and this might take some time. In this case, you have fallen into a waterfall. Fear not though, this is fine. As a good BA friend of mine says: This is exactly the situation for which waterfall was designed for". If this is not the way you and your team want to work, then you need to have a chat.

How do you ensure that the product remains user-centered and ends up being right?

If you are in an Agile environment, you need to ensure that while you are making, you are also discovering and learning how best to evolve your work. The diagram below shows that you should be focusing all of your energies around the product. The further you are from actually doing code (making), the further you are from the center of the concentric circles. Tasks on the outer rim might include user interviews for example. That isn;t to say that these tasks are less important or devalued, they remain deeply and crucially important, because they give you direction and ensure you make the right thing. Anything in between the outer disc and the inner one are things that...we...fall in between. To ensure that you are not just blindly making or lost in a world of research and no making you should be working on tasks on the outer and on the inner discs simultaneously. The stuff you do in between is up to you. Additionally I split the whole thing into examine, define, create, verify. Most tasks will see a full revolution.

To finish: Cultivate Li:

Jade cracks along its natural contours, which adds to the artistry in working with it. Jade carvers incorporate the breaks into their work, bringing into evidence the natural elegance and great beauty of these lines. They are said to rely on the stone's natural "Li". Each and every project has its own "Li". Allow it to be there and learn to work to turn all of the challenges into something beautiful in the end. Take advantage of them. Drop the fear and the resistance, trust the integrity  and capabilities of the team. It takes more than just your immense capacity to make logical decisions to succeed. You need to be invested fully so that you can trust your instincts, trust your heart and trust your gut. (More about "Li" in this excellent book: "Awake at work")