Dave: Tom Grant and I spent the past week in Orlando at Agile 2010 and thought it would be good to share our observations of a fantastic event. This conference has been running for 9 years and during those years has always tried to both balance content and scale with focus and intimacy. This year I think they got it just right.
Tom: Among many virtues of the yearly Agile conference is its ability to be simultaneously high concept and eminently practical. You find yourself in a conversation that’s down in the weeds of build and test methodologies but then veers into a philosophical discussion of what the term “value stream” really means. You can see how, by entering the mainstream, Agile forces a fresh look at everything from SOPs to values.
Dave: This year’s event featured the now-familiar smorgasbord of sessions, from Agile for beginners to advanced topics like scaling and technology support. In addition to the physical sessions, a lot of discussions moved in and out of “open space” where participants could build their own content and sessions. Aside from increasing the number of interactions around an event, open space generates additional energy within the event. Many times, I tried to walk from point A to point B, only to stop and listen to a heated discussion on a particular topic.
Tom: Unfortunately, after the event, some of this energy dissipates. The Agile community really needs a community hub, a site that serves the needs of beginners and veterans across a wide range of topics.
Dave: Because of the sheer scope of the conference, there was no one theme, but if I were to pick three, they would be (1) UX design and Agile, (2) development operations (dev ops) and continuous delivery, and (3) technical debt.
Tom: I’m going to expand Dave’s list a little to include one more hot topic worth considering in this post: serious gaming. I was very pleasantly surprised by how often it appeared throughout the forum. In a few paragraphs, I’ll tell you why it was a ubiquitous feature of the conference.
UX Design And Agile
Dave: Perhaps because of the importance of new media and their role in the development process, or the applicability of Agile to new media development, we heard many interesting discussions on how to make user experience (UX) design and Agile work well together. The sessions on this topic concentrated on solving one thorny problem: cadence. Traditional designers push for a complete picture; Agile teams want to build a more incremental understanding. Participants made the following recommendations for making the UX and Agile gears mesh successfully:
- Integrate the designer into the team. Embedding the designer in the team helps resolve the disputes between the need for a holistic view and incremental discovery. In addition, as part of the development process, the designer can tap new sources of inspiration and insight.
- Don’t start until you are ready. Agile methods encourage some thought prior to building software. In Scrum, this is called “Sprint 0,” which focuses on defining the initial backlog, team, and plans. Designers need to add their own milestones, such as indentifying personas, understanding context, and determining UX goals.
- Make usability testing part of the normal test process. As unfamiliar as it might be to some teams, incorporating usability testing into normal testing provides immediate feedback loops for both development and design.
Tom: My only addition to Dave’s observations is the following slogan I may put on a bumper sticker: The importance of UX increases every day. UX played a conspicuous part at Agile 2010 because, among other reasons, people are putting a higher premium on the UX component of their applications. That’s a whole other blog post, or several blog posts, to explain why.
Dev Ops/Continuous Delivery
Dave: Agile 2010 could be described as the breakthrough event for dev ops professionals responsible for delivering what Agile teams produce. Emblematic of this trend is ThoughtWorks’ timely announcement of a new continuous delivery product called Go. Too many Agile teams complain that they can only be as flexible as their release organization. Addressed through a tool like Go, process changes, or both, integrating development with operations and release is crucial for long-term business agility. (Phil Murphy from the Application Development & Delivery team has written a very interesting blog on the topic, in which he describes the conflict and asks the Forrester App Dev community for their comments.) At Agile 2010 the discussion about dev ops focused on:
- Shared goals. Developers (and Agile developers in particular) want frequent delivery; the system admins want infrequent delivery. People who are trying to square this circle are introducing incentives for the two groups to partner more effectively.
- One life cycle, one process. ITIL, CMMI, and to some extent Agile methods have reinforced the separation between development and operations. ITIL 3.0 may be the basis for an integrated view of the end-to-end process as applications move from development to deployment.
- Tooling that integrates. Currently, ALM tools support the SDLC, and IT service management tools support the operations groups. Organizations need tools that span these processes and teams. The scions of the Agile movement may have distrusted tools, but it’s hard to imagine solving the dev ops dilemma without them.
Tom: Agile focuses attention on the quality of decisions that guide the development process. By shortening the iterations, teams have seized the opportunity to assess their past decisions then make mid-course corrections (and even early-course ones). However, there’s nothing inherent in Agile that tells you how to make a better decision or even spot the bad ones. The exception, perhaps, is planning poker, a conspicuously game-like activity that, for many teams, makes scoping more accurate. Now, teams are considering other games to help with other decisions, such as prioritization, process flow, and design.
Managing Technical Debt
Dave: The Agile community has faced a lot of hard questions about how a methodology that breaks development into short iterations can maintain a long-term view on issues like maintainability. Does Agile unintentionally increase the risk of technical debt? Israel Gat is leading some breakthrough thinking in the financial measures and ramifications of technical debt. This topic deserves the attention it’s beginning to receive, in part because of its ramifications for backlog management and architecture planning. Application development professionals should:
- Start capturing debt. Even if it is just encouraging developers to note issues in the comments of code as they are writing it, or putting in place more-formal peer review processes where debt is captured, it is important to document debt as it accumulates.
- Start measuring debt. Once captured, placing a value/cost on the debt created enables objective discussions. It also enables reporting to provide the organization with transparency of the growing debt. I believe that this approach would enable application and product end-of-life discussions to happen earlier and with more accuracy.
- Adopt standard architectures and open source models. The more people who look at a piece of code, the more likely debt will be reduced. The simple truth of many people using the same software makes it simpler and less prone to debt.
Tom: Since the role I serve, the product manager in technology companies, sits on the fault line between business and technology, I’m really interested in where Israel Gat and others take this discussion. The era of piling up functionality in the hopes that customers will be impressed with the size of the pile is clearly ending. What will replace it is still undetermined.
Tom and Dave: It’s a great show that leads to discussions like these, and we’re both looking forward to the 2011 Agile conference in Salt Lake City, Utah. If you were at the show or have general observations about these topics, please contribute to our own open space here on the Forrester blogs.