A challenge awaits any IT group switching from a waterfall process to agile software development. It is often overlooked. It has to do with the mindset of the company’s business community and how they perceive IT.
The business stakeholders and end users have historically complained about issues like the following:
- It’s difficult to get IT to focus attention on their problems.
- Once they have IT’s attention, it takes a long time to get new or updated software delivered.
- IT won’t deliver everything they request, so they have to request everything they can think of.
- Once IT delivers (if they deliver), it will be a long time before they see any updates.
Ouch! How stinging is that! (Yes, these are real complaints I’ve heard over the years at multiple companies.) Does it describe your IT shop?
These complaints are a direct result of the waterfall process coupled with change control (better described as change avoidance). Waterfall approaches don’t always take longer than agile ones but it feels that way. There’s long lead time between user requests and tangible software. It feels like an eternity.
An Agile Dilemma
Now, let’s say IT decides to switch to some variation of Scrum. They seek collaboration with the business community. What would you expect them to encounter? Skepticism, right?
Scrum offers solutions to the above complaints in the form of:
- A dedicated software development team
- Frequent software deliveries
- Incremental improvements until all requests are filled
- Change acceptance
If you were on the receiving end of these promises, what would you think? How would you react? (I know I’d be extremely skeptical.)
Here’s my suggestion. Actions speak louder. You already have a backlog of user requests, right? There must be plenty of requirements that didn’t make the final list or were dropped during the project. There must also be defects that didn’t get fixed or weren’t fixed to the satisfaction of the users. Start with all these backlog items and software defects.
Get to work. Fix something. Add something. Re-work something. Just do something. Deliver it. Now repeat!
Engage the business stakeholders and end users in productive conversations about each delivery. Explain to them that this is how agile development works. It’s a whole new approach. You’re showing them, not just telling them. They’ll get the idea and become engaged in the new process almost immediately.
Stop talking. Start delivering.