Suddenly! I found myself with a group of complete agile newbies and I realised I had the opportunity to experiment with a 3rd method to try and help them understand these really concise pearls of modern management wisdom - the agile principles. By this stage in my career and experience I had convinced myself that the agile principles were just as relevant for software as for any other knowledge work taking place with large numbers of unknowns and lack of certainty. The plan-do-study-adjust collaboratively is remarkably effective in all conditions and circumstances where we're doing something new (more than 10% different from previous experience)!
My third approach involved the learners reading them, leaving them on screen, and then asking targeted questions. I was hoping that by causing all the learners to think and reflect on their own situation, using the principles as some kind of wise "flashlight", they would have flashes of insight!
Questions that I asked:
- Which agile principles were they achieving in their work 100%?
- And why?
- Which agile principles were they not achieving in their work 100%?
- Which principles were they achieving between 0-50%?
- Which principles were they achieving between 50-100%?
- Would you be agile if you followed 11 principles 100%?
- Why or why not?
- Of those that were not 100% in practice, which 1 putting fully into practice would bring the most benefit?
- Which would bring the second most benefit?
- Which would bring the third most?
- And which would bring the least benefit?
Typical answers that I received
Which agile principles achieving 100% and why?
- Retrospectives (the last one) - because "our Scrum Master makes us".
- Delivery of working software - because "that's what we're here to do". (note, no mention of trying to deliver quicker - with an emphasis on the shorter timescale)
Which agile principles not achieving 100% and why?
- Business people and developers did work closely, but not everyday - because "the business people were too involved or important for the business to operate without them".
- Sustainable development - because "our company encourages a good work-life balance, and we only come in for the weekend once per month, or work late nights 1-2 nights per week".
- We do welcome changing requirements but not near the deadline - because "then we would never finish".
Which principles achieving 0-50% and why?
- Technical excellence, best designs, and simplicity - because "we don't have time to improve".
- Build projects around motivated people and support them - because "we hire professionals and they have to adapt to our ways of working".
- We think we do satisfy our customers of our business - because "we don't know them and are not allowed to talk to them" or "knowing - that's someone else's job"
Which principles achieving 50-100% and why?
- Communication is good, we do face-to-face whenever people are close - but not if they are on a different floor, different building up the street, in another town, a different country or timezone - because "travel is expensive and wastes a lot of time" and "we need email trails for audit/regulatory purposes" or "we need emails for our monthly, quarterly or annual appraisals".
- We like software showcases, but we have a lot of reporting on the side/top of that - because "governance is required" or "regulatory" or "comfort factor for senior managers" or "good publicity for the good work we're doing"
Would you be agile if you were only achieving 11 agile principles out of the 12 - why or why not?
Which principles should be our top 3 to put into practice ASAP, and why?
Which principle would bring the least benefit and why?
Benefits of this teaching/learning approachWas better, slightly, than the previous two attempts.
There was some good discussion going on.
Consequence of this teaching/learning approachThe causal model for the 1 principle they believed would bring them least benefit seemed to cause hostility. Just because Copernicus had a model that proved the planets went around the Sun, did not win the hearts and minds of those who believed the Sun and the planets went around the Earth, especially not those with their own thinking and being models based on the incorrect one!
Several folks dis-engaged from this - I suspect because it is such abstract stuff and it is hard to think about abstract things with people who have different contexts entirely. It's hard enough to make sense of things with people who are on the same page with you let alone from different teams/streams of work!
Post mortemThis teaching/learning method also did not work as I had hoped. Despite many nods, smiles and hope-filled looks that seemed promising, nothing happened after the training session.
I did not see changes in thinking patterns, problems stated, solutions proposed or behaviours. There was no increase in flow of value nor deepening of team trust, no sighting of a high-performance shift or team. No one was picking up the seeds or threads and putting any of the collective wisdom onto the agenda and getting faster.
I had to keep researching, thinking, reflecting and trying different things...to see what I have tried, tested and concluded so far, read further: What Is Agile For You, What Is Agile For Us