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…
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.
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
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.