Over the last few weeks, we’ve talked about five specific benefits that Business Agility can bring to your organization. Among them are:

• Reducing costs

• Increasing revenue

• Improving your alignment

• Improving culture and retention

• Creating resilient systems

While Business Agility brings many benefits, implementing it effectively is a challenge. When adopting Business Agility, businesses are bound to encounter both internal and external challenges.

These challenges must be addressed if you wish to get the most benefits from implementing business agility into your organization. Below we discuss five of these challenges. We have also discussed these on our Definitely, Maybe Agile podcast. Let us take a look at these obstacles, and how to work through them. 

For this fifth article in our series on how business agility can improve your bottom line, we look at how business agility aids building resilient systems. Here business agility practices help by aiding us in looking at risk management for the entire system. Not only ensuring the systems we build respond even when under stress, but helping us build safety into the system.

Whenever the weather allows for it, we like to eat outside. At dinner time in our little courtyard in the city of Toronto, mother nature treated us to a beautiful scene. A few days later it turned into an invaluable lesson...

Two doves and a chick

A mourning dove landed on the fence, looking us straight in the eye. "What a wonderful sight," I thought, "I bet it's eyeing something on our plate." Without breaking the line of sight, the dove flew over to the side of the deck, even closer, testing the boundaries of its comfort zone.

"Roocoo! Roocoo!" A few minutes later mommy dove arrives, a little chick trailing inches behind her. The family reunited, they waggled to an open space a bit further away, while we watched the scene unfold at a safe distance. By now we realized that daddy had scouted the environment, checking our reactions to his proximity. He must have considered us safe, the little one would not be harmed.

To our surprise, the adults took off, leaving the little one alone. Stunne...

In previous posts, we discussed what you can learn about your team from tracking a minimum of data. We introduced throughput as the most meaningful metric you can get from only the completion time of a work item. In a subsequent post, we explained how you can calculate cycle time and work in progress by tracking the start time of a work item. In this post, we focus solely on how to calculate failure demand and what it tells you about the true delivery capacity of your team.

Recently I was on a call chatting with a group of senior leaders and the topic of work-life balance came up. More explicitly, how “now he seemed to have so much less time at the weekends”. Asking a few questions of the gentleman who brought this up identified that he had been newly promoted to a VP role.

Which got me thinking about the challenges as you move between roles in larger organizations. Expectations change as you move from an IC to manager to director to VP or above.

So I thought I’d jot down a few thoughts on the matter.

Let’s talk about the elephant in the room. Most transformations do not deliver upon their intended results. Many of these transformations use sound agile methodologies, yet they fail to deliver on the expected results. DevOps came along and refocused the effort, but still, we run into difficulty with transformations stalling or even failing.

Current thinking puts the development (aka. delivery) team front and center in the transformation to rapidly enable the delivery of value to customers. For a team, they need to be able to have all the right skills and capabilities at the disposal so they can own their delivery processes. In complex environments with multiple architectural principles at play, this can be difficult to achieve. To cope with this, we create another team, the platform team, to enable the delivery team.

The question is, do I need a platform team?