Haut Tech

The adoption of Agile approaches in software development has grown very rapidly in recent years. I remember that a couple of years ago a lot of people in the IT world hadn’t even heard about Agile. Today, most of the development groups I talk to claim to adhere to Agile, at least to a certain extent. But the reality is that many of them are not realizing the benefits in productivity and quality that they expected.

The truth is, many groups are really using Agile as an excuse to take shortcuts and avoid doing the things they didn’t like to do in the first place, so there is no surprise there that Agile is “not working” for them. However, other groups are making conscious efforts to adhere to Agile principles and they are still failing to realize the benefits they expect. Because of this, Agile advocates like James Shore are becoming concerned that Agile might be getting a bad reputation , and that the movement may be in decline despite its popularity.

For us, it took two attempts to “get it right”. As with many other software groups, when we learned about Agile we were very attracted to its promises. As a team dedicated to developing software for external clients, we saw in Agile both a way to give better, faster results to our clients, and an approach that would actually make it more fun and rewarding to do our jobs. So we started using Agile with a pilot team. After reviewing the alternatives available, we selected Scrum as our framework. We studied the literature, defined the processes and artifacts we would use, and implemented it on a new project. At the beginning it was very exciting to be working with Agile. We were doing everything by the book and we felt ahead of the curve. However, after a few weeks, our burn rate chart showed very little progress. In the daily Scrum meetings the typical report was that the team would try to finish today the tasks they were supposed to finish yesterday. But the next day the report was still the same. We abandoned Scrum on that project after 6 weeks and moved back to a waterfall approach. Needless to say, it was a very disappointing experience.

…fortunately, we persisted.

Despite the disappointment of the first attempt, we were convinced that the principles of being Agile could work for us and our clients. So we analyzed what had gone wrong, not only in the first Scrum project we had, but in all of the projects where we had had challenges. We arrived at the conclusion that most of the problems in projects arose from “people issues”, not because of the flavor of the project management approach we were using. People issues ran from communications, to visibility of goals, to commitment. So we set to work on those issues, realizing that as a growing company we had to reinforce the culture of participation, collaboration and commitment that was so natural for the founding team, but that was probably not so obvious to the stream of new team members we were integrating to the company. This time, Agile fit like a glove. It provided the framework to foster those precise values and attitudes we identified that needed improvement. And I am happy to say that moving to Agile delivered on its promises. Our customers are getting better quality, better control, better visibility and faster results. And our teams are more motivated, getting recognition from customers and internally, working in a more integrated way within the company and with the customer team, and overall, more satisfied with a job well done.

So in our experience, as long as the behavioral and attitude principles behind the spirit of Agile are present, Agile will deliver the expected results. And that is where I think the challenge for most organizations lies. Following an Agile methodology “by the book” will always fall short of expectations if the people involved in the process don’t work as a collaborative team of peers, with the needed visibility, and taking responsibility for their individual pieces of the puzzle. So moving to Agile is more than changing methodologies, it really requires a cultural shift.

For more on the topic, please see When Agile Projects Go Bad – and Good Luck in your efforts!