I’ve worked with a customer recently who was exploring the possibility of making the transition to agile. While they have decided at this time not to make the attempt, one of the primary reasons they gave was they felt that the business wasn’t ready to make such a change.
That got me thinking about what it means for the business to be ready for the IT department to work in an agile fashion. As we all know, agile is so much more than just a change in how IT works, it is a real culture change for the organization. In my last blog post, I explored what it meant for IT to be ready for agile. Let’s explore what it means for the business.
Yes, making a transition to agile definitely has an impact on the business as well, and will change the way that they work with IT. The business is used to working in a waterfall fashion with IT; they are used to structured status reports, formal documents to review and approve, detailed project plans that are tracked. Changes to approved requirements go through a change control process where the impacts of those changes are reviewed and analyzed before being approved (or not approved). The business is given a date that they can expect the software to be delivered, and have every expectation that IT will deliver on that date. Once the requirements are documented and approved, typically the business has minimal involvement with IT unless there are changes to be made and the occasional status report on how things are going.
Of course with an agile framework, there is a strong expectation that the business is actively involved with IT. Not only should the business be actively writing user stories (or at least involved in the process), but also participating in the prioritization of the backlog, and most definitely attending the sprint demos where they are expected to give feedback for what they have seen. This is much more involvement than they are used to!
And while this is all exciting at first, many business leaders I have spoken to stated that it was also a big change for them from a culture perspective. Gone are the detailed project plans. Gone are the “we will deliver on this exact date” (although, yes, whether or not IT actually makes that date was always a good question). Gone is defining all of the requirements up front, and having the expectation that IT will deliver all of those requirements on the said deliverable date.
What the business has to adjust to is the fact that there is some uncertainty in the agile process. That as the team learns more about what exactly the business wants, that priorities shift, the backlog changes, the date moves. The business needs to adjust to having a transparency into the IT process that they have never had in the past. And that they are part of the process along the way. And expected to participate at every step of the way.
This participation requires the business to make adjustments. For those individuals that are involved, they must be given time in their schedules for the participation that is required. This means that management must free up some of their time, move tasks that they would normally do to either a lower priority or to other resources. Expecting a product owner to do their full day job in addition to the demands of the tasks of an agile process is simply not fair to the resource. And can breed resentment of the agile process along the way.
The business also needs to be open to the fact that as IT learns how to work in an agile fashion, that there will be missed steps along the way. It’s a learning process for the entire organization. Some of the best lessons come from the mistakes that are made along the way.
And finally, I think the business has to want to learn about the agile process, what their role is in the process and how they can help. By being curious and open to learn, it helps to create a culture of mutual learning and process improvements. The entire organization gets better, not just IT. And that is a win-win for everyone.
