Catching the big one.

The release date is approaching and some important features are still missing. It might be that we are losing a customer because of that. There are basically two paths to take. First one is to start cut corners, do some hacking, maybe not test that thoroughly etc. In other words we take technical debt to try to reach our goal. For the short term point of view, this sounds attractive.

The second choice is not to take technical dept and leave some functionality out from the release and negotiate with the customer(s). For the long term this is usually the better choice. If the product is something for which the life time is long, even decades, we are doing less work, because we don't need to pay back technical debt and intresses. This is might be because we are not catching one particular customer, put there is plenty of fish in the sea and competitive benefits comes in t
he long run.   

Where the heck are we?

Your nightly build is red. There are some test cases failing and you know that this should be the moment when you need to stop and investigate. Your Product Owner runs in the team room and start to rant about features which must be in before the release at the end of the week. He is questioning are those faults so bad that we really need to consume time to fix them, because we have promised some cool stuff to our customer.

Roadsign to Lost farm near Bellabeg. (Stanley Howe) / CC BY-SA 2.0

What to do? Every time we have failing test case(s) in our build(s) it means that our location is unknown, failing test case says that behavior of our product is not what we have expected it to be and before those case(s) are green again, everything what you create are just hypothesis.

Abnormal situation is work need to be done, and it's work that does not get any better with age, actually quite the opposite. It's work which generates more work. On the other hand, if we use stop the belt and fix the problem immediately it causes idling to the rest of system and the bigger the system is, the bigger the effect of idling is. So what do? I think that abnormality should always be removed as soon as it is noticed. We should always have the best understanding where we are and get back on the map quickly.

Learning from your peers

Long time no see. :)

Scrum Masters and Agile Coaches are often promoting pair coding and collaboration. The reason for that is very simple, the best way to learn is to learn from you colleague, that drives both of you into the new path of learning.

 But how about the SMs and Coaches themselves? One of my mottos is practice what you preach. Which means in this case, that you should also do pair working yourself. One of the great opportunities, if you are in a corporate environment like I am, is to work together with one of your colleagues. If you find this hard, it's again a good opportunity for learning. If it's hard for you, it's probably hard for other people as well. My case hardness comes from exposing myself, as good as also in bad. Very sensible thing I must say.

BTW. We as Coaches and Scrum Masters must grab all the possibilities.

How to create un-cheatable Software metrics?

This is the question, what I hear from time to time and of course, metrics are our data from our life supporting system, which makes this question interesting.

Unfortunately I think, the whole question stinks. Let's assume that you are a patient in a hospital after a really bad car accident. Your condition is that bad that you need a hospital life supporting system to survive. If doctors and technicians, who are maintaining it, goal is just get this data look good and if their bonuses were depending on it, then the target would not be your overall welbeing. How would you feel if you start to doubt that they are trying to cheating with this data?

If people are cheating with data from Software Metrics we are getting false information and it always leads to wrong decisions (usually Business kind of). Software Metrics like Running Tested Features, # of Defects, Velocity, Lead Time, Test Coverage, data from static code analyzers... you name it. It should give valuable information to the whole organization, how we are doing and the possibility to react when something starts to go wrong. Metrics should be for every stakeholder (developers, managers, business) and they have to be everybody's concern to keep our product alive and in good condition.

Usually when I have experienced such cheating, there is mostly a reward or punishment involved. If you are a Manager and still seeking to create a waterproof metric, I must remind you, that you have the most vicious opponents, Engineers, they will always find a way to cheat... if they want to.

Organizations expecting Agile Coaches with Silver Bullets

I wrote a little bit provocative blog entry about the Cowboy coaches. In the of name of fairness I'll write now a blog-entry about Organizations which have unfair picture of what the Coach can bring.

I'm talking about my context, which is a big product, huge amount of people involved in multiple sites (I know, not recommended, but hey this is reality). These kind of organizations are generating a good stinking pile of waste, impediments etc, which causes pain. When you are feeling too much pain, you are calling Doctor(s), which is in our case are Agile Coaches. Now the organization is expecting a quick cure for the symptoms, but reality is something different. The organization should start to walk a path of self inspection and proper Root Cause Analysis to find true problems and fix them. On that path a good Agile Coach is more valuable than gold, because he is going to be your guide through, sometimes even very black moments.

Still a Coach cannot solve you problems, you must solve them by yourselves!

Is the Scrum Master a leader?

Follow The Leader
  © Copyright John Fielding and licensed for reuse under this Creative Commons Licence

Some time ago, I had small conversation in our company's Scrum Master mailing list and yet, there was no clear answer.


So if you check out Mike Chon's nice article about Six Attributes of the Good ScrumMaster and to me those attributes look like pretty much same attributes what a good leader should have. As a Scrum Master you lack old school management power, but good leader does not need it. Leadership comes from somewhere else, than artificial power.

Role of the Scrum Master (at least in our company) has been really vague. There are people from old Command & Control to people who are doing bare minimum which is basically calling up mandatory meetings in Scrum. What I think and how I teach is that Scrum Master is a leader and Scrum Masters must practice and learn leadership and they must be also supported by management to do that.

Get Agile! Stay Agile!

My previous blogging raised some more thoughts about Agile itself.

I would like to use an analogue to sports here. What I have experienced Agile is like sports, and if you want to be the best in the world, you must take practicing it very seriously. It does not help that you just get yourself fit (Agile), it's more important to stay fit (Agile) and also improving a little bit all the time. And it really needs enthusiasm to do what you do.

You should also consider the pain you feel during iterative way of doing, more like healthy pain, rather than car crash pain. Pain is something that tells you that you should improve yourself. Characteristic of doing eg. Scrum is that you are painfully exposed and that should be thought as a good thing. Knowledge is good, especially when you know that there are areas where you should be better.

In company context this means, that system itself should be Agile and also people inside it, should be Agile and you should constantly find a new ways and practice to be better.

Btw. In the picture my friend Sauli Kotisaari is finishing his half marathon in Austria.