The adoption of the agile methodology in software development grew in relatively rapid fashion. I remember not so long ago a lot of people in the IT world had heard about agile, but not considered it for their own teams. Today, most of the development groups I talk to claim to adhere to Agile, at least to a certain extent. But, many of them say privately they are not realizing the benefits in productivity and quality that they expected. In the end, they find themselves slipping back into the traditional waterfall model for all or some of their projects. They were thinking agile attitude? What for?
The truth is, many groups aren’t using agile attitude, they are really using as an excuse to take shortcuts and avoid doing the things they don’t like to do in the first place. There is no surprise there that agile attitude is “not working” for teams in these situations. However, other groups are making conscious efforts to adhere to agile principles and they are still failing to realize the benefits they expect. An interesting article in CIO puts the problem in a different light, “Is it agile we need — or an agile way of thinking?”
In Our Experience
For our teams in Scio, it took two attempts to “get it right.” As with many other software groups, when we learned about the agile attitude 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 burndown 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 six 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. The people issues we encountered ran from communications to visibility of goals, and individual 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. I am happy to say that today, moving to agile delivered on its promises. Our customers get better quality, better control, better visibility, and faster results. Our teams are more motivated, working in a more integrated way within the company and with the customer team, and overall, more satisfied with a job well done.
Agile attitude is on
So, as we learned, as long as the behavioral and attitude principles behind the spirit of agile are present, agile will deliver the expected results. And this 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, while taking responsibility for their individual pieces of the puzzle. Moving to agile is more than changing methodologies, it really requires a cultural shift within the development team and in the best case, the entire project organization.