For the next two weeks I shall mostly be walking, relaxing, reading, sitting in the sun, drinking cafe con leche and whatever other adventures await. More on my return…
For the next two weeks I shall mostly be walking, relaxing, reading, sitting in the sun, drinking cafe con leche and whatever other adventures await. More on my return…
Many years ago I had the fortunate experience of working with a hyper-productive and wonderfully lovely team of about 100 people. Within us we had many smaller teams, that topic is for another post.
The first thing that happened was the leaders of the group asked the people to choose their working hours.
Immediately this group of people had a puzzle to solve. The puzzle had one specific outcome. What times will we be working from tomorrow onwards? The puzzle was meaningful and had a hard deadline – the end of that day.
There were constraints. Every two weeks everyone had to share their work and plan together. This needed to be between 9am-5pm to make it easy for our users and business sponsors to attend.
Some wanted to have their own flexible hours. Most wanted to work with other people. Some just wanted a particular lunch time. As the conversations flowed people started discussing their personal needs. There were long commutes, picking up kids, rush hour traffic in central London and some even opened up about prayer needs and health problems.
As people were getting personal they all became willing to bend their first thoughts to accommodate. I doubt most people ever get to know these things about their colleagues. We’re often shocked by the variety of situations people face.
As humanity and empathy emerged deep thought and dialogue was becoming infectious in the group. It also meant they decided they’d rather work together all the time if they could. Indeed they were the only group I’ve known of this size who all paired quite naturally.
Some bright sparks decided to get everyone to put up stickies with their suggestions, they then got rid of the duplicates. Everyone had three dots to vote on whatever suggestion wished.
The most popular vote was 10am until 6pm.
The people and management accepted the proposed hours. This acceptance initiated the building of trust. And it paid off in later iterations when the teams would help each other get stories over the line.
It also gave everyone permission to ask for what they needed to do the job.
And thanks to the relationships formed that day, the people were good judges at who they needed to work with to make a great team.
Ah. Missing rush hour.
Most people I know would vote for this in their ideal working day. This team made it happen. People got in pretty chilled. Some had even managed to work on public transport – no noses in armpits thank you very much. It cost less for some to get to work. We managed to hire brilliant people from further afield.
And 6 pm was pub time. Even people with families and busy lives would pop in of an evening, have a coca cola (ahem) and chat. It was dinner time too. I found one of my favourite restaurants of all time through this crowd.
Eventually they were also spending break times playing together, hanging out on weekends. Lots of lifelong friendships (and more!) were born there.
So I ask you, ditch the theories for a moment, stop looking for methods, and know you cannot force people to change.
Try a single, simple act of leadership instead.
I often work with other coaches and this is usually a good thing. Sometimes though I get dismayed at the number of “experts” who want to force people to change to doing things their way.
When I come across peers who want to do change “to” people instead of explore “with” them I often think of a story I heard many years ago. So long ago in fact that I can’t remember the details but here goes anyway.
Some volunteers arrived in a small village in Africa. Their aim? To tackle the childhood malnutrition that besieged the area. Of course there had been others before them. People who lectured, people who taught, people who tried their best to get the villagers to do things their way. But the people resisted and no-one knew why.
A smart young volunteer had observed that a few of the local babies seemed well fed. These families in general were not suffering in the same way. The volunteer decided to find out the secret of these well-fed babies. She proceeded to learn the language and communicate with the families of these children. As the trust grew in these relationships the volunteer discovered more about these parents. They would take a local worm or insect (ah my middle-aged memory) and grind it into the milk. They then fed the babies and young children this mixture.
Now the village knew that this particular form of protein was edible. Yet the villagers deemed it beneath them to eat and so many did not even consider it.
With this volunteers help the mothers of the well fed children stood up and told their neighbours what they had done. At first the villagers were not entirely enthusiastic. But some courageous first followers tried in secret. And soon the village had much less problems with malnutrition. Success in any language.
I love this story because it shows how simply taking time to see, and being open to the unthinkable, can make the difference between life and death.
Of course in our professions we are rarely faced with such choices. But even in our pedestrian world, it is just better to do things with the people involved. Not to them. Be open. Be courageous. Be wild.
He took “protecting the team” quite literally. So every time someone disagreed with the product owner, or had bad news or a question to share…he did it for them.
The battles between scrum master and product owner were painful. As a distributed team (UK/US) they needed to make the most of their opportunities to work together. But every time they tried to do some planning there would be many misunderstandings and disagreements. And usually people left the conference call feeling low. After a while the team just stopped delivering.
So, behind closed doors, the angry scrum master and I had our first coaching conversation. And much to my surprise the angry scrum master was a caring but frustrated individual. He was stressing and striving to do all he could for his team’s success.
Over the course of our chat he came to realise that “protecting the team” did not mean inflicting help on them. Or always doing it for them (whatever “it” may be). We spoke about how it had affected his relationship with the (influential) PO. We spoke about how that in turn had affected how the team felt and how if had affected their work. We spoke about how he felt at the end of each day.
He changed his outlook and made some resolution when that first meeting ended.
Encourage the team members to speak for themselves. If they can’t make the sprint commitment – speak up. If they had a question for the business or each other – speak up. And if there was something that the team just couldn’t agree as a sensible thing to do – speak up. He realised his job was to help them feel comfortable opening up and to help them be mindful when someone else was sharing.
In just a few short weeks the relationship between PO and scrum master recovered quite well. The team meetings became joyous, raucous exchanges of ideas, thoughts and personal commitments.
They made their next release to boot!
I felt the need to tweet the other day.
“Why do so many use trad methods to influence agile change? I prefer to talk to people, get their input, iterate and continuously publish…”
and it seems to have struck a chord.
The ever growing popularity of agile is creating huge need. Need for experienced people to help organisations start doing things better. Because of this emerging massive need we have a surplus of Agile methodologists all selling their own brand.
Often the drive to install the method means people forget people and interactions over and above process.
I recommend this post, It describes how an agilist sees the usefulness of methods…vs how traditional thinkers view it.
Today I read this excellent assessment of SAFe training.
I have to be honest. There’s a wee bit of jealousy in me that Daniel wrote such an insightful and informative post. It can be hard to know what’s interesting for anyone who happens upon your musings. I could sit write about the mechanics of Agile methods. But that’s already out there (see Scrum Alliance, LeanKanban University, Scaled Agile Academy, amongst others ) . I never thought about writing about training I’d been on! But I will follow Daniel’s excellent example from now on and take better notes.
So I thought I’d share a less eloquent, but I’m hoping, somewhat informative run down of the training I’ve been on recently.
This week long residential look at yourself has to be the best investment I have ever made .
It’s tough going. You are often working from morning to evening and having one to one consultations with Gerry, Esther or Johanna. When I say work I mean experiential learning. In my case my biggest lesson was Gerry himself telling me to “Shut up or get out”. In the middle, when you’re already a little weakened, if truth be told, there is a complicated exercise. We were a proper little town for several hours that day.
Throughout there were tears and tantrums, crushes and friendships formed and deepened. In fact I find myself in the twelve months since wishing there were a regular way to reconnect with the group I went with. After lots of imparting of psychological knowledge, and treatment dare I say, the trio of wisdom task you with a few last things to ensure lasting effect.
No there were no drugs involved 😉 it was not a love in – it was about becoming a problem solving leader. Bugger the title, it was about helping people around you and being true to yourself doing it.
Today I can say I continue to learn more about others and myself every day thanks to Gerry, Esther and Johanna. They run PSL bi-yearly. Just go. You’ll also come away with tons of models and tools to use. But better still you’ll come away with more knowledge of yourself to offer.
Find more details here.
I agree with pretty much everything Daniel says. And he says it better.
All I can add is I liked hearing the stories from Dean himself (although even his business tales were about tech upgrades). It adds a certain je ne sais quoi to the spaghetti throwing.
I had some confused looking tablemates throughout.
This was a one day course with Johanna that I booked during PSL. It was full of useful information although some of the exercises with stickies felt basic. I suspect this is because most peeps were there to learn how to start using coaching skills. As an experienced coach I came away with a few extra tools in my belt, and of course Johanna is delightful to learn from as always.
I went with some deep expectations and came back with a round tummy (sacher torte yummy) and lots of marketing materials. There was no experiential side. Although there was sumptuous food served every two hours. Not a lot of kanban theory or practice. Mainly stories, and mainly dev team focused.
David had some interesting stories to tell and this was lecture style teaching. A large part of the content was about marketing Kanban, commercial restrictions. On the last day David explains that we must fill out an case study style application. We must then attend (and pay for) a further event in order for a panel to interview you. After this you might receive a Kanban coaching certification.
My Scrum Alliance CSM was many years ago now, and I have to say as someone who knew Scrum already it’s hard to be a fair judge – although it may be interesting for y’all to know that CSTs are not subject to PDU or quality reviews once they’re certified.
Following on from Psst. Wanna buy an agile? I wanted to explore more ways you can check out your agile consultant.
A common one in recent years are the people who have been using Agile since the 90’s. My favourites are those who have been agile coaches for 15 years plus.
For one simple reason. The term Agile was coined in 2001. For more details on the back story have a look here. You could of course have been using one of the methods or frameworks that spring up in the nineties…but Agile it was not yet.
To find out if your consultant is using buzzword bingo instead of being specific about what they used, or are simply employing a marketing trick to make you think they are more experienced than they really are…read on.
When a resume says Agile pre-2001 ask for more details. What do they mean by Agile? Ask them to explain it – if they don’t use any of the principles and instead offer another explanation be wary – they might be the type who are really asking Psst. Wanna buy an agile? Ask what frameworks or methods they used. Ask them to get specific. Then look them up on the bodies that train, teach and have communities in those methods. There are often clues when you explore each role more with candidates. Try asking what a typical day was like at their pre-2001 coaching engagement, this will often produce clues to the real role they played.
I find myself revisiting this video from Derek Sivers time and time again. It’s a great way of explaining courage and leadership…in a light setting 🙂
In the last decade almost everyone who has heard of software development has cottoned onto Agile methods and how they can help teams and organisations be better and add more value. This has led to a massive increase in demand for experienced thought leaders, coaches and “do-ers”. A demand that far outstrips supply. To fill the gap there is a fairly new clutch of branded agilists.
This is where it gets tricky to operate as a buyer of agile help. And trickier still as an ethical Agilist who cares about people. I am sick to the back teeth of wandering into so-called agile organisations and finding a horror story where agile is akin to snake oil. (It really doesn’t help when the goal is agile. What do they think that means? What do they expect agility to give them?)
One client I worked with had been using a so-called agile supplier to develop a simple website. I joined six months in only to find the code had never been deployed anywhere, and heck there was nowhere to deploy to. It took a further three months to convince the supplier team that they really couldn’t claim “shippable product increment” unless they knew 1. where to deploy it, 2. how to deploy it and 3. had tried deploying it. The same supplier refused to share stories with the development team until planning day, refused to see that a retrospective was a key opportunity to inspect and adapt…and various small things that meant that 14 months later and the team still had no infrastructure, and instead of delivering a minimal product they were looking for complexities to add…simply to keep the agile development team working at full capacity.
To top it all off my client was happy with the supplier because they were seeing something every two weeks..albeit simply html wireframes. And they were nice people. They never once challenged anything in the legacy organisation. Even when they were running months late and with massive challenges, no-one was asking why. There were multiple other reasons why this group failed to deliver, if only I could find a fractal and relational modelling tool I’d show you!
Often during transformation people learn some awkward truths, and sometimes it’s deemed to be the agile consultant or consultancy who are merely trouble makers – or even agile itself is commonly blamed (we tried that once – it made things worse/didnt work). The gains to be made from change are not always apparent, and through intelligent dialogue problems are often uncovered that have been around forever…but not seen. Only then can we get better. When we know what the problems are. However if you never look, you never find, and the status quo or mild improvement can sustain a consultancy for years if stage managed. (I know of one independent consultant who has made £1million plus from selling pixie dust and charm)
Agility penetrates every layer of your organisation, not just development. It also doesn’t come in a neatly rolled ready to go carton. It takes skills, experience and tools to assess and work with a client to define the way forward. Sometimes it’s the right thing to install a method like SAFe or Scrum and change on the go, sometimes it’s better to keep the status quo and use a method like Kanban to figure out which bits really need change. And sometimes it’s just a couple of tweaks, a mindset shift, facilitation and information that’s needed.
So here I am, writing a series of blog posts designed to help you suss out if you’ve hired a charlatan, a wanna-be or an ego-maniac. Some of you will be lucky enough to have hired agile experts. But not many I’d wager.
Beware of….the agile consultants who
We’ll explore more ways to rumble your agile consultant and consultancy in the coming weeks…..