Why Adopting Agile Won’t Magically Reduce Your IT Budget

Of course, all companies would like to reduce their budgets. But cutting back in the IT department can have unintended consequences. This article looks at two of the more well-adopted cost-cutting approaches, the software factory and distributed teams, and goes into how they can help and hurt your company.

Software Factory

A software factory is a collection of related assets used for creating specific types of software applications or components, often outsourcing the product to another company. A software factory draws from end-user requirements and applies an assembly process to software development, imitating the benefits of a traditional manufacturing process.

This approach was used in India with developers and testers following waterfall as their development methodology, as well as with several companies in South America. Because of the production model of how the service is delivered to the client, a software factory often requires people to wear more than one hat. The process results in mixed roles—such as technical leader and developer, or business analyst and tester—because the factory is attempting to save money by using one person to do the job of two. The problem with this overload of roles, obviously, is that a professional cannot be as effective working half the time in two jobs as he could working full time in one.

This model resulting in sharing of roles didn’t happen in the US or Europe until now, with the widespread adoption of agile. What is the cost implication of using an “agile” software factory?

Usually, it means outsourcing these roles and responsibilities to the aforementioned nations. Moving software factories to countries with lower wages means reducing IT cost without losing quality, and it also works out for these employees, as it’s beneficial to have clients who pay your salary in US dollars or Euros when your currency is weaker.

Distributed Teams

To save money when adopting agile, companies are working with remote teams in South America, Eastern Europe, or India. Sometimes they only have a local product owner, and the developers are in one place and testing is in another.

To me, the only reason to deal with a remote team is so you can hire inexpensive professionals. One of the most important agile values is communication, and although modern technology enables people in faraway places to chat or talk easily, it still doesn’t replace the in-person interaction between a product owner and the development team.

In a company where I used to work, I would have to travel regularly with my Scrum team from Chile to the headquarters in California. Every time we were there, our performance was extremely good. This was no coincidence: Everybody sharing a common place allowed us to talk about any issues we were having face to face, so we figured them out more quickly.

At that same branch in Chile, I had to deal with a product owner located in Buenos Aires who often did not have time to attend daily standup meetings or sprint planning. Imagine how difficult it was for me to chase him to write user stories only via chatting. In addition, he had never filled the role of product owner before, so I had to coach him remotely, which was difficult and made me crazy many times.

If you look only at the big picture, it is a great deal to have a remote Scrum team and only a local product owner. However, if you dig deeper you will realize that you have to expend more time and effort working this way. Due to working different hours across time zones, miscommunication, and waiting for results, usually distributed teams will not be as strong or produce as good results as a collocated team.

Blending Roles

As mentioned above, some companies also try to reduce IT budgets by using a mix of agile roles, such as making a ScrumMaster also act as developer, QA analyst, or product owner. Where this is the case, it’s difficult for teams to get adequate leadership and for a project to stay on track.

Once a company hired me to work as ScrumMaster, Scrum coach, and agile coach for three different agile teams. After reviewing the teams, I tried to convince management that one of the teams needed to follow kanban instead of Scrum because they were fixing bugs in production all day long. Unfortunately, the director of IT wanted to work with several projects but didn’t want to hire new professionals, so he just split one Scrum team in two.

So they had two tiny teams, the first with two developers and one tester and the second with three developers and one junior ScrumMaster also acting as a tester. Later, the director called me to complain about the poor performance of each team. I responded that this was not Scrum or agile at all, and team members were not motivated because every day they had to change the goal of the sprint.

There is a cost associated with having one person be a developer and ScrumMaster at the same time. Naturally, that person will develop less code because he’ll have to spend time helping team members with their issues and being careful about following Scrum. It will take him longer to accomplish work, and there is more likelihood of making mistakes. In the long run, forcing people to take on extra duties will not save you money.

Conclusion

If your company is really interested in adopting agile, I recommend you investigate what it really means. Agile won’t improve the profit of your company if you are not willing to invest money and effort to truly follow agile principles.