A great team

For me agile is about many things but first and foremost it is about people and dynamics between people, you get the right recipe going and anything is possible. I work with what I think is a great team, but what makes them a great team? I’m not entirely sure but here are some of my ideas of traits of a great team (in no particular order):

  • There’s a good level of respect not only for each other as people, but in each other’s ability to do stuff.
  • They trust each other.
  • The team has built in redundancy so anyone can take time off at any time, no silo’d experts.
  • There’s lots of laughter and healthy tomfoolery, they know when to work, but they also know when to play (at work!).
  • They allow failure and learn from it,  focusing on the problem, not the person.
  • High levels of collaboration, both at work and at play. They help each other out constantly, no-one is ever “too busy” to help.
  • They’re cross functional, there’s a good mix of skills amongst the team, helping with redundancy.
  • Everyone feels they can talk openly about issues and problems.
  • There is no fear (of failure, of specific people), they take chances and enjoy challenges.
  • They self organize, there is no one leader, they all lead, they all follow.

There’s more I’m sure, but those are the ones I can think of right now. At the core of it I think people must feel like they belong, that they are respected for their skills and trusted with responsibility and above all treated like people, not resources.

Thoughts?

I’m not a child…

Dear Manager,

I am one of your developers, when you hired me you treated me with respect, you asked me about my skills and abilities and (I assume) hired me because of these. Please could you explain to me why, now, the respect is gone and I’m being treated like a mentally deficient child?

If you want me continue adding value please consider the following:

  1. I am not 6 years old, stop treating me like a child.
  2. Using fear, intimidation and sarcasm to control me does not work, the more you try the more I will resist. Try a little more collaboration and a little less intimidation…
  3. If you would like me to tell the truth, don’t force me to lie by shouting at me every time I tell you the truth.
  4. Stop rejecting reality and inserting your own version of it, this is a sign of insanity.
  5. If you force me into a corner, I will lie to get out (see point 3).
  6. If you want me to be responsible, give me ownership of the problem AND the solution and stop telling me what to do by when.
  7. Stop treating me like the “bad guy” and take responsibility for your bad management decisions.
  8. I’m not giving my opinion to irritate you, I’m giving it in an attempt to add value. After all, you hired me for my expertise, right?
  9. Respect that I am a person, not a robot or a number, and that I have a life outside of work.

regards,

A. Developer

Trust…

Forcing impossible deadlines, ordering people to be at work during certain hours, denying leave, bringing in consultants and hinting at using them as a yardstick for productivity… I often wonder what makes people resort to these tactics and if they know the net effect of them? Decreased morale, lowered productivity, lack of any desire to do anything, “stick it to the manager” mentality, tiredness, increased stress, fear of job loss…I can go on but you get the point.

What brings this on? Not entirely sure but I can speculate…people react differently to varying degrees of stress and who can say what goes through someones mind when faced with pressure from above from someone who does not fully understand the given situation and lacks (or has incorrect) facts. I would say though, having worked with various managers under varying degrees of stress, that this is indeed the role of middle management, to absorb, explain, clarify and defend the team in which they trust, assuming the trust relationship is there.

Trust, that’s perhaps the key factor here and I think the core of where these decisions come from. Trust is the difference between saying “all leave has been denied until project X is done” and “as a team you guys decide whether you can absorb the impact of this leave but whatever you decide, I will back you”. Trust is not telling your team “you will be at work between the following hours…” but rather saying “there’s an incorrect perception linking the current level of productivity to peoples hours of work, how would you guys think we should approach correcting this perception?”.

Patrick Lencioni, in his book “Overcoming the Five Dysfunctions of a Team”, lists Trust as the foundation of any good team:

“…members of great teams trust one another on a fundamental, emotional level, and they are comfortable being vulnerable with each other about their weaknesses, mistakes, fears and behaviors…”

“Team”, in this case, includes everyone trying to achieve a given goal…everyone. Often I see management reeling under the pressure from above and, instead of approaching their team, bringing them into their “world of pain” and trying to collaboratively find a solution, they will resort to giving orders and clamping down. Inevitably though, the harder they squeeze, the more they lose control, forcing them to squeeze harder…a vicious circle from where the only thing that results is broken trust, something that’s almost impossible to fix.

Implementing an Effective Build Dashboard (for Hudson) (Part 3)

Not really part of the dashboard configuration but more of a cool thing I thought I’d share the underlying layers (hardware, OS etc) behind our monitor.

I decided to go with full portability and hands free start-up, I did this as follows:

  1. Installed Puppy Linux on a 2gb USB stick.
  2. Installed Firefox 3.x (needed for the Autohide extension).
  3. Installed Autohide extension (auto hides parts of Firefox and forces full screen on start-up).
  4. Found an old derelict PC and plugged it in, started up, configured the video display (once off on start-up).
  5. Configured the build monitor as per previous posts.
  6. Changed the start-up of Puppy Linux to auto start Firefox.

And there you go:

Build monitor, on a steeeck!
Build monitor, on a stick.

Implementing an Effective Build Dashboard (for Hudson) (Part 2)

This is a follow on of my previous post and details how to implement the code available in the original post by Fabio Parera here, together with the modifications I made for our environment. I suggest you look at the original post first though to understand the extra stuff that I did not implement (I removed “expected duration” and “pinging servers”).

  • To start, modify Hudson to generate a code coverage percentage file, in our environment (.NET) we used NCover and NUnit but adapting your tools to do the same shouldn’t be a problem, the concept is simple:
  1. Generate the coverage percentage file(s). See this post on setting up NCover and Nunit in Hudson
  2. Extract the percentage from the file(s) and put into a single file in the root of your project. This is now accessible as http://<ci-server>/jobs/<project>/<coverage-percentage-file> after every build.

  • You need to install the Greasemonkey Add-on for Firefox for the script to work, do that now. After you’ve installed, you need to modify Firefox’s config and set greasemonkey.fileIsGreaseable to true:
    • Open up Firefox and open up the page about:config (type it in the link box).
    • Find the greasemonkey.fileIsGreaseable setting and, if it’s not set to true, double click it to set it.
  • Now extract the contents of this file to a working folder. Please note that this code is neither pretty nor up to date but is completely functional, feel free to modify at will.
  • Edit build-dashboard-radiator.html. Each project is defined in a section like this:

Create a section like this for each project you want to monitor, changing the href to your projects base directory.

  • (Optional) Edit build-dashboard-radiator.css and modify the style-sheet so it’s suitable for your display, the sizes for the fonts are located towards the end of the script. The current sizes are great for a 40″ screen.
  • Edit build-dashboard-radiator.user.js
    • Change coverage_minimum to whatever value you want, anything more than this will be displayed as green, less, red.
    • Find the section that looks like this:

you need to link the names of commiters to your project(s) to pictures, do this here. The names are what’s extracted from the version control system you use and should be set by every team member before checking code in. To find out what it is in Hudson, find a build and have a look at the json object generated from it, you can find it here (look for the value of “fullName”):

http://<server>/hudson/job/<project>/lastBuild/api/json

Note: This is, in fact, the source for all the information in the script, if you’re thinking of extending the monitor this is the first place to look for information on your build. Another place to look would be

http://<server>/hudson/job/<project>/api/json

which lists information related to the project as a whole (not build specific). Also, you can substiture lastbuild in the previous link for any build number.

  • Next, after you’ve saved all your changes, open Firefox and load the html file. Drag and drop the js file into the browser and this should now install if you have Greasemonkey installed correctly

You’ll know it’s installed correctly if you see this in your status bar

That should be it, hit refresh on your browser and bask in a cool dashboard monitor.

I’d like to thank the original poster (Fabio Parera), and of course all the people he thanks, for linking this awesome monitor, it was exactly what I was looking for and I hope it turns out that way for you too. Let me know how it goes and if you can think of any way of improving it.

Implementing an Effective Build Dashboard (for Hudson) (Part 1)

Information radiators are one of the core building blocks of any agile environment, you should never hide or feel the need to hide anything you’re doing. Information radiators encourage (or at least they should) a feeling of pride in teams allowing them to show off what they’re doing. They should be freely accessible for everyone to see what’s going on and share in the joy of what’s being created. They also encourage (if used correctly) good behaviour in teams: no-one likes public shame.

In line with this and following on my post of setting up a Continuous Integration environment with Hudson and .NET I decided to go about putting in place an effective Build Dashboard. For me an effective dashboard (or information radiator) is one that gives as much relevant information as possible with the least amount of effort to read. So, lots of flash, none of the boring stuff, easily accessible by as many people as possible.

Of the various methods out there I went for displaying information on a big screen, this gives you both the high visibility and the information all in one. Some of the other methods like lights and sound are nice, but limited in some way.

In our environment Hudson is our CI tool of choice and it has a pretty nice built in default dashboard:

.. which works great at short distance but not really great at long distance. There are also lot of plugins available to customize this dashboard and make it better viewable but none of them appealed to me as fit for purpose.

Looking around I finally found a post by Fabio Pereira that looked promising. Essentially the monitor is an HTML page with backing style sheet and javascript to extract information from your CI Server (like Hudson, using it’s API facilities). The standard one that he supplies in his blog looks like this (sorry for the bad quality of the pic) (when implemented in our environment):

Dashboard Version 1

For each project is should the following:

  • Name of project.
  • Build result (green for passed, red for failed, orange for building).
  • Time since last build.
  • How long the last build took.

I made the following modifications:

  • Added in a unit test coverage percentage (with colors indicating above/below agreed minimum).
  • Changed the font size based on how long ago the project last built. In other words, old projects shrink, lots of tiny font projects = not much being done.
  • Added a picture displaying who checked in code that triggered the build. Encourage responsibility for what’s done.
  • Added a color (yellow) to indicate an unstable (but not failed) build.

And now it looks like this:

Dashboard Version 2

Also, it’s strategically located:

Location of Dashboard

In the end it turned out to be pretty effective. It was fully automated, highly visible, everyone (team and customer) had access to it and could see it clearly and understand at a glance what was happening on each project. Broken builds and low unit test coverage are quickly exposed and no activity on projects can be seen quite clearly. Only thing I need to figure out now is how not to burn the image into the screen (no screensaver :) ) but I guess if there’s enough churn on a project that shouldn’t happen, more motivation to continuously check in and build I guess…

As usual I’m always looking for ways to improve so feedback is more than welcome. Can you think of ways to improve what I’ve done?

In part 2 of this I’ll got through the code behind this dashboard and try and explain it a little so that implementing it becomes easier, I’ll also attach the actual code (not pretty, but effective nevertheless 🙂 )