What does it take to be Agile?

Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change.


Sean Cody, Bank of America’s process architect, is reinforcing the paybacks of adopting an Agile development in an interview for Information Age . He is offering insights into how Agile reduces risk, the shift away from from classical waterfall approaches and the return on investment. I mostly agree with his ideas, but I would like to outline some differences about the skills that developers need to be part of an Agile team, the benefits of adopting this approach and what it means to be part of a hybrid team.  The one point to be understood from reading this is that there is not only one correct way of doing things. Applying an agile methodology across a big firm is a big advantage, but you will find it hard for people to adapt, especially managers (who are sometimes too tempted to micromanage) that find it hard to delegate and let people come up with their own ideas.

Why do people need to change from the classic waterfall approaches to Agile?

Sean is arguing that working in a business that gains money from being a little bit faster than its competitors brings us to the conclusion that working software needs to be delivered on time and with as few defects as possible. Agile reduces risk and facilitates open collaboration between developers and business stakeholders, and enables process adaptability throughout the software development life cycle.

In addition to these ideas I would say that by adopting Agile, people in teams give deliverable software each sprint (a sprint is a period of time – usually two weeks), which makes it faster to find defects. The progress and the speed of the team can also be monitored between sprints. This way you can see which teams perform better and even do competitions between teams (gamification), so they would be more challenged.

What skills do people need to be part of an Agile team?

Sean’s argument is that people do not need a specific set of skills and that all Agile practices are simply common sense. I would like to contradict this idea and say people need a certain set of communication and inter-personal skills.

From what I have seen young people tend to be more open to the new methodologies, are open to try with the risk of failing, while more experienced programmers do not want to change their routine that has worked well for them throughout their career.

With teams spread over 3 continents, you would find it hard or impossible to be pair programming with a colleague that is 3000 miles away. Pair programming is when two people pair to resolve one task, one is coding and the other one is looking and asking questions/ having a conversation. I have worked in Bank of America over the summer and I realized that with today’s technology it is not that hard to do, you only need a headset and screen sharing software. Although there are some difficulties caused by different time zones. The good thing about pair programming is that you need to know what you are doing (no more trying something without actually knowing what you are doing); you have a pair of eyes looking all the time “over your shoulder” and asking about what you are thinking about.

This kind of pressure makes you be more consistent, more serious, change the game and make you work better and harder, but also helps you become better at expressing your ideas and having to communicate all the time. In conclusion, people having problems communicating their ideas would find it hard to adapt in an Agile team.

Are there any Team Managers?

The short answer is maybe. An Agile team is supposed to have no team leads/ lead developers/ managers, but as Sean is suggesting: “a purist interpretation of Agile practices would state that the business must fully commit to the process if Agile is to succeed, but the reality of the business environment we operate in is that we’re not always going to get that complete level of buy-in”.

I would reinforce this idea with an example. The team I was working in was a hybrid team. Changing from a waterfall approach to Agile did not seem to be as straightforward, so a hybrid was developed without changing the fundamentals: continuous integration, test-driven development, iterative and incremental approach, etc. The sole difference was a designated lead developer who set long term goals and checked everyone’s progress. Although many “hardcore” Agile adopters from other teams, that were following the methodology to the letter disagree that this was indeed an Agile team, it seemed to work perfectly for us.

Even if one was called manager, most of the decisions were still taken together, the tasks were assigned to pairs of two and the sprints’ projects were successfully finished on time.

Is Agile right for all projects?

The article suggest that Agile is not suitable for distributed teams or large projects. I would like to argue against this idea, based on the following examples:

  • For a team split across 3 continents (London, Hong Kong, New York): There are two scrum meetings (scrum meeting happen so that everybody keeps up to date with the progress of the sprint): one in the morning and one in the afternoon – Europe time. In the morning meeting all the people from Asia and Europe, with a few from the States would be online. In the afternoon meeting all the people from Europe – New York and a few others would be online. This means that everybody has the opportunity to report what they are working on and also ask for suggestions when they get stuck.
  • A large scale project can be difficult and time consuming. If this project is time consuming, requirements can change over time. If the requirements change you would need a suitable approach where you can change the direction in which the project is heading. By following the Agile approach you can easily adjust your next sprint to introduce possible changes in the management’s perspective over the final product.

Developers need to learn to work in smaller teams. No one needs to be continuously checked to see if they are doing well. . Today’s programmers are more than just software programmers, they also do testing, design and planning, which involve a number of different qualities to consider. Being part of a multifunctional team is an advantage and pairing makes the team balance the work better and get rid of the dependence over certain key people. In an Agile team everybody works for a common goal, there are no individualities, no one is considered better or worse than anybody, and this makes the teams be more competitive and get more software done in time.

I would like to conclude that I agree with most of Sean’s ideas, but consider that agile developers need different sets of skills. They need to be more malleable and this is a good thing because the technologies change so quickly now and will definitely change quicker in the future. Being an agile developer is the best preparation for the future.