This is a back to basics post driven from a number of interesting conversations I have had recently.
Firstly here is my personal definition of Agile:
An umbrella term for the toolbox of light-weight methods, practices and techniques that are focused on working smarter, not harder.
So let’s break that quote down.
“An umbrella term” means to me that it is encompassing, or arching loosely over something.
“toolbox” suggests that there are tools within it. Like all good tradies (that’s Australian for tradespeople) they know which is the right tool to apply to the right problem. You won’t use a hammer to tighten up a screw.
“light-weight” I debated whether to use this in the definition or not – primarily because to some extent I believe that Agile requires greater disciple than ever before, then again, you can still be disciplined and have simple tools in your box.
“methods, practices and techniques” Most believe that Agile is just either Scrum or FDD or XP, but you are rarely ever using just one method (or model) by itself and in reality you are likely to pick and choose the methods, models, practices and techniques that apply to both your organisation’s culture, to the system, to the people and to the situation.
For me a practice is a repeated activity – stand-ups are good example of this, as are retrospectives. The line between practice and technique is where it gets really interesting. Let me give two examples:
- Prioritise work
- Plan your ability to deliver based on facts
So we can prioritise work in many ways – we can prioritise based upon value, based upon risk, based upon both. We can use MoSCoW, High/Medium/Low, we can have ordered lists – the techniques that we use to get to a position whereby we have a prioritised set of work are quite varied.
We can also plan our ability to deliver based on facts in a number of ways – we can pull in an iteration worth of points based upon the velocity of the last iteration, we can measure average cycle time and understand our variations. Again the techniques to get the answers are varied.
In both instances we want to regularly ensure that we are prioritising work and that we are planning (where needed) based upon facts.
In this context it becomes simple to argue that maybe Retrospectives, as an example, are not actually a practice and more a technique. In this mindset the practice would be “Evolve the way you do your work” and the technique would be “Retrospectives”. I could live with that. There are many different formats that retrospectives come in – deltas, sailboat, quadrants, timelines. You can also evolve how you do your work in many other ways.
This then leads to the debate about whether statements like “prioritise work” and “evolve the way you do your work” are more principles than practices. Ultimately, if you are regularly doing something that reaches that outcome in a repeatable way I would say it is a practice. I am happy to debated otherwise on this front.
“working smarter and not harder” Note what I don’t say in this definition – I don’t say that it is a software development approach. It can be used for software development, and works well for it, even was born from it, but it can be used for more – so why be exclusionary, spread the love! For this reason it isn’t about working software it is about working smarter. For me, working smarter means delivering value to customers in ways that have reduced waste, improved innovation and a very healthy respect for people.
So in conclusion – just to re-iterate, to me Agile does not mean Scrum. Scrum is just one single element of it. I like to think that methods, practices and techniques such as Kanban, Cynefin, Systems Thinking, Lean, Systemic Flow Mapping, etc all have a place in Agile.
Within Australia I have never seen us as an exclusionary crowd. We embrace better ways of working smarter. We like to absorb them into the Agile toolkit we have, a toolkit that should evolve and change over time as we better understand our world and what works and what does not. Most coaches I know don’t teach just one way, they teach a toolbox of ways and often subscribe to the Oath of Non-Allegiance. They have moved on from the Agile Manifesto and begun to embrace the MoreAgile Manifesto.
As always, all comments are welcome but I desperately desire feedback from the Australian Agile community – what do you think: are we embracers of evolutionary Agile or as a community we are stagnant?
Agile Forest 
Nice post. But fails to address – or even ask – the central question imo (as does the MoreAgile Manifesto). The question in question being: “Is there any point pursuing local optima?” (and a second question follows: can Agile EVER be more than a pursuit of a local optimum?)
– Bob
Hi Bob – can you please explain further what you mean by local optima? I am assuming you mean that Agile changes a team and not changing a system? If this is your interpretation how do you go about changing a system (in your opinion)?
Hopefully this can begin to explain what I meant, and provide a little context too: http://results2match.com/ackoff-70-of-business-improvement-programs-tqm-downsizing-benchmarking-decrease-performance
I also concur with Dr Ackoff’ suggestion that a sound way to change a system is voas e.g. Idealised Design a.k.a. Interactive Planning for which see e.g.: http://www.ida.liu.se/~steho/und/htdd01/AckoffGuidetoIdealizedRedesign.pdf
– Bob
Thanks Bob for the links. I had a look over them. The first I intepreted as systems thinking which I do believe should be done when implementing Agile. I agree it isn’t enough to just apply Agile to a team or that in doing so has limited success. I even mentioned that I would include Systems Thinking inside of that umbrella that we evolve to incorporate.
The second one reminded me a lot of Lean’s 7 step process blended with systems thinking. Whilst it asks a lot of questions I found it hard to practically apply answering how to implement such a method in a 15000 person organisation. Can you get a system of 15000 answering all these questions? At some point in time you are going to split it down and then you have the very problem you are raising.
Interested in your thoughts.
This is a good question to ask ourselves all the time. With the huge diversity of topics at Agile Australia 2012 and LAST Conference as 2 examples, we are growing an embracing agile culture.
I am happy to keep looking at new ideas and pleased when I see so many other people doing that as well. Not for the sake of adding lots of things but for the purpose of finding better ways to work.
Great post Renee
Here is an alternative wording:
“An umbrella term describing a toolkit of principles, practices and methods that help teams work smarter and achieve better outcomes.”
My reasons:
– Light-weight might imply that Agile is not suitable for large teams/projects.
– Toolkit is broader than toolbox
– Principles enable the addition/inclusion of new practices – provided they are aligned with the principles
– Achieving better outcomes is the reason we do Agile
Hope this helps.
Better at what? As I explain on my blog, so called agile techniques WERE originally called lightweight, until it was decided as you said that there would be a perception that they aren’t serious.
That was a mistake. Aluminum is lightweight — and it is strong than steel (pound for pound).
So called Agile — Lightweight methodologies make sense just like lightweight materials make sense.
In some — but not all cases.
It’s time to call spades spades again, and not call a spade a bulldozer or vice versa.
Jordan
I would say in general that so called “agile” — lightweight techniques are designed to produce tangible results faster.
I would leave words like “smarter and better” out of the equation.
They may be better or they may not be; they may be smarter or they may not be. In fact they may wind up being quite average.
However they will see tangible results faster. That’s what I see the real thing that “agile” brings to the table, once the glittering generalties are removed.
Jordan
I would agree that as it stands some of the agile methods, practices and techniques have no proof of the claim. That said, they should and we should be focussing as a community to prove or disprove whether something is working or not.
Well that is a valid argument and I agree we need more proof of efficacy –but what I’m speaking of here is not even whether it works or not — but what is it trying to achieve.
Even if it worked, comparatives like “better” would need qualification. Better than what?
But I’m going at the moment meta to all that and merely speaking to — so called “agile” tries to get tangible results quickly. irrespective of better than or etc. Is that fair?
Jordan
It is pointless getting tangible results quicker if the results are not something that a customer truly wants. Historically Agile has failed to do this, we have just delivered the wrong thing faster. What we must also do is deliver the right thing. This is where Lean Startups being added into the umbrella makes sense.
For me better means both “delivering better” and “better at ensuring we are delivering the right thing”.
I’m not sure that “Lean Startup” is 1) part of “agile” or 2) delivers a better product. Lean Startup tries to develop a MVP at essentially the lowest possible cost.
It doesn’t mean it’s the “right” product. I don’t think we should be talking about “better” or “worse”.
A shovel does not need to be better or worse; a shovel can be defined as a stick with a scooped blade that can handle up to xyz cubic inches of load.
There is no need to talk about better or worse. It’s the better or worse thing that causes all of the problems in agile — the whole versus, cult religion thing.
I think defining “agile” as a way to get tangible product quickly is accurate — better or worse need not be part of the equation.
I certainly don’t see “agile” as being working smarter — at all — it’s just another way of working, neither better nor worse.
Jordan
It is unfair to say that Agile methods can only produce tangible results faster without better quality and that they are merely “lightweight”. Time to market may be the primary reason for many companies to go Agile but in our case, we explore Agile methods for better quality.
Sorry for off tracking a little bit but the debate reminds me of the history between Newtonian & Quantum mechanics when Max Planck’s first published his quantum hypothesis in 1900. Albert Einstein, one of the early contributors to Quantum Mechanics & also a member of 1927’s Brussels Solvay Conference (Quantum manifesto?), refuted some of the “unproven claims” of quantum mechanics, such as effect without a cause or random effects. Another example was one subatomic particle could occupy many areas of space simultaneously. His famously saying, “God does not play dice” was cried out loud in 1935.
Of course, some claims failed to be proved but many got proved and applied. Among them is the famous Quantum tunneling which was first noticed by Friedrich Hund in 1927. Newtonian mechanics predicts that a ball without the required energy cannot get over the hill to the other side but will simply roll back. But when breaking the ball down to sub-atomic particles, a particle without the required energy can, in probability terms, tunnel thru the barrier to the other side. It was not until 1957 did Quantum tunneling be generally accepted. Almost 50 years later, Hund, Leo, Ivar & Brian got their Nobel Prize in 1973 for their work in Quantum tunneling on semiconductors & superconductors. Nowadays, everybody knows that the transistors inside our computers work by Quantum tunneling of electrons. Scientists are still attempting to use Quantum tunneling to explain the extreme efficiency of photosynthesis in plants (Scientific American – May 18, 2011 issue).
My point is that the law of nature may vary across different scales and we can make use of the phenomena at different scales to improve our life. Similarly, after breaking down a project into tiny (e.g. 20 days) iterations and an application into user stories & tiny features, I found some phenomena that we can make use of to improve quality. Here, I would like to name three, in Quantum mechanics terms.
1. Specification / Acceptance “duality”.
If the duration between requirement and acceptance is long, we need to sign up the requirement specification to protect both sides. At the end, we have two out-synchronized documents. But with tiny iterations, we can directly discuss with users the acceptance criteria as specifications. Thanks to so many BDD tools out there (Concordion, Cucumber, FitNesse, JBehave, SpecFlow & etc) that we can break software into “subatomic” features where users can easily define scenarios in Gherkin language and give test cases as acceptance criteria (ref. Gojko Adzic’s Specification by Examples). Since they are acceptance criteria, the Specification is always up-to-date (i.e. living). We are now in the maintenance phase and we still communicate in Gherkin! After the change, we will execute full regression tests on all features to ensure that no other features are broken. We feel that better quality is achieved by merging Specification & Acceptance, giving living documents.
2. Employee “tunneling” (an energetic and happy team)
With tiny iterations, we can afford to maximize employee empowerment because we can easily smell a rat towards the end of the 20 days and do something. If in months, we have to institute more controls.
– 3 keys for empowerment from the book “Empowerment Takes More Than a Minute” (Ken et al).
– Share information with everyone (whole team listen to user requirements, not just Architect, BA or SA)
– Create autonomy through boundaries (e.g. Governance, tools, architecture and 20 days iteration defined by enterprise architect and PMO)
– Replace the old hierarchy with self-managed teams (team members take up jobs themselves. Tasks are not assigned)
– Keys to ignite engagement from the book “The Progress Principle” (Teresa et al).
– Employees’ biggest motivator is making consistent, meaningful progress
– small wins – seemingly minor steps forward in the work
SCRUM seems to have all these characteristics and the team is very energetic and happy. To us, quality of the team (energetic and happy) can directly affects the quality of products. After all, people are our valuable assets.
3. Uncertainty principle (the reality of user requirements)
Users only take final acceptance against working software seriously because they have to propose their acceptance to their boss and make payments. We have tried wired frames and prototyping but users are not serious enough. With tiny iterations, users have to propose acceptance every 20 days. In our last project, only 65% of the original planned scope was actually implemented while the rest had given way to new user stories identified during iteration acceptance. We believe that it is better quality if users can get what they actually need.
With tiny iterations, users stop gold-plating automatically and are more anxious of getting all user stories done and demo to their bosses. Their bosses are more willing to sacrifice “should” user stories for newly identified “must” user stories. With long iterations, users always have the illusion that IT can do more (by more OTs perhaps) but in tiny iterations, they realize the physical limit. The team has a better work-life balance (quality).
SCRUM can be seen as condensing the change requests of the upcoming 15 years into 15 iterations. These changes are uncertain and may shake your “pillars” of your design. We are now used to make these changes without affecting previously accepted iterations. We are not afraid of large scale refactoring because we have automated story tests as safety nets. Although layered architecture is in our governance framework, we still believe that tasks like changing ORM is not possible without all these “living” automated stories tests. Better maintainability quality is now a natural byproduct.
It’s unfair to rewrite what I supposedly said and then claim it to be unfair.
I said, agile means tangible things get done sooner, not that they are better or worse.
I never said that wouldn’t have a better or worse result, I said better or worse is not intrinsic to agile.
Your quantum tangent aside, you feel, (in some cases) that delivering features faster will cause your PO’s to be more realistic.
That is a possibility, it’s not a certainty.
You say that “quality” is enhanced by having features the customers want — that is not true.
The featureset might be more in tune with what users want, but the overall quality of the project is not a function of one aspect (the featureset).
Your statement that 15 years worth of changes can be foreseen in 15 iterations seems quite suspect; how can you predict the future so far out in advance?
Jordan
Thanks for highlighting my unclear and wrong statements. Excuse me that I am a newbie and I concur that “Dialogue is the key to improving”.
My quantum story is not about delivering faster (we practice water-scrum-fall with planning, architecture design, Governance, PMO, SCRUM, final UAT, data conversion, dress rehearsals and cutover). It is about a different way of divide-and-conquer. With this new way, we found new phenomena, which can help us to improve quality in certain aspects. In our past waterfall experiences (may be we are not smart enough), we seldom encountered these phenomena. I have shared 3 phenomena.
You are correct that the sentence about condensing the change requests of the upcoming 15 years into 15 iterations is wrong. It should read “SCRUM can be seen as a way to rehearse our development methodology’s ability to accommodate unexpected changes while maintaining clean code (Lasagna)”. Delivering clean code is not enough in our case. The clean code need to survive 15 years of unexpected changes. We found rehearsing it “early on” is an effective way.
My company is in the “Control / Competence” quadrant of the Schneider Culture Model and there is no need for a change (99.9998 reliability is our differentiator). We have implemented successful complex waterfall IT projects in the past and yet we pioneered water-scrum-fall to raise the quality bar (not delivering faster). We are not dogmatic but pragmatic and sometimes skeptic. We have not spent a penny on Agile consultants. We read books, blogs, InfoQ and customized our own set of Agile tools. We learn from the posting of seasoned bloggers, both positive and negative advices. We especially welcome postings like “Hey we have an innovative idea. Here are the full details how it works in my case.” and “Hey I hit a wall. Here are the full details of why it failed in my case”. We did learn a great deal from these.
We take your advice seriously but are confused.
It seems that the one and only real thing about Agile is faster potentially shippable product. From our experiences, we did found some Agile tools useful in improving quality in various aspects, like what I have shared. Are we cheating ourselves?
We shared quality improvement “A” and you said “that is not true…the overall quality of the project is not a function of one aspect” [subtext: “A” is nothing if you don’t make improvements in all aspects. Forget about Rome or you have to build it in one day.]
If we share improvement “B”, “C” & “D”, we expect to receive similar comments, which is quite discouraging.
The provability issue has also confused us. Newtonian mechanics is repeatable but can development methodology be practically repeatable? Resetting our memories and the same inputs can generate the same EXE? I once lost a program and rewrote it using the same programming methodology on the following day. After recovering my hard drive, the two programs were found quite different and the latter was even buggy because I was angry at that time. Besides repeating, another one is empirical method. Someone has tried to use it to proof that OO language is better than procedure language without luck.
(http://c2.com/cgi/wiki?OoEmpiricalEvidence). Software development methodology is even more complex than programming methodology. Another seasoned blogger argued that “Did we have great successful complex software delivered prior to Agile. Yes we have” [subtext: why innovate? Stick to past success!]. We can substitute “Agile” with “OO”, “COBOL” and even “Microcomputers”. Are we wasting our time?
Actually my reply should have gone here…oops 🙂
Jordan
It sounds like you are doing many different practices, but ascribing all “success” to agile.
I’m talking about Agile, and that’s it.
As far as your 15 years, you can’t tell whether your codebase or the product itself it will survive 15 years until 15 years from now.
Jordan
Many years ago, I did procedural and OO but ascribing all “success” to OO because “success” was referring to those advancements on top of procedural. Relativity is build on top of Newtonian mechanics. Calculus is build on top of Arithmetic. There is no pure Calculus without Arithmetic; no pure Relativity without Newtonian mechanics and no pure OO without procedural.
I can’t tell whether I can survive a fire until breaking out a real fire (touch wood) [subtext: why fire drills?]. Those who participate in rehearsals have higher chance of escaping.
Hi Renee,
Firstly, great post. I use a very similar definition in my agile training, I like to emphasise that it’s not one size fits all and we should be constantly looking for more tools to put in our kit bag.
To your question, is the Australian Agile community stagnant? As you say I think almost all the experienced coaches I know are embracing new methods and techniques so I don’t think they are stagnant. However commercially I’m seeing a disturbing narrow focus on scrum. For example, my new introduction to Kanban course is the only public Kanban training in Australia at the moment. This makes me sad.
Hope that helps,
Ben
Thanks for popping in Ben and replying!
To me agile is much more about a philosophy or culture than it is about tools and practices. All of those idea systems under the agile umbrella at their core have a lot in common in terms of attitude and goals which is why they are more or less compatible. The wider question about where agile is going in Australia is to some extent dependent on the culture of business and work here. I learned about Agile in Europe and the US where I think the culture of innovation and entrepreneurship is stronger, and as a result agile there is a little more widespread and mature. It may also explain why some cultures genuinely struggle to adapt to this style of working. Agile has been mainly focussed to date (with much success) on the delivery of software and the larger challenge for software people now is to push this thinking into the broader business context which is more difficult. It seems to me it is why water-scrum-fall is the norm for most agile implementations.
It is equally important to realise that the “culture” of agile was not invented by software developers in the 1990s. It has been around for at least half a century and in all likelihood much longer than that. Mary Poppendieck describes in one of her recent books how the Empire State Building was built. I was amazed when I read it (it’s a great come-back to the ignorant who believe you couldn’t build a bridge using “agile” principles). In response to your question are we embracers or are we stagnating then I think that as an agile community in Australia we are as passionate and innovative as anyone out there, but there aren’t very many of us and we operate in a relatively conservative and minor business environment that is at best slow and at worst incapable of change. This is however a huge opportunity for anyone who does have that agile mindset to gain real competitive advantage.
Great post Renee , as aways thought provoking , for my money I have always thought the the following from Alistair Cockburns “Agile software development : The cooperative game ” resonates with me .
Methodology: A series of related methods or techniques
Method: Systematic procedure
Alistair has a view that Agile is a methodology based on the definition above.
In many senses I see this a still very true.
I would add to that in my opinion where the methodology has been adopted or is in the process of being adopted holisticly it becomes an ” Ethos”
I say this because the definition of Ethos rather than culture alone (” The characteristic Spirit of a culture ,era or community as seen In its beliefs and aspirations ” ) is for me the idea state .
Perhaps however this is the idealist in me.
Hi Renee – interesting question. I tend to agree with you that in Australia there is a somewhat open-minded approach to implementing new practices. Unlike other parts of the world, I certainly don’t get the impression that we are dominated by any one framework. For example, most of the recent clients that I’ve been working with have proactively started their agile journeys by exploring several frameworks. I’m seeing interest in Scrum, DSDM, XP, Kanban and Continuous Delivery (and blends).
I actually anticipate more growing Aussie interest in DSDM due to our strong Prince2 heritage (much like the UK but unlike the US) and general cultural conservatism (especially among larger enterprises).
Comment emailed directly by Craig Brown:
Are we evolving?
Are we evolving? Always, regardless of whether we are agile or not. Are we getting better at business? Slowly, but perhaps we are getting better at getting better.
There is a bell curve of advancement across the adoption of better practices. It’s been moving slowly for a long time, and while the IT crowd is making substantial changes it feels a bit like corporate world beyond IT is only just now catching on. Dialogue is the key to improving.
I hear some people lamenting that universities aren’t preparing graduates sufficiently in the ways of work, but I think that’s the wrong way of thinking. In reality people learn to work from the first few bosses. The 25 year old comes to work and gets shown “the way we do things around here” by her 40 year old manager, who was shown a variation on the same thing years before by his first manager. While organisations are inward looking, or rely upon packaged consulting models for their thinking the way we work will only ever evolve slowly and incrementally.
The current trend for graduates (and frustrated middle aged folks) to invest time in underfunded start-ups means that inward looking (myopic) reflections on how we work aren’t an option. These businesses need to constantly scan the environment for knowledge that will make them not just competitive but sustainable. Start-ups are probably a great apprenticeship even though most don’t pay off. And that environment provides a great alternative to the corporate apprenticeship I described above.
Add to that the internet (which is still blocked in so many corporations who don’t want their staff learning from the outside) and the rate of change in the way we work is increasing.
On top of all that I do my part to share knowledge through the creation of community spaces where people can find a place to exchange ideas. The LAST conference, the meet-ups, blogs and even lunchtime sessions at work all contribute to a community of learning, and I encourage everyone reading to do their bit to facilitate and participate in their local versions of these groups.
We don’t always know what the right way forward is (although some of us think we do) and being an expert is probably less valuable than being part of a community of learners.
This (lengthy) post has very little to do with the Agile movement in particular. But it’s one of many frameworks people are using to learn to improve. They all add value in different ways, as long as we talk about what we learn. If we don’t share our experiences and opinions our knowledge walks out the door when we leave.
Let me wrap up with a quote from your mate Joseph Campbell; “If you can see your path laid out in front of you step by step, you know it’s not your path.”
Glintech’s response (which was more a report post AA): http://www.glintech.com/blog/agile-visionaries-vs-agile-pragmatists?page=1