I started to analyze possible reasons for not finding agile methods motivating. Agile aims for shorter Time To Market. Check. This means better capability to serve the customer. Check. If serving the customer better is not motivating it makes me think ones own sources of motivation?

“Could we proceed like this?”

“Am I alone here?”

Agility aims for better Return On Investment. Check. Agile teams implement the most valuable features first. This means that the customer gets better value for his money. Nothing motivates me more than knowing I’m doing something really valuable to somebody. Am I alone here?

“Don’t we want to get things done?”

Agile methods combined with Continuous Delivery, Continuous Deployment or even plain Continuous Integration gives fast feedback from your work. Agile is about getting things done. Isn’t that something we all want? Don’t we want to see concrete results from our work? Don’t we want to get things done?

“If improving, learning and trying new things is not motivating then what is?”

Continuous learning and improving are important corner stones of Agile. If your team is using Scrum you have retrospectives at the end of each sprint. In Kanban you can define intervals of your own. Regardless of the cycle time, retrospectives provide a moment for learning, a moment for inspecting and a moment for choosing how to adapt. Retrospectives are a place to improve your skills, your teams methods and the connection to the business. In Sprint Reviews you get feedback from your work. If improving, learning and trying new things is not motivating then what is?

Freedom of choice for quality, methods, organizing, …

“Isn’t freedom motivating?”

Self organizing teams are essential in Agile ideology: people should be able to organize their work in the most efficient way. People have the freedom to choose, they are not commanded by a project manager or others. Isn’t freedom motivating?

“Isn’t it motivating that you are entitled to do high quality work?”

When implementing Agile with Scrum many teams use User Stories as a form of documenting Product Backlog Items. With User Stories teams have an Acceptance Criteria defined for each story. Acceptance Criteria together with the agreed Definition of Done criteria harnesses the desired level of quality. This is a quality agreement signed between the development team, the Product Owner and other stakeholders. In other words, you can declare a feature as not done if it does not meet the quality requirements. Isn’t it motivating that you are entitled to do high quality work?

“Isn’t it motivating to keep your house clean?”

The quick release cycle in Agile sets a big challenge to quality. Luckily we have automated tests. With automated tests you can ensure the desired quality while offering the possibility for quick and cheap changes. With the tests backing you up, the team has the possibility to improve the codebase safely. Refactoring removes waste from the codebase. Isn’t it motivating to keep your house clean?

“Please help me to understand!”

Please help me widen my perspective!

Speaking of waste, you can’t call your system Agile unless it’s neat and elegant. Lean thinking and removing all waste is a commonly used principle in Agile. Isn’t it motivating that the ideology drives you to remove the unneeded, unnessential things which are preventing you from being more productive?

What am I missing here? I can’t find a single demotivating thing in Agile or its implementations. Please help me to understand! Tell me what does not motivate you and let me improve my way of thinking. I want to improve and learn – that motivates me.

Sincerily yours,

Pasi Honkanen

An active team at work!

“Are the changes something else than the actual will to improve?”

Let’s take another moment to think what triggers the changes. What really makes the water boil? Pay attention to the root cause. Are the changes in your team actually triggered by something happening outside the teams control scope? Maybe the organization changes, the budget changes etc? Are the changes something else than the actual will to improve? Your team might be just making itself comfortable to outside changes. Is your team coping with the environment rather than improving? Continuous improvement is one of the key success factors in Agile organization. The agile doctor is glad to discuss how to create and nurture a culture of improvement!

Sincerily yours,

Pasi Honkanen

“I got the possibility to attend the GR10 Xtrem ultra trail competition in Valencia”

I got the possibility to attend the GR10 Xtrem ultra trail competition in Valencia, Spain on the 14th of January 2012. It is an ultra distance run (93 km) in the mountains with 3800m of positive altitude change and 3000m negative altitude change. A tough race that is not completed in one sprint for sure.

Race on!

The story began when my colleague Miia at our client mentioned she was going to attend the event next month with her friends Sanna and Ilkka. “Wanna join” she asked? I was not able to resist. The registration was done the same day.

The Race

14th of January, Valencia, Spain. Miia, Sanna, Ilkka and I woke up around 4.30 am on the race morning after sleeping the night on the floor of a multisport center near Valencia. I felt full of energy maybe because of the huge amount of spaghetti and pasta for carbo-loading earlier that week. The only thing I needed before the start was one breadroll and a cup of espresso to get my legs moving.

“The first 30 km went incredibly fast.”

The opening shoot was at 6 am. About 300 runners started their journey. It was still dark and we all had headlights on. Usually my body is like a diesel engine: doesn’t want to start in the beginning, but when it gets moving, it wont stop. Today it felt the opposite. I needed to hold back constantly not to go too fast. If I wanted to run fast, I’d better do it at the end when one surely doesn’t have any extra energy. Well, no worries, soon after we reached the forest all the runners stopped for almost half an hour. There was a huge climbing ahead. Everyone had to climb it one by one. The most difficult terrain was at the beginning of the race. The first 30 km went incredibly fast. Ilkka and I agreed that it felt too easy. It felt easy, because we ran quite slowly and had not any strict time targets. Just the twenty-hour time limit that was the maximum time runners could use for the race.

Running during the night.

“Enjoy the journey, not the destination.”

This landscape outside of Valencia was incredibly beautiful – a lot of orange gardens, olive groves and nice little villages that we passed. “Enjoy the journey, not the destination”, I reminded myself. The sun was shining and the temperature was around +15C at daytime and about 0C in the evening. Perfect for running! Every time we passed some of those beautiful villages, local people were catering to us. There was a nice atmosphere all the time.

 “Go Finlandia!”

The first 40 km I ran together with Ilkka. Miia and Sanna ran about half an hour behind us. Just before the 50 km mark was passed, Ilkka and I separated and ran on our own. Till 70 km I ran with various Spanish people. Most of them didn’t speak any English, but with those who did I chatted quite a lot. Those who didn’t speak English just cheered “Go Finlandia!”. Everyone was smiling. After 75 km I ran mostly alone. It was already about 8 pm. Darkness came incredibly fast. Most of the time I didn’t see any lights other than the stars and my headlight. I had to concentrate not to get lost. The route signs were quite small and sometimes hard too see. After the race I heard that some people had gotten lost during the race.

 “I already heard the music from the last village”

Suddenly, I saw the lights of the village. It was the second last village we had to pass before the finish line. It was a small village, I saw just a few people there in the street who were cheering for us. I already heard the music from the last village, where the finish line was located. I headed from the forest path to the street and saw the signs to go forward. I started to run faster on the street, made the last turn to the left and saw the finish line. Now it was time to think about the destination! I passed the finish line at 16:12:46 and got a finisher’s medal around my neck and a big smile on my face

16:12:46 finish line!

One life – live it, Hannu Rytkönen

The author training his dog.

“The animal achieves the goals on its own.”

Let’s go back to this shaping technique. The principle is pretty simple: The animal gets a reward when it performs the correct action. Then little by little you change the requirements to get closer to your ultimate goal. Most importantly: You don’t deny actions from the animal, you stay passive and reward it from the correct actions. The animal achieves the goals on its own.

“I would guide the first candidate only with positive words like: ‘good, yes and excellent’”

I demonstrated this technique by taking two persons in a separate room and telling the rest of the group that the objective for both persons will be the same: I need to get them to sit down into a chair in one corner of the room. I’m not allowed to use any aids like touching, guiding or telling. I would guide the first candidate only with positive words like: “good, yes and excellent”. The second one would be guided with positive words but also with negative words like “no” and “don’t” where necessary.

“Now he was very motivated to find the solution.”

"Yes, good, excellent!"

I took the first person in and said nothing. He stood there and looked completely lost. After a couple of seconds I saw that he was looking towards the corner I wished him to go. I immediately encouraged him:  ”Good!” He didn’t get the idea right away, but after a couple of tries he took his first step towards the corner and I got the reward timing right. He started to get the idea. He was ready to try out many different actions. At one point he thought he was supposed to follow my movements. I had to ignore this unwanted behavior and not reward any actions where he followed me. Now he was very motivated to find the solution. He actively tried different things, different directions and different moves. Suddenly he realized the chair in the corner. Now I only had to reward him for focusing on the chair…and… there it was! He ran towards the chair and sat on it laughing. Mission accomplished!

“The end result was a huge MMA fighter just standing by the curtain, refusing to do any actions and thinking: ‘This game is dull.’”

"No, no, no"

It was time to take the second candidate in. His objective was the same, but this time I was going to to use negative words as well. The person came in and like the first one, he looked like a question mark. I began by rewarding for looks towards the corner. He started to move but when he took his first step towards the wrong direction, I said firmly: “No.” He stalled and looked insecure. After a while he got some of his confidence back and slowly started moving again. I gave rewards for correct movements and here and there used positive punishments by saying “no”. For demonstration purposes, I suddenly stopped rewarding him at all and started to use only positive punishments – in other words I just kept repeating “no”. The end result was a huge MMA fighter just standing by the curtain, refusing to take any actions and thinking: “This game is dull.”

“Loosen your control and let people go.”

What’s the point here? To me this experiment demonstrates the essential principle on how to get people encouraged to try new things by themselves. Well made encouraging creates a fertile ground for innovation.

Let people surprise you with their achievements. Give them a chance. Reward them, let them fail and build a culture where failing is safe and trying new things is rewarded. Give them new challenges all the time. Loosen your control and let people go. Instead of telling how and what to do focus on motivating people. Motivate the journey – not the goal!

Have you tried similar experiments?

Pasi Honkanen

Our people work at customer sites, geographically isolated from other teams and Houston’s management. This enables efficient customer communication but sets great challenges for internal communication and development! Of course we have Houston days, customer specific development meetings, yammer, circles and peer groups, coding dojos, weekly newsletter etc. I still felt this wasn’t enough.

“I would make 100 home visits by the end of the year.”

100th home visit!

I made a plan last february. I would make 100 home visits by the end of the year. That meant about 3 home visits a week. Those visits were lunches, breakfasts and other informal meetings where I could share my knowledge and bring up everyday issues. Our people could tell me their ideas and challenges or just let out some steam! 10 months later in december I completed my 100th home visit.

“Oh no…is he coming again?” - An unknown Houstonian

What did I learn? Did I make a difference at all?
I learned to know our people. I hope that now I know at least some of their abilities and ambitions. I am able to share these to our management and to other Houstonians. This way we can support our peer groups, guide internal development and implement the best ideas quickly. We know to give credit to people who deserve it and can identify the biggest causes for frustration right away.

The seeds for Houston days, company-wide retrospectives, coding competitions and architect circle among others have been planted at home visits. I hope I’m able to keep my ears on the ground, right next to our people and customers. My job is to detect the development potential and everyday challenges. We have made 100 small steps this year which have contributed to a truly giant progress that our customers can harvest!

“Whatever we do, we do it with a big heart!”

Yet, in my opinion the most important thing I’ve discovered: Whatever we do, we do it with a big heart! And yes, our people love coding!

Memories throughout the year.

Hoping to break the 100 next year,

Ohto Rainio

Two Houstonians with guts!

“If you make a formal transition to agile and then think your work is done, you are missing the point.”

Yet the organizations that can reach their potential are few and far between. This is because the way to benefit from agile is to live it, to embrace the values and principles in our everyday work. If you make a formal transition to agile and then think your work is done, you are missing the point.

“Organizations that live according to the agile principles and reap the rewards accordingly, are very few.”

We, celebrating the tenth anniversary of Agile Manifesto, are not alone in this observation. At ALE2011 unConference, Rachel Davies mentioned the same thing in her keynote. Even though in the last ten years agile development methods have become quite well known and widely used, organizations that live according to the agile principles and reap the rewards accordingly, are very few. This is due to a more fundamental problem: developers and managers alike struggle to see possibilities of transforming their daily work for the better with the help of agile methods. The existing structures can make change very uncomfortable for individuals: maybe you are accustomed with your personal sales bonuses or maybe your company does not exactly celebrate failure.

“In a true agile organization, every employee acts as a change agent.”

That’s why it is important to stay vigilant and concentrate on the big picture. Doing this demands guts. In a true agile organization, every employee acts as a change agent. It is not enough to do agile software development, you have to live the agile values and principles.

“The best way to do this is to have courage but be humble at the same time.”

So what can we do to make things change for the better? The only people who can make a difference is you and I. If we embrace agile values and principles in our everyday work, we cannot help but spread the agile mindset. Our good example will spread among the people we work with every day. The best way to do this is to have courage but be humble at the same time. We must continuously question the way things are done and look for improvements. At the same time we must respect the views of our peers, for that is the way towards mutual communication.

So, here is our challenge: I’m sure you got the guts, please show it by driving change with humility and living by the agile values and principles!

Humbly yours,

Antti Kirjavainen

Our last Houston day wrote a new chapter to history books: We held our first coding competition using a concept called Extreme Startup. I think this quote from one of the participants says it all: “I thought I’d never say a coding competition is fun – I was wrong.”

Introducing the competition.

Extreme Startup is a concept created by Robert Chatley and Matt Wynne. We found out about it when Johannes Brodwall demonstrated it at Tampere Goes Agile. From there we got the inspiration to try it ourselves. The competition works like this:

• One machine acts as a question server
• Participants register the URL of their own web servers with the question server
• Question server starts sending questions as HTTP GET requests with specific intervals
• Players need to return the correct answer as a HTTP response

An easy question could be e.g. ‘what is 2 plus 4′. You’d think you could just write ’6′ as a response and you’d be correct. But when the next question is ‘what is 3 plus 5′ you actually have to implement a program for answering these questions.

“And that’s just the beginning.”

The vanilla version of the server contains six levels of questions with increasing difficulty. The facilitator switches the game to the next level when he feels that the players need more challenge. New more demanding questions start flowing from the server. Sounds simple, right?

The leaderboard

At the beginning players have no idea what kind of questions the server will give them. Neither do they have any idea how the scoring system works. Yet you should make some kind of a design! Correct answers increases the scores and certain other responses give penalty points. And all the time the leaderboard is visible to all participants.

“While the facilitator is shouting a countdown you feel your fingers moving faster than ever before.”

Imagine the feeling when your team is couple of points behind the leading team but only a few points ahead of the third. While the facilitator is shouting a countdown you feel your fingers moving faster than ever before. You are ready to do anything to get one more question correct and take the lead. If the clock only had couple of more seconds in it and hopefully my latest change doesn’t break any old answers…

If the amount of talk after the event could be used to define the success, then this was a great experience! Few even continued coding after the competition just to prove themselves how it could have been done without the stress. One of the participants commented:

“I woke up on Saturday morning irritated by the code I had written the day before. To my girlfriend’s delight I just had to write a better version while still in bed!”

Hectic, stressful, and hasty were just couple of adjectives used after the competition. But one adjective rose above others:

FUN!

Competition winners!

So what’s next?

• We’ll give you a peek to the actual results of this competition
• We’ll definitely do more of these…
•  …and we might give YOU an opportunity to challenge us!

So stay tuned!

Esko Pylsy

“Coding, open spaces, retrospectives, lightning talks, architecture presentations, peer groups, strategy bulletins, …”

Google has its 20% rule, Atlassian its fedex day. We have Houston day. We didn’t invent Houston day just to copy Atlassian or Google. We invented it because there was a real demand for sharing information and learning together. We have 50 highly skilled software professionals working at Houston. We want to provide them facilities for exchanging experiences, developing our technological know-how and building a better company for us and our clients.

Getting ready for coding competition!

“Trust, Professional, Velocity, Ambition and Pride”

The first Houston day started with a retrospective. Our retro facilitator had designed the retro to reflect our company values: Trust, Professional, Velocity, Ambition and Pride. How did our action reflect our values in the last quarter? What actions should we take in the next quarter to improve?

The most important part during Houston days is coding together. In the first Houston day we self-organized in five teams and design an “innovative feedback system” for our customers. The results were rated for team work, innovativeness and technical elegance. Last time we competed using ExtremeStartup challenge. It was a true pair-coding-hacking-morning!

Extreme startup dojo and innovative feedback system competition at Houston day.

Open space themes at Houston day.

Besides coding and retrospectives, Houston days provide a fertile ground for open spaces, lightning talks, architecture presentations, peer groups and strategy bulletins. One hugely important part is of course taking actions on the action points and innovations that have been identified. That means workshops!

Our support functionalities like sales and board of directors have their own working slots while others are coding.

Houston day is the corner stone for developing Houston, our employees and our culture!

Looking forward to our next Houston day before christmas,

Ohto Rainio

Chain reaction campaign

Kilometrikisa is a playful cycling competition to motivate companies and other institutions to:

• use two wheels over four wheels
• burn calories instead of gas

“The employer promises to donate one euro to Finnish Red Cross for each 25km of cycling done.”

Our Employer was thrilled. Who wouldn’t want their employees to exercise and generally feel better! So to motivate us even more, Houston Inc. joined the Ketjureaktio-campaign (“chain reaction campaign”). It is an addition to Kilometrikisa and means that the employer promises to donate one euro to Finnish Red Cross for each 25km of cycling done.

And so the journey began.

From 10.5.2011 to 30.9.2011 we used bicycles as our main transportation mean as much as possible. But it was a bumpy journey. None of us were so-called cycle enthusiasts and we mainly owned regular city bicycles. During the challenge there were periods that we logged a lot of kilometers and periods that we logged almost none. But at the end we were content with the results.

“A nice result for first-timers but this leaves a lot to improve in the coming years!”

The total result of the whole Kilometrikisa was a staggering 17145300 kilometers of cycling! Out of that Houston on Wheels team did 2374 kilometers with 395,67 km per consultant on average. That also means that we saved 166 litres of gas, produced 415 kilograms less Co2 and earned 95 euros to give to Finnish Red Cross.

A nice result for first-timers but this leaves a lot to improve in the coming years! At least couple of points to consider how to get better results:

• motivate each other more!
• create a feeling of competition within the team by maybe offering a small price for the best
• publish the status of the team to the rest of the company during the competition
• get more people involved

Houston on Wheels team enjoyed this challenge and will definitely do better next year. Maybe you would like to challenge us? Or maybe you want to challenge us in what we do best – coding?

On behalf of the cycling team,

Esko Pylsy

A master at work.

I attended the Scandinavian Agile Conference 2011 and listened to Jason Gorman’s presentation on The Imperative Software Craftsmanship. Gorman’s talk, however brief, gave me the nudge needed to start structuring my views on how I see my occupation as a software developer.

“The only way to learn how to code is to actually go out and code.”

“The only way to learn how to code is to actually go out and code.” I’ve heard this statement many times from the so-called experienced programmers. In my experience this perception takes time to mature. Typically the more mature programmers also start to emphasize quality aspects of their work.

“Only after this ten year ‘internship’ can one start dreaming of someday mastering the art.”

Coding is in many respects comparable to the traditional crafts: the basic theory and techniques can be learned from books, but only through actual practicing can one eventually become a true master. Experience can’t be rushed. As an example in the craft of glassblowing there seems to be a consensus that it takes at least 10-years of practicing to reach a stage of maturity. Only after this ten year “internship” can one start dreaming of someday mastering the art. After almost 20 years of programming Gorman calls himself a journeyman programmer. He still gets inspired from the displays of excellence by masters such as Bob Martin and Ward Cunningham.

A software developer improves her programming skills in software projects. An agile software project has a goal, which a team is formed to accomplish. The goal is met through series of incremental prototype versions that are built iteratively to the best of the team’s know-how. The project owner sees the iteration outputs in demo sessions and uses the wisdom gained from them as the basis for steering the project.

“In modern organizations results are needed yesterday”

For projects that span over a year the team’s ability to react to change is of great importance for the overall result. In modern organizations results are needed yesterday, pressuring the team to work too fast for their abilities. Gorman spoke of anaerobic software development: “When teams write code at an unsustainable pace, code smells build up faster, making progress increasingly difficult and painful.” Without adequate skills or discipline, a speed too high will rapidly decrease the team’s productivity. This means that the cost of change will increase. Soon the benefits derived from the change won’t cover the cost of the change anymore.

“If you don’t understand your own code, how can you expect someone else to understand it?”

Gorman specified five cost-increasing factors in software development:

1. Poor readability of the code
2. Complexity of the code
3. Code duplication
4. Coupling of code and the resulting ripple effects
5. Inadequate regression testing of code

According to Gorman our ability to understand a piece of code affects crucially our ability to change it. Even code you have written yourself will be difficult to understand over time if its clarity and readability are neglected. If you don’t understand your own code, how can you expect someone else to understand it?

Complex algorithms and code structures increase the possibility of something going wrong. If something goes wrong, it needs to be fixed. That costs money. A large amount of duplicate code means that a fix has to be implemented in many parts of the system. The resulting code must be maintained. When a component is broken, a dependent component might also brake causing a butterfly effect. Without adequate regression tests the developer has no way of knowing things have gone awry. The cost of this will be unbearable for any organization.

It requires a right kind of learning environment to evolve as a programmer. Junior developer needs the hands-on-example of a senior developer. He also needs to be continuously confronted by demanding challenges that put her learning to the test. There has to be room for errors.

“An imitation eventually develops into a habit”

Furthermore, as Jason Gorman’s presentation outlined: the “pupil” has to want to learn. Gorman’s way of promoting high quality programming is based on continuous training. The team should agree on a set of practices that every team member commits to. The more experienced developers help the inexperienced ones and little by little the practice that started of as an imitation eventually develops into a habit. It is essential that even though experience levels might vary, every member of the group is considered equal. Trust is the cornerstone of building a learning-friendly and truly fertile development environment.

“So how can one differentiate an experienced programmer?”

So how can one differentiate an experienced programmer? In assessing the experience level of a developer Gorman advises people to follow the person in action: if you want to know how good a juggler is in juggling ask her to juggle for you. While assessing the skills of a junior software developer the more experienced one literally logs all the deviations from the agreed practices. The stumbling logged during the assessment is not to be held against the assesse but to be given as a foundation for improvement.

“Repetition is the key and there are no shortcuts”

Finally Jason Gorman reminded the listeners of an old saying about a tourist in New York asking renowned violinist Jascha Heifetz how to get to Carnegie Hall.  Practice, practice, practice was the answer. Even though the saying is meant as a joke I think it contains the essence in becoming a craftsman: repetition is the key and there are no shortcuts.

I believe I’m fortunate to work in an organization where it’s possible to evolve as a professional software craftsman.

How do you see your occupation as a software professional?

Vesa Teikari

Vesa Teikari