Saying what needs to be said

Are business people ready for the transparency agile software development brings?

Taken from Marta Jasinka’s InfoQ interview with me about No Bull.

Business teams can and should 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?

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, business assumptions and ideas can be tested with customers to discover what they think is useful. It sounds good – to us. I suspect it might be scary for some 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.

Energized Work was setup 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.


Beware Agile coaches bearing transition blueprints

Taken from Marta Jasinka’s InfoQ interview with me about No Bull.

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?

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 become part of ‘the system’. But an agile coach isn’t 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 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.

High labour costs? Chances are, things have been overcomplicated – unnecessarily

Taken from Marta Jasinka’s InfoQ interview with me about No Bull.

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?

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. Labor costs get expensive when projects get big. The thing is a lot of projects are bigger than they need to be because they get overcomplicated unnecessarily. I remember hearing a CTO talk about having 400 developers working offshore, as well as 100 onshore. At the risk of assuming the back-end of their e-commerce site is simpler than it actually is, that still seems like an awfully lot of developers. Size matters! It 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.

If you haven’t already, please go read my No Bull paper. It sparked a conversation about offshoring in the Agile group over on LinkedIn, with people citing real examples of unexpected issues and hidden costs.

No Bull: An author’s note

No Bull
Does not contain bullshit or nuts!

No Bull started with an invitation to write a 10-year anniversary piece on the Agile Manifesto for an InfoQ series by the recipients of the Gordon Pask Award. It ended up being something bigger. In a way it’s my attempt to record my journey over twelve agile years. 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. It’s not meant to be a rallying call. My hope is simply to raise the awareness of where we are twelve years later; to cause people to stop, 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.

Has the world of software development changed after twelve agile years? It’s a rhetorical question. Please use it as a frame for a possible discussion you might choose to have. Software development is nowhere near achieving its potential. While the changes we collectively seek are wrapped up in wider and deeper sociopolitical issues and may take decades to come about, we can ask ourselves how we hamper our own progress towards the production of useful and usable products created from quality software?

As a Chartered Engineer I’m a strong advocate for software craftsmanship and disciplined engineering approach. For me, these have to become established as the bedrock of software development going forward in order for software developers to be professionally credible and self-regulating. I also think that developing software is fundamentally a creative endeavor. It’s not data entry and it’s not a building activity that comes with a set of instructions. When engineering thinking isn’t folded into the creative design process there’s real danger of delivering products that look great but perform like shit.

By the way, I’m not a software developer. But I have seen the good that’s possible when there is only high-quality software.

My enthusiasm makes me impatient. I want to see business, technology and financial thinking converge on a profound understanding of what it actually means to deliver software effectively and produce meaningful results that have positive impact.

I want to be around when that happens.


Blog at

Up ↑

%d bloggers like this: