Tag Archives: agile

how to make good teams great – episode 2

Leave a reply

Feed your brain

In a rapidly changing environment – as the IT world is – you want to stay on top of things and you can’t only rely on techniques, languages, frameworks & technologies you played around with at school or in your current projects.

You must feed your brain with new ideas, new cool stuff (even old cool stuff by the way) and there are various places you can get brain food: conferences (if you or your company can afford it), bar camps & user groups (often free), brown bag sessions over lunch at the office, …

Say “well done”

Give your co-workers credit for a well done job. It does not necessarily need to be for big accomplishments only and you should also communicate on smaller achievements. Kudos can be given via an email sent to the Kudos mailing list or can take the form of a small present you know will be appreciated (a chocolate bar for instance).

Keep in mind that not everyone likes to be a star (even for a minute) and it is important that one gets kudos only if she/he wants.

That was easy!

In my team we use one of those EASY buttons (that says “that was easy” when you press it) for telling the floor someone has achieved something (small or big). It is not exactly the same as saying “well done” but still is a nice way of showing some pride.

Eat your own dog food

As a developer you should already be familiar with the quick feedback that a suite of unit tests provides but that is still pretty “low level”. Feedback is important but quick feedback is even more important since it helps you catch bugs early and fix them early (at a lower cost).

So what about testing the software as a whole? What about using it yourself? Eating your own dog food is all about using the software you develop instead of simply developing, shipping the product to the testers and waiting for feedback. By doing so you also see your software with your end users’ eyes (may it be a tester – internal – or a customer – external) and have a better understanding of their needs.

Experimentation time – motivation through innovation

By giving the developers the opportunity – read time – to explore and implement new ideas a company is making an investment that may or may not pay back. But a lot of products were born during experimentation time (FedEx days at Atlassian, Google Fridays, …) and if a company can afford to set a couple of hours aside for their employees to think out of the box it should go for it.

“Do what you want” time

The “do what you want time” differs from “experimentation time” in the sense that it is more about assigning some time (like 20%) for the developers to improve or implement a feature not yet in the backlog in an existing project.

You can find the slides from Sven’s presentation at Jfokus here.

how to make good teams great – episode 1

Leave a reply

As we are implementing new development processes in the department I work for teams are going through a lot of changes. Attending Sven Peters’ (@svenpet) talk on “7 things: how to make good teams great” at Jfokus was an obvious decision and I’m glad I went. It was really nice to hear that some of the actions we are taking right now have proven to be successful and appreciated by teams in other companies.

I’m not going to write about the 7 things at once but will break them down in a couple of posts. Let’s start with “It’s flow time” and “Report robot”.

It’s flow time

Ever heard of context switching? It is probably one of the biggest problem of so called knowledge workers who – according to various studies – waste 20% to 30% of their time switching from one context to another. And that problem is even more important in an open space where one can easily be disturbed: a colleague or a manager stopping by your desk for a “quick” question (notice the “quick” there: sounds familiar?), someone just walking by, …

Unfortunately there is no “quick” question or task and you will always waste those 20% to 30% of your time (that’s almost 3 hours of a normal day at the office) switching context.

To Not Disturb

In such work environments it is therefore all about finding the right balance between productivity and collaboration. Collaboration is the idea behind open offices but productivity is not and you need to build virtual fences in order to secure high productivity periods – as if you were working in a closed office – over the day or week.

  • do not disturb time – together with the team members agree on a day (or half a day) when it is not allowed for an outsider to break the flow. The team needs to communicate when it’s alright to disturb and when it’s not. It could be done with a red flag on the desks or with the team members all wearing the same and explicit t-shirt for instance. All you need is basically a visual clue that people can easily interpret.
  • support guy of the day - one of the team member is responsible for isolating the team from the outside world and handles all the questions, meetings and so on. It is a good idea to rotate among the team members so it’s not always the same person being disturbed.

Andy Hunt dedicates a whole chapter on the subject – Manage Focus – in “Pragmatic Thinking & Learning: Refactor Your Wetware” and suggests team to “establish rules of engagement to manage interruptions”.

Report robot

Constant feedback is one of the key factor of successful agile teams and there are a great deal of tools that can help feeding the team with relevant information.

In your day to day activities you probably use a wiki to share documentation and knowledge. You probably (and you better do) use a bug tracking system to manage the defects in the code your write. You also might use a build system to automate builds and deployments.

When you think about it the list is much longer than that and it is almost impossible for a single person to keep track of all the data the different tools provide. If your company (read manager) understands the issue and is willing to invest some money in it maybe it’s time to build information radiators!

Information radiators are central locations (a web page, a flat screen TV close to the team) where the feedback from all those tools can be presented in a concise and visual manner: charts, green and red lights, numbers, … for anything that adds value to the team productivity and spirit.