- Small Things Agile -

Vanity metrics makes you feel good in a laid back feeling, and makes you not really caring when they are bad. Excuses generally makes them go away.

Value metrics makes you wanna be on your toes, makes it personal and inspires us to greatness.

Vanity metrics tries to prove that we are right, while value metrics tries to prove that we are wrong.

It’s always easier to make excuses than making an effort from the beginning. If you constantly look for proving your point and making sure you are right, that’s all you going to see.

Failing is an option, and not something to be afraid of.

You win some or you learn some.

Change is everywhere and driving a team or an organization is to driving continuos change. How to make “change” happen faster?

In every organization there will be people that loves what you do, those that hates it, and those in between that follows the bigger group.

The worst mistake you can do is to focus on the haters.

The second worst mistake is to focus on everyone.

Focus on those that are the on board of your change, your ambassadors, the guys and girls who already have their sneakers on.

I believe you need to give 80% of your attention to your “runners” and 20% to everyone else. That is, if you want to scale your change fast, not doing everything yourself, and not loosing your organization’s driving force.

In an Agile environment we give Teams a lot of freedom because we trust in them to self-organize and solve the tasks they are given. We also expect Teams to, from time to time, reflect on their way of working. Here is the Retrospective meeting the principal enabler for this continuous improvement. The most common way to facilitate this type of meeting is to try to identify the following...

What did we do well, that gave us energy, and that we should continue doing?

What stood in our way?

Can we do something different next time?

Or some variant of this. But the retrospective can take many different forms depending on the situation that the team is in at the moment. It can be a meeting that focuses on solving a single big impediment (1-word retrospective) or it can be a Strengths-based retrospective. What I’m trying to say is that, although the retrospective is the most important practice for building self-awareness and for improvement, the dynamic form of this meeting makes it not so good as a measuring point for Team health. Sure, there is value in communicating the Teams biggest impediments and strengths but it might be tricky for external people to interpret this information and get a sense of Team health.

As mentioned earlier, agile teams are given a lot of freedom, with this freedom comes the responsibility for the Team to demonstrate control. Sprint burn- downs, sprint reviews, demo meetings etc. are all different ways of demonstrating control. Some sort of Team satisfaction measurement, that communicates a bird’s-eye view of the situation in the team, is another. The purpose of this measurement is first of all to help the Team itself to identify areas for improvement, but also to communicate to stakeholders how the Team is doing. 

In the ZervicePoint development Team at Zipper we have experimented with using an online survey containing a number of simple rating question on the form “How likely is it you would recommend this way of working to a friend or colleague? (1-10)”. The average result of this survey gave us some sort of Team Satisfaction Index that we could look at. If it increased it was supposed to be good. But after a while we realized that this method had number of drawbacks. First of all, it was a online survey that each team member had to answer alone. I, being the Scrum Master, found myself nagging about that everyone has to do the survey NOW! The developers had to break out of their creative focus bubble and that they didn’t like, of course. The quality of the answers surely got affected by this. Even more important, there were no discussion and thus no feedback around the different questions and areas that the questions were covering. Sure, you could get an indication if something was wrong in any area but the discussions that builds self-awareness in the Team were absent. 

I started thinking about alternative ways of measuring Team health and, as usually is the case, someone else had already come up with a better solution. In this case it was Henrik Kniberg and his awesome article Squad Health Check model – visualizing what to improve. I will not describe Henrik’s model in any depth here, just read his blog post, it is a good read and well worth your while.

In short what you do is to: 

Have a workshop and discuss the Teams current situation based on a number of different areas.

Create a graphical representation of the result showing current status and trends.

Use the result to find actions that help the Team improve.

Now go and try it out!

I just read an interesting blog post on a phenomenon that probably happen all to often. Being iterative does not necessarily means that you are agile. I see it happen in our journey towards a new way of working and often used as a defense mechanism before truly understanding what being agile means.

I’m not really into the “religious war” for and against different aspects of agile, but some key aspects in the foundation of agile is hard to disregard.

Being iterative is good, but does not necessarily mean that you are agile. Keep fighting! ;)

-rickard-

Some quotes:

"Ideally, in an agile process, all types of work would finish at exactly the same time. The team would finish analyzing the problem at exactly the same time they finished designing the solution to the problem, which would also be the same time they finished coding and testing that solution. All four of those disciplines (and any others I’m not using in this example) would all finish at exactly the same time."

“A team should always work to overlap work as much as possible. And upfront thinking (analysis, design and other types of work) should be done as late as possible and in as little detail as possible while still allowing the work to be completed within the iteration.” "If you are treating your user stories as miniature specification documents, stop. Start instead thinking about each as a promise to have a conversation."