Agile software development is a framework for software engineering that promotes development iterations throughout the life-cycle of the project. The concept behind Agile is to minimize risk by developing software in a short amount of time with the goal of having an available release (without bugs) at the end of each iteration.

Agile has gained a lot of cache among senior developers drawn to a less-restrictive approach to code development. But critics charge that Agile methods (there’s more than one) are inherently flawed. They say Agile’s pared-down specifications don’t address the core value of developing to meet business needs, and that there is too much margin for error in the absence of hardcore planning methods.

Red Canary asked three Canadian proponents of Agile Microsoft MVP (Most Valuable Professional) James Kovacs, Strangeloop CTO Kent Alstad and Imaginet co-founder/Microsoft Regional Director Joel Semeniuk to share their thoughts on Agile.

Red Canary: Let’s start by defining some of the key characteristics of Agile.

Semeniuk: From my perspective, Agile boils down to a feedback mechanism. Feedback with your customers, feedback with your technology, feedback with your team . . . Agile’s all about communicating.


Alstad: There’s an idea that Agile has a willy-nilly, do what you want approach, which to me is not true. Some of the key principles of Agile are having shorter development cycles, building understanding over documentation, accounting for past behaviour in current decision-making, and working really closely with a customer advocate.

Red Canary: Traditionally, development methods are thought of as ranging from predictive to adaptive with Waterfall methods on one of the continuum and Cowboy coding on the other. Where does Agile fit in?

Semeniuk: Agile is in the middle. In order to have a predictive method you need extremely defined requirements and in almost all software development that’s not the case. With Waterfall you try to do your entire design up front and then go through implementation, testing and deployment. With Agile, you kind of do all of those things in smaller chunks inside of smaller iterations. Agile sets it up so we can be more resilient to change. That allows you to add value and respond to change as you go.

Kovacs:[Many] people put Agile in the Cowboy [camp], but it isn’t like that. In the 90s there was a lot of Waterfall methodology with intense processes, and experience has shown that it didn’t work well – you never know enough to fully spec a project until you’re actually done. Agile methodologies like Extreme programming and Scrum talk about the notion of an architectural spike . . . the idea that at some point you’re going to have to deal with new integration that goes all the way from your UI down to your database. Rather than waiting until the last phase of development to address those issues – like waterfall does – Agile has people making informed decisions along the way in real time.

Red Canary: Do Agile methodologies rely on the close proximity of team members in order to be effective?

Alstad: I don’t think so. We operate virtually . . . I spend a lot of time on the phone and in screen share sessions. Nobody’s ever late to meetings in the morning and everyone always has all their resources available. I’m not saying it (virtual Agile) is a piece of cake; from an HR perspective it’s harder, you really have to be a Caesar. But I’ve done it for 12 or 15 years successfully.

Red Canary: Is Agile better-suited to boutique-sized teams, say no more than about a dozen developers?

Semeniuk: That’s the perception. The reality is that the core principles of Agile can be scaled up considerably. We’ve worked with organizations in the financial industry where there were upwards of 150 people on our team. Agile doesn’t have to be limiting in terms of size or scalability . . . more than anything else, it’s a mindset of how you approach the project.

Red Canary: I’ll list common knocks on Agile and ask for your response. First, Agile relies on a small team of highly-skilled people, meaning there are fewer hands, higher personnel costs and bigger egos to wrangle.

Alstad:Man, I don’t want that to be true but I fear that it is. We have very senior people and there’s a reason for that: with Agile, you have an expectation that people won’t drop balls. And there’s not a lot of patience to go back and clean-up.

Red Canary: Another knock: Agile puts too much business power in the hands of developers (who may not be very business savvy).

Kovacs: Interesting question. Another ideal of Agile that’s sometimes difficult to get is that a project team consists of more than developers. It consists of developers, technical writers, project managers . . . but it also consists of business users. It’s the business users who should make decisions about how a customer is structured. Business users provide feedback, run test cases, decide how orders are handled, and such. In the ideal Agile team, they sit right alongside and design solutions with developers.

Red Canary: Another knock is that Agile methods are ‘product-quick’ but result in a lack of documentation that leads to business pain down-the-road.

Alstad: No. The problem is that you have to introduce documentation at the point where product is stable. All too often in Waterfall methods you spend time writing documentation about what didn’t get built. Build time in to your plan to produce documentation once you actually know what you’ve built.

Red Canary: Finally, consulting firms that use Agile development write outsourcing deals with no specifications. So, when the application is delivered – and doesn’t perform to expectation – the consultant can’t be held accountable.

Semeniuk:I have to agree that Agile in a consulting engagement is very difficult. Customers are looking for “What will I get for this amount of money?” and Agile is more about changing value. It’s been my experience that even though a client will want fixed requirements around a project, those requirements will inevitably change. Agile lets that change happen while still working within a fixed budget environment. Structuring Agile deals so dollar flow is triggered by incremental milestones rather than in fixed-lump sums is important.

Red Canary: When do Agile methods make the most sense?

Semeniuk: It’s a tool for evolving businesses. Agile [was] created to provide higher value to business processes . . . it actually leads to a higher degree of discipline both for clients and the team. Mature companies tend to see the value a bit better, but Agile also works really well for start-ups that want to demonstrate early and often that they have value in their product.

Kovacs: I think Agile is widely applicable in a variety of business contexts. It excels at new and speculative development where you’re integrating business systems – CRM, back end stuff – where no-one has integrated in that way before. Agile is about interaction and dealing with business risks head-on. It very much breaks the mold of what people think software development is.

Red Canary: Thanks guys.