BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Diana Larsen talks about Agile Fluency, Barriers to Agility and the value of Open Space Technology

Diana Larsen talks about Agile Fluency, Barriers to Agility and the value of Open Space Technology

This item in japanese

Diana Larsen, the founder of FutureWorks Consulting, has many years of experience working on products in the Software Industry. Besides coaching teams in Agile ways-of-working she also leads teams/projects based on collaborative thinking and planning. She is an advocate of and facilitator for Open Space Technology events and is renowned for her work on agile retrospectives. Her ability to solve critical problems in tough situations has given her an edge in her work.

She has co-authored three books including ‘Agile Retrospectives: Making Good Teams Great’. Her work with James Shore on an Agile Fluency(tm) model has been applied across teams all over the world. She served as chair for the Agile Alliance and is now a board member of the Organization Design Forum.

She is presenting a keynote talk at the upcoming Agile India conference.  Her talk is titled "Dancing Along the Agile Fluency Path" in which she will present a model for achieving and assessing the level of fluency an organisation has in their adoption of agile values and principles.  

In advance of the conference she spoke to InfoQ about collaborative work cultures, organisational barriers to agility, retrospectives, the value of open space and what agile fluency is actually about:

InfoQ: What is the biggest bottleneck for collaborative work culture?

In most organization that find a bottleneck (not all do), I’ve seen a bottleneck caused by shifting expectations. The change in expectations influences bottlenecks in information flows, communication channels, product decisions, opportunities to learn from experience, and many more aspects of software development and product delivery. Transitioning from a hierarchical way of working to a more collaborative work culture creates changes in role definitions and role requirements. It requires letting go of habitual behaviors that may have worked well in the hierarchy, but no longer serves anyone when collaboration becomes a critical part of the work process.

For example, a QA or Engineering manager may have been rewarded for managing a number of people in a narrow functional area, for getting information from direct reports and transmitting it to the manager’s boss, for following conventional wisdom for keeping costs low and productivity high. In short, for working well within their functional silo. Now we know that for knowledge work like software development, none of these activities deliver the desired result...though they did protect opportunities for promotion. As many have said, “what gets rewarded gets done” And no one was being rewarded for taking the kind of risks that lead to innovation or other breakthroughs in performance which thrive in a climate of collaboration.

Visionaries are designing organizations for collaboration. These firms remove the bottlenecks imposed by the strict hierarchies of the past.

InfoQ: What are the typical challenges you’ve seen with Agile implementation in large organisations?

The biggest challenge I see is the belief that an Agile implementation begins and ends with making changes in how front line delivery teams do their work. Another, more insidious, challenge is a fundamental misunderstanding of the nature of knowledge work and how it is best accomplished. This misunderstanding seems to expand with the size of the organization. I rarely encounter it in startups or small companies.

Knowledge work differs from other work by its emphasis on "non-routine" problem solving. Tim Ottinger and I have shared conversations about whether software development is more about the ability to learn quickly or make high quality decisions quickly. In truth, it’s both. Knowledge workers spend a large proportion of their time seeking information, much of the rest making sense of what they’ve found, and relatively little time in applying what they now know. As some have said, they “think for a living.” This stands in stark contrast to managers who believe that software development can be measured by the amount of time a person spends typing on the keyboard.

Shifting people’s beliefs about what constitutes work poses a huge challenge.

InfoQ: Over the next few years, what does the future of Agile look like?

I have a standard answer. In my view, Agile is in its adolescence. We don’t know what it’s capable of yet. Every month or so, I read or hear about a new model or approach that adds to the body of knowledge we have about “Agile” and what it looks like. The future of Agile is one of continued evolution and increasing efficacy in ways we can’t imagine today. Like all complex ideas, it’s usefulness will continue to emerge. It may even become known by a different name. Look for its hallmarks: humanized work with an emphasis on mastery of our craft, a focus on rapid learning and feedback, delivery of business value (sooner not faster), and close connection to customer needs (even ones the customers’ haven’t noticed yet).

infoQ: What is your view on ‘prescriptive’ retrospectives?

I’m not sure what that term means. When I looked it up, the first url was a Christian History blog. And I didn’t find much that was useful after that. So, I’m going to take a guess. The definition of prescriptive leads to a sense of “rule-based” “right and wrong” as opposed to descriptive which is more focused on the current situation and its needs. I’m not a big fan of the focus on right and wrong. One of my favorite quotations comes from Rumi, “Out beyond ideas of wrongdoing and rightdoing, there is a field. I’ll meet you there. When the soul lies down in that grass, the world is too full to talk about.”

I want my retrospectives, and everyone’s, to provide a useful focus on continuous learning and improvement for the team, its product, and the organization and customers it serves. If kaizen (incremental improvement) or kaikaku (transformative improvement) are the result, you’re doing fine, in my opinion. If your retrospectives give you no benefit, stop! Or rethink how you’re approaching improvement.

The framework for retrospectives that Esther Derby and I described in our book has worked well for me as an organizing principle for designing the meeting. Every retrospective I lead is custom-designed for that team at that time with those conditions. it describes their current state and looks for ways to make it better.

What gets taught in too many Scrum and Agile training courses, “make lists of what worked well and what we want to do differently,” doesn’t work for me. Maybe there’s some team somewhere for whom that’s effective. Not me, not mine. That truncated retrospective form is a way of pandering to organizations who want their retrospectives short (half hour) more than they want them to be useful.

InfoQ: What are the fundamental principles for any retrospective?

First, prepare in advance. Come to the meeting with a designed flow of group process activities. (Sounds more daunting than it is.)

During the meeting:

  1. Bring people together in a way that helps them focus on the work of improvement. Esther and I called this, “Set the Stage.” Pay attention to the setting and the mindsets.

  2. As a group, describe the situation so that every team members can view the iteration (or other period of work) from all perspectives, not just their own. We called this, “Gather Data.” My colleagues at the Human Systems Dynamics Institute and the Institute for Cultural Affairs call this “What?”-answering the question, what is the current state? what have we just experienced? I have also called this the learning aspect of the retrospective. Everyone learns what everyone else knows, has experienced, and how it impacted their work.

  3. Spend time making sense of the “what”. In the Agile Retrospectives framework, we called it, “Generated Insights.” Others describe it as the “So What?” step. Now that we know what we know, what meaning do we make of it? This is the group thinking/analysis part–discovering implications, interpretations, significance, and evaluation.

  4. If we’ve done a great job of #2 and #3, the next step is to choose our next improvement action or experiment or , to “Decide What to Do” or frame the “Now What?” which includes the small increment of action and how we’ll track and assess its effectiveness.

  5. Finally, “Close the Retrospective.” End the meeting in a way that respects and honors the people and the work they’ve done, reinforces the action they chose, and helps to give feedback to the facilitator, so they can improve the way they serve the team.

Beyond that, the fundamental principle is: find a way to continuously learn and improve that actually works for the team.  I don’t care whether you use our framework, the Toyota Improvement kata,  Quality Circles and A3 reports, or some other process...find one that works. That’s my only prescription.

InfoQ: How important are open space sessions for Agile community? 

Open Space Technology as proposed by Harrison Owen nearly 40 years ago makes a great match with the principles of Agile. Both foster empowered action and self-organization. My most recent Open Space experience ended just two days ago - Agile Open Northwest 2015 - and it was another delightful instance of community members coming together to discuss what’s most important to them right now. I find people understand Agile better after they’ve spent time in an Open Space.

InfoQ: We often find companies confuse Agile Fluency Model with an Agile Maturity Model? Using it as a yardstick to measure their teams. What advice do you have for them?

Agile has a problem. When we started out with Agile, people used it because it made their lives and products better. Now people complain that Agile is about meetings, top-down mandates, and wasting time. We can do better. It’s time for a change.

In response, James Shore and I developed The Agile Fluency™ Model and Martin Fowler published it, “Your Path Through Agile Fluency”. The model describes how teams grow in their understanding of Agile over time. It's a descriptive model, because it reflects what happens in the real world, and in it's an aspirational model, because you can use it to understand how to invest in improving your teams.

We've found the model very useful for helping teams, managers, and executives understand what they can get from Agile and what they need to invest in order to get those results. The model's emphasis on concrete outcomes means executives are open—even eager—to devote the effort needed. Leaders appreciate being able to see the tradeoffs and make a strategic decision, and teams thrive when given meaningful goals and the time and resources needed to achieve them.

We hope the model is used in this spirit and not as an Agile Maturity Model. If this sounds interesting, come to my session at Agile India 2015 to find out how the fluency model can help you and your teams.

 

 

Rate this Article

Adoption
Style

BT