Agile In A Nutshell Part 3

Okay... I don't know if you noticed... but it is really really hard to really curate an agile in a nutshell post that is quick to read, grasp and move forward. This is partly why I avoided much agile postings over the past decade - it's a very very long piece of string (or rope to hang oneself with)!

:)

The previous 2 attempts at this (Agile In A Nutshell and Agile In A Nutshell Part 2) I like and I teach fluidly. But I also add the following nugget when I am teaching.

Where did these agile manifesto, the 12 agile principles, and especially those 10,000 odd agile practices (half of them technical/technology focused like pair programming; and half of them people/organisation/management/process focused like standup meetings) come from?

Well it's clear where the agile manifesto was written and by whom in 2001 - 17 world-recognised software engineering consultants, coaches, managers and all importantly - practitioners.

And it's clear as well where the agile principles were written and by whom in 2004 - the same experts that formulated the agile manifesto.

But what about those 10,000 agile practices?

The agile practices have been observed by team members, team managers, coaches, consultants, and other observant people ... of high performance teams. These observers have then documented them online, or in books, and have presented them at conferences as well as internally. 

This means that we're still discovering practices all over the shop/place that help organisations become quicker and nimbler.

In my opinion, the smartest organisations are recognising their own unique practices that are giving them competitive advantages, and keeping them secret. The even smarter organisations are making their unique practices transparent and world-wide accessible because they realise others may contribute small tweaks that give even better performance - ala open source.

They also recognise that thinking is really hard to replicate and their organisation as a whole organism is thinking differently and hence behaving differently. Behaviours are easy to observe and replicate, but does not mean you will get the benefit.

Countless stories abound how GM documented all the things Toyota was doing in their factory in Japan and tried to replicate in the US - but failed. And we see that quite a lot industries - competitors hire people from the other organisation (or the same consultancy!) and then try to copy what worked elsewhere - and it usually fails expensively, spectacularly, and hurts a lot of employees, shareholders and stakeholders.

The simplest way to deeply understand this is a story about a piano made by a world famous piano maker. A wood furniture carpentry company decided to move into the piano manufacturing business as they had the same required tools, they could buy the same materials, and they thought they had the same skills required. So they bought a piano and dismantled it, making notes and designs about how to assemble. Then they assembled it back. But once it was back in "1 piece" there was a problem. It did not sound like it had. So they tried to manufacture a new one from their instructions. And they succeeded in making a pretty good replica of a real piano, but once again there was the problem - it did not sound right. So they got out of the piano making business (wisely). They lacked the "secret sauce" of being musically minded and aware how all the complexity of sound generation, amplification, transmission integrated with the different moving complicated parts of a piano.

And that's also what agile is - the practices help - in the same way that knowing what the keys of a piano are what notes. But playing a piece of beautiful music on a piano is differently from knowing things about music and piano operations. Yes the analogy does stretch to "practice is required, and feedback" to get them right.

But more importantly it is the secret sauce - it is the agile mindset that causes these agile practices to evolve into something unique for the organisation and its context. Some practices are individual targeted (like disciplined arrive on time to meetings), some are pair targeted (like pair programming to create, quality assure, reflect, learn, and make better realtime), some are team targeted (like whole team planning game), some are larger organisation targeted (like town hall meetings), some are senior management targeted (like go-and-see/use-your-legs reporting walks). And on and on :)

It is much more important to be agile than to do agile!

For more and deeper thoughts about agile check What Is Agile For You What Is Agile For Us. Thankyou!

Agile Principles 103

So I was frustrated with both my previous 2 methods as described in Agile Principles 101 and Agile Principles 102.


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%?
• Why?
• Which principles were they achieving between 0-50%?
• Why?
• Which principles were they achieving between 50-100%?
• Why?
• 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?
• Why?
• Which would bring the second most benefit?
• Why?
• Which would bring the third most?
• Why?
• And which would bring the least benefit?
• Why?

Typical answers that I received

A lot of concerned faces, puzzled frowns and a handful of the class beginning to figure this stuff out. Reviewing these responses made me cringe - I am sure often my look of disbelief crept past my ability to control my responses. Reader beware!

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?

"Yes! Because that's pretty good, it's like 91-92%!" - note, no mention of which one is not being achieved! Just a simple, naive response to the a multi-choice answer sheet. No deeper thinking evidenced.

and

"No! Because there would not be 12 principles if following 11 made an organisation quicker and nimbler!" - note, although this answer is better than the "Yes", this is still insufficient/a bit naive as the principles are a set of cause-and-effects that together create the synthesis required to be quicker and nimbler. It takes deep thought and putting into practice for some time to fully "feel" agile.

Which principles should be our top 3 to put into practice ASAP, and why? 

The only typical responses I got from this question were that there were no patterns. Every organisation has a different context, with different problems (and size of same problems), prioritised differently and solutioned differently. This is expected. Asking the "Why" for each did cause good conversations between the trainees and really helped people clarify their assumptions and perspectives. So too was the conversations around benefit, and benefit to whom. Good stuff!

Which principle would bring the least benefit and why? 

Again, a total myriad of responses - the only pattern being that everyone fell for this "trick question".

Yes, like most agile things, with teams being in unique contexts, "it depends" is always the right answer. But that helps no one quickly!

Once the trainees had convinced themselves of 1 least beneficial principle, I always constructed a causal model that showed they had picked the most beneficial principle to them. Why this complete opposite approach? I was trying to highlight all the other ways of thinking about things, and highlight that they needed to learn more than their default model in order to achieve agile for their organisation and for themselves.

Benefits of this teaching/learning approach

Was better, slightly, than the previous two attempts.
There was some good discussion going on.

Consequence of this teaching/learning approach

The 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 mortem

This 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 as no one is really talking or writing about this stuff - how to reach critical mass across the whole world! To see what I have tried, tested and concluded so far, read further: What Is Agile For You, What Is Agile For Us. Thankyou!

Agile In A Nutshell Part 2

Okay, so I tried (really really hard) to capture the essence of the vast topic "agile" in my Agile In A Nutshell post earlier ... but something is bothering me. Really.

So I hope you don't mind if I give a second dimension to this massive multi-dimensional concept! This stuff is BIG!

Agile In A Nutshell - Agile Is Now An Umbrella Term

Agile as a mindset and a movement started out in the software development and delivery space. But my first brush with "agile" as a concept was when I was studying business management in South Africa around 2003. The South African management textbook that mentioned "agile companies" stated that the future of businesses relied on them becoming more agile to keep up with customer needs. Although this was after we had implemented much of eXtreme Programming (XP), it was still before (because South Africa has/had very slow internet connectivity, and expensive imported books were scarce) the big software movement really got going worldwide.

I reckon it is likely that the line in that South African management textbook had been inspired by The New New Product Development Game written by the great management scientists Hirotaka Takeuchi and Ikujiro Nonaka in 1986.

But skip to the here and now nutshell point:

Agile is now an umbrella term to mean all of the agile manifesto, agile principles, agile frameworks, agile practices, agile tools, agile approaches.

Basically, any abstract or tangible thing that helps an organisation or an individual, be quicker or nimbler, in delivering value to the end customer. Usually this begins with the mind/thinking framework being applied by the people to the challenges they're responding to.

In other words, it is more important to be agile, than to do agile. For more practical thoughts on agile checkout my collection of teaching/learning agile at What Is Agile For. Thankyou for supporting!