Agile waterfalls

How to organize the designers: save time, money, and - maybe the world.

What are some success tips for moving from waterfall to agile software development?
~ someone

It’s a little more complex than just ‘switching’ - so, let me get a few things straight.

Waterfall - means

1. Boss or a “creative” “creative director” - comes up with what they think should be made - and ‘sells’ it to the client in a series of meetings. Sometimes - they even do a huge expensive proposal (RFP) with no money upfront! (Yikes).
   
   (keep in mind - that there is no reason to believe this is a good idea / there’s no proof of concept… but the client has already fallen in love with the feeling that the salesperson gave them.)
   
   (things are being priced out already… even though no one has talked to anyone who can truly know how much it will cost)
   

2. NOW - the ‘visual designer’ is going to make something that “looks like a website” - and then they are going to show that to the client - and iterate and iterate until the client feels like they created it themselves - and their pride for their hard work - will set in stone that they created something amazing. Now this team just needs to hurry up and make it…
   
   All of those meetings are really expensive. They usually involved 5 of the highest-paid people in the company - sitting in rooms for over 20 hours. (10-20k?)
   
   (keep in mind - that there’s still no reason to believe that any of the work that has been done - has any value… and that the prices are getting put in place…. and that NO DESIGN THINKING has happened yet….)
   

3. Now there are going to be a bunch of meetings set up so that the team that knows nothing about ‘code’ or programming - can tell the developers how long it should take - and they’ll surely invite the visual designers who will just sit there… quietly…
   

4. There are so many many steps now… but to keep this short…
   
   > an unthoughtful thing got mocked up and sold to the client. It doesn’t meet the true goals of the client… and now: everyone is on the hook to “finish it” - when it never really got started. They might even bring in a UX designer now to create visual mockups that explain how the website should work (after it’s already been sold to the client).
   

5. Everyone will rush to make a ‘thing’ that looks like the photoshop document that the production designer created. Pixels will be pushed. Developers will try to reverse engineer the mess… everyone will be stressed out. There will be many more meetings…
   

6. The project will get “done” - and then an entire phase of “fixing it” will ensue. There will be meetings - and in the end - the goal shifts to:
   
   “anything we need to do to get this thing over with…”
   

7. Then you have a “web-site” - or a “web-application” - that doesn’t do its job, was really really expensive, and that (almost) everyone is embarrassed by.
   
   
   

So - OF COURSE we should move away from this ASAP for everyone’s sake.

But now you have to figure out how… and be really careful! because “Agile” - isn’t a noun. It’s a verb. AND- the “Agile workflow” salesman - wants to sell you a new terrible set of workflows that are just as bad as the waterfall!

—-

Instead - put on your thinking cap. Just be logical - and think things through. Make sure you put someone smart in charge of the next project - and give it a whirl. Give them full control to “Design” and “manage” the product.

However small or large the team is… these steps must take place (even if it’s just one person / or a group of 10 on each task) This person can be called the “product designer” or the “designer” - or the “UX designer” - but it doesn’t really matter… they are in charge of making this thing happen - like a movie producer.

Working in a “Lean” and “Agile” way:

First off: make sure that every single person on your team - has read the following books: (in this order)

• The Elements of Use Experience

• Just Enough Research

• Don’t Make Me Think

• Letting Go of The Words

• Every day Information Architecture

• The Design of Everyday Things

• You’re My Favorite Client

• Ruined by Design

• Rocket Surgery Made Easy

If they won’t read them, fire them.

Steps

1. Ask the client what they want (I know that sounds crazy…)

2. Based on experience: and a lot of listening - help clarify and distill that down into a real goal - that can be measured. “We want a website” is not a goal. “We would like to tell 10,000 people a story” is a goal. “We want to double engagement” is a goal. You can measure that. The client doesn’t always know what they want… so, that’s a design skill that you’re team should have.

3. Do research on the company, on the other things in the field, and talk with users and stakeholders. Document this in a place that is accessible to everyone on the team. (Google Drive is really great / when everyone uses it properly)

4. Based on that research, hypothesize some strategies that might get to the goal.

5. Build out prototypes and start testing with users (tiny ones) (even just drawings on paper) - right away. Even just in the office - or ask your kids or your mom.

6. If this hypothesis seems good… then continue to iterate, if not - go back to 4.

7. At this stage, you’ll be learning more about the project - and you can create sub-goals.

   1. What type of system will you need? Instruct the systems designers (back-end etc.) to put together a prototype of what you’ll need there.

   2. What kind of interfaces might you need? Instruct the interface designers (UX, UI, front-end devs, etc.) to put together a prototype

   3. What type of visual design might be needed? Instruct the visual designers to put together some prototypes (styletiles) (note: not ‘finished’ full production art in photoshop (that’s no longer needed)

   4. Have the UX people and everyone use the prototypes until they are meeting their goals. Each part of the project should have a clear and public goal. Should the type be “playful?” Does it make the viewer feel “excited but supported?” - (might seem silly… but how else can you prove it’s doing it’s job? Every little thing - needs a clear goal / or you can’t prove that your choices are successful. This also helps you sell your decisions to the team and client.

   5. Prove that everything you are doing in in-service to the goal. Test with everyone on the team, with real users, with the stakeholders.

   6. Everything will be BETTER and LESS EXPENSIVE… but you have to trust the process… and you can charge more - because it will bring much more VALUE. Consider pricing on the value you create instead of the hours you spend. The client would much rather have the work done - in 1 hour - instead of 400, trust me.

   7. Surely - at some point, the prototypes turn in to MVPs and the MVPs turn into the real first iteration of the product… but it will never be done. Everyone will test - everything - at every stage. Web-products are born - and not ‘finished.’

8. repeat 4–7 forever.

.

Document how successful this much better workflow works - and you’ll have very little difficulty in selling the idea to everyone on the team. Case studies that showcase your goal-driven design will PROVE your value - and you can spend a lot less time trying to “talk people into working with you.”

.

This is why we don’t teach “programming” - and instead / we teach - “The Design Process” - because it’s timeless.

Don’t work in a Waterfall. Don’t become a crazy “Agile/Scrum” team — Just be a bunch of designers - and design a system that helps you all work together to design and build great things.