Nine-to-Five folk

I have been working as a change agent now for a while and one question that I pump into from time to time is: "How about the non-motivated part of our people?". The curious thing is, that most of these people were enthusiastic students. The working life is the one that has killed the passion.

Cubicles in a now-defunct co-working space in Portland, Oregon. CubeSpace 2009-05-20 20:30 By Asa Wilson

So why is that? In a natural way, people are organising themselves into a dynamic network. I wrote a blog post about this. Workplaces are forcing people to form unnatural constructions and the agony which is caused by this is the one which starts to eat the motivation of people.

As long as we are not going to fix this, we are only dealing with symptoms. By fixing symptoms nothing magnificent will happen.

ps. With the Nine-to-Five, I mean second definition from here: http://www.yourdictionary.com/nine-to-five

Hierarchies are oversimplifying complex things

After I started working as a Scrum Master back in my times. I felt, that there is something really dysfunctional about our workplaces. Still I was not able to put my finger on it. There was an excellent talk by Kati Saarikivi about Work as learning, meaning and interconnectedness in my previous company where I worked. In the talk there was something mind blowing and it has been puzzling me ever since.

Here comes the idea in brief:

By nature, people are creating human networks dynamically. Pretty much same way as neurons are working in brains. In other words we (group of people) organise ourselves automatically to correspond to the changing environment.

During that time, I was working as an Agile Coach and of course I started to think, how this idea reflects to companies which I have been working with. If you have ever worked in corporate, you know that organisation change is something which is constant... every year.

So this was my first tought out of it.

Forced organisational changes are bad imitations of humans natural way to organise themselves freely to respond to a changing environment.
— Ismo Aro (@ismoaro) April 7, 2013

Workplaces nowadays does not really support this natural way of forming. If we think about all the "fun" stuff, what is happening, like policies, rules, hierarchies and matrix organisations. I came to this one.

Companies policies, rules, hierarchies are usually causing more harm than good. Is it unethical to follow them?
— Ismo Aro (@ismoaro) November 24, 2013

and this one.

Social networks are dynamic by nature, not a hierarchical or matrix.
— Ismo Aro (@ismoaro) November 24, 2013

But I was not quite happy yet. What is the reason, why is it like this? The final piece came from Duarte Vasco, he tweeted like this.

Hierarchies are good at avoiding complexity. Networks are best to *embrace* the existing complexity. #socbiz #pmot
— Vasco Duarte (@duarte_vasco) December 10, 2013

We are trying to make sense to these complex things. How to do it? We try to categorise things. Introduce different kind of boxes with different functions. Oversimplify things with the hierarchies and matrix organisations.

So what should we do? A change in paradigm is required which makes it hard. We should embrace the environment which nurtures adaptive social networks.We should not create any artificial borders or roles. And we should not be bothered about the fact that the situation changes all the time. And above all, enjoy working together!

And how this reflects thing like Agile methods and frameworks? Kids, that's an another story. :)

How to install Robot Framework to the Windows machine using PIP

Pre-Requirement: Python 2.7 is installed.

1) Install Setup tools.
http://www.lfd.uci.edu/~gohlke/pythonlibs/#setuptools

2) Install PIP
http://www.lfd.uci.edu/~gohlke/pythonlibs/#setuptools

3) Add Python Scripts to the path

Start -> Edit environment variables

eg. C:\Python27\Scripts

4) Install Robot Framework
Start -> cmd

 pip install robotframework  

5) Execute Robot Framework

 pybot --version  

Robot Framework 2.8.1 (Python 2.7.5 on win32)

Free Jam

Have you ever felt bored in technical conferences? Long talks, presentations that did not hit your spot, although the topic sounded interesting. Hey, we are engineers, we want to build!

This idea came to me from the Open Spaces. Open Space is a great way to have dynamic discussions around the topics. The whole nature is, that people are voting with their feet and it’s ok! The process of free jam is so simple, that it made me almost embarrassed to see it working.

All workshops, presentations, etc are coming from the people inside the organisation. There are absolutely no pre-selections. Before the event itself, there was a whiteboard, in a very popular place where people are passing by on daily basis. With the post-it notes, people could propose things they wanted to learn about and things they were ready to present. This is only preliminary input for the session itself.

In the session, there were numbered tables. We called those tables “resources”. There were also three white boards

- the Wishlist, here people could write what they wanted to learn more about.

- Ready to Rock, in this one, there were things were a presenter had volunteered for.

- There were two things in the last one.

- WIP, if people had chosen a topic they could reserved the table here. There were columns as many as tables.

- Done. Things that were ready.

When there was enough people around the topic, they could choose a free table. They worked around the topic as long a they wanted and when they were ready, they freed the resource for the next session.

And what kind of topics were there? Learning coding skills, playing with the gerrit, presentation about Cloud Technologies. etc. There were no limitations how and what you can have there.

How this all came together? Extremely well, there were almost no hassle at the beginning and people were enjoying their time to learn new things. Should we do this again? Absolutely YES.

Radical Coaching - What it was for me

By Hans Hillewaert [CC-BY-SA-3.0], via Wikimedia Commons

We have started a new training/coaching/mentoring session called Radical Coaching. This session has already gained publicity inside the company and also around external communities. The problem has been, that it's like the Matrix, you need to see it for yourself.

I'll try to explain now the Matrix. :)

Like one of the fathers (Henri Kivioja) of the sessions has said, it's emotional. There are almost none Agile/Lean methodology and framework stuff. We are going to the core values, where all the good things grow. A true change is not eg. taking Scrum into use, a true change is to change the surroundings in order to support people to evolve.

The entire session was based on conversation. Facilitators created a context and then people started to share ideas and opinions about it. It takes the whole session to a new level, that actually our leaders are the ones who are facilitating it. It's just not that this has outsourced this to eg. some external company, it gives strong feeling of commitment, that we are really going to do it.

This whole thing gave me a lot of new hope! We are really going to change things to the better and we are truly going to support each others. Maybe the biggest thing that I felt from the whole session was companionship. You guys and girls are amazing!

Feedback Loop Workshop - The Vision

It  is extremely important to understand where we are and where we want to go. This Workshop is all about that, regarding Feedback Loops. It is mandatory to have people from every part of the organisation and from different roles, not only developers or testers. This is how we are ensuring that we are drawing a complete picture.

Material:

• Big White Board. I prefer a movable one
• Flip Charts. 1/5 people
• Post Its
• Pens 

Agenda:

• What are the feedback loops
• Picture about the present
• Break
• Vision about the future
• Wrap UP

What are the feedback loops

This is a short talk about the Feedback Loop itself. This gives a basic understanding what we want to achieve in this Workshop.

Picture about the present

Split people in small groups. In the groups there should be diversity as much as possible. The size can be around 5 people. Give people a flip chart, pens and post-its. Ask people in groups to create picture about Feedback Loops in timeline. It needs to present the situation at the moment. People can be really free style. I usually draw really simple example. You can give groups around 20 minutes time to create their own picture.

After creating pictures, every group presents their view to the rest of the people, question may be asked, but try to avoid criticism, this is just showing the result from this part.

Create common picture. Share the white board into two parts. Draw the timeline and let people merge their pictures together. You can give a 20 minutes time box.


Rough example about feedback loops

Vision about the future

Now we are ready to draw the picture about the bright future. People can stay in the same groups or create new groups, again with the diversity. I prefer old groups, because there might be already some group dynamics in. Now same exercise, but let the people create a picture without the legacy. People should free their minds about solutions at the moment and they can really be as creative as they can. Again about 20 minutes.

Presenting the picture and in the end merging the pictures.

Wrap UP

You can briefly tell, what has happened today and what are the next steps. Ask people to present their pictures again.

My Last Words

Like I said in the beginning, the idea is to create vision. Vision does not need to be perfect. Nature of things are that they are changing, so this is just a snapshot about the situation at the moment and the vision what it should be. This snapshot should be created as often as needed. In other words, this is a longer process, not just one shot. :)

Feedback Loops

I have been thinking, how to dig out the essence, why do we need Test Automation and Continuous Integration. Also how to help people to understand why these things are really important, when we are doing more fast paced software development.

I came up with two Workshops  which are related to one another. In this blog post, I'll explain the concept of Feedback Loops and there will be two more posts, which are describing those Workshops more carefully.

Copyright Robin Stott and licensed for reuse under this Creative Commons Licence.

So what do I mean with Feedback Loops? Feedback Loops are the things, when people who are developing the product starts to get feedback. Did he/she provide right kind of behavior to the product? In the end, customer is the one who gives the final verdict, does it do what they want.

These Feedback Loops can be something like this:
IDE
Unit Tests
Gollegue
Acceptance Tests
System Tests
Load Tests
...
Customer

And why are these so important? I have used this wine metaphor before. Abnormal behaviour is not like a wine, it does not get better with age. The sooner you catch and fix the abnormality, the better. What do you think, which one of these scenarios is cheaper? Customer finds a performance problem, which is caused by an architectural flaw vs. create small functionality based to the architecture and test it as soon as possible.

These thing are not directly tied to the Test Automation and Continuous Integration, but with the knowledge what I have, those things are mandatory to create as fast feedback as it can be.

Like I promised, following two posts will be about those workshops, so stay tuned.

It's just the tip of the iceberg.

An organisation is in the middle of Agile transformation process. Some Agile methodology is implemented, but something is not right. Teams are lazily having their retros, some of them are dropping the daily stand ups. All cool practices are not really taken into use. The organisation feels like teflon, nothing really sticks and some off the stuff is falling off.  Does this sound familiar? If so please go on.

Introducing Agile software methodology (eg. Scrum) to the organisation is fairly easy, most easiest way is just to use old Command and Control mechanics and just push it in. The process is pretty simple, only three roles, handful of artifacts and meetings and that's it. But does it really stick? I would say no. I see the whole thing as an iceberg.

By Created by Uwe Kils (iceberg) and User:Wiska Bodo (sky). [GFDL or CC-BY-SA-3.0], via Wikimedia Commons

TIP

This is where all processes, practices and methodologies are. If this part starts to show symptoms it's really painfully visible for everyone. In my experience, this is also what people are trying to fix. Usually this is just pushing more those processes, methodologies and practices in and what I have seen, this rarely do the trick. The reason for this is that there is really no soil to grow, soil is in the rest of the iceberg.

REST OF THE ICEBERG

Here is the organisation culture, if this is not right, nothing magnificent really happens. When I'm talking about organisation, I mean everybody included from the coding grunt to the highest manager (and whatever roles you have in your organisation). Do you have trust in place? Are the different roles of your organisation blaming one another? Are people really taking responsibility? Is it really a great place to work? Do your people collaboratively seek better ways to satisfy the customer?

If you get this part working, I claim that magic really starts to happen. People are seeking better ways to work and they are learning and discovering new things.

LAST WORDS

It is always easier to work with the tip of the iceberg, the rest of the iceberg is really much harder and also more fuzzy. But hey the question is: do we really want to change the world? Or at least our organisations? Please, if any ideas, post a comment.

Given Empowerment

The company goes Agile. In one night teams are in self-organization and -management mode. The management announces empowerment to the teams and stands aside. Time goes and it seems that teams are not performing as expected. The blaming starts: "even with the empowerment you are not delivering".

Sculpture "Empowerment", Lincoln (PAUL FARMER) / CC BY-SA 2.0

Empowerment is something what leaders should foster. Leaders should create an environment which really supports people's and team's self-management. In an environment with no blame but trust, people can truly choose how they are working and learn new things. Also a clear vision why and what we are doing, including constant constructive feedback must be in. These things are not coming automatically when empowerment is given.

It is about focusing what you can do for your people, not what they can do for you, or how they should act / behave. As a work it's difficult, much more difficult than giving commands.

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. 

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!