Andrew Cox

Declaring Chapter 11 Bankruptcy

I’m following Seth Godin’s advice of declaring Chapter 11 Bankruptcy on a number of my commitments.

At the beginning of the new year, I established my foci for 2011. The intent was to consciously plan how I was spending my free time. So far, I’ve been very successful in focusing on the things that matter to me, but I have also developed a growing list of commitments.

I’ve just gone through the list of things that were hanging over my head and declared Chapter 11 Bankruptcy on 5 of them. Most of them are personal, but I did finally admit to myself that I will not be trying to run a sub-5:00 mile barefoot this year.

I feel better already.

With the weight lifted, I can now focus all of my energy on my most important pursuits. What could you declare Chapter 11 on?

Agile Product Ownership with Jeff Patton

I just finished a 2-day course on Agile Product Management led by Jeff Patton, one of the foremost authorities on User Experience and Agile Product Development. It was arranged by Jon Stahl of LeanDog and hosted by Matrix Solutions in Pittsburgh. Although this was a Certified Scrum Product Ownership course, almost all of the principles apply to any Agile project.

I met both Jeff and Jon at the 2009 Simple Design and Testing Conference here in Pittsburgh. At the conference, it was Jeff’s paper airplane Kanban simulation that gave me my first taste of Kanban. I started Kanban with my team a few months later and have been doing it ever since.

It’s hard to distill 2 days of Agile training into a blog post, so I’m not going to try. Instead I’ll give you my biggest takeaways from the course.

My Agile background

From a functional perspective, the best way to describe what I do is “UX Developer”. My team is responsible for both the User Experience and development for our user-facing web applications.

At my company, our project methodology looks a lot like Waterfall with Agile in the middle. We do requirements and software design up front, some Agile development in the middle, and then finally documentation and testing.

Within those Agile development iterations, we use a host of Agile, Lean, XP and UX processes, such as:

• Collaborative Design Sessions (aka Design Studios)
• Personas
• User Stories
• Story Point Estimation
• Kanban
• Product Backlog
• Daily Standups
• Retrospectives
• Pair Programming
• Test Driven Development
• Continuous Integration

I can say that my team has been very receptive and happy with all of these practices (though some took longer to adopt than others). What I hope is that we can bring the requirements and testing phases into the Agile fold. Fortunately, we have support from product management now to pursue a more Agile development process. This course was the first step in that direction.

Questions I had before the class

I’m a big believer in Agile, but there were some questions that I haven’t found satisfactory answers to yet:

• How do you manage non-functional requirements?
• What is the right level of detail for a user story?
• What (if any) permanent design artifacts should an Agile project create?
• Where does documentation fit within an Agile project?

Things I learned

Aside from a lot of little insights and explanations that helped solidify key concepts, these were the big items that I took away.

User Research

As a UX practitioner, one big piece of the puzzle that I’ve realized we’re missing is user research. Working at an enterprise software company, our users are not readily available. Instead, we rely on user “proxies” within our own company to find out what our customers need and how they respond to the applications we create.

The importance of going out and talking with users within their own environment was made clear to me in this video about the world-famous IDEO design company. They showcased their design process by trying to design a better shopping cart in a week:

We had already identified the need for developers and UX folk to get more direct exposure to our customers and potential customers, but this aspect of the course really hammered it home for me.

The role of a Product Owner

According to Jeff, the traditional role of a Product Owner in an Agile project typically fell to one person who was the voice of the customer. But, in a software product company, the Product Owner should be comprised of three primary roles, each with their own responsibility:

• Product Manager - business value
• Development Architect - feasibility and innovation
• User Experience Expert - usability and desirability

This team of “Product Owners” has the joint responsibility for:

• Determining what functionality goes into each release
• Managing and prioritizing the product backlog
• Reviewing quality and progress at retrospectives

User Story Mapping

I’d read about user story mapping before, but I’ve never tried it and it didn’t resonate with me until Jeff explained it and had us try it out with a real problem.

User Story Mapping is about visualizing all the steps a user does to gain value from the system. It forms a narrative left-to-right with sub-tasks or details filled in below each major action:

There are two really important benefits of a story map:

1. It forces you to think in terms of how a user will use and gain value from an application, as opposed to just feature sets.
2. It makes you really think about what a Minimal Viable Product (MVP) is.

If you get the user story map right, you shouldn’t need to estimate releases. Of course, you should still be able to estimate when you’ll get done based on your velocity, but if you’ve truly mapped an MVP, you don’t need to set a release deadline and then back your way into it with feature sets.

If you haven’t heard of user story mapping or have overlooked it, I encourage you to read up on it and give it a shot. I can’t speak from experience yet, but it’s one of the practices that I plan to start very soon.

Collaborative Acceptance Criteria

This is the simple idea that a cross-functional team determines what the definition of “Done” is for a story. It’s not the tester’s job to discern acceptance criteria from a requirements document; the acceptance criteria needs to be agreed upon by the developer, tester and product manager.

The big wins from my perspective are:

1. Testers get the information about how a feature should work directly from the developer and product manager.
2. Developers learn the way testers think and what common failure cases they look for.
3. Acceptance Criteria can be a substitute for a formal Requirements document.

Retrospectives

My team has regular bi-weekly retrospectives, but they aren’t as structured as Jeff suggests. There were some new ideas to me here that I think are really great, such as:

• Do a walk-through of new functionality and note any UX or functional issues
• Rate the features, code, user experience, and quality on a scale of 1-5
• Review velocity and note reasons for any major variations
• Identify any new risks or user stories

By having the walkthrough as the focus for the retrospective, all concerned parties can raise any issues or help steer the direction of the next iteration.

One of my favorite aspects of this is that the UX representative gets to point out any minor cosmetic issues and get them fixed immediately. Boy, I wish I could’ve done that on the “form gets too wide on wide monitors” bug that’s continually de-prioritized in our backlog!

What about my questions?

So did I get my major questions answered? Somewhat.

Non-functional requirements need to be addressed within the context of user stories or epics. A good example is authorization. This should be rolled up into the “User logs in” epic. “User logs in” might have seemed like a small story initially, but when you start decomposing it, you realize that there’s a lot of hidden complexity under that story.

User Stories paired with Acceptance Criteria sure look like they can take the place of permanent formal requirements document. Well-written Cucumber features might be able to fill this gap as well, but I need to think about that a little more.

I have a better understanding of the dark art of creating good user stories and decomposing them into smaller tasks, but realize that it will also require a lot of practice.

And what about our poor documentation team? I didn’t bring this one up explicitly in the class, but I’ve been thinking about this problem for some time. For new products or new large features, I think documentation time has to be added to the end of the project schedule and given ample time along with any other rollout rituals (marketing, training, etc).

One thought that occurred to me though, is that the documentation can evolve along with the development work, but at a level of fidelity that’s just a bit behind the actual product. I’m imaging the documentation could be fleshed out at more of an outline level as the project progresses, serving as both proto-documentation for the eventual users and internal documentation for the project. There’s a lot more to say about this subject, so I’ll just leave it at that for now.

Conclusion

I knew this would be a great opportunity to learn from Jeff, but I learned even more than I thought I would in just 2 days. A training opportunity like this gives you an extra level of insight and interactivity that you just can’t get through books, blog posts or conferences.

There were a ton of other great concepts and ideas in the course that I didn’t mention above. Whether you’re an experienced Agile practitioner or just starting out, I can’t recommend this course enough.

Oh, and another big win for this training course is that Jon Stahl has kickstarted PittsburghAgile. Judging from the early sign-ups and people waiting for an Agile group on Meetup, it looks like there is a significant amount of interest in Agile software development in Pittsburgh. Our first meeting will be at Bettis Grill on Wednesday, April 6th. Join up on Meetup.com or follow me on Twitter for updates.

Further reading

My manager and I were eager to share these ideas with our office, but not sure of the best way to transfer our newfound knowledge.

I’m going to put together a list of “Core Agile Processes” that I consider to be fundamental to practicing Agile. Until then, here are some resources that I’ve found helpful:

• Agile Manifesto - Agile is more of a mindset than a set of processes. Start here to ground yourself with the fundamental principles.
• Kanban Development Oversimplified - awesome intro to Kanban as well as the best of the “Agile buffet”
• User Story Mapping
• kanbandev Yahoo! Group - great place to lurk or ask questions about real issues you’ve faced with Agile adoption!