Learning to learn
June 25, 2006
I was going to write about the various ways that people learn, and then my colleague Jeremy Stell-Smith wrote an excellent article describing one of my favourite learning models, so go and read that and I’ll see you back here shortly. Jeremy also alludes to Shu-Ha-Ri, another learning model based on repeating “cycles” of learning, found in Japanese martial arts (I haven’t linked to a single definition because there are a few subtly different ones around).
Ok, so why are learning models useful? To quote Edward de Bono, we should teach our children to learn. In other words, Learning should be on the school syllabus alongside all the regular subjects. I would go further and make it a core subject of every school year. There’s plenty of material about learning, memory and concentration to fill the lessons. But here’s the good bit: it would be an exponentially useful subject.
To start with, teachers would have to learn the syllabus material. As they were learning they would apply what they were learning to become better learners. At the same time as they were learning about learning, they would become intrinsically better teachers, because they would understand more about their role as facilitators to learning. Then they get into the classroom (or outside in a park, because they have learned the importance of physical environment to learning) and provide an exciting, engaging, varied and responsive introduction to learning.
But now it really gets exciting, because as the kids learn the techniques and principles of learning, they become more accomplished and voracious learners, and they understand the dynamics of how they are being taught. And not just in their Learning class, but in History, Geography and all the other subjects where we have traditionally learned and regurgitated reams of dull information by rote. They will have a vocabulary and an awareness about learning so they can communicate how they want to be taught. And their education becomes exciting and useful.
I spend quite a lot of my time teaching, whether in the form of coaching, workshops, conference tutorials (some poor Swedes had an entire day of me recently), internal training within ThoughtWorks, or on-site with a client, and I really enjoy it! I love creating an environment that encourages people to learn, and I love seeing the lightbulbs go on.
I’m lucky – I’ve had some amazing teachers and mentors, whether in school, my brief martial arts career or work – which has led me to invest in understanding the dynamics of teaching and learning, communication and rapport, feedback and change (particularly cultural or organisational change). Systems Thinking is another useful avenue to explore.
Studying how learning and communication works has definitely made me a better teacher. I’m still an enthusiastic amateur – I would never describe myself as an “expert” teacher, simply because there is still so much out there that I don’t know, and because I keep encountering people with different and inspiring teaching styles. I don’t believe it is an area you can ever fully “know”.
The best advice I can offer to anyone who finds themselves in a teaching role is this: learn to learn before you learn to teach. If your last experience of learning was History-by-numbers at school, then unfortunately that’s probably how you will end up teaching, and that would be a shame.
How quickly can you evolve?
June 19, 2006
When Darwin’s “On the Origin of Species” was published, evolution was already a well-established idea. Darwin’s insight was that evolution – through the process of natural selection – led to the introduction and extinction of entire species. This of course upset the established church, and to this day there are still religious groups who reject the idea, in the face of overwhelming scientific evidence.
The early twentieth century saw the rise of “neo-Darwinism”, which finally provided a mechanism for natural selection. It wasn’t happening at the level of creatures but at the microscopic level of genes. Natural selection is simply the playing out of a long-running stastistical game based on shuffling genes, and more disturbingly the creatures themselves (and ourselves) are just a very sophisticated form of temporary accomodation for those genes!
Richard Dawkins, the acclaimed scientist and author of “The Selfish Gene”, goes a stage further. He suggests that a species’ ability to adapt or evolve may itself change over time. In other words, evolvability is a trait that can evolve, just like a tail or gills.
Agility is another word for Evolvability
So what does this have to do with the world of software development? Well the various flavours of agile development, such as XP, Crystal, Scrum, Lean and DSDM, are all trying to solve the same problem, namely coming up with a repeatable, predictable way to adapt to change. In other words, they are trying to make software delivery evolvable. This ensures that delivery isn’t wrong-footed by a change in the project’s ecosystem or environment.
As an agile process coach, my job is to increase a team’s – or in the case of an Organisational Transformation programme an entire organisation’s – ability to evolve. Taking a cue from Mother Nature, you can’t expect this to occur overnight. The weight of evidence shows that macro-mutations in the process are almost always going to be detrimental. Instead you need to evolve the organisation towards evolvability, or agility, through a series of small steps that are easy and intuitive to grasp.
You can’t just walk in and announce that “this is how we do things now”. You need to take the time to understand and appreciate the existing ecosystem, and present the change process as a simple and natural way to improve delivery. At a getting-things-done level this is usually pretty straightforward: tested code tends to break less than untested code, and paired code tends to be better designed than solo code, so the incremental changes are intuitively a Good Thing.
At a project management or governance level the messages are more subtle. It’s not about how quickly or accurately you can deliver – you can put a bunch of bright people in a room with a big enough incentive (be it carrot or stick) and software will come out. Instead it’s about how resilient the process is to some sort of disruption.
Delivery Assurance addresses exactly this, and agile delivery is the most effective way I know of managing this risk. By pair programming you reduce the impact of a single person becoming unavailable or leaving the team. By applying the principles of test-driven (or behaviour-driven) development, you eliminate the risk of introducing regression defects into the codebase. Adaptive planning and tracking – and their resultant incremental steering and project funding – leverage this to provide programme-level adaptability. The requirements can change, the political environment can change, the goalposts can move, and you are still in with a chance of delivering something useful.
The more you can evolve an organisation’s evolvability, the more resilient you make it to change, and the better it can adapt to changes, both internally and in the external market. As Kent Beck famously said, embrace change. It is inevitable, and your chances of survival are directly linked to your ability to evolve.
ps. Thanks are due to Mats Helander for the casual comment that inspired this article.
There's more to BDD than evolving TDD
June 4, 2006
Behaviour-driven development started life as an NLP exercise to stem the abuse of the word “test” in “test-driven development”. Since then it has grown into a respectable and proven agile methodology (with a small “m” of course).
Dave Astels, the award-winning author, was an early adopter of BDD and has been instrumental in raising its profile. He presented it at Canada on Rails and is taking it to JAOO and SD Best Practices. He has even presented it to Google. His Ruby BDD framework, rspec, has inspired a number of similar projects.
Now, Dave is a programmer. What’s more, he is a very thoughtful programmer, which means he invests a lot of energy in making programming productive and effective – and more importantly fun – for himself and other programmers. He doesn’t get very excited about capturing requirements or the dynamic between testers and analysts, so you won’t hear him talking about the wider context of BDD, but you will hear him saying that there is one!
BDD is fundamentally about identifying behaviour. At the analysis level, the behaviour of a story is its acceptance criteria, which BDD expresses in the form of automated scenarios. You need analysts working with testers to capture the stories and identify the acceptance criteria, and then you need programmers working with testers to automate the scenarios.
So the ironic twist is that all that talk about “testing” in TDD was taking the focus off the real testing action! My efforts to put the word “test” back in its box have in fact propelled the testers into the central role on a BDD team.
So the message here is twofold. Firstly, although a lot of the existing BDD message is in the TDD space, don’t lose sight of the bigger picture or you’ll miss out on all the good stuff. And secondly don’t underestimate the value of the testers on your team: they are your direct line to delivering high value software.
