Sharing Our Passion for Technology

& Continuous Learning

What you missed at Agile 2013

By Cecil Williams | August 26, 2013 | Agile

I was able to attend the Agile 2013 conference in Nashville, TN earlier this month. I had previously attended Agile 2006 in Minneapolis, MN. There was a significant difference.

At this year's conference, the overall theme seemed to be that teams needed to focus on producing value rather than following a process. Most of the attendees have figured out that the process will only get you so far. At that point you have to figure out how to improve what you are delivering, not what you are doing.

Dreyfus Model

As described by Udayan Banerjee (Technology Trend Analysis, 2013), this is a direct application of the Dreyfus model of skill acquisition. As teams start out adopting agile processes they are at the novice level; hence they need to follow the process exactly as prescribed.

Over time, teams become competent at the process and start to make changes to better fit the process to their organization. According to the Agile 2013 conference chair Kent McDonald, 85% of the attendees indicated they were practitioners of an Agile processes (Keynote, 2013). So most of the attendees at Agile 2013 have reached the competent or proficient stage and are seeking out ways to reach the expert level.

Quality not Quantity

I attended several sessions that discussed ways of achieving the expert level by focusing on producing value rather than improving the process. One way that was presented was to focus on delivering value to the customer rather than what fits into the sprint. If the next 10 stories don't provide value to the customer then you shouldn't work on them just because they fit into the sprint. Furthermore, if you simply show the customer what you finished at the end of your sprint, they won't care. They want you to deliver something that provides value to them.

Measure Value Not Speed

It doesn't matter how fast you go if you are delivering the wrong thing. When the pizza delivery driver shows up 15 minutes early but with the wrong pizza, do you focus on the fact that they were there early? Probably not. You focus on the fact that the pizza is wrong. Customers of Agile teams think the same way. So Agile teams should not focus on velocity, but other metrics like customer satisfaction or customer usage. For example, Netflix (Tech Blog, 2013) will monitor their customer usage after a production deployment and if usage starts to trend down they will revert the deployment. For them happy customers are people using their system. If the usage drops, there is a good chance that their users don't like something that they have done to the system.

Story Mapping Rather Than Story Boards

Teams are improving what they are producing for the customer by utilizing value stream mapping from the lean community in the form of story mapping. This change in mindset forces teams to focus on delivering value rather than prioritizing a list of stories in a backlog.

A story map is focused on a user and how they will use the system. The map shows all the steps a user will do and any variations. Then you can select a series of steps to produce a minimum viable feature for the user. A minimum viable feature is a concept taken from the lean startup community (Lean Startup, n.d.)

Example Story Mapping by Steve Rogalsky

These steps become stories for the team to work on. The team focuses on these stories regardless of the estimated duration. What is important is that they provide value, not that they fit into a pre-defined window of time.

Use Hypotheses Rather Than Requirements

Requirements are what we know. They are our attempt to document what we think the customer wants. But more times than not we are wrong. So why not experiment with a hypothesis? This is what lean startups do. They test the market to see if there is any interest in their product or service. If there is, then they proceed to invest further. We can do the same with software development. If we have a feature that we think the user wants, why don't we build a simple version and get it in their hands. Then we can get feedback on whether they really want that feature.

Conclusion

This was my second time attending the Agile conference, with the first time being in 2006. I have seen a significant change in the industry during that time, which was represented in the sessions at Agile 2013. These changes represent the further evolution of agile. As teams have progressed through the Dreyfus model, they have become proficient at implementing agile. Therefore, the focus has now shifted towards delivering more value to the customer.