There is no greater threat to an idea than it alienating the very people it purports to help. Technicians can be deeply reflective, serious people, so forcing them to take part in trivial team building exercises can do more harm than good.
Being an occasional extrovert, I had a favourite game I used at the start of retrospectives. “If you were an animal in the jungle of your organisation, which animal would you be and why?” I think I learnt it from the fabulous Mike Lowery and have used it extensively ever since; until recently when I was given cause to rethink my approach.
The game’s purpose was three fold:
But after one rather excellent retrospective one of the senior programmers came up to me and said, “Please don’t ask me to be an animal again.” I looked at him open mouthed.
“It has no dignity.”
The conversation ended right there. Not another word was exchanged.
But it got me thinking. I realised that I had to enhance my facilitation skills to include everybody, not just those willing to risk a gentle ribbing by choosing a peculiar animal.
I now use a variety of different techniques to open retrospectives, and yes, I still sometimes use the “Animal Game,” when the situation warrants it. But I have found a wealth of information and great ideas in the book, Training from the back of the room, by Sharon L. Bowan. Sometimes collaboration requires deep thinkers to open up, and I don’t think this can be avoided completely).
Plenty of technicians are introverted, thoughtful and serious. When you run your team-building games, make certain you have the mandate to do so, and be sure that you are helping people to come forward, not filling them with dread.
The latest research into what makes people happy intersects neatly with agile philosophies and good collaborative practices. If you want the best from your teams and you want them to be content, you’d better go agile.
Grumpy, uncommunicative work places are a scourge in digital and IT departments. I’ve worked in offices where retrieving a ‘good morning’ was cause for celebration and where a chat round the water cooler was frowned upon as disturbing the work ethic. But common as these things are, they do not help the well-being of staff, do not promote happiness and cause distress among the very people that are supposed to be making a difference to the organisation.
We all know that digital technicians and IT people are fabulously well paid. This is important for recognition but it turns out to be far from the most important factor for predicting happiness.
In David Rock’s excellent book How The Brain Works, he sets out five parameters for mental well-being in work situations:
Happy agile workers
Agile teams, and Scrum teams in particular, are encouraged to relate to each other, do not blame but look for solutions, and follow a strong vision. Team ceremonies build trust, continuous improvement is highlighted through regular retrospectives, and the commander’s intent, or sprint goal, gives certainty. A well performing team is in charge of how it builds solutions and the work it chooses to do (i.e. it is autonomous).
Agile promotes communication, vision, excellence and well-being through its rigorous processes, and attention to transparency. It turns out these are the very things that make most people happy.
And we all know that happy people are productive people.
Personal organisation is not the strong suit of everybody. But here is a mechanism to get your small tasks under control without becoming attached to agile zen, tied to trello, or upset by updates.
It takes an excellent imagination to see how to profit from getting all your little tasks organised, so you can guarantee you’ll finally get round to completing them. But those creative enough to work out they need organisation, are often the very last to ever put it into practice.
Apparently, there were 14 reasons to get organised in 2014 and who knows, there might be 16 this year (2016). But most of us can agree that being organised saves us time and reduces stress.
But in work I am embarrassed to say organisation has not always been my strong point. I’ve tried electronic tools and find them frustrating, and I’ve seen personal organisation mechanisms, like that one with the elephant, and the filofax come and go. Yet I have always dreamed of a perfect future where all my jobs are prioritised, never forgotten and always transparent.
In The Key Habits of Organization, on the excellent zenhabits site, Le0 Babauta says, “…when I get my system down, and the habits are on track, things are smooth, I feel good about what I’m doing, and I’m much better able to let everything else go and focus on what’s in front of me, confident that everything else is in its place.”
I too would like a bit of that, but the simple lure of pen, paper and stickies is strong with me; electronics will not work.
Now I tried the Kanban for One desktop board for a while, but found it inflexible with its photo-frame form factor. I wanted a mobile version that could go with me and act as a conversation focus. So I have invented -- with a little encouragement and help from my colleague Julien Thomas -- a folio Kanban board.
Like a traditional folio this can be used to carry documents, but it also includes a handy Kanban board perfect for the smaller size post-it notes and stickies. Print it out in A3, or, if you can, use the folio size to give a little extra real estate.
I use one for each client I work with and sometimes one for each team or individual I coach. I use them to visually show others what I will be doing next and let my mentees see that I am delivering what we agreed. I can be seen carrying the folio from standup to standup marking little stickies and displaying my tasks to everybody that needs to know.
Personal organisation must be simple, lightweight, visual and accessible if it’s going to work for imaginative people, and there’s nothing simpler than opening a folder to see what your priorities are. No need to get out a device or search for a wifi connection, folio Kanban gives you organisation, communication and peace of mind. Download it here, or if you live in Wellington, just get in touch and I’ll get you some. (There might be a small print charge for large orders)
Specification by Example (SBE) requires clear instructions and time for practice for even the most basic concepts. It is not a common-sense solution, it requires a multi-month journey that starts with small, considered steps, most likely in the training room.
A picture paints a thousand words, so they say. But when you are trying to explain technical things so that business people and geeks share the same understanding, it seems a thousand block diagrams and a million process maps do not a picture make.
Which is why SBE (specification by example) is becoming so prevalent among certain sections of the Wellington IT industry. Giving business people the chance to show their thinking by writing examples seems like such a simple idea, you wonder why it wasn’t always done like that. It’s a colourful dream.
Yet black and white reality kicks in soon after teams start out. Thinking in examples is such an alien concept to most that it takes months of practice, review and experience to optimise the process. And unfortunately in these cash-strapped times, giving teams space for training and contemplation is not fashionable.
But teams will respond beautifully even late on, when given a safe environment to explore. “It reinforced the concepts of the whole agile process,” said one business analyst, after a morning’s workshop, adding that SBE, “Accentuated the importance of communication.”
And the folly of late training was exposed by another attendee who had been working with SBE for eight months without having the chance to understand first. For her, the lost opportunity was exasperating: “We totally should have done this eight months ago,” she said.
Forcing teams to take on any technical practice without them clearly knowing the importance is a crazy waste of money. In my experience, SBE can lift a team from quality duffers to zero defects in about four months from a standing start, if adequately trained and mentored. That’s not much to ask given the usual effort spent fixing things after release and the liability of supporting broken features that nobody really wanted anyway.
Practice does make perfect. If you want your teams to excel in specification by example you must give them the foundations on which they can build. They won’t of course become experts overnight, but at least they will begin the journey facing in the right direction
It's an experiment, but to promote the upcoming Agile Blog in, I have created this little video explaining how I use the Six Ps to create and finish a narrative style blog post.
To explain, the Wellington Agile Blog-in meetup, is a dedicated time set aside to write a blog have a drink and some crisps. Too many of us want to write blogs but find it difficult to get started, let alone finish. But Blogging is so very important these days, whether it's for self promotion or so that your team can explain itself in confluence to your stakeholders.
So the blog-in is a way to instil just a little bit of discipline while meeting new people and having some fun.
You can find out more at the meetup site: Wellington Blog In
I hope to see you there.
By William Knight