Agility as an Enabler for Local Intelligence
February 10, 2014
Much has been written about agile processes, how they can better respond to changing requirements and be used to tune approaches over time through retrospectives and adaptation. While this is true, it masks the importance of human involvement. It is people that respond to change and teams who update and tune their processes. Agile methods give more freedom and autonomy for teams to do the right thing, but it is the team members that act intelligently to improve things.
Understanding this distinction that agile methods don’t directly help much, instead it is the actions of agile team members, allows us to better explain why some agile projects go well and others do not. Agile processes are an enabler for intelligent action, but not a guarantee of it. Teams that are asked to follow agile methods, but not motivated or equipped to improve the project environment will likely fail.
This is why we often see some agile project teams do very well and others struggling to produce results within the same organization. If you look at the processes both teams are following they look the same. They might both be doing daily stand up meetings, iteration planning sessions, backlog prioritization, demos to the business and retrospectives. However, these processes don’t ensure success; it is the local decision making that comes from them (which we observe in different ways) that lead to successful projects.
The concept of “Local intelligence” is described nicely by Malcolm Gladwell in his book “David and Goliath: Underdogs, Misfits, and the Art of Battling Giants”. Gladwell tells the story of Lawrence of Arabia, an archaeologist conscripted into the British Army in World War 1 who led the Arab revolt against the Turkish army occupying Arabia.
Lawrence’s goal was to destroy the long railroad being built to set up operations deep in the Hejaz desert. The odds were against him, the Turks had a modern army and Lawrence commanded an unruly band of Bedouin nomads who were not trained in combat. However they were mobile and self sufficient they travelled extraordinary distances, attacked quickly and were gone before major battles ensued.
Lawrence is best known for leading a daring attack on the port town of Aqaba. The Turks expected an attack to come from British ships offshore, but Lawrence attacked from the unprotected East desert during summer, leading his men on a 600 mile loop no one thought possible and to anyone but the Bedouin nomads likely fatal.
His success was attributed to a number of factors. First, as a historian and archaeologist he had little regard to traditional military order or standards and that helped with unconventional thinking. Second he made great use of the local intelligence of his men who were very self-reliant and skilled in dessert survival and travel to mobilize and do the right things to be successful.
This enablement of local intelligence is the key to agile success too. The agile process is only a framework, the real work happens in the discussions and decisions made by the team. I used to be concerned by how much time some teams spend talking about work compared to actually doing work until I saw a correlation with project success. The teams that spend lots of time discussing options, priorities and business requests were actually thinking and refining strategies to be more effective. They were using local intelligence to be more successful and it showed in their results.
When my current team stopped holding daily stand-up meetings I was a little concerned. I wondered if we were getting lazy. If the process was devolving and should I intervene? However I trusted they must have had the same thoughts and the frequent discussions both face-to-face and online for remote members negated the benefit in these daily updates. To them these meetings felt unnecessary and low value. So, stand-ups became three times a week then twice a week then more sporadic. We have not had a daily standup meeting for three months now and things are going great.
One practice we are doing extra is a weekly technical show-and-tell meeting so developers and QA’s get to see what people have been working on and ask more technical questions ahead of, and separate from, the bi-weekly business demonstration. I am not suggesting that agile teams drop daily stand-ups and adopt weekly technical reviews. For most agile teams the daily stand-up is core and critical for effective communications between team members.
Instead, my point is that success is more closely aligned with the application of local intelligence from the team members than adherence to agile process. What works for one team may not work for another. As leaders of agile teams we should not be looking for conformance to process but signs of effectiveness and the application of local intelligence. High levels of “productive work related discussion” appear a good sign.
By “productive work related discussion” I mean new discussions that cover fresh ground and solve issues, not Bill and Ted having the same argument about architecture X or tool Y. Ask if the discussions result in solutions, are they business results focused, and inclusive to all team members that want to participate? These are indicators that they are productive.
In addition to productive discussion, team led modification of process is another sign of local intelligence applied. The fact the team diagnosed, discussed and agreed on an amendment to regular working process is a good indicator that they are applying local knowledge. Alistair Cockburn’s Shu, Ha, Rei model, describes a progression from obeying the rules (Shu, which means to obey, or follow), consciously moving away from the rules (Ha, which means to break or change), and finally unconsciously finding an individual path (Rei, which means to separate, or release).
Organization adopting agile and teams using agile methods are encouraged to first “use it out of the box” i.e. without modification. Then, only when everyone understands why things are as they are might we want to change process. Many of the agile processes balance each other. Rigorous testing allows for light documentation for instance. Dropping one without addressing the other and you could be headed for trouble.
However, in my view agile processes are a default starting point for teams. They work well and cover all the basics. Yet if the team sees a problem, or an opportunity for improvement then we should not stop them trying to become better. Iterations provide short test cycles to try new approaches and revert back if they are not working or build on success if they are.
When leading teams look for and encourage high levels of engaged debate and productive discussion. Support team based process adaptations and change. They are both signs of an engaged team applying local intelligence to improve their ability to deliver. Agile methods should be enablers of change not strict frameworks to work within. Our goal is performance not conformance so we should provide support and encouragement accordingly.
When asked if my team is agile I answer “kind-of, “mostly” or “predominantly” depending on the formality of the question. However I don’t really care about the label, they are kicking butt and delivering a ton of high quality software the business loves, which is my real focus and measure of success. Methodology labels help shorten conversations about process but are of a lower importance than results, we should act accordingly and spend more time encouraging local intelligence - a critical key to success for today’s knowledge worker projects.
(Note: This post was first written for ProjectManagement.com here)
I love the concept of "enabling local intelligence!" If a team wants to stop doing a practice, it's helpful to ask why--what problem is the team trying to solve? I agree that telling the team not to change the process and follow the rules is not necessarily the best advice for the team's context.
Posted by: Allison | February 10, 2014 at 08:20 PM
Hmm. Seems to me they are Responding to Change whether from within or discovered via Customer Collaboration. (Perhaps during a regular period of reflection and tuning.) This is producing Working Software with more concern for the Individuals that Interact during the process than for the process itself. You've given them the environment support they need to succeed, not a prescribed set of rules.
Why exactly don't you answer the "Is your team Agile" question with a resounding "YES!"? Not being in one of the popular frameworks or using one of the popular methodologies does not mean your team is not Agile. On the contrary, what I am reading about is a high-performing team that has reached the "Ri" level. Be proud of that! They are an Agile team, a true Agile team that has moved beyond the shackles of current trends. The next great methodology or framework could be borne out of the way they work today.
Agility is not a destination reached when certain criteria have been met. It is a Journey undertaken in pursuit of excellence. I believe that the further a team goes along that journey the less need they have for established methodologies and processes. In fact, forcing themselves to stick to the established might prevent them from getting even better, possibly discovering the next popular process.
Posted by: Adam Myhr | February 12, 2014 at 02:14 PM
Great observation, and yes, in my mind I see what we do as entirely agile too and the correct progression from basic agile usage. However the reason I respond “Kind of” when asked if what we do is agile is for two main reasons. The first is largely a function of who is asking it. If someone from, say, the PMO asks if we are doing agile and I say Yes, they often follow up with assumed Shu level application questions like can we attend your Standups, can we see your story point estimates. This leads to long or abandoned explanations of how actually we have also adopted some kanban concepts and now view granular estimates as lower value, bordering on waste activities and instead spend more time developing features via an iteration-less pull model. I know it is lazy of me, but answering “kind-of” or “mainly” and “would you like to hear more about it?” diffuses the questioning and allows me to explain if they are truly interested in how we work.
The second reason for not admitting this is purely agile is because people fixate on the process not the people. The reason my team is so effective is because they are very smart professionals with many years of experience in our domain and motivated. To be honest they would be successful if I tried to lead them in a waterfall approach (because they would discreetly manage risks and prototype approaches on the side). Replicating process is easy, replicating talent is not. The people make the project a success, if I said we are successful because we do agile, it would be short selling the talent of the team and setting up people for failure who want to replicate the approach.
I agree that the next great methodology or framework may be born out of how we are working, but the term agile now has a lot of associated baggage, so I blur my answer somewhat to open up the conversation to discussions around getting the best people you can and keeping them happy and engaged.
Thanks for your comment – I think this topic would be good material for a future post.
Posted by: Mike Griffiths | February 12, 2014 at 02:54 PM