One of the interesting things about having an outsider look at my work is that I have an opportunity to gain a greater understanding of what I do and, specifically, what I do differently from others. Joanna Geraldi gave me such an opportunity when she came to interview me about my approach to project management for some research. After the interview Joanna characterised my approach as "’real’ principle-driven agile project management". That got me thinking because for a long time I was far more concerned about practices than principles. It seems that has changed.
Practices: Just tell me what do I have to do
Back in 2000, when I started on my Agile journey, I was running XP teams by following the book but I was interested in the other methods and read widely. Even at that stage there were several players in the Agile ballpark; XP, Scrum, DSDM, Crystal Orange, Feature Driven Development were all there. It was all fascinating and exciting yet also frustrating and confusing. I found the practices of the various Agile methods too diverse to easily make sense of it.
The question I asked myself was, if all these methods are “Agile” then what does “Agile” mean? Or, more specifically, if I am an agile project manager then what do I have to do?
The Agile Manifesto of Nov 2001 didn’t really help my confusion. Although the values and principles behind the manifesto looked good to me (and still do) they didn’t tell me what actually to do as an Agile Project Manager. In particular I wanted to know which practices were universal and which were specific to a particular Agile method (XP, Scrum, DSDM, etc).
This confusion led me to write my Agile Comparison in Apr 2002. The comparison is perhaps now dated but it was very useful to me back then. If you have a look the focus is exclusively practices. I was very much interested in what I had to do and not interested in anything deeper.
A decade later it seems I’m doing "’real’ principle-driven agile project management" – what happened?
The Irony of Practices
There is an implicit irony in Agile practices. They are easy to teach but, of themselves, convey little understanding. And it is understanding that makes effective practitioners.
One of the lessons we’ve learned from the Agile development movement is that just telling people to do things doesn’t create lasting or sustainable change. When the people you’ve advised encounter a situation that isn’t covered by the rules, they’re lost.
Hoover & Oshineye (2009), Apprenticeship Patterns: Introduction
Ohno – the originator of Lean – was never keen on codifying method:
Ohno said "Don’t call it anything. If you call it something, managers will expect it to come in a box." He was right.
John Seddon cited in David Joyce
The point is that a method in a box doesn’t help much. I’ve had people imitate the things I do when running projects but without deeper understanding then imitating the steps is unlikely to lead to success.
Going Deep on Practices
Personally I am not content to just learn a practice and apply it. I want to understand it. And that means knowing, to borrow a journalistic line, the who, what, when, where, why and how of the practice.
- who does it: me, somebody else, a specific role, the whole team
- what to do, i.e. the repeatable steps
- when to do it, i.e. when the practice fits in the agile heartbeat
- where to do it, i.e. the context for which the practice is intended; where it is likely to fit
- why do it, i.e the gap the practice fills and proof it will do it effectively
- how it works, i.e. the underlying principle(s) and value(s)
Somebody can get going with a practice just with the who, what and when. These are the mechanical bits and a lot of books and training focus on these. But I believe a practitioner needs the where, why and how as well. These are harder to define and harder to learn.
Where: Looking for the fit
Over time I’ve realised a practice has to fit the context in which it is used. And a practice that worked in one context might not work in another. There are organisational, team and personal aspects to this "fit". If a practice doesn’t fit for any reason then it will be abandoned, quickly.
For a start the organisation must be open to the practice. That might mean active support by providing some resources such as machines or investing time in the development infrastructure. But openness, or lack of, can also be something more fundamental. Energized Work: Values, Practices & Principles point out that the values underlying some of the Agile practices can be in conflict with organisational values.
Agile/XP teams often run into difficulty with organisational structure – many of the practices support values that are not necessarily consistent with those of the organisation (empowerment being a key example). Worse still, a company may have no common values (perhaps due to a lack of common vision or leadership) or different elements of a company may hold conflicting values.
Energized Work: Values, Practices & Principles
Similarly, the practice must fit the team, whether programme, project, or product. The most obvious example of a mis-match is that some practices might work for a small team but not for a big team.
I’ve also noticed that practices have to fit the style of the people involved. What works for me doesn’t necessarily work for other people.
Why: Why Bother?
I’m not too impressed by slavish adherence to a process, no matter how esteemed the book, author, or Agile guru. I like to know why I should introduce a new practice.
For a start I need to understand the purpose of the practice. My material on Agile Project Management attempts to highlight the purpose of various Agile practices, at least through a Project Management lens.
I also want confidence, often before trying the practice, that it will work in the field. There has to be compelling evidence (see Evidence for Agile) or acknowledgement that adopting the practice involves risk.
But the most important part of “why bother” is identify the gap or deficiency in the current process that needs the new practice. If there is no gap, then the only reason for adopting the new practice is in the spirit of experimentation … again with a risk factor.
How: Principles and Values
The Agile literature is full of references to practices, principles and values. There are the four values in the Agile Manifesto (that the signatories reaffirmed in 2011 – see PragProg: The only Agile tools you’ll ever need) and the Principles Behind the Agile Manifesto. XP has some values and principles (Beck, 2000), as does Scrum (Schwaber, & Beedle, 2002). Now there are some more values in the Manifesto for Software Craftsmanship. All of these values and principles have associated practices, for example, the Manifesto for Software Craftsmanship is backed by a whole book of practices (Hoover & Oshineye, 2009).
And, of course, I’ve already used all three terms in this post. So what is the difference between values, principles and practices. The way I look at it is that:
A good practice is a set of repeatable actions
that works because of some underlying principle(s)
and produces effects that support some underlying value(s)
If that definition isn’t clear enough then have a look at Energized Work: Values, Practices & Principles. Their post includes some pretty good examples.
I’m not looking for a method in a box. I follow a set of guiding principles that align with my belief system (Agile Manifesto and Lean Manufacturing) and then do what works within the context. (David Joyce is right that there are no clear Lean principles but the specifics are not important; the essence is.)
It is this philosophy that gives me my eclectic style to software delivery.
The current war between Kanban advocates and Scrum enthusiasts highlights how putting the practices first can lead to entrenched and combative views. I believe there is a lot more alignment on principles and values.
References
Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.
David Joyce: 14 Principles, 5 Principles, 5 Pillars, Which do you use?
Energized Work: Values, Practices & Principles
Hoover, D. & Oshineye, A. (2009). Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly. [Available on-line http://ofps.oreilly.com/titles/9780596518387/]
Manifesto for Software Craftsmanship
Principles Behind the Agile Manifesto
Schwaber, K., & Beedle, M. (2002). Agile software development with Scrum. Prentice Hall.