Between principle & practice: Agile disciplines

I’ve always admired the Agile Principles. They seem to capture what was wrong with quite a lot of waterfall development and replace its mechanistic bureaucracy with individual expertise, discipline and professionalism and the people’s spontaneous ability – even, in the right conditions, enthusiasm – to lead, create, and assume responsibility.

Don’t get me wrong, I like bureaucracy. It’s what pays me every month, puts the electricity into the lights every morning and generally runs the world. But it’s not necessarily the best thing for dealing with an activity that is highly dynamic, inherently difficult to specify and generally the antithesis of the orderly flow of information and decisions that regulate most other forms of engineering.

But I still think the Agile principles could do with extending into more practical disciplines. We’ve been doing Agile for a while now and we’ve learned a lot. One consequence of this is that the original principles seem a little superficial and trite. Again, that could just be that they operate at a level of abstraction that is, in itself, very desirable – I wish the same could be said of any waterfall methodology. But they would benefit from being elaborated downwards to a deeper level and brought more in touch with the types of activity real engineers are engaged in every day. That would allow us to transition straight from principles to day-to-day work, and without such a bridge, the principles are likely to hang very vaguely over what people do, and break down when they are challenged by powerful people with bureaucratic instincts.

Analysing the Agile Disciplines

With that in mind, I started to think through what a complete set of Agile disciplines might be. of course, quite a few disciplines have already surfaced – things halfway between principles and practices. But they could do with being organised into a comprehensive suite. Such a set would need to relate to all the old principles, to reflect existing good practice, but not to impose any special flavour of Agile as though it were sacrosanct.

Here is what I came up with in about half an hour (and then 3 weeks of on/off editing!):

AgileDisciplines

 

I arrived at this version quite pragmatically (a weird feeling for an inveterate theorist like me!):

  • I wrote down the original principles.
  • I listed all the practices and disciplines I could find in my own work, in some of the key books on Agile, and among the mass of good Agile websites.
    • (This isn’t a full set – Agile201’s most current version is considerably more comprehensive. Subscribe and see.)
  • I connected them together by loose, intuitive affiliation or something like cause and effect.

To my surprise, they quickly broke out into a small number of groups, which I’ve called User, Team, Product and Work. And they seemed to centre on a single point: Transparency. Which seemed plausible enough.

Another thing: If you look not at where all these groups converge but at the discipline that seems to gather together most of each individual group, there is also a single, unifying item (something halfway between a discipline and a principle):

  • For Work, Simplicity.
  • For Team, Adaptation.
  • For User, Change.
  • For Product, Quality.

Well, if I were trying to summarise Agile in a sentence, ‘Adaptable teams using simple methods to deliver a quality product in the face of constant change’ would be pretty good.

How the Agile Disciplines are grouped

Interestingly, when I analysed the data farther and looked for how many links there were between the disciplines as a whole (i.e., regardless of these four main groupings), this is the order in which disciplines were most connected (most cross-linked disciplines first):

1. Motivation
2. Simplicity
3. Adapt continuously
4. Transparency
4. Fastest way to do anything…
6. Sustainable pace
7. Cross-functional
7. Iterative & incremental
7. Look ahead
7. Self-organisation
11. Just enough
11. Refactor
11. Welcome change
14. Deliver early, Deliver often
14. Grooming
14. Prioritise
14. Working software
18. Challenge everything
18. Continuous everything
20. Collaboration
20. Quality first
22. Collocation
22. Just in time
22. Pairing
22. User involvement
26. Automate everything
27. Debug first
27. Trust the team
29. Test first

Admittedly I drew up these links in exactly the same way as I grouped the disciplines in the first place – by intuition. Even so, it’s an interesting list, I think. Although three of the five key disciplines – Simplicity, Adapt Continuously, and Transparency – appear in the top 4, two of the most emblematic items – Quality First and Welcome Change – come in at 11 and 20 respectively.

And at the very top? Motivation. Which is perhaps the best news of all, as it insists that (to repeat a tedious old 90’s cliché), people really are our greatest asset. Always an implicit theme of Agile, so it’s nice to see it validated so dramatically. Taken with the centrality of Transparency to the overall picture, I find it genuinely moving.

Much more concisefly…

But not as funny as Dilbert’s view of the same topic:

Dilbert carbon paper

Or maybe it’s just me agreeing with the prejudices I’ve built into my own diagram!

By |2018-04-25T16:52:01+00:00Wednesday, July 22 2015|Categories: Agile, All, Bureaucracy, Process and method|0 Comments

About the Author:

Chief Architect, Agile201.com.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.