Edge of Chaos | Agile Development Blog

Kai Gilb started a series of posts that challenge Agile Software Development. Part 2 is about creativity and “how well” focus in software development. While I agree with the problem, I strongly disagree with the solution. Kai recommends to write requirements (the format he uses doesn’t allow me to call it “user stories”) in a form that does not contain solution:

Developers Are Not Product Owners

Then developers should creatively find the ways to implement this requirement, to invent the solution and to solve the “how well” puzzle. We’ve got a huge problem here indeed. Most developers can’t invent solutions at this high level. They can create beautiful architecture and build the quality in. They can write tests upfront and use powerful tools to speed up development. They can do many things, but often they can’t invent a “how well” solution that will make customers happy. Why?

1. Most developers know nothing about User Experience (and don’t care).
2. Most developers can’t create usable design.
3. Many developers barely know a problem domain and in any case don’t want to dig into much details here.

In short, most developers are engineers (so far?), so what Kai proposes will not help. It is just a theoretical solution to “how well” problem. It’s the same like trying to grow 4 hands and 2 heads to double your productivity (well, sacrificing beauty maybe…)

In Scrum Product Owner is responsible for writing User Stories. It means he should invent solutions and care about “how well” thing.  I don’t see a significant problem here. Of course, it’s great if developers are interested in requirements handling and solutions investigation process, but if they are not, Product Owner can do that alone or with special people who care. Who they can be?

Those people are UX specialists. They know how to solve “how well” problems effectively. They know many things about design patterns and all new trends in interfaces. They like to explore problem domain and talk to customers. If you have such people among developers — you are SO lucky! But often this is not the case.

We, at TargetProcess, try to instill UX culture into development process. We started in August, now it’s February and I can’t say we’ve had much success. Sure there are significant improvements, but to be honest most developers are not so interested in UX staff, they like BDD, DDD, C# and SOA more. I expect it will be a long process that will take years. And our company is quite small. I can’t even imagine an effort for such a radical shift in a huge company.

Broad Requirements Are Not Testable

I wonder how you can write BDD scenarios for broad requirements as Kai suggests. How the hell can you test anything, if you don’t have any clue on how it should work? So broad requirements can’t replace user stories obviously. They can live in backlog, but developers should deal with concrete requirements that are testable right away.

I can agree that you can split backlog in 2 parts. The first small part contains detailed stories that can be put to development asap. The second large part contains broad requirements without solutions. That might be a good idea. But we should clearly separate UX phase and Development phase. During UX phase we should solve “how well/how cool” problems, and during development phase we should solve technical problems only (with some corrections in “how well” for sure if required).

P.S. Kai, I hate gray text on gray background in your blog. It is not user friendly.

Books by Edward Tufte are a piece of art. I’ve been savoring them to myself for a while, and now I decided to share some sketches and criticism inspired by Tufte’s high art visual designs.

Commonly, designers represent visual information by scarce means of 2D realm: screen and paper. Our universe is 3D (if not 5D, 6D or whatever more dimensions), but people got used to squeezing  images into 2D flatland.  Even rock paintings of pre-historic humans have their touch of 2-D abstraction and symbolism.

Our universe is not just 3D. It’s dynamic 3D. Paper is static (paper planes are exceptions). That’s another limitation of 2D.

Limitations are great. They motivate designers to find solutions. The more limitations - the harder it is to find a solution. Good designers love difficult tasks, since they view them as great opportunities to put their brains to use. Bad designers do not want to use their brains - they want to use templates.

The image below is a template solution for a weather map. View from above.  Let alone template thinking, the representation of this template is poor.

The appalling hint of white shade is a helpless attempt to compensate inadequate color selection for numbers.  What do you think of blue numbers on blue background? You hate that, to say the least of it. What’s the message of these pseudo-3D grey circles? Are they some grey moons? Or cavities  in the designer’s brain?

Now let’s take a look at the Euronews channel weather map.  One may think that this map represents the effects of global warming and Australia is completely hidden under water now. Also, what do those bold numbers show? Probably the depth of the ocean in this area. In meters. Or in miles? But the area is still lit by sunshine, which instills some hope.

As a contrast, here’s a weather map from a Japanese daily, beautiful in its simplicity.  This is the same Japan as on the first weather map above, only from the ocean perspective.  This map provides 0°C и 10°C  isotherms.  You see fine clouds on this map. The map shows sun movement.  OMG, it shows stratosphere! And it’s nothing more than just a weather map from a daily newspaper  - but created by a good visual designer.

Of course, Japan is well-suited for such a nice graphical representation. But you gotta have guts to catch and use this ocean perspective, instead of helplessly surrendering to boilerplate view-from-above weather maps imposed by paper sheet or screen limitations.

Overall the recent Agile 2009 Conf. in Chicago was a good event. Unfortunately, the first two days were not quite what I expected. Combination of just “OK” sessions and jet lag left me wondering whether the trip was worth it. However, the following two days were much better, but the very last, Jared Spool’s keynote, left no doubts that Agile 2009 was totally worth coming to! An absolute killer presentation on User Experience with an excellent steak on the side (yes, Americans know good steak) – what else could you ask for?  A lightning bolt, a hit, all of the above - I can hardly express how enlightened and inspired I felt walking out of the ballroom where the speech took place. And that’s when reality hit me, and I suddenly understood how bad we suck with our User Experience… I got depressed for about 2 days, but then I started to act.

I read several books about User Experience. I read countless articles, forum threads, blog posts on the same subject and finally started a process of searching for UX specialist to add to our development team (and we hired him already). I’ve dug through all the information about UX, UI, Design and thought about how we could integrate it into our development process.

In one month I came up with a vision. I created interesting presentation and shared my vision with the team and inspired them. They applauded (thank you, folks!). I believe Agile and UX is a great mix. Definitely it is not easy, but I think it is a right path to follow. We want to create the best agile PM software in the world, and it is just impossible without outstanding user experience.

We want to share all the new experience about the journey. I’ll post more about process changes, mindset changes, education and whole team involvement. Here is our first try, see how we are re-designing ToDo list in TargetProcess:

• Personas
• Scenarios
• Wireframes - part I (part II, part III)
• Prototype and Usability testing results
• Improved prototype
• New ToDo list in TargetProcess

• Interesting post from Joel Spolsky The Duct Tape Programmer and even better reply from Uncle Bob. Uncle Bob’s hottest phrase is “I want you to ship, but I don’t want you to ship shit.” I personally like it very much. It is a paramount of software development.
• 10 Useful Usability Findings and Guidelines. Very good list of practical UI advices. For example, do you know that the ideal search box should be 27-characters wide?
• Two posts about how to inject User Experience into Agile development: Twelve emerging best practices for adding UX work to Agile development and Agile + UX: six strategies for more agile user experience. “Unfortunately, the iteration cycle, “agile”, and phrases like “team velocity” were confused with “fast”. The biggest problem with lots of user experience methods is that they’re not necessarily fast. They’re not necessarily slow, but they do take time.”