Sunday, December 28, 2008

Thursday, December 4, 2008

People versus Tools

I recently blogged about releasing every day and I got some interesting feedback from the community. However, I am sad about the fact that I got asked "What (software) tools you use" rather than "Could you tell me about your team".

I hope that people don't believe in achieving agility by downloading some tools from the Internet.

Simple (and stupid) comparison atleast may reveal something: "agile tools" gives me 24,800 hits on Google.

With "agile people" I get 7 210 hits...

Thursday, November 27, 2008

It is a craft aka when do we start the thinking

I participated to OO Days at Tampere University of Technology. The days were quite commercial (way too many open sales pitches about tools) but luckily there were also few good talks.

Alistair Cockburn was giving a talk about Effective Software Development In The 21st Century: The New Face Of Software Engineering that made me thinking the craft of software development. Take a look at his slides.

Another great talk came from James O. Coplien, I especially liked his criticism towards agile implementations and our industry not thinking nor feeling.

Nokia: Making the impossible happen: a few hundred synchronized Scrums -- setup and experiences was pretty "scratch the surface" kind of talk. It sounded very familiar based on the customers I have tried to help scale up. I was disappointed by the fact that Juha-Markus Aalto could not tell us if they actually had improved their cycle-time or even decreased the number of defects.

I find it disturbing that they have put gazillions of euros to get the implementation going on and they do not have any numbers to prove that it would be worth of it - why did they even started scaling before finding this out?!

Tuesday, November 18, 2008

I release my software every day

We had a new office opening party at our premises and as part of the party we were telling about Nextdoor, which is pretty nice web application.

The thing that got most of the interest was the way we have developed it and how we are able to release it every day. As an agile coach I have seen teams applying Scrum or even trying the XP practices, but still not getting stuff out fast due to various blockers in their value stream.

As part of the Nextdoor development we have wanted to demonstrate that "It can be done even you are not 'Google'" and to be honest we have even surprised ourselves with the results.

So to give you some idea what we have done so far:
  • We have a web application that has over 400 use cases
  • All the use cases are automatically tested by our automated acceptance tests on every build (build time about 1 hour, including tests, reports, and deployments)
  • We have practiced "Test-First", meaning that before we write any new functionality, we write the test first (we actually do that in cycles, but still)
  • The implementation from the day that we bought the hardware and started installing software has taken about 120 man days
It has been quite challenging in various aspects. Here is few of the challenges we have faced:
  • Our Scrum team is not co-located
  • All the team members have been part-timers, which makes velocity tracking and coordination pretty hard
  • Usability and interaction design has been challenging
  • We have tried to merge any outsourced resources to our Scrum
  • Some test scenarios are pretty complex (for instance testing of Google Maps integration or fancy AJAX components)
Despite the challenges faced we have seen very good results with our implementation of Scrum and agile engineering practices. For instance we have found that the bug tracking has become actually "fix tracking" as no bug lives very long (most of them get fixed in 24 hours) and therefore the priority of the bug has become almost irrelevant. With 24 hours release cycle the customer (our Product Owner) has become almost a bottleneck as he cannot revise the implemented stories within that time frame. Naturally we release some bigger features via sprint demo (every 2 weeks) still so not all the features are released in "one day pieces".

Some people have argued that our software is not very lean as the test mass that can see as machinery to produce quality software is pretty big and requires maintenance. We agree, but we still are confident about paying the price in order to be able to release as often as we do.

I need to stress that implementing Scrum (or any agile method) requires a lot from the people. You have to be very disciplined to get it right and not to forget adjust and learn from the previous sprint/iteration/thing that you have done. Inspect-Adapt cycle may sound easy, but it is not.

Do not forget the 0-step of every method: Think

Want to hear more? Mail me (marko dot taipale at huitale dot com) and lets see if I can arrange a demo for you :)

Markus also has blogged about this.

Saturday, November 1, 2008

Scandinavian Agile Conference 2008 is over

Based on gut-feeling it was pretty good. We are just about to collect feedback from the visitors to improve it (yeah, Scan-Agile 2009 will happen). I want to thank the speakers (especially the ones that were on Practioners track ;) ) and the visitors (as Vasco puts it: "You are the Agile Finland").

I also want to thank Markus Hjort for co-chairing the track with me and rest of the organizers for giving me a chance to be part of it.

Some stuff that has come online so far:

From Pascal van Cauwenberghe - Business Value Game pictures:

From Artem Marchenko - Open Space session about Distributed and offshore teams:

Saturday, October 25, 2008

Scandinavian Agile Conference 2008 on Next Week

First Scandinavian Agile Conference is taking place in next week.

We have over 200 hundred registered agilists/to-become-agilists and good bunch of excellent speakers coming. I can't wait for the corridor talks with various people. It seems that Agile Finland's vision of having real agile conference in Finland is really going to happen!

Monday, September 29, 2008

Leadership is about being aware - What happens if Go-And-See is not practiced

Finnish schools may get great scores in PISA, but it is sure that the management practices are still falling short as the following article on Metro demonstrates.

The students are sitting on the corridors as they cannot fit in to the school cafeteria. One of the managers is saying that they have not been aware about the issue.

I would recommend that the managers would exercise the Go-And-See practise. It could tell you much more than sitting behing the desk and expecting somebody to come and report you that there are students eating on the floor. :)

Thursday, September 18, 2008

Everything About Testing (Does your company cover all this?)

Kind of ambitious title right there but still I honestly think that the following picture (originally presented by Brian Marick) contains everything about testing.

Lets first look at the four areas: Unit, Acceptance, Usability & Exploratory and Property testing.

Unit testing supports programmers to design their code. Unit tests are automated (usually with help of some XUnit framework) and they closer to tech than business. Based on my experience it is not common that companies actually have unit tests written, especially not Test-First fashion. In Huitale we implement JUnit tests in Test-First way (... I do not use TDD here as it is a misleading term).

Acceptance testing helps to design the product (if done in agile way). What I've seen is that most companies still have "testing phase" in their process, where some testers manually go trough the "customer acceptance" tests. It's a shame cause nowdays there are lots of acceptance testing frameworks helping out to automate the acceptance testing and getting it as part of your (expecting you have it) continuous integration cycle. In Huitale we have managed to automate all acceptance tests (for the user stories) with Selenium - eventhough Ajax has been a bit painful to test and our build cycle has come pretty long due to these tests (they are executed on every build, every 2 hours).

Usability & Exploratory testing are manual and will be manual in the future. You simply cannot automate usability evaluation nor thoughtful tester. We have practiced setting up the UI experts together with scrum team and it has been challenging. I may blog about our experiences in near future.

The challenge of property testing is often attacked with silver bullet-projects that try to fully automate every bit of the process. I have never seen such an effort to succeed, maybe cause the analysis involved cannot simply be automated :) What you usually need is just tools to help you with the testing, but still you need the analytical mind of an engineer to look into the results, tweak the variables involved etc. Some simple checks naturally can be automated, but one should try to proceed step-by-step when building such solution.

Anyway, I hope that you got something out of this - at least it clarified my mind. Sometimes you know all the stuff beforehand but it still is not crystal clear until you get it nailed down into one simple picture. If you want to read more about the picture, see Brian's blog

Thursday, August 14, 2008

Wednesday, July 2, 2008

Common Scrum Pitfalls - Splitting stories makes building the quality in hard

I have noticed several scrum teams applying Test-Driven-Development, having stories tested and still not managed to build the quality in (lean principle, remember?). I've asked myself why and here's what I've learned so far.

Let's start from basics. Your team is having 2 weeks sprints. We are in sprint planning and the product owner explains a story that is too big for team to implement in one sprint. Common solution for this is to split the story (to fulfill the INVEST attributes; Independent, Negotiable, Valuable, Estimatable, Small, Testable) so that's what the product owner does. He needs to do it actually several times in order to fit it in to the upcoming sprint.

Fine, team goes and implements the story (test-first) and then demonstrates the story to the product owner. Everybody's happy and next sprint the team continues from other subparts of the original story (that is not visible anywhere - maybe a theme, but that's it).

After three or more sprints we get a bug report from production. User's have discovered a buggy scenario that actually was the original story that was split few sprints back. Each individual test passes in teams integration environment, but we discover that the team did not have test for full scenario (as we split the story and implemented test for INDIVIDUAL stories, but not for the original story).

Lesson learned

When you split the story please still add a task to implement the test for original story with the scope of that story. Add the test to your integration environment and see it passes once the "theme" or "epic story" is done.

Or ... implement kanban instead of scrum - why bother with splitting if you do not need to split :)

Oh, btw about TDD.. Remember this post? Take a look at the following video - great conversation between great names :)

Thursday, June 19, 2008

Huitale Launched

Huitale launched friends beta on 15th of June.

I want to share some numbers to shed a light on what and how we did it. I need to stress that we did not have full time developers, only myself as 1 day per week and Roberto on his freetime.

Note that we started the company without computers and network.

After ~70 man days spent on development and infrastructure we launched a consumer website for 100 beta users.

As part of the development we
  • Setup environments (wiki, CI, version control, bugtracking, web servers and database, end-user forum, nightly backups on mirrored network drive)
  • Setup scheduled hardware monitoring (memory, cpu, disk) and application monitoring (exception check)
  • Setup machines (2x Debian laptops)

  • 15 Sprints (2 week each, effective 2 working days per sprint per person = 2*2*15 = total 60 man days)
  • Stabilized velocity around 90 story points

Over 270 automated tests (and over 160 use cases tested)

  • ~7600 Non Commenting Source Statements (NCSS) (+ tons of HTML, not calculated as part of this)
  • ~400 classes

Wednesday, June 11, 2008

Scandinavian Agile Conference - get ready

As a member of the organizers I want to promote upcoming agile event.

Here's the official announcement:

Hello all,

A group of Agile Finland members have volunteered to start organizing the first Agile Finland Conference that has been baptised Scandinavian Agile Conference.

The Conference aims to fill-in a gap in the Finnish and Nordic areas where there is little opportunity to listen and discuss with world-class Agile leaders. Through this Conference organization we want to increase the knowledge about Agile and contribute to a faster and wider adoption of Agile Software Development in the Nordic countries. Being, as we are, Agile Finland we also want to provide a unique opportunity for our members to network with each other and other industry experts, in order to build a strong and active Agile community.

The Conference will take place on October 29th and the location will be the Marina Congress Center ( It will comprise three tracks: Awareness, Expert and Open Space.

The Awareness track will concentrate on case studies with Q&A sessions from the Agile change leaders from Scandinavia and elsewhere.

The Expert track will concentrate on more hands-on workshop aimed at people that want to increase their practical knowledge of Agile, this includes methods and skills.

The Open Space track is open to all of the participants, and it's contents are going to be defined on the spot by the participants. The Open Space track has become a key feature of Agile conferences/seminars all over the world and reflect the belief that people know what they need to discuss and would like to have an opportunity to discuss the latest hot topic with other like minded people. In this track you are expected to share your experiences but will also have the opportunity to get feedback on your ideas from real practitioners.

The organizers for the Conference are:
Pekka Abrahamsson, VTT, General Chair
Lasse Ziegler, Agile Finland, Awareness track Chair
Markus Hjort and Marko Taipale, Agile Finland, Expert track Chair
Petri Haapio, Agile Finland, Open Space track Chair
Vasco Duarte, Agile Finland, Organization Chair

All organizers can be reached at: firstname.lastname@... or alternatively at organizers (at) scan-agile dot org

Volunteer needed to maintain web-site:
For the organization of this Conference to be a success we also need the contribution from the community in many practical issues such as the web-site design/implementation and maintenance. As of now we are asking the community for a volunteer in helping us set-up the Conference web-site which is for now only a landing page (

If you are interested we can offer you free entrance to the Conference (estimated value: 200 Euros) and a special place in everybody's heart! Let us know of your interest by contacting the Organization Chair (see e-mail above).

Use of "kanban" in software development

I have found presentations about using kanban in software development. Take a look at the slides at Agile North.

I would suggest to try that out in operations and/or support functions. If you have some experience about that, please share :)

Tuesday, June 10, 2008

Introduction to Agile and Lean

I did a brief introduction to agile and lean in HSE New Business Center. Here are the slides for those who are interested. I also want to thank Henrik Kniberg for most of the pictures and slide layouts.

As part of the questions and answers there were some points raised that I promised to clarify so here you go:
If you think I missed something just drop a comment. Thanks for participating and hopefully it was a good session for you.

Monday, June 2, 2008

Let them Fail...

I was requested to visit a scrum team that needed some extra help with their planning. That was my personal lesson about letting team to fail in order to learn from their experience.

I joined the teams planning as chicken (= not allowed to speak). Their ScrumMaster asked me to collect some notes and then after the planning to give the feedback about their way of executing the planning session. My first note was that their Product Owner was not present in the meeting. However they had done some preparations and they got prioritized backlog so they started by pulling the stories from it. The stories were not in story format and they were overly complicated as they contained tons of technical details. I noted that these stories must be something their Product Owner has not understood as even I had hard time grasping them (with my 10+ years experience in software development).

After some time the whiteboard was quite full of stories. I thought that these guys must be hyper-productive already though I had some doubt about it. I asked their ScrumMaster what is their current velocity. I could read the confusion from his face as he asked me back "what do you mean by velocity?". Instead of going trough scrum terminology I just calculated their average velocity over last 7 sprints or so. Their average velocity was around 45 story points but their current sprint contained stories that totaled over 150 story points! Obviously the team was about to overcommit.

I raised the fact of overcommitment to the team and challenged them to think it as "lying to Product Owner as he makes business decisions based on the given information". They protested by saying that "we need to show that we are at least trying to make it happen - we are about to have release soon and we must have these features in it". I told them that it is not the teams responsibility to think even about release schedule. Rather the team just gives the effort estimates and Product Owner comes up with release plan. Actually the team had been (micro)commanded & controlled for last few years so they had hard time understanding the self-organization and empowerment that is involved in scrum.

I also asked them if their Product Owner understands the stories. They told me that Product Owner had not even seen the stories! I asked how they have come up with them in first place and they told that Product Owner had given them an epic story (BIG story) and they had asked what does it mean... Product Owner told them to figure it out what it means and thus they had done one sprint with spike "figure it out" and then done second sprint with their own stories that were results of "figuring it out". I realised that their Product Owner was not doing his job and basically the team was responsible also for the ownership. They did not have transparency towards the business side (stakeholders, Product Owner...) and therefore they also felt responsible for release planning.

I told the team that it is their responsibility to not to commit unrealistic schedule but they still did. Finally I had to let them fail - they overcommitted and ... failed ... and hopefully learned the lesson.

Tuesday, May 6, 2008

Some stuff going on in Finland

I decided to participate on arranging an agile conference here in Finland (in name of Agile Finland). I am trying to contribute on getting the expert track sorted together with Markus. More information will follow as we move forward.

As part of the arrangements we had short get-together with Markus and talked a hour about the conference, half hour extra time about our experiences about agile. It was nice to share the buzz and the pain - common challenge seemed to be getting QA involved to iterations (Sprints in Scrum). Far too many companies do not have practices and especially the culture in place to make cross-functionality to happen. For instance I gave an example of a Scrum team that asked me to join their daily stand-up to help them to see what exactly is blocking them to get stuff out.

I went to their scrum board to see what's wrong and it hit me hard: they had columns "not started", "in progress", "QA" and finally "done". Guess which column had most of the stuff pending (yeah, they had pushed the stuff till QA column..)? :) Anyway, I asked the team that why the QA has so much stuff and why they do not get one thing done before moving to the next. The answer was blunt: "Well, we are waiting to tester to get it done and meanwhile try to get our stuff done"... I asked "so from your point of view the tester is solely responsible to get stuff into the last column that states 'done'?" ... after faint "yeah... sort of" they realized the problem. In few minutes the ScrumMaster was explaining how team is committed together instead individual commitments and I left the room. Sometimes people miss the message from information radiator - no matter how strong the signal is.

Oh, and if you are about to join Agile Dinner, do not hesitate to poke me; I want to hear your story :)

Tuesday, April 22, 2008

Fixed Price Agile Contracts

Jeff wrote excellent blog about applying Scrum into sales process.

I get this question about how to do fixed price & scope subcontracting over and over again and I usually start asking about their partnership with the customer. In most cases it is all about trust (or politics..) ... actually lack of it. Contracts are made to cover up the areas where there is no trust between the parties. I am not saying that you do not need contracts - you do as we are doing business after all - but I think the focus should be more on collaboration and communication about incentives rather than what are the delivered features and what is the time frame (and what are the sanctions if supplier won't make it).

As Mary Poppendieck has done excellent job putting this all down to a presentation I won't elaborate it more here for now.

Totally about different topic, but still important enough: It's often surprising how incentives end up pulling people in the wrong direction. See daily WTF for real life example.

Wednesday, April 16, 2008

What is Agile?

Think the following: "Be inside your enemy's decision cycle - if you can decide faster than your enemy then you will be victorious over her".

Agility is about establishing yourself on changing environment - it is a survival strategy for changing conditions where the environment (be that market conditions or customer changing her mind) throwing changes at you constantly and unpredictably.

The ultimate agility test is modern warfare. It is a good example about leaders to stand back and let the team on the field do the decisions on the spot.

How the team can do that? Or better, how do you as leader enable them to do that? You must lead team cause the team won't get anything done until you provide a vision or goal for them to accomplish. "I want you to accomplish this, but it is up to you how do you get it done and how fast you can get it done". Isn't it funny that most leaders in agile training will ask "so what's my role in Agile as the team will self organize and I must not interfere the team or if I will the ScrumMaster will protect the team from me"?

Now as the environment changes on the field (imagine that warfare still), the team can do kind of plan-do-check-act (in military they actually do OODA) on the spot based on the common goal and more over the teams decision will be more likely right as they share the goal and organizational principles if you will. Think about the movie Blackhawk Down when a Blackhawk went down the teams acted immediately. They changed their plan accordingly and started executing it as they knew that the principle is 'Leave no man behind' - is that happening in your organization?

... Are you Agile?

Without the goal they will either do wrong decision or even worse, do not do decision at all.. and if the company culture is not open enough, they won't even raise impediment about it.

If you want to measure your agility, one way to do that is to check how many Agile Machismo points you get or read about it.

If you got interested about hearing more about this check out an excellent podcast or/and contact us to do Agile Assessment in your organization.

Thursday, March 27, 2008

Western Manufacturing - No Toyota Way ... I Assume

I love real stories so I have to share this one with you.

I ordered a module sofa few weeks back and yesterday I finally got it. After I got rid of the packaging I noticed that the pieces were wrong (or that the sofa would be more modern than expected ;) ).

I wonder what would happen if the manufacturer would use one-piece-flow instead of mass production including inventories. At some point of the flow someone would go "hmm, something is probably wrong here ... either the order is wrong or our flow is broken". What happened here (most probably) was that some guy got the first piece of sofa and then some other guy got the second one and yet another guy (or two?) packaged it all. No communication happened in between so end result is X weeks of wasted production time (+ rework), unsatisfied customer and no improvement to manufacturers processes (lack of kaizen, maybe).

Anyway I am happy with the quality of materials and wishing to get the sofa soon.

Thursday, March 6, 2008

Common Scrum Pitfalls - self-organizing teams taken to extreme

This time I am introducing yet another pitfall that is probably the most "managerial" so far: Self-Organizing Teams Taken to Extreme. I have seen it happening in some Scrum implementations so far so probably it is a "common" pitfall - leave a comment if you have experience about similar problem :)

Anyway, it is very common that software company is having a organization structure following the Conway's Law. I have been part of these companies and seen them trying to implement Scrum. Here's what happens according to my experience:

  1. One team is chosen to be a pilot team for Scrum, this team is a "architectural layer" in the product, usually something like "core" or "platform" team (as they are usually most experienced engineers in the house)
  2. Team tries to implement Scrum, they wonder why their velocity is not getting stable (even the Book says that it should after few sprints).
  3. The team realizes that the velocity is not getting stable cause they are not in full control - they are impeded a lot by other teams (like database team that is underlying in their architecture, or client team which is on top of them).
  4. They raise the issues to the organization as they feel that fixing all the dependencies is out of their hands and should be handled by the organization instead. Usually a issue is that other teams are doing waterfall and do not have enough information (as their project is in "requirement gathering phase") to support the one and only Scrum team.
  5. The organization follows the Book and wonders "what happened to the self-organizing team". The organization rejects to lead and facilitate and tells the team to "go and figure it out". Cross-functionality is not approved as the original goal was to do "pilot first" to see if Scrum works. (Yeah yeah, they are breaking one of the rules of Scrum: cross-functional teams... but hey, they started from Conway's Law, what do you expect)
  6. One of the following happens:
    1. Team turns to anti-Scrum, they do not like it as it just brings all the problems to them and makes them endless problem-solving task force
    2. Organization drops Scrum - "It does not work for us"
    3. Team starts hating organization - "Organization does not support us"
    4. ..
So how to avoid this pitfall? Simple, when you are piloting or trying out Scrum, do it with cross-functional (truly) team. If you are not able to do that, try it with traditional team but pay attention that this is an issue that you will face. If you do not face it, then somebody is hiding something.

One more note, as a manager do not ask the team to go and figure everything out - they may do it, but you will not have transparency anymore as the team does everything under the hood. Impediment should be raised when team faces problems that are created by organizational boundaries. I have seen teams applying "Go and See" (Toyota Way) and fixing everything ... and over a time totally lost their focus as they do not know anymore what is their responsibility and thus not raising anymore impediments. This may or may not be real life example:

Development team was asked to develop a piece of software and "put it in production". The team maintaining the production system was not involved and they were "too busy" to support the development team so the development team (as result of self-organizing) bought their own hardware, setup "production like" environment and started operating that as "production environment". All this, without the "production system team" knowing anything about it.

Imagine what would be the result of doing this with several development teams - you would have as many "production systems" as you have development teams. Ouch.

Anyway, pay attention to your Scrummers ... till next time.

Tuesday, March 4, 2008

Exercising TDD with a Scrum team

Quite recently I was in charge of TDD exercise for a Scrum team at my customer. Some team members had quite extensive experience about TDD, some didn't have any experience at all. I find the setting pretty interesting and eventually the exercise turned out to be more about team building than about TDD.

Every developer has their view about development cycle (coding, compiling, testing etc) and people tend to stick their own way - even when told to try something different. Here is my setup for the exercise:


Team to learn apply TDD


2 days


  • Reserve a laptop with empty Eclipse project, JUnit configured
  • Reserve a meeting room for the days
  • Team available for the days
  • Material for exercise


  • Marko will give the exercise and answer any questions about the problem at hand (10 minutes)
  • 2 developers will pair at the laptop, rest of the developers will review the implementation all the time
  • We will check up the status every hour together, we can change the pairs if team is feeling so


  • Implementation pair will all the time say out loud what they are about to do and then do it, THINK OUT LOUD
  • Do The Simplest Thing That Could Possibly Work
  • Everything MUST be implemented test-first
  • Remember You Aint Gonna Need It
  • No more than 10 minutes design allowed (whiteboard)
  • Reviewers can only ask question "Why are you implementing it like that?" or similar, reviewers cannot tell what the implementing pair must do, decisions are done at the laptop

Changing pairs early on really helped as less experienced TDDers saw the more experienced TDDers in action. Team felt exhausted after the first day and there were some questions in the air about productivity of the approach compared to other approaches.

Second day was a bit different. Tests were slowing developers down and design issues became obvious. Parts that were not refactored early on started bugging developers so atleast one of the goals were achieved: team noticing that refactoring is a must. Another interesting finding for the team was that the pragmatic approach of "not thinking too much of a head in the implementation itself" requires great discipline in planning the tests in first place. Soon team started questioning themselves: "So what should I test exactly and why" before coding anything at all.

Sometimes team found themselves stuck on algorithm design and we had to call timeout every now and then. I think it is very important to have the facilitator telling the team that "now the time is up, lets try to test first, code and then see if the design is good - if not, then we atleast know a bit more about the problem".

After the second day we had some working software and every team member had tried to do TDD. Some members had questions still about the productivity but everyone agreed that TDD with merciless refactoring can lead to good designs (once you also do "refactoring in the large" at whiteboard). However, doing good test cases is hard for beginners as they probably are not too much familiar with mocking nor thinking test-first.

Interesting exercise - I as a coach learned also quite a bit how to improve guidance and handle different people during the exercise - we are in people business after all.

Are you interested to learn more or even have a TDD exercise for your developers/team? Do not hesitate to contact me if you are :)

Tuesday, January 15, 2008

Tired but Happy - XP2008 Experience Report Done

I and Ari Tanninen finally got our experience report done. We went trough several iterations as we had so much to say and so little number of pages to convey our message. Anyway, I feel that we finally managed to point out the essential learnings and hopefully our report will get approved.

Later on we have received emails form some developers having similar problems on their agile projects.

Thanks for James O. Coplien and Pekka Abrahamsson for sparring us.