Processes and practices are nothing without principles

During the last 10 years, quite a large chunk of the developer community in Sweden have evolved with the help of Agile (and, recently, Lean). This means that almost everywhere you go, IT departments are inspired by this fairly new approach to development. And quite often people have implemented different Agile techniques in their processes, making the turnaround times smaller and collaboration better. But, in too many cases, people try to do “Scrum by the book”, copying the methods and techniques without questioning, without adapting them to the situation at hand. I’ve seen many companies saying “Yeah, sure, we’re doing Agile, we have our daily scrum every morning”. You can probably guess where I am heading, just by reading the title of this rant, but before that I have another tale to tell…

The UX community have, through the years since its birth, been wildly influenced by both cognitive psychology research and design (as in creative, graphic design in the ad agencies) as well as traditional IT methods. The psychology foundation has given the UX practitioners a firm method base to stand on, but (and I do say but) the ad agency heritage had made the UX practitioners heroes of design, working on their own, producing wireframes and other deliverables like magic. When UX:ers entered the old IT world of the waterfall method, this malpractice was enforced, it was easy to set up shop in the silo named “The Design Phase”. This way of working was also taught in the human-computer interaction courses. I am not passing blame, only telling it as I actually lived it and taught it this way myself. Everything could be solved by just applying a bunch of techniques in a certain order, that was the message I used to preach.

Then combining Agile and UX should be as simple as shoehorning in the old UX methods into the Agile iterations, right? We’ll just do our pixelperfect wireframes that we will deliver to the developers a bit quicker than we used to do. But, all that shoehorning only gives us blisters. Putting a lot of thinking in the design is needed, we have learnt that, to build the right product. The complexity of the analysis and design phases are high, there are a lot of things that needs to be set before we deliver what shall be implemented. (This is by the way also true even if we use an Agile method.)

So, we add a long Sprint Zero before the developers start implementation, thus going back to the waterfall-style design phase were we feel comfortable. We continue throwing documents over the invisible but oh-so-tangible wall. Some teams have found that doing design one sprint ahead helps, and it does, but it is still throwing documents, albeit smaller ones.

Going back to the Agile peeps from the first paragraph. They too are trying hard to make the methods work for them in their setting. Their management are telling them to work faster to be able to deliver on a certain date. But things like on-time and on-budget delivery or even high quality aren’t helpful if you’ve built the wrong thing. I guess I said that already.

Scrum, Extreme Programming, Kanban and the rest of the Agile and Lean methods are actually frameworks. Frameworks with the purpose of upholding the 12 Agile principles. These principles shall lead the way to better products through things like better collaboration and motivated people. We have to understand why we are implementing a certain method. When we have understood that, we can pick the practices we see work towards the principles and for the specific product we are working on right now. So, following principles, working smarter instead of faster, will in the end make us work faster while maintaining depth and quality.

But to make sure that we are doing the right thing, we must constantly fight. It will not be enough taking a 2-day-long Scrum Master course to know what methods and practices are the correct one, we must constantly inspect and adapt. Our tool for that is 改善 – Kaizen, continuous improvement. If someone tells you that Agile is to have a Daily Scrum each morning, I can tell you they are wrong, but if they say it is to have a retrospective every week (and react on things said there), then they are on the right track albeit not totally there yet. UX practitioners can use this tool as well, to adapt their methods (we really have a lot of them) to the agile ones. Inspect and adapt.

Through inspecting (reading about or discussing methods and trying them out in an agile setting) and adapting (them to the situation at hand), I have found a few principles that seems to work for me. They might prove a good starting point for you. My goal for these principles is to deliver actual value through collaboration, building on the Agile principles.

• • Stop delivering deliverables, deliver value.

    User research and design that is continously communicated to the team and the stakeholders give a lot more value than a wireframe in a document. Use the Build-Measure-Learn-loop from Lean Startups  to make sure that you are always on the right track instead of trying to validate only when the product is “done”. You should always look at your product as a hypothesis that can and should be validated as soon as possible. Building a minimum viable product and throwing it away if it proves to be the wrong thing to build gives validated learning, and that is more valuable than anything else. Eric Ries argues that “Success is not delivering a feature; success is learning how to solve the customer’s problem”.

• • Let go of the hockey rink boards and sketch early

    Short feedback loops. The quicker ideas are visualized, the faster you get feedback. Use pen and paper. Stay away from cumbersome Adobe products. Or as the Agile manifesto says: “Simplicity – the art of maximizing the amount of work not done – is essential.” Be transparent. Put your sketches on a sketchboard and let everyone give their comments. Of course, you as a UX:er is the expert, your final decision is what goes into production, but all input is good input. Yes, the ice is slippery, but you can do it!

• • Collaborate collaborate collaborate!!! (Paraphrasing Mr Ballmer)

    Create the possibility of collaboration everywhere. This will make you able to dig in deep, to iterate design as much as it is needed, but with a lot higher speed. Dare to step out of your silos. Pair design with developers, bring them with you on usage tests, involve everyone in the product team in a design studio-session where everyone can try out their ideas. The possibilites are many and should be taken. Everyone wants to work on something tangible, and what is more tangible than a mockup that you’ve built together. As a UX:er, you change role from being a design to become more of a design facilitator. This will build trust and team spirit. It’s not only “developers developers developers”, but they can be a lot of help in situations you’d never imagined.

• • Get out of the building 

    Meet actual users. Jeffrey Liker says, in The Toyota Way, “In my Toyota interviews, when I asked what distinguishes the Toyota Way from other management approaches, the most common first response was genchi gembutsu [go and see] […] You cannot be sure you really understand any part of any business problem unless you go and see fo yourself firsthand.” This should be a no-brainer for a UX practitioner, but we tend to do it in large scale and quite seldom. Have a “user-day” every week, even if you do not have anything apparent to test. It’s worthwile just sitting down and talk for awhile. Don’t make a big thing out of it, make it normal.

• • Continuously improve

    I’ve given you examples of what works for me. Now, try it out yourselves. Inspect and adapt. 🙂