With only 4 weeks to go until Agile-Lean Ireland 2017, we had a chat with our keynote, Woody Zuill, to find out his thoughts on topics ranging from the future of Agile, the origins of #NoEstimates, using Mob Programming, and more…

ALI: Where do you see Agile being in the next few years?

Woody: If we look over the past 15+ years since the Agile Manifesto was first published I have noticed three periods, each about 5 years long, with a lot of overlap: 1) The introduction – people learning and trying things, 2) The Doing – Lots more trying, learning, doing, and gaining experience, and 3) The Growing – Many getting success are learning to stretch and evolve beyond the beginnings. Many others trying, learning, doing, getting experience.  Clearly, everyone is on a different path along this timeline.

What I am seeing now, and hoping will continue in the coming years is a focus on the “system” of work – that more and more of us will recognize that providing an environment where everyone can excel in their work and life is important.

ALI: What is the one thing would you suggest to a company if they are about to transform to Agile?

Woody: My focus has been on understanding the Agile Manifesto and principles, and use them as a guidebook for evaluating the practices and methods that we choose to use in our software development efforts. Understanding that flow is important, understanding that bringing our ideas from inception to “delivered and in-use” as directly as possible in small and rapid increments has been very useful for me. That is, discovering ways to optimize for flow rather than for individual productivity brings a lot of benefits.

ALI: What is the biggest thing companies keep getting wrong and what advice would you give to help?

Woody: I don’t think I could identify a single “biggest” thing, but one common thing I see is that most companies are trying to find ways have control and certainty in their software development efforts, and I would suggest this leads to tremendous waste, loss, and suffering.  We want control and certainty, and we think we can manage for that, but end up paying a huge cost for mediocre results.  I can’t give meaningful advice as the variables are numerous, but my general observation is that learning to scrutinize and question with an open attitude the practices we are using is a great starting place. Anything we do “by default” because “that’s the way business is done” is a great place to start. It is in those areas that our biggest problems are likely hiding.

ALI: Five years ago, you first tweeted using the #NoEstimates hashtag – what prompted this at the time? 

Woody: #NoEstimates is about questioning our dependence on estimates for time, effort, or cost of software development work. Over the past 20 years I had been noticing a pattern at most places I had worked where everyone felt estimates are needed, but were almost always disappointed with the results of using them.  Over and over I heard some version of this: “We aren’t very good at making useful estimates, and we need to get better at that”.  While this seems like a reasonable approach, learning to make “useful estimates” was elusive for them. This made me to wonder if we were trying to deal with a symptom, rather than the actual problem. In discussing this with folks in Twitter, like Vasco Duarte, Neil Killick, and Ron Jeffries, I used the “NoEstimates” hashtag one day to identify a link to an article I had just written about a project where we had used “no estimates”.  It wasn’t meant to be a running hashtag that would last much beyond that first use, but it seemed to hit a nerve so I have continued to use it.

ALI: One of the arguments for estimation processes such as Planning Poker is that it helps create shared understanding on complexity, between testers and developers for example. When taking a #NoEstimates approach, what type of approach you would recommend to achieve this outcome?

Woody: I hear that frequently, and it makes sense to use estimates to help us spark our discussion about a work item. By each of us making a quick estimate we can get a sense if we all agree about the nature of the work.  However, it is the things that we base the estimate on that are meaningful, so for me it is much more useful to focus on those things rather than the estimate itself, In my opinion it is much more useful to have a discussion about the elements that make up the work. My goal is to look for ways the work can be broken apart into more discrete chunks that can be delivered into use independently. When we do that we get useful results we can act on.

I’m concerned that when we all quickly estimate the same same number of story points for an item we might mistake that as an indication that we have a shared understanding.  However, we could just as easily have very different understandings that each result in the same number.

ALI: Any advice to convince leadership in a company to try #NoEstimates when their outside senior stakeholders want the traditional estimation approach?

Woody: Nope. This sort of thing requires a willingness to question the practices we accept as “this is how business is done”.  If leadership and “outside senior stakeholders” are not willing to question these de facto practices then that identifies a starting point: let’s figure out how to influence our environment so a culture where questioning our deepest held beliefs is acceptable, expected, as well as regularly and frequently practiced.  Then, someday we will be able to engage in meaningful dialogue about estimates.

ALI: In what situations does Mob Programming work best? 

Woody: Almost any software development work can be effectively handled by a Mob Programming team. The main benefit comes from having everyone needed to do the work on hand and working together to accomplish that work. This provides a focus on the work that drives it rapidly from start to finish.  While many teams practicing Mob Programming use it for big, complicated things or emergencies, it can work very well for “simple” or rote things as well. As the team tackles these simple things they begin identifying ways to automate them, or to find better ways to knock them out quickly.  The benefit of having all the brilliant minds working together on a single thing at the same time is that it amplifies our ability to innovate and find better ways to approach any particular work. Mob Programming also works great for learning new technologies.

ALI: A manager doesn’t understand the benefit of 5 developers working at the same screen. How would you convince the manager of the value of taking this approach?

Woody: Again, I’ve not had much success trying to convince people of things. When someone is open to learning and innovating, they’ll allow for the experiments needed to try or discover better ways.  So rather than try to convince, I look for ways to influence the general willingness to become more open to questioning our long held assumptions about “how business is done”.

The underlying assumption with productivity of “5 people at one computer” is that having each developer work on alone something separate is somehow effective. The idea that “we’ll get more done if we divide up this work” can be useful in some kinds of work, but in knowledge work we can get amazing improvements when we take to heart this quote from Russell Ackoff: “A system is not the sum of the behavior of its parts, it’s the product of their interactions.” To me, this suggests we might want focus on making interactions easy, natural, and continuous. Another way to think about this is from the Agile Manifesto: “We value Individuals and Interactions over Processes and Tools”.  I believe that the process of splitting work up and having people work on it separately is done at the expense of the value we get from effective communication and interactions.

ALI: Where can our delegates learn more about Mob Programming? Would you recommend any useful resources?

Woody: I have a blog at mobprogramming.org, and I’ve written a book with Kevin Meadows named “Mob Programming: A Whole Team Approach” that is available through LeanPub.com. I provide workshops on Mob Programming, and anyone interested can get in touch and I’ll provide the details to hold one at your company or group.  You can contact me via Twitter: @woodyzuill.

Woody will be talking about “Estimates or NoEstimates?” at Agile-Lean Ireland 2017 on May 6th.