You're Never Done in the Age of Outcome-Driven Development
Given the rise of outcome-driven development, modern developer teams have a new (and sometimes confusing) definition of "done" when it comes to their software projects.
The problem, of course, is that most companies have not figured out how to adopt the agile processes required to complete the development lifecycle - at least not effectively.
In this week's installment of Website Magazine's Expert Series, Patric Palm, CEO and Co-Founder of Favro, a leading provider in agile project management solutions, shares some useful insights into three obstacles that may just be hindering your own outcome-driven development efforts.
The first challenge, according to Palm, is being too dogmatic, about methodology — rather than treating it for what it really is; not a new methodology but rather doing Agile well.
"If you look at what outcome driven development means, it’s about formulating very good epics," said Palm.
"When you look at the definition and success criteria of an epic, it’s about achieving good outcomes. For example, let’s say you’re looking at a goal of reducing churn by three percent, so you break the epic down into user stories or various kinds of experiments towards that outcome. Some will contribute towards the goal outcome, and some not."
Succes in anything, of course, often comes down to people.
The second challenge cited by Palm is that the team attempting to execute outcome-driven development is not knowledgeable or empowered enough to do it properly.
What that ultimately means, of course, is that if you have a team that is not able to actually understand the outcome and what affects the outcome, they can’t do a good job. Development teams, suggested Palm, need to be more autonomous and more empowered with the right knowledge and skills to be able to really do this well.
Outside of the right approach and people, of course, there's another important challenge that must be addressed.
The third challenge, according to Favro's Palm, is not having the right infrastructure in place.
"If you’re going to do outcome driven-development successfully, you need to be able to effectively test lots of different things autonomously of what is going on in other teams. Toggle features and the ability to deploy with limited blast radius at any time will be key. All those kinds of things are going to be very important. If you can’t run a lot of different experiments towards the desired outcome in rapid fire, then you’re not going to be in a position to do outcome driven-development."