Tagged: Coaching

How Tidy Is Your House?

Messy DeskI really enjoyed the entry that Rachel wrote giving “Refactoring” a normal name that ordinary people could understand. I like her synonymous term, “Tidying Up”, because it’s a great metaphor for understanding how important it is to any project in the long term.

There are obvious immediate side effects to tidying anything up. Things are easier to find, easier to move about and much easier to change. People who inherit or work in this “tidied up space” can do everything at amazing speeds. It also means that things can get messy quick. Fast forward three weeks and with all the changes, suddenly the “tided up space” no longer looks very tidy. Clutter begins to build up in piles, you see people duplicating effort, and then you need to start moving things around to even begin finding anything important. The clutter is slowing you down.

Tidy DeskIt’s important to keep on top of “tidying up” because it maintains your ability to stay fast. It also means that people coming along after you can work almost as fast as you (it still takes them time to adjust to finding where things are and where they should go). More importantly, those people following you need to understand how important it is to keep “tidying up”.

Thanks to lildude for the ‘Messy Desk’ picture and chaosbit for the ‘Tidy Desk’ one (both from flickr).

Moving Out and Moving On!

The biggest news I have this week is that I’m going to be living in India for about 6 months starting from January. I’ll be taking on a new role with other instructors running training and induction classes for people that join Thoughtworks. I’m really looking forward to the experience and I have a lot of support from my work colleagues and sponsor. I hope the people I will be working with will be able to capitalise on all my experiences I’ve had working on the many projects I’ve been on, and I think I will be able to refine a lot of the techniques and approaches I use when coaching teams and pair programming with people. I will also get a huge kick of working with people that are genuinely interested in learning and sharing and like most projects I’ve been on they’ll no doubt be plenty of fun along the way.

It’s a big change for me once again after moving to the UK, but I do plan on returning to the UK after six months and going through the paces again to find another place to live in London. It’s an exciting time and though there’s plenty of stuff to fit into the week before Christmas, it’s going to be completely worth it.

Trust, Honesty and Sometimes Saying No

I find that the people that set themselves up for trouble are the people that want to please everyone. I want to please everyone, but I’m also realistic in that I want to tell people the real picture and not some fictional world where nothing goes wrong. Some people like to paint this idealistic world – those people are also living in a dream world. In the real world people make mistakes, things aren’t perfect and you can’t promise everything will be fine. The only thing you can do is be honest, learn from your mistakes quickly and try to stop it from happening again.

I prefer being honest and telling people exactly what is going on, instead of pretending everything is going fine, because at some point things won’t and by telling people things will go smoothly you’ve effectively lied to people. I personally want to do right by the customer/client, and sometimes that means saying that it’s going to take some time to develop/test/deploy something. It means sticking by your guns, and being completely honest that things do take time in proper software development.

I really like this approach and I find it effective. Customers are glad to hear both good news and bad news from me, because they know that I have nothing to hide. They know that they will always be able to help make decisions and do right by the team.

Devolving to Waterfall (Part 1)

Context: A multi-part entry about how fast, responsive teams devolve into slower teams as a result of what seems like reasonable and completely rational decisions. I hope to understand when the turning points are and think about what other options existed, so I can either prevent them or turn them around in the teams and organisations I work with. I’m keen for some feedback so please email me (emailpat@[thisdomain]) or leave me a comment!

Imagine that one day, a business had a fantastic new idea to do something revolutionary. They manage to get a team of people together, develop some software for it and get it deployed. It’s a huge success, and the customers and business are happy. They work hard to get features out as soon they are ready (developed, tested and passing Quality Assurance) so that customers can use it as soon as possible. Daily deployments into production are the norm.

Things get bigger over time and the team starts to grow larger. The team can no longer keep up with the pace of requests and deploy the software as well, so they hire a “Release Engineer” who can deploy it instead. The team is ecstatic as they can focus on producing workable software, but then a manager turns around to see the Release Engineer sitting around. He says, ‘Hey, there’s someone who’s doesn’t appear to be working full time. Let’s get him involved on another project.’ To maintain order, the Release Engineer is only available to the team one day a week to do anything. Any new features that the team develops now take a week to appear instead of when the features are ready.

Lesson: Over-optimising locally affects your ability to respond quickly and effectively by adding waiting time to the cycle time.

Solution: Understand the system as a whole and don’t over-optimise. Generate solutions that might have been more effective (i.e. The Release Engineer works half a day on each project and can shift days about when needed).

Notes: I see this all the time at client projects when teams are split into their “functional” areas and need to juggle simultaneous projects about. Context switching constantly over email, IM, telephone and a person sitting there waiting for something to be done prevents them actually getting any work done.

Communication Channels

The way you choose to communicate with your team on a daily basis carries more than just the message you’re trying to say:

  • Finding time to talk to someone one-on-one that suits both of you tells them that you respect them.
  • Talking to someone in front of a crowd tells them that you trust them (note the difference of talking down to them).
  • Talking to them over the phone, or emailing them when you cannot physically talk to them shows that you care.
  • Emailing someone directly when you’re close enough to talk to them tells them that they’re not important to you.
  • CC’ing someone when you’re close enough to talk them tells them that they’re really not important to you.

What things in your day add value to the end product?

Something that add values…

Three people with different sets of skills (application developer, server administrator and release engineer) all looking at what could be causing an issue that manifested itself only in the production environment at release time.

In contrast with something that doesn’t…

A manager not involved in the release, sitting over everyone’s shoulders while they’re trying to understand the issue, reminding them to record the time spent against the estimated times in the plan and all the other paperwork.

Removing Overused Words From Collaborative Discussions

I was involved in a great discussion on the weekend about two words that never help in conversations.

‘Actually’ and ‘but’

Sometimes you may find yourself in a good situation to use these “blocking” keywords, but far too often, they are abused as implicit “no, you’re wrong” statements. These words stop innovative, flowing conversations and turn them into a debate.

An alternative that I will be trying hard to use is “and.” Please post a comment if you have one you could recommend.