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. 

Cowboy Coaches

I have noticed this phenomenon where Agile Coaches are like lonely riders, with their six shooters loaded with silver bullets and they come to tell you (probably also little bit arrogantly), what you have to do to get yourself more Agile. Most sad thing in that is that they are not helping their cause. Getting Agile and being Agile is a really hard work, at least in the corporate environment where I am operating, and it does not happen easily and during this never ending journey more questions than answers have arisen . Acting like that just pisses people off.

Actually I have also been there. After my Certified Scrum Masters Course, held by Bas Vodde (was great course btw.) I thought I was ready, and I had my moment of revival. Now 2 years has passed from that and I have all that time worked in the same project, and I feel more humble now :)

To the end, small related quote.

"There ain't no way but the hard way. Get used to it."
- Airbourne

Why automate your test cases?

Where this, maybe even very basic question came from? I talked with my old schoolmate and he had had a hard time to prove to his boss why they should automate some of their test cases. They are doing regression tests that people are executing before every release. To me it seemed like a very simple case, to automate what they were doing.

So why should test cases be automated? Feedback time is the key. With testing you are trying to find (and also trying to avoid) defects as soon as it has been presented to the code. With manual regression testing, this feedback loop is long and regression testing itself is time consuming which causes a problem in test coverage. With automation, you can have bigger set of test executed with shorter time and after creating good Continuous Integration system, there is no need of human interaction for regression test execution.

You can sleep your nights better, with good test automation. Because with it, you know all the time where you are with your Software.

Ps. You can find some Automation testing tools here.

Automation frameworks: Robot framework, Cucumber and Fitnnesse.
Continuous Integration Servers: Hudson and BuildBot

Incentives are a bad substitute for leadership

Managers are using incentives in order to achieve things they think are important instead of good leadership, that is, discussing, interacting and collaborating with people, why they should do like this. Money is a carrot. Problem here is that those bonus targets must be somehow measurable and IF people are trying to get their carrot they are trying to get those meters green, instead of focusing on the root causes. People must feel that they own the problem and be motivated to solve them. Also if problems are discussed, instead of stated, there are probably popping up better ideas than the original one man's idea.

Btw. Good video siding the issue by Daniel Pink

Our show in XP2010 and more

We had quite a good warm up band. Mark Streibeck from Google introduced us their Continuous Integration system and it was amazing! Everybody always committing to same head and it must be green all the time. Pretty mind blowing if you think that they have 1500+ product, 10000 developers and 60M+ test cases.

Anyway. My feeling about our presentation was pretty good. If you were there, please give me feedback. It was first time for me and Ran to write something for conference and it was an extremely good experience. I must continue with this path little bit further, because my opinion is that companies should do more scientific research.

The conference was facilitated greatly, everything from preparation of the conference itself to evening programs, or what can you say that we had Jazz musicians improvising and telling the theory about that (which is very close to pair programing) and later on there was a gig by an extreme metal band called Keep of Kalessin (you should check out this).

So, thank you very much and see ya!

Viking Laws

I was in Trondheim for the XP2010 conference (btw I had a good and educational time, I'll write more details later) and afterwards we visited Oslo with my wife and daughter. I found this extremely neat postcard. It says:

§1 Be brave and aggressive.
Be direct.
Grab all opportunities.
Use varying methods of attack.
Be versatile and agile.
Attack one target at a time.
Don't plan everything in detail.
Use top quality weapons.

§2 Be prepared.
Keep weapons in good condition.
Keep in shape.
Find good battle comrades.
Agree on important points.
Choose one chief.

§3 Be a good merchant.
Find out what the market needs.
Don't promises what you can't keep.
Don't demand overpayment.
Arrange things so that you can return.

§4 Keep the camp in order.
Keep things tidy and organized.
Arrange enjoyable activities which strengthen the group.
Make sure everybody does useful work.
Consult all members of the group for advice.

In the future I wont refer anymore to the Agile Manifesto, the Viking Laws will be the thing ;)

Experience Report in XP2010: Automated Acceptance Testing of High Capacity Network Gateway

I'm going to be in XP2010 and be one of the presenters of our Experience Report. First time for me to publish something. If you are around, please come to say hello :). Here is our abstract:

Abstract.
In this paper we will explore how agile acceptance testing is applied in testing a high capacity network gateway. We will demonstrate how the organisation managed to grow agile acceptance testing testing from two co-located teams to 20+ multi-site team setup and how acceptance test driven development is applied to complex network protocol testing. We will also cover how the initial ideas that we had of agile acceptance testing evolved during product development. At the end of paper we give recommendations to future projects using agile acceptance testing based on feedback that we have collected from our first customer trials.

What Key Performance Indicators (KPI) should Agile Team(s) use?

It would be nice to measure how we are doing and also check, has our newly implemented improvements hit the spot. Metrics are always nice, but (un)fortunately only few of them are usable. Here is a list of those KPIs what I think should be used.

Velocity
How many Story Points(SP) has team consumed during previous iterations and use this information to forecast. Keep your Story Points uncorrupted and here you have good and handy tool. If you are wondering what is SP, you should read Mike Cohn's excellent book Agile Estimating And Planning.

Cycle Time
Cycle Time (or Lead Time), means a time from when a customer request comes into a process to a time when it has actually delivered to a customer. Good way to measure the whole process, not only R&D efficiency. With this, you can check how good your flow is.

Boomerangs
Boomerangs are things, which are coming back to the process after they have declared as done and delivered. Because those things are defects like bugs and misunderstandings in customer requirements, this is a measurement for quality and communication. You can read more about this from Gojko Adzic's blog.

Customer Satisfaction
It's good to check, time to time, what people who are paying our salary think about us :)

Agile Testing vs. Waterfall Testing

We had this small conversation with my colleague, what Agile Testing really is and is there a conceptional difference between these two?

One thing should be common. Both should verify that the customer expectations are satisfied. But when in waterfall way of testing, the testing phase is long and in the beginning of testing condition of software is uncertain, in Agile the emphasis is always on working software, situation where we are each moment should be clear. This is done by using Continuous Integration, with Automated Regression tests.

Finding bugs is one of the main reasons of testing in waterfall model. In Agile, on the other hand, and especially when using Engineering practices like Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD), tests are telling when things are done and bugs are avoided in the first place.

Also iterative way of doing makes planning different. In waterfall, testers have a long period of test planning, but in Agile test planning is made in the same way as everything else, in the last moment (of course not too late :) ) and also it's short term.

Exploratory Testing - Practical Guide

We had a small session with one of our Agile Coaches about Exploratory Testing (ET) and we came out with following practical guide. This guide is written in Scrum Context. I'll try to update this guide, when I explore more about Exploring :)

So what is Exploratory Testing? Word exploring is actually very defining word. Idea is to explore, how product the in our hands is working, and this does not mean only trying to find as many bugs as you can , but also find out how it really is behaving and come familiar with it.

How to do this?

- Product Owner (PO) should be the person, who requests this.
- PO decides the area which is going to be explored.
- You should not write own User Story out of ET, just allocate time in Sprint for it.
- Short 30-60min intensive session.
- Intensive session excludes time for preparation and analysis.
- All observations are written down, during session but not analyzed.
- Analysis happens after session.
- You can use real entities towards System Under Test, or use test tools.

That's all folks. Happy exploring :)

Dilemma of: Scrum from Above and Self-managed teams

Scrum values strongly self-managed teams, with a good reason and that probably works nicely, if Scrum has been taken first into use in R&D team(s) and after that it has spread up.

But when you are in situation where Scrum has been decided in the management and it has dropped to teams, situation is pretty much different. Job of a Scrum Master or an Agile Coach becomes very interesting when you offer the gift of self-management to persons who are absolutely not wanting it.

This is again the situation where your people skills are far more valuable than technical skills, because changing people to think that self-management is rather like freedom than a cage of responsibility, is a challenging task.

Journey from Scrum Padawan to Scrum Master

I have been a Scrum Master now little bit over one year and now I want to share my thoughts.

I have heard from time to time, that a Scrum Master job takes only about 5 - 10% of your time and frankly I believe that can be even less. If you use only minimum effort to be a Scrum Master, you need only summon couple of meetings (Daily Scrum, Retrospective) and that's it. If a team is extremely good and self managed you don't even really need to facilitate those meetings.

But if you want to take your job seriously and your organization and team is not mature enough, here comes the real work, and now I mean this heavy impediment removal. There might be huge things, like collaboration between different stakeholders. There might be some big technical problems, which are not easy to fix and they are affecting everybody's daily life. Your team can be really dysfunctional caused by some personal level problems. And you should also be the guy who are searching all the time better working practises and introducing them.

Question is, how to improve? 2 days Certified Scrum Master training is not enough, not even close but it's a good start. First thing is that you must decide that you want to be a better Scrum Master, after that learning by doing, starting to read books about the issue and following blogs, tweets and pod-casts of people who are practising this field of profession.

and my journey continues...

Acceptance Testing Complex System

I want to share some thoughts about writing Acceptance Tests for a complex system.

General idea of Acceptance Testing is to write Test Cases to User Story which creates value to the customer. My argument is, that it might be impossible, in some cases to create User Stories for one team for one sprint, which creates really something usable. Reason for this is middle ware, complex technology, low level programing language. etc.

So basic idea for this, is to create Upper level User Story and create Acceptance Test Cases for that and those test cases are purely black box. After that you can break user story to as many smaller pieces as it's necessary and those smaller pieces can be really something which is not providing anything really working, but compilation of them creates value. Those pieces are still acceptance tested, but you can use more like white box and gray box approaching to them. Test Cases for Upper level User Stories are assuring that everything is implemented and nothing is missing because of splitting.