Tag Archives: agile

UX and Project Mangement cross-over article from Interactions magazine

Posted on by
Reply

A Taxonomy of Models Used in the Design Process by Joanne Mendel in the Jan + Feb 2012 edition of Interactions magazine is pretty interesting.

At Covenant Eyes we’re continually in the churn of Agile development, and integrating user experience work can be challenging. We’re figuring it out, and have definitely made some breakthroughs, but this article has provided another perspective that is helping me think about timing of user experience work within the loose phases of work that a typical project runs through.

It isn’t a stretch to layer the phases of Discovery, Reframe, Envision, and Create over a project’s lifecycle, and so tying different models for design work in each phase provides an opportunity to reflect on how we’re doing with matching up appropriate design work.

I’m asking my team and our project managers to read through it, and perhaps we’ll get a chance to discuss it together and consider if we can use some of the ideas to do better work.

Does Kanban hurt Agile teams by decreasing iterative development?

Posted on by
3
Workers welding on an automobile assembly line.

Kanban/Lean manufacturing makes sense for factories. I'm not sure how well it translates to web and software development.

Kanban is a balm now being used by some Agile development teams to soothe the pain caused by timeboxed development cycles. Jeff Patton’s statement, “Short timeboxes herniate,” sums up that pain (from his excellent post “Kanban development oversimplified”). As a Product Owner with a team that started out using Scrum and has gradually drifted to something else, I identified with all those critiques of timeboxed development.

Management expected the team to deliver user stories every week because our iterations were week-long. So when the team realized at mid-week that they wouldn’t be able to deliver a story by Friday, the team would pick up a small bug to fix just to show something by week’s end. That’s a problem. As a Product Owner I saw this mid-week “save” for the sprint review as pure distraction from more important work. So we dropped the weekly delivery requirement.

When I read Jeff’s article, I realized that the way we were working looked more like Kanban than it did Scrum—except we were still using Scrum words and concepts to discuss and analyze our work. Words like “iteration”, “sprint”, “daily scrum” no longer fit.

As a team, we had let go of the expectations of a sprint, and we were still delivering great value, just on a more natural timetable. I believe our efficiency stepped up when we ceased adhering to the rules of Scrum.

However, because we still spoke in Scrum phrases, our company had not followed-suit. Frankly, without a name and model for what we were doing, we weren’t sure ourselves.

Months have passed since then, and some Kanban ideas have seeped in to our work. But we haven’t embraced any change, really.

Why change? Despite the problems I’ve alluded to, the team is really doing great work. They are delivering value to the company and its customers. So one argument is to simply continue on our course. The other is that we’re already practically doing Kanban, so why not start using words and tools that match?

In my brief review of Kanban, I see that it comes from the Lean Manufacturing philosophy. How it is being used in the Agile world is really taking Kanban as a metaphor. It is adapting a model from the manufacturing world and applying it to the software development world. I’m naturally wary, and so want to critique this adaptation for the sake of clear-headedness.

First, let me admit that of all the Agile flavors, Kanban seems the most practical to me. I’m a fan. That said, software development is not an assembly line. We don’t deal with pre-designed units like car doors. Instead, we have a variety of problems and need to be able to design a system to appropriately handle whatever those problems happen to be.

Whereas Kanban works well for an assembly line that puts the cars together, software development looks a lot more like the design shop that engineers and prototypes new car concepts or revisits problems with existing cars to make them more efficient and safer for the next model year. Sure, we produce applications, but a whole lot of the work is really design work.

Design work tends to be iterative and recursive, but I don’t see words from Kanban that support iterative work. In general, a card moves from left to right across the board. Sometimes, the card ought to be killed and restarted with the  ideas we’ve learned during it’s first round. However, from what I see of the Kanban model, this just doesn’t happen. (Not that is happens in Scrum either.)

Why is that? Maybe it’s because coding is expensive and we suffer from the sunk-cost bias. That seems like flawed thinking.

Maybe, as I wrap up this half-thought-out post, I’m simply frustrated by the lack of deep design work in our projects.

More later. I’ve been thinking of the design process with insights from some recent research and articles seen via SIGCHI, and it may result in some design management postings.

Anyone else have ideas to share here?

Let’s stop playing Frankenstein

Posted on by
Reply

Consider the monster from Mary Shelley’s Frankenstein:

The creature is described as being about eight feet (244 centimeters) in height, with translucent yellowish skin that “barely disguised the workings of the vessels and muscles underneath”, watery, glowing eyes, flowing black hair, black lips, and white teeth. (http://en.wikipedia.org/wiki/Frankenstein%27s_monster#Appearance)

I read that phrase describing the skin of the monster, that it “barely disguised the workings of the vessels and muscles underneath.”

My hands have worked on Web pages that were little more than that yellowish skin.

It’s no wonder customers fled in terror.

By now, most of my nameless monsters have died off, thanks to the hyper-life-cycle of the Web, but recently I gained a new perspective of how ungainly, ill-proportioned Web sites are created.

HOW TO MAKE A MONSTER OF A WEB PAGE

If you want to create a monster of a Web page, the trick is quite simple: Work, work, work at it, one page at a time. Write the code, make it work, make sure the forms submit. Whip up some error text, insert some confirmation screens. Check the boxes on your to-do list of functional requirements. Light it up, and let it out onto the world.

But wait…isn’t that how most of us get our jobs done? These days, we like to call this kind of heads down, busy-work “Agile.”

HOW TO STOP PLAYING DR. FRANKENSTEIN

Step away from the keyboard, Doctor.

Pick up a pencil. Draw out the whole process from the point of view of each actor, be it a person or some agent like a search engine robot. Draw pictures using easy graphics, like Garrett’s visual vocabulary palette, and be sure to include every point of contact with an actor.

Having done this recently, it became clear immediately that there was a series of email messages interspersed amongst Web pages, and that those emails were as important as any single Web page.

Also, the timing of those emails was important. For instance, Jim uses a Web page to send an email message to his friend Bob. Jim then sends an instant message to Bob asking if he signed up yet, assuming that Bob did in fact receive that email message and was able to decipher it. Those are two tough assumptions.

Each piece of a larger process overlaps with its adjacent pieces in a series of feedback and feedforward communications. Once we have these communications, these pages, emails and so forth, laid out with balance, proportion, and clear purpose, a more beautiful creation can take hold.

Nurturing and shaping this flow of interactions between people using a system is a great step in putting an end to the monsters we’ve become so good at creating.

Once we’re into this process, we invariably realize there are many more questions to ask, but the point is this: Design processes, not pages.