Infoq is running a series of interviews with speakers at the upcoming Agile Indonesia conference 2017. One of the speakers is Evan Leybourn, currently working at IBM Singapore. Leybourn is a regular speaker at Agile Conferences around the globe. He recently organized the business agility conference in New York and leads the agile practice of IBM in Singapore.
InfoQ: Evan, please tell us a bit more about yourself.
Evan Leybourn: I keep myself very busy. I've been with IBM now for nearly 18 months and continue to enjoy the challenge - how do you make a company that size an "agile organisation"! Personally, I think I'm most satisfied with the Business Agility conference I created in New York. It was amazing. I've also nearly finished my second book (this one is on #noprojects) and am aiming to have a review copy ready for the publisher by the middle of the year.
InfoQ: You have been very active in the agile community the past few years and your travel itinerary is impressive. What do you see as the three main developments in the agile world globally?
Leybourn: I’m biased, but business agility is number one. The awareness that to “be” agile, an organisation must embed agility throughout its systems, processes and divisions, from HR to finance and the PMO. Second would be the continued development of technical agility as a key enabler - from DevOps to CD and beyond. Finally, the success of agile outside traditional software organisations into those who, 10 years ago, thought they couldn’t be agile - banks and governments.
InfoQ: Yes, you seem to be biased, but it also sounds like a worthwhile course of action. Why is it important to become agile throughout the whole organization?
Leybourn: I wrote about this in my article, and with apologies to Eliyahu Goldratt, “Evan’s Theory of Agile Constraints”.
"An organisation can only be as agile as its least agile division!"
Very basically, the Theory of Constraints is that there is a constraining factor in any process. More importantly, that there will always be a constraining factor. The Theory of Agile Constraints is that, in an organisation, there will always be a constraint to business agility. 20 years ago, that was IT. That was your software team. And that’s why it was logical for Agile, capital “A” Agile, to emerge in that domain. Today the constraint to agility isn’t IT, but rather it’s the PMO, HR, finance, or legal department.
InfoQ: Yes, so IT started the agile adoption and now delivers better software in increments, based on what users really need. It seems that agility gets constrained by PMO still working the ‘old way’ with annual budgets and fixed planning cycles, and procurement still delays the buying process because of old routines that are not flexible at all. But why does an enterprise want to change all that, why would they want to become ‘agile’?
Leybourn: It's not just the PMO, but the very DNA of many organisations, but your point is correct. For the same reason software became agile 30 years ago - the fallacy of predictability. An agile organisation does not have the comfort of assuming their five year plan is correct. Rather, they have the ability (and governance) to iterate and adapt to market changes. It's but just reactive; an agile organisation is one that leads the market as well.
InfoQ: One of the topics I don’t hear many answers to is ‘defining value’. Product owners are supposed to prioritize work based on the value it brings to users or customers. How does a product owner do that?
Leybourn: It depends on how easy it is to quantify. In most cases you can’t put a financial return on a feature so we need to use qualitative measures. My favourite are value points. Similar in approach to Stormy Points, Value Points are a relative measure of how valuable a feature is compared to another. If all we want to know is “which feature to do first”, Value Points can help define that.
InfoQ: For the newbies among us, how do story or value point calculations work in a nutshell?
Leybourn: They are relative measures of complexity or value. From a baseline story (let's call it X and give it a value of 1 SP) assess the relative effort or complexity. If Y is twice as hard as X it must be 2 SP. If Z is twice as hard as Y it must be 4 SP. Value points work in the same way but are assessed by the product owner.
InfoQ: If we measure one feature relative to another feature, how do we translate that to business value, to value delivered to a user? Do you have a good example of a product where the PO was really taking the users as the starting point for prioritizing and defining value (as opposed to perceived value by the team)?
Leybourn: First understand the difference between the estimated value and the realised value. Those two numbers can be worlds apart. But that's why we do Agile - so we have a constant and rapid feedback cycle allowing us the adjust accordingly. Organisations who do this successfully have clear measures and active measurement of the actual business value once a product increment is released. I'll be talking about Outcome Profiles in my talk which is one way to achieve this.
InfoQ: Similarly, how does an organization calculate ROI for their agile transformation? What are some of the best metrics to keep track of the value agile brings?
Leybourn: I think that’s the wrong question. Start by asking why you want to go agile? Define an outcome profile for that (description, measure, baseline, target, dependencies and owner). Your ROI is then calculated based on your specific outcome. Each organisation is different. It can be anything from quality, staff retention, market branding, customer expectations, time to market or even (incorrectly) speed.
InfoQ: Ok, so let’s say that my enterprise wants to be agile for three reasons: A. we want to become more ‘startup like’, launch more innovative products and B. build better software (i.e. traditional waterfall doesn’t always deliver the quality we desire, so we want to improve); C. increase employee satisfaction. How does your above calculation work for our sample?
Leybourn: As long as you can define the measure for the business outcome it works. They can be direct or indirect measures. For examples for C., increase employee satisfaction, you could have a direct measure like a satisfaction survey or an indirect measure like staff attrition.
InfoQ: Many large organizations use traditional budget and planning cycles. How do we change budgeting to fit with an agile way of delivering outcomes?
Leybourn: I’m going to cheat on this question. There’s no way I can answer it in a paragraph or two. :-)
Have a read of Beyond Budgeting , Pat Reed’s Agile Account Standards and my #noprojects articles here on InfoQ.
InfoQ: You also talk a lot about #noprojects. What does this mean for you and why is that important for organizations?
Leybourn: For me this is important because the very concept of a “temporary endeavour” is in opposition to agility. For organisations to be truly competitive they need to be able to deliver continuous value and continuous change. The key word here is continuous. While there may be fluctuations in demand and effort, there should be a continuous allocation of resources to maintain, enhance and support most IT systems. If done properly there should never be a need to run an "upgrade" project, a "version 2" project, a “maintenance” project, a “greenfields” project, or a "redevelopment" project. Even when creating something for the first time, a revolutionary change rather than an evolutionary change, a project structure explicitly defines an end; a point when the project or product will be done. Rather, it should be understood that, every product will continuously change and improve. You may bring in additional staff early on, but with good management and capacity planning this can be managed across different demands.
This is fundamentally what #noprojects is. The approach, structure, tactics and techniques available to successfully deliver continuous change. At its core, #noprojects predicated on the alignment of activities to outcomes, measured by value, constrained by guiding principles and supported by continuous delivery technologies.
I’m currently writing a book on the topic and, with a bit of luck, it should be complete in the next month or two.
InfoQ: You are giving a talk at Agile Indonesia next month ; what can people expect from to hear about?
Leybourn: It’s going to be a practical introduction to business agility. From organisation design (“how do agile organisations design themselves?”), transformation (“how do you get 1,000's of employees to align to your vision of an agile organisation?”), to governance (“how do agile organisations ensure the right work is done?”) and leadership (“what does it means to be an agile leader?”).
