February 22, 2006 | John Rusk | 7 Comments Agile development is hard to define, because most people define it by giving examples. For instance they give a specific description of Extreme Programming (XP), instead of defining of agile development in general. We’ve ended up with a widespread misconception that agility is about XP techniques like Pair Programming and Test-Driven Development (TDD). By the way, if XP is the only form of agile that you know, this page probably won’t make any sense. Am I really saying that TDD is not part of the core definition of agile? Yes I am. Look for TDD in the Agile Manifesto. It’s not there. While TDD is a good thing, and I like it, it’s not the core essence of agility. You’re welcome to define XP in prescriptive terms, mandating pairing and TDD, but those same prescriptive terms do not describe the agile movement as a whole. It is, after all, about “people and their interactions; over processes and tools“. Defining agility by describing XP is like defining democracy by describing America. Such a “definition” obscures the underlying concept with details of the chosen example. Agility is not defined by TDD, just as democracy is not defined by having a President. Democracy is defined as “choosing leaders in competitive elections”. It makes no difference whether you have a federal system or not; whether the executive is or isn’t separate from the legislature; or which method you use to count the votes – it’s still democracy. Do we have a similar definition of agile development? One which is uncorrupted by specific examples and which defines the core underlying concept? In many respects, we don’t. The agile manifesto is the founding document of the agile movement (and the source of the term “agile development”). It’s a great definition of what agile developers think; but it doesn’t concisely define what they do. In other words, it talks about values and principles but not about practices. Here’s my soundbite-size definition of agile: The agile movement asserts that software development works best under: Simple, iterative processes, which empahsise creativity and collaboration. Other definitions include this one from Scott Ambler and two really nice ones from Alistair Cockburn, here. Notes: I use the word “creativity” to mean “inventiveness” – i.e. “producing solutions to difficult problems” (not just artistic ones). The most difficult problems are those involving (i) lack of clarity of the situation [e.g. requirements], (ii) multiple goals, (iii) complexity and (iv) time considerations – sounds like software!
While improving my PHP coding skills, I have been looking for tools to help me become a better programmer, estimator, a more productive member of any team. The further down the agile rabbit hole I travel, the more obvious it becomes, successful groups have one thing in common. The company, the management team, the group all focus on “people” first and those programmers select the tools/processes that work for their team. As long as the group can reach a sustainable velocity, that never results in a death march, enabling them to deliver “done done” end user solutions in a repeatable way…does the process they use truly matter? [Assume members can be swapped in/out, code is not refractored beyond a state of understanding nor is it sloppy as that would seriously impact future velocity in maintenance.] When the agile (little a) group choses the tools and processes, they will be more effective than a group that has tools/processes thrust upon them. Its a subtle yet very important difference that often makes the difference between success and failure. (i.e. Are your stories assigned or selected?, that subtle) Perhaps TDD will be the best, perhaps XP, perhaps some hybrid of those with a little something spicy thrown in will work better. Whatever the end recipe, tools, processes, intelligent management gets out of the way to avoid killing the groups creativity and inventiveness, at least if they are truly “smart” they do. When in a management position, my team members always came first and we delivered. My experience in teams and business units where the processes were dictated by others, not selected by the group, we often had difficulty delivering completed products on time and on schedule, without a death march. We were often micro-managed and the processes were onerous…programmer turnover was high. The concept of putting people first is hardly a new one, just reference Wideband Delphi, developed in the 1940s. And agile makes estimating effective with the ability to reach a sustainable velocity in as few as three or four iterations. Your definition focuses on people first, without regards to any specific process or tool, that makes it a good definition.
So far we only learned that being agile has become necessary. The best way to agility however has still to be found. My definition of Agile is twofold: Software Developer’s Definition of Agile: Agility means to have a process in place that will allow us (and urge us) to react on changing business requirements as soon as possible: Accept that the project’s goal is a moving target. Project Manager’s Definition of Agile: Agile Project Management means to have a process in place that is to maximize team efficiency. You may want to read Agility is fine – the Manifesto can be Poison.
Your post has helped me to identify where I was going wrong. It is important to follow a strategy just like you have displayed. Taking a different approach is important, and taking things in strategic steps.
To start, you cannot really define agile software development in the traditional sense. The closest definition that relates is the term “Agile” and is defined as “Simple, iterative processes, which empahsise creativity and collaboration.” Of course, this only defines the process, not actually what they do because the term agile software development can describe an almost limitless amount of individual teqniques. Since the term agile in itself describes the use of creativity and collaboration the end result will always be different. Therefor when asked to define agile software development many people usually use examples to define it. This leads to many misconceptions about agile software development. For instance they give a specific description of Extreme Programming (XP), instead of defining of agile development in general. https://en.wikipedia.org/wiki/Agile_software_developmen https://www.agilekiwi.com/other/agile/definition-of-agile-development/