Dan Prager is active in the Melbourne Agile community, presenting at meetups, delivering training with Tabar, and is also a co-founder of www.skillfire.co, an Agile and Innovation consultancy. He works with forward-thinkers to bring the best of Agile and Lean approaches to Business and IT in a sensitive and effective manner.
Dan switched from scientific research to software development immediately after completing his PhD in mathematical physics, and was an early local adopter of Agile approaches. Given his broad experience Dan seemed like a great person to interview for some insights into 1st Conference, and he certainly didn't disappoint.
Read on to find out about Dan's upcoming talk and workshop, and a little bit of his story and relationship with Agile.
As always, if you have any questions or comments please don't hesitate to reach out to us. My email is Ringo.Thomas@tabar.com.au and I'm always happy to hear from you.
1st Conference is being held on 2-3 March. Registration is available now.
Ringo: What are your talk and workshop about?
Dan: My talk is about introducing disruptive ideas into an organisation -- especially Agile ones! -- and thereby challenging the established customs, practices, and power structures without being burnt at the (metaphorical) stake.
The workshop is independent of my talk. In the workshop I'll teach and facilitate a lesser known, but powerful technique for medium to large groups -- the "bubble up" method -- using it as a vehicle for participants to collaboratively reflect on what they learned on Day One of the conference. We'll also use the fishbowl technique in the concluding part of the session to enable further discussion and exploration.
Ringo: Where did the inspiration come from and what do you hope people can take out of it?
Dan: When I first came across Agile in 2004 and began to get involved with Scrum and XP, my immediate reaction was "this is fantastic stuff, but large organisations won't go for it" since it seemed clear to me that Agile thinking inevitably implied transforming the culture from focussing on hierarchy and status quo into one that emphasises collegiality and rapid learning. So I stuck with small companies and start-ups until 2010, by which time -- somewhat to my surprise -- the interest in Agile approaches from larger organisations was burgeoning. Why? As the pace of change and competition heated up the old ways no longer cut it.
But here's the interesting bit: the mainstream acceptance that Agile approaches had operational and competitive virtues was not accompanied by an acceptance of Agile culture. While many have embraced Agility with open arms there are at least as many who would rather that it remain safely confined to pockets of organisations and to the lower levels. Fear of loss of status and security are common: "what will happen to my role? will my skills remain relevant?" and sentiments like "it's just a delivery methodology" or "it's only for IT" abound. So on the one hand we have enthusiasts and converts, and on the other hand we have plenty of people (often very well-entrenched) whose understandable reaction is to try to hold back the tide.
In trying to help the former group and give the latter their due I'm always looking for potentially helpful approaches. And while reflecting on this I was reminded of something I learned in my previous life as a scientist: Thomas Kuhn's theory of scientific revolutions, from which we get the expression "paradigm shift". Kuhn's idea was that science proceeds in two modes: most of the time we have slow incremental elaboration of the current paradigm, but occasionally we get a revolution, in which the dominant paradigm "shifts" and there is great pain and upheaval, but also rapid progress. And when that happens the old guard are not happy and do their darnedest to fight off the revolutionaries with every tool at their disposal.
It seems to me that we are dealing with a very similar psychological phenomenon in organisations, and the scientific analogy can be helpful in framing our approach to the challenges that the psychological and cultural disruption that introducing Agile approaches entails.
My hope is that attendees will gain empathy for the people that are reluctant or resistant to the Agile revolution, plus useful insights and tools for navigating and catalysing positive organisational and cultural change.
* * *
As for the workshop, one of the things I've noticed is a bit of repetitiveness or sameness when it comes to engaging in reflection and retrospective activities. It's almost as if people have learned one or two introductory techniques and then stuck with them come hell or high water. The advantage of having a large toolkit is that one can not only vary it up, but (assuming sufficient insight) also pick the right tool for the job. Personally, I relish the opportunity to try out different formats to expand my repertoire, although more recently I've been consolidating: focussing on a smaller number of what I call Agile Power Tools - techniques that are relatively easy to learn and apply, give good value up-front, address multiple needs, and have the potential for adaptation and expansion. I believe that this is consistent with the spirit of the Heart of Agile: learning techniques is valuable, but remember to simplify!
The "bubble up" technique, which truly draws on the wisdom of the crowd, is a great power tool for large scale retrospectives, and I thought that it would be a good fit for First Conference, enabling effective Reflection in a highly Collaborative setting. I hope participants will take both content and technique from the session, gaining insights as well as the confidence to apply this method in their own organisations. If they connect with other participants too, that would be fantastic.
Ringo: Given this conference is centred around the Heart of Agile, is there one of the four parts that particularly resonates with you?
Dan: I like to look at Deliver, Reflect, and Improve as forming a cycle, with Collaborate applicable as an overlay to all of the other quadrants. If I had to pick one that resonates for me personally, it would be Reflect, since that's where imagination, creativity and insight begin, but it's essential that we take our reflections and test them out in practice.
For the cycle to work well it's important to give attention to each part. Traditionally Deliver is overweighted in importance: we should be reflecting and improving a lot more.
Ringo: What should people be thinking about before they come to 1st conf to ensure get the most out of the two days?
Dan: Reflect on your Agile journey to date. Bring a couple of pressing questions. Your context will have unique aspects, but there will be a lot of great ideas and capable people to listen to and engage with over the two days.
Ringo: How do you think having a second day of workshops will add to the overall learning experience?
Dan: One of my favourite proverbs is "Tell me and I forget, show me and I may remember, involve me and I understand."
I think a day of short workshops is a wonderful innovation. The workshops will give an opportunity for participants to learn-by-doing, and sample a variety of new techniques in a safe and supportive setting. It's also a nice variant on the more common (and pricey) full day workshop experience.
Ringo: What’s the best advice you’d give someone starting out on their Agile journey?
Dan: First, get inspired. Check out wikispeed and the Nordstrom Innovation Lab, for example.
Second, Agile is a broad church and there will undoubtedly be aspects that strongly resonate with you. You may well be able to harness pre-existing experience, which is a good thing and will give you a head start. But please be sure to also explore the parts that seem weirder and more challenging: that's where your personal growth will occur.
Ringo: What are the most common roadblocks that people come across they should look out for?
Dan: Here are three that I see frequently:
1. The superficial approach: just adopting a few practices and then declaring mission accomplished (or failed).
2. The best practice fallacy: copying practices without adapting them to your context, and then wondering why they didn't live up to expectations.
3. The in-group impediment: Whenever part of an organisation successfully adopts Agile approaches there will be friction where these interface with other parts that operate in a different manner. At this point it is very easy to get bogged down by adopting an "us and them" attitude.
In each case the guidance and support of one or more experienced Agile coaches or consultants should help.