Can Agile Teams Be Too Fast?

I worked on a project where the software development team provided rapid response to user requests. We’d meet with the business team leaders every week. Often, they would ask for a change or a new feature and it would be delivered before the next meeting.

Of course, some requests were larger or in a few cases could not be done. But overall, we delivered fast and often.

We had a close knit team. We prioritized stories weekly. The quality of service was outstanding.

There was a downside, however. The business team leaders came to expect this level of service. As a result, they would often fail to think through the consequences of the change they were requesting. They adopted the attitude that if a change didn’t work quite right or didn’t meet their needs, it could quickly be changed again.

Our rapid-response, agile process was too successful.

Product owners and business users need to think through the business processes impacted by a software change to fully understand it’s effects. If they don’t, they end up creating more work (actually re-work). The user community gets frustrated with changes on top of changes. The developers get frustrated having to change what they just changed.

It’s not just about making software changes. It’s also about the impact those changes have on business processes and the people that follow them. Fast and responsive are good agile traits. Adding “business analysis” to the mix makes agile better.