BT

Interview with Simon Baker, Author of No Bull

Posted by Marta Jasinska on May 28, 2012 |

Earlier this month Simon Baker, agile coach and co-founder of Energized Work, published an interesting overview of his experience with Agile methodologies. The paper, entitled “No bull”, can be downloaded in pdf format from Energized Works servers. Simon Baker agreed to answer several questions for the InfoQ readers.

InfoQ: Why did you decide to write this paper now – after 12 agile years?

Simon Baker: Shane Hastie invited me to write something for an InfoQ series from the recipients of the Gordon Pask Award. No Bull started out as a 10-year anniversary piece on the Agile Manifesto. I ended up writing something bigger based on twelve years with Extreme Programming and my current thinking.

InfoQ: What was the intention behind the publication?

Simon Baker: I wanted to share some of my experiences and, for what it’s worth, how this agile stuff connects in my head at the moment.

The subtitle asked the question: After twelve agile years has the world of software development really changed? I didn’t really answer that question, intentionally. As I said to Jerry Weinberg, it was posed to create the frame for a possible discussion people might choose to have. We should also ask ourselves where we’d be now if it wasn’t for agile methods? In some way I hope No Bull causes people to stop briefly, step back and take in the present – to celebrate what’s good, be clear about what’s bad and why, reflect on the journey so far and think about the future.

Some people have said there’s nothing new in No Bull. I didn’t know we were all about novelty. Why does there have to be something new to try raise awareness? Is anything truly new? Some people have asked what actions I wanted readers to take from it. Not telling people what to do was kind of the point.

InfoQ: You use twitter and blogs to spread the word about the paper on the Internet. Do you plan to use other ways to promote it?

Simon Baker: I haven’t thought about promoting No Bull but I’m happy to hear ideas. I figured people would do what they want with it. If it’s relevant or controversial I assume people will talk about it and share it. If it’s useful I assume people will put it to good use. It covers a lot of ground generally. Maybe I’ll pull some smaller more focused articles from it if time permits.

Twitter is easy. A few people have blogged. There are a couple of discussions over in the LinkedIn groups. Most of the commentary has been direct to me in emails. This week I’ve been invited to talk about No Bull, which is nice. I’m always happy to talk, even if it’s just informal Q&A over coffee. Gus Power, cofounder of Energized Work, is a keynote speaker at Computer Weekly's IT leadership forum, the CW500 Club, in June. He’ll be talking about the future of software development and I dare say some of the No Bull thinking will come up.

InfoQ: You talk about the cost of large offshore teams. Did you ever work in a successful environment with distributed teams? Do you know of any strategies that work for this setup, which are not as wasteful?

Simon Baker: No is the short answer, if success means predictably delivering the right thing for the budgeted amount of money or less, with quality software that has a low total cost of ownership. It comes down to lead-time and the cost of delays. When people are spread out it takes longer to go from customer request into the customer’s hands; transaction and coordination costs are higher. Sure, a distributed team can be made to work – look at 37signals. It comes down to having a simple setup and having people with passion and capability on the team, wherever they may be, rather than just fungible resources who tick the boxes on a skills matrix.

The decision to offshore is usually driven by cost. Labour costs get expensive when projects get big. The thing is a lot of projects are bigger than they need to be because they’re over-complicated. I remember hearing a CTO talk about having 400 developers working offshore. At the risk of assuming the backend of their e-commerce site is simpler than it actually is, that still seems like an awfully lot of developers. Size is an issue. I don’t believe a big project with a big offshore team and the usual politics mixed in is a setup for success. Then I see companies building it into their KPIs, like mandating 40% of capital expenditure must be offshore. I don’t consider this to be a good sign. “Do the simplest thing” doesn’t just apply to software. There are just simpler more cost-effective ways to get things done.

InfoQ: In the paper you point out that agile methods are being implemented in different ways. How does that affect the work of the Agile Coach? Can somebody outside the company, without deep understanding of the business and process requirements, help a team make a transition to a more agile way of working?

Simon Baker: I think the method doesn’t matter for a coach with a deep understanding of agile and lean principles. That being said, the appetite to buy something called Agile has seen the market saturated with coaches making questionable adaptations to achieve corporate fit. So who knows? There’s no reliable way to know what you’re going to get when you hire a coach.

Transitions usually take companies to a ‘place’ where they’re doing Agile. What’s needed is for companies to get to a capability that continuously experiments and deploys accumulated learning to good effect for customers and stakeholders. What companies haven’t realized is that the benefits they seek by becoming more agile require profound change in people’s operating principles and beliefs. That can’t happen if the environment won’t support it. Having someone from outside the company to challenge ideas, assumptions and decisions and disrupt the status quo can be valuable. As they say, when everyone’s in the frame nobody sees the picture. That person will come to understand intimately the business and process and other aspects of ‘the system’. That person will be a part of ‘the system’. But an agile coach is not a silver bullet. Every company is a unique context and change requires visible support and tangible actions from the people at the top. It's never just a “fix IT” situation, despite what people often think.

The techniques for helping companies change are evolving. I see more references to Systems Thinking and perhaps even a rediscovery of the thinking techniques from the Theory of Constraints. I also sense a maturing attitude that recognizes change as learning cycles. There’s a move away from teaching people to work differently towards learning with people and co- designing system changes. This is demonstrating an approach that balances inquiry and advocacy, which seeks to help people reveal beliefs and assumptions that drive their thinking, create awareness of context, encourage a willingness to experiment, and ultimately facilitate deeper learning. This just might win hearts and minds, and bring about the new thinking and different behaviours needed for change.

InfoQ: Business teams can go through a similar change the sysops teams are going through right now and become agile so they won't be a bottleneck in the development process. Have you worked with any agile business teams? How do you think transformation like that can impact on how companies build their products?

Simon Baker: Business plans, budgets and feature ideas are hypotheses. Iterative development and continuous delivery generates customer feedback and reduces uncertainty without over investing. As long as the cost of change remains low, assumptions and ideas can be tested with customers to discover what they think is useful. It sounds good – to us. I suspect it’s scary to business people.

I’ve spent twelve years telling businesses that detailed specification at the start doesn’t reduce uncertainty and that releasing everything in one go is making a bad bet with the whole budget on hitting a hole-in-one. Maybe they’ve always known this? Maybe it’s safe hiding behind a big specification that takes a long time to deliver? As someone in the business team, once the specification is given to IT, maybe I don’t have to think too hard about what’s really needed; I can dip in and out. For 95% of the time I can report “everything's on target” because that’s what the project manager tells me. This highlights a possible tension as values may be in conflict with the transparency that closing the loop on business decisions actually brings.

We setup Energized Work to provide an end-to-end delivery capability that implants into business teams. By connecting to daily business operations it becomes a collaboration to decide what product or features to spend money on based on measured benefits incrementally realized. We’ve taken this further when there are multiple business teams in a company by introducing portfolio governance focused on incremental investments tied to value realization, as opposed to tracking progress against planned milestones and a forecasted burn rate. When a business grabs the steering wheel with both hands the competitive advantage is almost unfair. Unfortunately we’re some way from seeing more businesses being willing to close the loop on their decisions.

InfoQ: Are you surprised by the state of things after your 12 agile years? Do you think a lot will change in the next 12 years?

Simon Baker: I guess the enthusiastic part of me is impatient and always hopes for more action, faster progress and bigger impact. The realist in me knows this is a long game. Kent Beck reminded me that we’re in a change that will take decades. It took fifty years or more for mass production and lean manufacturing to be widely accepted. Software is a young technology. It is also ubiquitous. Whatever way you look at it, software development is nowhere near achieving its potential.

No doubt the next twelve years will continue to see the practice of software development slowly progress. The question is will businesses be wielding it more effectively? I hope the value of high-quality software, in terms of its total cost of ownership, will be better understood and that companies will invest more in its development knowing that continuing benefits will be realized with less ongoing expenditure for as long as there’s customer demand. I hope to see business, technology and financial thinking converge on a profound understanding of what value means to customers and stakeholders. I hope to see end-to-end operations reconfigure for greater effectiveness and more meaningful results.

I think organizational change, change in the workplace and in working culture, and change in people’s beliefs and behaviors is all wrapped up with wider and deeper sociopolitical change. That's going to make it slow going. But every now and again we hear about a new type of company emerging, companies like Semco and most recently Valve. Change is inevitable.

About the Interviewee

Simon Baker is a cofounder of Energized Work and 2009 recipient of the Agile Alliance Gordon Pask Award. He speaks internationally about applying agile and lean principles and techniques in business, software development, and information technology. With 20 years experience delivering software in the media, retail, healthcare, financial services and banking sectors Simon isn't afraid to question conventional thinking and disrupt the status quo. He feels strongly that work shouldn't feel like work and he has a track record creating exciting working conditions that help people change the way they deliver software for the better. You can read more about his paper “No bull” here.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Business execs & agile by Lisa Crispin

No Bull raises so many great points. A lot of people have mused on the 10th anniversary of the manifesto, but No Bull digs more into the issues.

I think many agile practitioners underestimate the ability of biz execs to understand what agile does for them. It was the CEO and CFO of our company, who are finance guys, not software guys, who had the idea to try agile, and took them no time at all to see the benefit of the transparency of agile, frequent delivery to production, and short feedback loops. They've often been overheard telling potential partner companies, "You couldn't pay us enough money to stop doing agile."

If we spent more time helping the business folks understand concepts such as technical debt, Real Options, and incremental/iterative development, I think we'd build a lot more trust and see a lot more good experimentation happening.

Re: Business execs & agile by Simon Baker

+1. The failure I see repeated is constraining agile methods to technical departments and teams. This makes it hard for the business folks and techies to create opportunities to play together and build the trust necessary to support transparency. It stops the delivery capability getting close to the business coalface where it can really be used effectively. As you know, I'm a strong advocate for removing the business-technical divide altogether.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

2 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT