Software Quality

January 8, 2010

Code Freeze 2010 – Redesigning Agility

Filed under: Practices — Tags: , — David Allen @ 9:26 pm

In the last 5 years, the University of Minnesota’s Software Engineering Center has sponsored the CodeFreeze conference here in Minneapolis, Minnesota. This year,  Code Freeze 2010, was led by David Hussman of DevJam.  The theme was Redesigning Agility. I found the speakers thought-provoking and a refreshing change because both agile junkies and designers were there. Designers? What kind of designers? Interaction designers, web designers, product designers…

Overall Feel

Some conferences feel like a great rock concert by Kiss. You just want to rock and roll all night, and party every day.

For me, this one felt more like a great concert by Aaron Copland, where they played Appalachian Spring.  They leave a lasting impression on you because they remind you of your humble roots.

Yes, it had some rock and roll moments, like the time Alan Cooper told us to revolt against managers who don’t “get” the agile way of doing things.  Instead, he urged, go straight to your customers and work together, underground if necessary,  to do what is right for your business despite your managers.

But generally, it was a much more thoughtful event for me.  It was less like “Star Wars” and more like “Andy Griffith”.  You know, … deep.

“Now Barney, don’t just run off half-cocked.  Sometimes you need to listen to folks before you start scolding them.  Look at how Floyd cuts hair. He first asks you how you want it. Did you ask the customer how they wanted their hair to look? “

My favorite line from one of the many good speakers

If you are a kindergarten teacher, and your kids ask for cookies and ice cream do you give it to them? To do so would be irresponsible. Instead, you LISTEN to them and realize they are hungry. And you offer them a nourishing meal instead. Are you feeding your customers ice cream and cookies?


Alan Cooper emphasized that personas are useful tools to keep  our analysis and design focussed on user goals, and the value they receive, rather than what features we deliver and how we deliver. They discussed how many agile teams seem to over emphasize delivery issues at the expense of the big picture and business issues. This sounds remarkably like a comment our program manager Ken Cychosz recently made that we need to use more business language in our sprint reviews and planning meetings. I don’t yet know how to strike a better balance between conversations about software delivery and business value. But I agree with those who want more business language.

Story Maps

Jeff Patton and David Hussman spoke about a very practical application of personas with story maps.   I went and applied the ideas the very next day at work.  We had a story we were working on. The technical goal was clear, but the relation to underlying business value was vague.  I would have probably questioned it regardless of whether I had attended the conference.  But having just attended these sessions, I was much more sensitive to how our software was going to be used in the real world. After discussing it within our team, we realized that this particular story had become separated from delivering usable business value.  There were several related features that the customers wanted. But none of them was in scope for the current release.  So we postponed work on this piece until a future release when it becomes a proper priority.  Another problem that was uncovered by thinking about personas and scenarios was the confusion of our customers about exactly how the features would add value to their business and who would be using them. The customers and the technical team both agreed that we needed to do some advanced analysis to better understand the business problem we were solving, and better understand who the target users were before we started building software.   In this case, by thinking in terms of personas, scenarios, and story maps, it became very clear that we were not ready to code the related software.

Agile methods – strengths and limitations

They work.
Users who want software need to work with us, within iterations because the agile, iterative approach is a good way to produce useful software. We don’t have to apologize for these improved methods .
 But not EVERYTHING we do fits in a sprint.
Business strategy, budgeting, user goal design, process design, adapting best practices and rightsizing them for your organization, infrastructure architecture, support, organizational change management, training, and many other things have a life and rhythm that is beyond specific projects.  These topics intersect with projects from time to time.  But they are broader than any single project. To me, the risk for us is that we will think that all process design, user design, and requirements gathering must be done in the context of an iterative software development process. Instead, I think some of those activities need leadership that is not necessarily associated with the project, and growth and development that is not necessarily associated with our projects.  Some of these issues were discussed during this conference. I think there is a tension between the big upfront design methods that believe in long-term artifacts, and the agile methods that believe that produce you should produce whatever is good enough for the sprint, and that is good enough.
But several of the more thoughtful agile leaders have acknowledged that “good enough” is in the eye of the beholder. I have seen with my own eyes that grabbing a couple of business users, and executive, and the business analyst, and throwing them in a room for a sprint will not produce stories of sufficient quality to produce a solution that adds value to the organization. Instead, we do analysis ahead of the delivery iterations. Our goal is to have clear business strategy, a clear understanding of our users (personas help), and align our stories with those users and uses.  These business strategies and tactics are developed and revised in an iterative fashion, but they are on a different timescale, using a different culture and methods than the methods we use for software development. 


At one point, I was moaning about the friction between those of us who develop software using agile methods and mismatch between the style of management we work under .  Alan Cooper went so far as to say we should stage a revolt, and any manager who can’t keep up with the new paradigm, should be left for the wolves (I’m paraphrasing a bit).  I’m not sure that is humane (managers are people too). I’m also not sure whether that is practical  (managers control our salary, work assignments, and ultimately whether we continue to work in this organization).  I’m much more of a harmonizer. I would like to think that we can educate management so that they can work with us in a more agile and dynamic fashion. But I am notoriously optimistic when it comes to people’s ability to change and improve.


My coworker, Uriah and I had several thought-provoking conversations throughout the day.  At one point, he said
I would like to see the entire business run in an agile way.
I’m not qualified to know whether that is possible, and have not given it enough thought to decide yet whether it is desirable. It would certainly make my life easier on a selfish level.  And there are certainly elements of our agile culture that are also used in business, and would be beneficial far beyond the delivery of software systems.   But since I still have some reservations about our understanding of what we mean when we say “agile”, I’m not ready to tell managers I know a better way to run their business.  But I think we can say with some confidence is that the practices that are necessary to deliver reliable and useful software are complex and demanding. And it is readily apparent that we often have confusion and conflict with the customers who pay us and the users we serve. Anything we can do to improve the way we work together will be a good thing. 
We need to listen to each other and learn from one another.


  1. My advice… investigate Lean and Kanban. I’m not implying that you replace your ideas or that these are better, just that they complement and help answer some of the questions you raise.

    Good luck!

    Comment by Kevin E. Schlabach — January 11, 2010 @ 11:48 am

    • I really enjoy reading the ideas about lean manufacturing from folks like Mary and Tom Poppendieck, and how they translate to software development. But I’m unfamiliar with which of the lean concepts speak directly to the issues of usability and interaction design. Can you give me some idea as to what concepts you are thinking of and how they apply?

      Comment by codecontracts — January 11, 2010 @ 9:38 pm

  2. David,
    You captured the feel of this thought-provoking conference. Thanks for the handy summarizations. I liked your Appalachian Spring analogy (..leave a lasting impression on you because they remind you of your humble roots). Also, thanks for reminding me of “Are you feeding your customers ice cream and cookies?” which is a good caveat that customers don’t always know what’s good for them.

    Alan Cooper’s slides were a bit militaristic for me, but dude has significant programming and design chops so I liked what he had to say during the panel discussion. I disagreed with the part in his talk where he implied the community is at war — seems a bit hyperbolic.

    My take-away-inspiration was to figure out a way to include both Design and Delivery in our cycles. Say we had two weeks of heads-down coding & delivery interspersed with two weeks of discovery (i.e., processing feedback from users and doing interaction design)?

    Comment by Bob MacNeal — January 11, 2010 @ 4:22 pm

    • Thanks for your feedback. Let me know if you have any success in your attempt to include more design in your product development. In your organization, who (by role and department) does interaction design? I’m curious to learn about this myself.

      One of our projects involves the construction of a website. We have a marketing department with several people who have titles like Webmaster, information architect, website administrator, marketing coordinator, etc… Some of these people are familiar with the concepts of interaction design. But we are a small organization, and they do not have the luxury to be specialists in that area. They have many responsibilities. We also have a technical architect, and several enterprise business analysts who work for the technical side of our organization. These people also contribute to the conversation about usability and design. But again, none of them are specialists in usability, or product design. It is always such a challenge for a small organization to allocate scarce resources.

      Comment by codecontracts — January 11, 2010 @ 9:30 pm

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: