One element is often forgotten when we think about Agile: You need to build real teams before you can tap into the benefits of agile methods. Teams are at the very core of many methods, and without a real team, your agile adoption will become challenging.
So what’s a team, or more specifically, a real team? Real teams share these characteristics:
Agile sometimes works, sometimes it doesn’t. What are the circumstances in which agile software development yields positive results?
It seems clear that it relates to the context in which Agile is applied, i.e. the kind of project or the organisational structure. So, if we divide the problem into two parts, the context on the one hand and the method (i.e. set of agile practices) on the other, how would we go about choosing the right set of practices for our software project? It requires an understanding of both sides, but more importantly the interplay of the two.
Many things have been said about Agile and why it seems “better” than other approaches. But an answer to the why often only considered the outcomes (i.e. project deliverables and measurable aspects to it). But how agile software development (ASD) achieves this isn’t well understood, researched and documented (i.e. the lack of conceptual clarity in ASD). However, if we are to chose an agile development method, understanding the how becomes crucial in order to know which actions and behaviours can positively contribute to the outcome. …
When are agile practices are useful and when should we avoid them? Discussions like this often revolve around aspects like project size, team distribution, lack of management support, etc. All of these aspects seem to have an impact on the success of agile development practices. In his paper “Contextualizing agile software development” Philippe Kruchten (2013) presents a contextual model for software development to guide the adoption and adaptation of agile software development practices.
Kruchten’s definition of agile builds on “the purpose or function of being agile for a business, rather than defining agility by a labeled set of practices”. He points out that many projects “do agile” without actually being agile. As a result projects regularly fail when applying agile practices “out of the box”, without contextualising the approach, i.e. …