Software Development Today

Story Points Considered Harmful - Or why the future of estimation is really in our past...

noreply@blogger.com (Vasco Duarte) — Wed, 25 Jan 2012 09:08:00 +0000

This article is the companion to a talk that myself and @josephpelrine gave at OOP 2012.

We have a lot to learn from our ancestors. One that I want to focus on for this post is Galileo.
Galileo was what we would call today a techie. He loved all things tech and was presented an interesting technology that he could not put down. Through that work he developed optic technology to build first a telescope and later a microscope.
Through the use of the telescope and other approaches he came to realize and defend the Heliocentric view of the universe: the Earth was not the center of the Universe, but rather moved around the Sun.
This discovery caused no controversy until Galileo wrote it down and apparently discredited the view held by the Church at that time. The Church believed and defended that the Universe was neatly organized around the Earth and everything moved around our lanet.
We now know that Galileo was right and that the Church was - as it often tends to be with uncritical beliefs - wrong. We now say obviously the Earth is round and moves around the Sun. Or do we...

The Flat Earth Society

Actually, there are still many people around (curious word, isn't it?) the planet that do not even believe that the Earth is round! Don't believe me? Then check The Flat Earth Society.

The fact that is that even today many people hold uncritical beliefs about how our world really works. Or our projects in the case of this post...

Estimation soup

We've all been exposed to various estimation techniques, in an Agile or traditional project. Here are some that quickly come to mind: Expert Estimation, Consensus Estimation, Function Point Analysis, etc. Then we have cost (as opposed to only time) estimation techniques: COCOMO, SDM, etc. And of course, the topic of this post: Story Point Estimation.
What do all of these techniques have in common? They all look towards the future!
Why is this characteristic important?

The Human condition

This characteristic is nt because looking at the future is always difficult! We humans are very good at anticipating immediate events in the physical world, but in the software world what we estimate is neither immediate, nor does it follow any physical laws that we intuitively understand!
Take the example of a goal-keeper in a football (aka soccer) match. She can easily predict how a simple kick will propel the ball towards the goal, and she can do that with quite a high accuracy (as proven by the typically low scores in today's football games). But even in soccer, if you face a player like Maradona, or Beckham, or Crisitiano Ronaldo it is very difficult to predict the trajectory of the ball. Some physicists have spent considerable amount of time analyzing the trajectory of Beckham's amazing free kicks to try to understand how the ball moves and why. Obviously a goal-keeper does not have the computers or the time to analyze the trajectory of Beckham's free kicks therefore Beckham ends up scoring quite a few goals that way. Even in football, where well-known physics laws always apply it is some times hard to predict the immediate future!
The undisputed fact is that we, humans are very bad at predicting the future.
But that is not all!

This is when things get Complex

Lately, and especially in the agile field we have been finding a new field of study: Complexity Sciences.
A field of study that tries to identify rules that help us navigate a world where even causality (cause and effect) are challenged.
An example may be what you may have heard of, the Butterfly effect: "where a small change at one place in a nonlinear system can result in large differences to a later state".
Complexity Sciences are helping us develop our own understanding of software development based on the theories developed in the last few years.
Scrum being a perfect example of a method that has used Complexity to inspire and justify its approach to many of the common problems we face in Software development.
Scrum has used "self-organization", and "emergence" as concepts in explaining why the Scrum approach works. Here's the problem: there's a catch.

Why did this just happen?

In a complex environment we don’t have discernible causality!
Sometimes this is due to delayed effects from our actions, most often it is so that we attribute causality to events in the past when in fact no cause-effect relationship exists (Retrospective Coherence). But, in the field of estimation this manifests itself in a different way.
In order for us to be able to estimate we need to assume that causality exists (if I ask Tom for the code review, then Helen will be happy with my pro-activeness and give me a bonus. Or will she?) The fact is: in a Complex environment, this basic assumption of the existence of discernible Causality is not valid! Without causality, the very basic assumption that justifies estimation falls flat!

Solving the the lack of internal coherence in Scrum

So, which is it? Do we have a complex environment in software development or not? If we do then we cannot - at the same time - argue for estimation (and build a whole religion on it)! In contrast, if we are not in a complex environment we cannot then claim that Scrum - with it’s focus on solving a problem in the complex domain - can work!
So then, the question for us is: Can this Story Point based estimation be so important to the point of being promoted and publicized in all Scrum literature?
Luckily we have a simple alternative that allows for the existence of a complex environment and solves the same problems that Story Points were designed (but failed to) solve.

The alternative prediction device

The alternative to Story Point estimation is simple: just count the number of Stories you have completed (as in "Done") in the previous iterations. They are the best indicator of future performance! Then use that information to project future progress. Basically, the best predictor of the future is your past performance!
Can it really be that simple? To test this approach I looked at data from different projects and tried to answer a few simple questions

The Experiment

Q1: Is there sufficient difference between what Story Points and ’number of items’ measure to say that they don’t measure the same thing?
Q2: Which one of the two metrics is more stable? And what does that mean?
Q3: Are both metrics close enough so that measuring one (number of items) is equivalent to measuring the other (Story Points)?

I took data from 10 different teams in 10 different projects. I was not involved in any of the projects (I collected data from the teams directly or through requests for data in Agile-related mailing lists). Another point to highlight is that this data came from different size companies as well as different size teams and projects.
And here's what I found:

Regarding Question 1: I noticed that there was a stable medium-to-high correlation between the Story Point estimation and the simple count of Stories completed (0,755; 0,83; 0,92; 0,51(!); 0,88; 0,86; 0,70; 0,75; 0,88). With such a high correlation it is likely that both metrics represent a signal of the same underlying information.
Regarding Question 2: The normalized data (normalized for Sprint/Iteration length) has similar value of Standard Deviation(equally stable). Leading me to conclude that there is no significant difference in stability of either of the metrics. Although in absolute terms the Story Point estimations vary much more between iterations than the number of completed/Done Stories
Regarding Question 3: Both metrics (Story Points completed vs Number of Stories completed) seem to measure the same thing. So...

At this point I was interested in analyzing the claims that justify the use of Story Points, as the data above does not seem to suggest any significant advantage of using Story Points as a metric. So I searched for the published justification for the use of Story Points and found a set of claims in Mike Cohn's book "User Stories Applied" (page 87, first edition):

Claim 1: The use of Story points allows us to change our mind whenever we have new information about a story
Claim 2: The use of Story points works for both epics and smaller stories
Claim 3: The use of Story points doesn’t take a lot of time
Claim 4: The use of Story points provides useful information about our progress and the work remaining
Claim 5: The use of Story points is tolerant of imprecision in the estimates
Claim 6: The use of Story points can be used to plan releases

This these claims hold?

Claim 1: The use of Story points allows us to change our mind whenever we have new information about a story

Although there's no explanation about what "change our mind" means in the book, one can infer that the goal is not to have to spend too much time trying to be right. The reason for this is, of course, that if a story changes the size slightly there's no impact on the Story Point estimate, but what if the story changes size drastically?
Well, at this time you would probably have another estimation session, or you would break down that story into some smaller granularity stories to have a better picture of it's actual size and impact on the project.
On the other hand, if we were to use a simple metric like the number of stories completed we would be able to immediately assess the impact of the new items in the progress for the project.
As illustrated in the graph, if we have a certain number of stories to complete (80 in our example) and suddenly some 40 are added to our backlog (breaking down an Epic for example) we can easily see the impact of that in our project progress.
In this case, as we can see from the graph, the impact of a story changing it's meaning or a large story being broken down into smaller stories has an impact on the project and we can see that immediate impact directly in the progress graph.
This leads me to conclude that regarding Claim 1, Story Points offer no advantage over just simply counting the number of items left to be Done.

Claim 2: The use of Story points works for both epics and smaller stories

Allowing for large estimates for items in the backlog (say a 100SP Epic) does help to account in some way for the uncertainty that large pieces of work represent.
However, the same uncertainty exists in any way we may use to measure progress. The fact is that we don’t really know if an Epic (say 100 SPs) is really equivalent to a similar size aggregate of User Stories (say 100 times 1 SP story). Conclusion: there is no significant added information by classifying a story in a 100 SP category which in turn means that calling something an "Epic" is about the same information as classifying it as a 100 Story Points Epic.

Claim 3: The use of Story points doesn’t take a lot of time

Having worked with Story Points for several years this is not my experience. Although some progress has been done by people like Ken Power (at Cisco) with the Silent Grouping technique, the fact that we need such technique should dispute any idea that estimating in SP’s "doesn’t take a lot of time". In fact, as anybody that has tried a non-trivial project knows it can take days of work to estimate the initial backlog for a reasonable size project.

Claim 5: The use of Story points is tolerant of imprecision in the estimates

Although you can argue that this claim holds - even if the book does not explain how - there's no data to justify the belief that Story Points do this better than merely counting the number of Stories Done. In fact, we can argue that counting the number of stories is even more tolerant of imprecisions (see below for more details on this)

Claim 6: Story points can be used to plan releases

Fair enough. On the other hand we can use any estimation technique to do this, so how would Story Points be better in this particular claim than any other estimation technique? Also, as we will see when analysis Claim 4, counting the number of Stories Done (and left to be Done) is a very effective way to plan a release (be patient, the example is coming up).

Claim 4: The use of Story points provides useful information about our progress and the work remaining

This claim holds true if, and only if you have estimated all of your stories in the Backlog and go through the same process for each new story added to the Backlog. Even the stories that will only be developed a few months or even a year later (for long projects) must be estimated! This approach is not very efficient (which in fact contradicts Claim 3).
Basing your progress assessment on the Number of Items completed in each Sprint is faster to calculate (number of items in the PBL / velocity in number of items Done per Sprint = number of Sprints left) and can be used to provide critical information about project progress. Here's a real-life example:

The real-life use of a simpler metric for project progress measurement

In a company I used to work at we had a new product coming to market. It was not a "first-mover" which meant that the barrier to entry was quite high (at least that was the belief from Product Management and Sales).
This meant that significant effort was made to come up with a coherent Product Backlog. The Backlog was reviewed by Sales and Pre-Sales (technical sales) people. All agreed, we really needed to deliver around 140 Stories (not points, Stories) to be able to compete.
As we were not the first in the market we had a tight market window. Failing to meet that window would invalidate the need to enter that market at all.
So, we started the project and in the first Sprint we complete 1 single Story (maybe it was a big story -- truth is I don't remember). Worst, in the same period another 20 stories were added to the Product Backlog. As expected, the Product Management and Sales discovered a few more stories that were really a "must" and could not be left out of the product.
The team was gaining speed and in the second Sprint they got 8 stories to "Done". They were happy. At the same time the Product Manager and the Sales agreed to a cut-down version of the Product Backlog and removed some 20 stories from the Backlog.
After the third sprint the team had achieved velocities of 1 (first Sprint), 8 (second) and 8 (third). The fourth sprint was about to start and the pressure was high on the team and on the Product Manager. During the Sprint planning meeting the team committed to 15 new stories. This was a good number, as a velocity of 15 would make the stakeholders believe that the project could actually deliver the needed product. They would need to keep a velocity of 15 stories per sprint for 11 months. Could they make it?

The climax

As the fourth sprint started I made a bet with the Product Manager. I asked him how many items he believed that the team could complete and he said 15 (just as the team had committed to). I disagreed and said 10. How many items would you have said the team could complete?
I ask this question from the audience every time I tell this story. I get many different answers. Every audience comes up with 42 as a possible answer (to be expected given the crowds I talk to), but most say 8, 10, some may say 15 (very few), some say 2 (very few). The consensus seems to be around 8-10.
At this point I ask the audience why they would say 8-10 instead of 15 as the Product Manager for that team said. Obviously the Product Manager knew the team and the context better, right?
At the end of the fourth sprint the team completed 10 items, which even if it was 20% more than what they had done in previous sprints was still very far from the velocity they needed to make the project a success. The management reflected on the situation and clearly decided that the best decision for the company was to cancel that product.

Story Points Myth: Busted!

That company did that extremely hard decision based on data, not speculation from Project Managers, not based on some bogus estimation using whatever technique. Real data. They looked at the data available to them and decided to cancel the project 10 months before its originally planned release. This project had a team of about 20 people. Canceling the project saved the company 200 man-month of investment in a product they had no hope of getting out of the door!
We avoided a death-march project and were able to focus on other more important products for the company's future. Products that now bring in significant amount of money!

OK, I get your point, but how does that technique work?

Most people will be skeptical at this point (if you've read this far you probably are too). So let me explain how this works out.
Don't estimate the size of a story further than this: when doing Backlog Grooming or Sprint Planning just ask: can this Story be completed in a Sprint by one person? If not, break the story down!
For large projects use a further level of abstraction: Stories fit into Sprints, therefore Epics fit into meta-Sprints (for example: meta-Sprint = 4 Sprints). Ask the same question of Epics that you do of Sprints (can one team implement this Epic in half a meta-Sprint, i.e. 2 Sprints?) and break them down if needed.

By continuously harmonizing the size of the Stories/Epics you are creating a distribution of the sizes around the median:

Assuming a normal distribution of the size of the stories means that you can assume that for the purposes of looking at the long term (remember: this only applies on the long term, i.e. more than 3 sprints into the future) estimation/progress of the project, you can assume that all stories are the same size, and can therefore measure progress by measuring the number of items completed per Sprint.

Final words

As with all techniques this one comes with a disclaimer: you may not see the same effects that I report in this post. That's fine. If that is the case please share the data you have with me and I'm happy to look at it.
My aim with this post is to demystify the estimation in Agile projects. The fact is: the data we have available (see above) does not allow us to accept any of the claims by Mike Cohn regarding the use of Story Points as a valid/useful estimation technique, therefore you are better off using a much simpler technique! Let me know if you find an even simpler one!

Oh, and by the way: stop wasting time trying to estimate a never ending Backlog. There's no evidence that that will help you predict the future any better than just counting the number of stories "Done"!

Photo credit: write_adam @ flickr

Kanban vs Scrum, the ultimate fight? Don't think so, here's why:...

noreply@blogger.com (Vasco Duarte) — Fri, 25 Nov 2011 14:47:00 +0000

Wow, what a week! A BIG post on Kanban by Scrum evangelist @jcoplien litterally put the blogosphere (and twittersphere on fire!).

It is good to have these family fights in the Agile family once in a while. As a life-philosopher once said: "These things gotta happen every five years or so, ten years. Helps to get rid of the bad blood".

But what are the differences between Kanban and Scrum, really? What are they?

Here's my take on the differences:

Kanban innovation

Kanban is, from it's origin a more systematic approach to measuring, visualizing and following up work in a "system" (one team, many teams, a company you name it). Thanks to the work by the Poppendiecks, David Andersson and Don Reinertsen (and others I'm sure) a pretty interesting and innovative economic framework as been put into the software process development lingo. Cost of Delay, Queues, optimize the whole, etc.
This economic framework is, in my view, the major innovation that Kanban proponents bring to the table. This was to be expected as many of the early adopters of Kanban were using Scrum before and felt the need to quantify and analyze some aspects of software development that Scrum did not tackle.

Scrum innovation

Scrum brought to the fore-front of process discussions issues that had never made it to our attention before: Self-organization, people/team dynamics, problem solving within a short cycle with feedback loops in place (Sprint), etc.
The major innovation of Scrum in my view was the introduction of the Socio-technical system of software development as Liker describes it in the Toyota way. Other similar software development processes took some of the ideas that Scrum also took, but shied away from the self-organization at the team level and blocker-removal focus of roles such as the scrum master. Those methods did not last long because the teams felt like puppets instead of adults with the possibility (and responsibility) to produce the best product they could.

Wrap-up

Both Kanban and Scrum brought significant innovations to the software development world. Those are just two types of innovations. There is more coming from the community and instead of focusing only on these two methods (which all of you should experiment with!) we should also look at what else is missing in the software development ecosystem.
My next interest area is "Complex Systems" (Complexity + Systems Thinking) and Management as a profession. I'll be exploring those subjects more and more in the future as a way to complement my use of Kanban *AND* Scrum. I suggest you do the same and find what else is missing in your environment and look for what else is around that could help you complement what you are already using. Here's a suggestion: start with @jurgenappelo's book on Management!

Happy reading, happy learning!

XP2012: The Extreme Challenge

noreply@blogger.com (Vasco Duarte) — Wed, 09 Nov 2011 07:00:00 +0000

"Agile has crossed the chasm" we hear often. But has it really? In the last few years Agile has gone from being "the cousin in the corner that shouts and screams but no one wants to talk to" to being "the famous cousin who everyones wants to talk to". It was not an easy transition, and to be sure there are still many in the Software industry that call that cousin the "bastard child" of software. Need an example? just take a look at the title of this book.

Agile has turned a corner, there's no doubt about that. However, we have also grown as community, and what was the focus of the last 5 years is also being challenged from within. J.B. Rainsberger described the evolution in a very critical as well as prescient way: the future of Agile is XP (the irony is not lost on many, I'm sure).

JB Rainsberger's keynote "The Extreme Decade: Progress, Pain, Paradox" from Agile Eastern Europe on Vimeo.

XP2012 happens in this context and in itself has a challenge of re-inventing the tired old format of Gurus coming to install the faith on the rest of us. Erik Lundh started a project for XP2012 that deserves some attention as well as exposure. XP2012 will be the first conference in a few years to live up to its name *because* of this challenge!

The XP2012 challenge!

The challenge is to do full cycle from Agilehttp://www.blogger.com/img/blank.gif Planning Game or similar to DoneDone deployed into production at least once in a week.

A set of teams of developers will be invited to attend the conference and effectively develop and release software at the conference in one week or less. They will start and end an iteration during the conference. Random people from the audience will use the software in the technical demos (not the team!) to check that everything is working.

So, if you work in a really good Agile team why not take the challenge? Come to XP2012 to *prove* that you can do Agile Software Development just as it should be done!

Photo credit: sanfora @ flickr

Kanban in a networked process -- Visualise the network!

noreply@blogger.com (Vasco Duarte) — Mon, 07 Nov 2011 07:00:00 +0000

It seems that the idea of a work-network instead of work-flow is catching on and I'd like to throw a bit more fuel in that fire!

Knowledge work is not linear! This we have learned from the experiences with failed Waterfall projects. There are things we do over and over again, and there are things we do only once in a project. None of those can easily be predicted. Scrum and Kanban are examples of our quest to distill what we do to the bare essential. Only then can we understand and manage our work.

Scrum does this by strictly limiting the work in progress through the concept of time boxes. The idea is: do something that fits a (reasonably) short timebox, and nothing else. Get that done and released before you go on to the next thing.

Kanban does this by strictly obeying Work In Progress (WIP) limits and establishing a Pull system (instead of push as much content as you can into an iteration). Both have pros and cons which I will not discuss here. http://www.blogger.com/img/blank.gif

But most interestingly, both tackle the flow of our work in a linear fashion. Both Scrum and Kanban assume that some work can "flow" orderly to completion. However that is not the case! In knowledge work we have many loops and re-loops in the process that are hard to visualize and follow. Without visualizing those loops we cannot effectively manage our work!

Jurgen Appelo and Allan Shalloway had (what looks like was) an interesting discussion on the non-linearity of work and consequently on the non-linearity of Kanban boards. Check out Jurgen's and Allan's posts on the subject.

Since I've been experimenting with Personal Kanban for 3 months now I'd like to share some of my own experiences.

The picture below depicts my process boards as they evolved (click for larger images). The initial one was simple and linear, and it did not disclose enough information for me.

The second one was much better in highlighting some of the bottlenecks in my process (waiting for my action, waiting for others action, waiting for meeting), but was still too linear to reflect the work in a way that was useful to visualize.

The final Kanban board is actually what I use now and is a slight modification of the second one. As you can see it depicts the networked nature of my work and therefore also helps me set my WIP limits appropriately (for example why not have many things waiting for meetings?).

A conclusion of mine from the above boards is that it is not possible to set WIP limits without understanding the work (for example what "wait" states do you have in your process). On the other hand, trying to follow the WIP limits you have set will help you visualize those "wait" states as a consequence of the search for sustainable WIP limits

How about you? What are your experiences in using Kanban boards or other visualization techniques to uncover the networked nature of our work? Leave a comment below with a link to your post!

Photo credit: sjcockell @ flickr

Adapting to a different country and culture - a story

noreply@blogger.com (Vasco Duarte) — Wed, 26 Oct 2011 03:01:00 +0000

This is the story of Jerome (names changed to protect the innocent), and his adventures while changing countries for work.

Jerome always wanted to work in another country. He had bought into the whole globalization/Cultural experimentation ideas of the 90's. The economy was growing quite strongly, there was a strong need for IT professionals and he wanted to explore the world.

Armed with a degree and the will to explore he left his country, which was warm and sunny, for Finland. He arrived in the early afternoon of one gray and rainy day. "The prototypical autumn day" - he was told.

"Never mind" - he thought. I can certainly survive a bit of rain and snow. He was met at the airport by a colleague who drove him to this first apartment. Jerome had never seen that apartment but that did not worry him. "How bad could it be?" he thought.
As he pushed his large suit case up the ramp to the apartment, he thanked his colleague for the ride and entered the room. This was the first shock. The apartment was a room, a single room. "Talk about nordic architecture!" he said out loud.

He sat down and appreciated the last few moments of calm before the real battle started. Next morning he would have to visit many offices before his arrival and relocation to Finland could be completed.

Relocation to a new country can be a daunting process for a person. Many new people to interact with, many laws and rules to learn, many things to buy. A whole new life to build! In fact, adapting to a new country can be down right scary. Really scary. However Jerome's employer seemed to be aware of this and had organized for a person to be with him through the "legal" process of relocation. This, Jerome learned, was called a "Relocation Service". "What a great idea!", Jerome thought to himself, "this makes my life so much easier, and already gives me a link to someone I can call in case of an emergency".

So, he went about visiting the "Alien office" (Yes, Jerome was now officially an 'Alien'). "What a way to welcome people, by calling them aliens!". Later he visited the Maistraati, then the bank, then the local phone company and finally the most used relocation service around the world: IKEA!

That night, while reviewing in his mind what had happened during the day he realized that even if much of the communication with the many clerks he met happened in Finnish, all the paperwork was readily available in English. Never for a moment did he feel lost in the paperwork process. Even the web bank (and there was a web bank! -- in 1998!) was in English. Reflecting back Jerome realized that having all the bureaucratic documents in English was one of the most important reasons he felt welcome in his new country. He felt that in this country they were serious about accepting and welcoming people into the society. The barrier was low enough that in retrospect he felt that he would do the same again, if given a chance.

The first barrier was overcome. He was now an official resident of his new country. Next came the integration to the work life, after all work had been the reason for him to move to this new country.

Next was his first day at work. Jerome was apprehensive. he had visited the company offices before during his job interview, but now was his first work day. He entered the office and asked for his manager. After a few minutes waiting, a smiling person came to greet him. Jerome remembered him from the Interview a few months prior to this encounter. He felt immediately at ease.

In the company he was working for the hierarchy was not emphasized, people worked together at all levels and he never felt like an "inferior". He was hired for his knowledge and experience and he felt that his presence was welcome. The fact that he had the support of the relocation service also helped as he did not have to bother which colleagues with questions about the bureaucratic issues and could fully focus on the work at hand. He reckoned that, all in all the relocation service support actually saved him and the company many hours and stress by handling the legal issues and allowing him to focus on work from day 1. This would become even more clear years later when he moved to Germany and did not have that extra support from a relocation services company. But I'm getting ahead of the story. Let's get back to the process of integration to the new culture.

It was now early 1999 and winter had settled in. When he arrived he was warned about winter, and he fully expected cold and snow, but that year was a record year. The boy from down south - where snow meant "no school!" was fully surprised by the -25C winter that year. The snow was another big impact surprise: he had bought some boots that were obviously not fit for Icy roads and spent most of the November/December measuring the temperature of the snow with his lower back. "Auch!"

Getting used to the cold and dark was something that many of his Alien friends struggled with. You can actually see it happening as the level of complaints about culture, bureaucracy and other topics goes up, way up in the winter. Some of the those complaints are justified like the issue with the language learning. No matter how you try if you don't pronounce "kertalippu kiitos" perfectly the tram driver will always reply "and where are you going sir?" - in perfect Oxford English, of course! Language is one of the biggest obstacles to completing the process of adaptation. After many years of attending Finnish courses, Jerome finally learned enough words to confidently order his food in Finnish and not be completely surprised by what was brought to his plate later on.

The first year was gone and one surprise awaited him. One day he got home and saw a letter from the police. "oho" he thought "what now?" After consulting with his colleagues he found out that he had to go to the police to renew his residence permit. This was his first encounter with the local bureaucracy on his own. Would he able to understand what he was told?

Jerome timidly entered the room and saw tens of other "aliens" waiting to be received. Certainly many in the same situation as him. This made him think "why do the police isolate us 'aliens' into a different office? It probably has to do with the efficiency of having all 'alien' issues handled by the same people" he thought. But is this how it really should be? What is the message that his sends to those so called aliens? How does an alien feel to be put into the alien-ghetto like that?

Gladly the Tax Office (verotoimisto) has totally different approach and all tax payers are welcome to any office, despite being an alien. "I much prefer the Tax Office" Jerome thought while at the same time realizing he would never have imagined himself thinking that way.

His preference for the Tax Office was about to grow as later that year he received his first tax return. "It is already pre-filled for me! What a great idea!" Jerome thought while realizing that he would not have to spend endless hours trying to decipher local tax code. "I can get used to this!" he said. This was the first painless tax season of his life! Definitely a plus when considering where to live in the future!

Back to work Jerome could not help but feel that his personality was very much in synch with the way his company was organized. There was a clear purpose and people were encouraged to be autonomous and collaborate across department borders to achieve their common purpose - what a difference to other countries where nothing happens without the boss giving the green light to everything. This focus on autonomy and purpose eased Jerome's integration to the work-place.

Some years later Jerome would receive an offer to move to Germany. He was tempted. Germany's political tradition and strong economic growth were strong attractors, but perhaps the final reason that pushed Jerome to leave Finland was the fact that many companies that he contacted just flat-out refused to hire people who were not native or near native speakers of Finnish. This was in conflict with everything Finnish companies and entrepreneurs were saying publicly! Publicly many companies talked about wanting to go international and about the fact that their companies depended heavily on trade, but when it came to their hiring policies that was not the case! This was 2010! and in Finland we are still hiring people depending on whether or note they speak a language that is probably harder to learn than most of the jobs we hire for! Here's a suggestion: why not have language learning as part of the job? That way we would get highly qualified 'aliens' and would be able to keep them in Finland! But I am digressing now.

Later on Jerome thought about what made his integration at work and in the society harder or easier and he came up this list:

Easier
- Relocation Service support to a new comer
- Low hierarchy and clear-purpose at work
- All bureaucratic processes had been documented in English
- Web / Internet banking
- Pre-filled tax returns
- And... lots of friends, many in the same situation
Harder
- New culture: when to be friendly? When is that just akward? How to make friends? What do people value?
- Dealing with many different authorities / entities (although relocation services helped!)
- Learning a new language (although knowing the language made the integration process easier later on)

Recently Jerome moved to Germany, and he had a chance to go through the same process again, in a new country. Now more experienced with the process of moving he felt confident that he could tackle the challenges ahead. Little did he know!

Upon arrival to Germany he was informed that he had to decide on a health insurance, and fast because his salary could only be paid after that. "Hmmm, they don't make this very basic thing very easy here, do they?" he thought to himself, and went on: "Strike one for Finland with it's universal health care system. In retrospect KELA makes integration much, much easier by having a universal health coverage from the start!"

Jerome decided to register with a national health care provider. He could have registered with a smaller / local health care provider, but he had heard enough horror stories about smaller / local providers that could go bankrupt at any time. Scary stuff for an Alien!. He then had to register as a "legal alien" - to quote Sting's. He went to the local Amt (that's office in German) and registered, not an "alien" but as an Ausländer. Don't know about you, but Jerome felt much better with the term Ausländer, maybe because he did not speak German.

Jerome arrived at the Ausländeramt desk and politely asked "Sprechen Sie Englisch?" - that being all the German that he could muster. The clerk, however, replied "Oh, but we are in Germany. We must speak German." "Strike 2 for Finland" Jerome thought to himself. Struggling with understanding what the clerk was trying to say he was able to successfully register as a resident of the city. "We have to applaud the idea of an open Europe, this is the stuff that makes us happy we pay our taxes. Long gone are the days when we had to sneak through borders illegally to find a work place to our liking. Now we can freely travel and settle with minimal bureaucracy. That is a real tangible benefit to the people! Borders only benefit the powerful who can find legal, and not so legal ways around them."

Political rant aside it was now time to start enjoying life in a new country. Until...

Later that week, Jerome received a letter at home. He had to present himself in the local city office. His registration had a problem... "Oho! I spoke too soon about freedom from borders..."

Jerome reached the office and asked what the issue was about. After he was explained what the issue was he could not believe it. "Really? in the XXI century? We can send a man to the moon but we can't solve a problem like this?" -- he thought to himself.

The issue was that when he completed his original registration, he had used the wrong postal code and therefore he now had to correct it. But the process for that was worthy of a Kafka plot. He would have to drive to neighboring town, register there (with the original date of his initial registration); then he had to come back to the city office and register again with his current address so that his registration could be considered valid! Basically he had to register twice in two different places to finalize his original registration process. "Talk about bureaucracy! Strike 3 for Finland!"

But the situation got worse later on! Jerome received a letter from the local court where he was instructed to pay a fine for not having registered on time in his current municipality! "The nerve" he said out loud as he read the translation from Google translate. "I've now registered 4 times" - he had registered once more when he changed apartments in between these events - "and they have the nerve to tell me that I have not registered on time?" "Strike 4 for Finland!".

After this ordeal Jerome revised his table of things that make your integration easier or harder:

Easier
- Relocation Service support to a new comer
- Low hierarchy and clear-purpose at work
- All bureaucratic processes had been documented in English
- Web / Internet banking
- Pre-filled tax returns
- And... lots of friends, many in the same situation
Harder
- New culture: when to be friendly? When is that just akward? How to make friends? What do people value?
- Dealing with many different authorities / entities (although relocation services helped!)
- Learning a new language (although knowing the language made the integration process easier later on)
- Bureaucracy!

The end!

Photo credit:

Rob Young @ Flickr
mac_filko @ Flickr
Giorgos @ Flickr

Dude! Where's my manager? or Why you should attend LESS2011

noreply@blogger.com (Vasco Duarte) — Fri, 16 Sep 2011 04:44:00 +0000

Many teams start their agile transition from the "developer-side". This is quite normal, developers (coders and testers) feel the pain more than others because they need to actually get the product/system finished. But by focusing on developers, aren't we missing something? Aren't we forgetting that many of the consequences we so detest come from un-informed decisions by people higher in the chain?

In my experience many agile transitions fail by not involving managers in the process. Sure, it is possible to change how your team works with minimal involvement from your manager, but at some point the team is constrained more by management decisions than actual technical practices or even understanding of the product.

I remember a story of a team that was on their path to agile adoption, but could not progress further because management had decided that certain tools should be used. The usual explanations were given: "IT can only support one tool", "we need to harmonize our tool landscape", etc. Whatever the reason for the decision what we can say is that in this case management had a real - and negative - impact on the team's capability to deliver working software.

Sure we can go rogue and use our own tool chain "hidden" from IT and our manager (and many teams have done that), but that is not a long term strategy. Sooner or later we will bump again against a set of decisions that will hinder us from progressing.

I believe we need a new model for Agile adoption. One that includes the managers, leaders, VP- C-level people in our organizations.

It is this belief that has led me to participate in a project to organize a set of conferences focused on the role of leaders and managers. Last year we organized the first of that set of conferences in Helsinki and named it LESS2010. This year we are continuing that project with LESS2011 in Stockholm.

There are many reasons for you or your manager to attend the LESS2011 conference in Stockholm. From the individual speakers (check-out our keynote line up) to the people you will meet. But If I had to name one reason it is this: Agile and Lean adoptions require our managers to understand the new mindset, and without that we are bound to fail. So, get yourself and your manager to LESS2011 and talk to other managers! Share your experiences and questions and come learn from people that have been facing long lasting agile transitions (the kind that requires management involvement)!

Guest post: Building and scaling a startup - Feature or component teams?

noreply@blogger.com (Vasco Duarte) — Tue, 13 Sep 2011 04:42:00 +0000

There are some really cool startups in Berlin. Last week I met Alexander Grosse (@klangberater) from SoundCloud at ALE2011. Alexander is their VP of engineering and he had been thinking and writing about Feature teams. After reading his article I thought it would be a good and balanced view at that topic that could generate a good (and balanced) discussion on the blog. Alexander kindly agreed to let me publish it, so here it is!

Building and Scaling a startup - the Feature vs Component teams debate

Guest post by: Alexander Grosse from SoundCloud

The first team in a startup is a feature team by default. But as the company grows and you hire more developers, a common question pops up: How do you structure your engineering department when you have more than one team? Two common approaches are teams per component/service/layer or feature teams. This article describes the pros and cons of each approach based on experience.

So you have a startup. Let’s assume for the sake of simplicity it is a consumer facing website done in Ruby on Rails with an underlying database (but this article applies to other kind of startups too). You have around 10-15 employees, of which 6-10 are developers. These developers are one team, some of them concentrate on front-end work, some on the back-end, the mysql database is maintained by a handful of the developers. The team feels like it has reached the natural size limit and is considering splitting into smaller teams. Before discussing team structure let’s first talk about some important goals while scaling up the company.These goals should determine what you do:

Developers should have as much knowledge of the system as possible, so that there is no single point of failure and technical decisions are made with an understanding of the overall system.
There should be common approaches to most technologies like CSS and for some technologies, like databases, specialists are needed.
Communication overhead should be avoided where possible as well as handovers between teams.

Overall there should as much common knowledge as possible but specialists where needed. Let’s first discuss the terms “Feature Team” and “Component Team”, especially in a startup context. The usual definition of a Feature Team is: Feature teams are supposed to be cross-functional groups that focus the software development process in valuable-chunks of work, which normally cross the whole system (vertical slices of the system).[1]

While this sounds good you usually reach pretty fast the team size limit when trying to compose teams which can touch every part of the system. At SoundCloud we currently have 35 engineers working on topics like Android, iOS, Search, Anti Spam, MySQL, Operations, Web Front-end, Back-end and so on. So you can see very easily that if you define seven as an ideal team size, we have difficulties forming teams which can touch every part of the system.

A lot of consultants say that engineers should be able to work on any part of the system, but in reality and especially if you operate under scale, where for example every single SQL query can impact the site, this just does not work. Component Teams are usually defined as horizontal slices of a system, so for example front-end, presentation layer, business logic, database and operations. But I haven’t seen a startup which organizes it’s teams exactly that way. This is usually a team structure big companies choose. But what I’ve seen at a lot of startups is the separation between front-end, backend and operations. There are lot of obvious disadvantages associated with component teams:

Features often touch several teams, this leads to costly handovers
Teams often act as silos and lose sight of the coherency and goals of the product But especially in large organisations component teams also have some advantages, like having dedicated teams for components - like databases - under scale. (please look at [3] for details)

So, we now have two approaches which on the surface both are not applicable for startups either at all or from a certain size on. Reading the post from Vasco Duarte ([4]) clarifies the situation in a very good way. Feature teams are not necessarily defined by their structure, but the most important thing is that a feature team can deliver value to the customer without dependencies on other teams. The reason for that is to reduce handover between teams which usually produces what “waste” is in terms of lean. Citing Vasco: A feature team is not defined by it's structure (being cross-functional), it's defined by it's output! (delivering shippable pieces of the system)[4]

A common anti pattern for the implementation of Feature Teams is (similar to the one mentioned in the article): design is not integrated into front-end teams. This often causes blocked user stories (waste) when design specs are either unclear or during implementation a necessary change in design has been discovered. In reality there is no such thing like having absolutely no dependencies on other teams. So we defined teams, which can work on the vast majority (at least 90%) of the stories in their backlog without needing other teams. How those teams are formed changes over time.

We at SoundCloud did not always have a stable API. So in the beginning front-end and back-end developers were one team until we were able to extract a well defined API, which offered the necessary functionality for all front-end clients (mobile and web). At that point we separated the joint web team as the front-end teams were now enabled to work on the majority of features without involvement of the back-end. Looking back at the start of the article where we defined that we want to have developers as much overall knowledge of the system as possible it seems like the chosen setup at SoundCloud violates that. To achieve a compromise, we encourage developers to rotate through teams. Some developers want to stay in their comfort zone (these are often the specialists mentioned above), some are interested in all parts of the system. As long as half of the developers in a team are aware of what other teams are doing, that team will be fine.

Combine both approaches The question is not so much which formal definition of team to follow. The importance is for teams to deliver the majority of stories in their backlog without depending on other teams. And team composition ought to change over time as the overall software stack matures. Analyze your teams if they can deliver value without depending on other teams (for at least 90% of the features). Do this regularly and team composition changes over time just as architecture does!

Inspired by:
[1] Scaling Lean and Agile Development, Larman, Vodde: Feature team definition on page 153
[2] http://blog.mountaingoatsoftware.com/the-benefits-of-feature-teams
[3] http://scalingsoftwareagility.wordpress.com/2009/07/15/organizing-agile-at-scale-feature-teams-versus-component-teams-part-1/
[4] http://softwaredevelopmenttoday.blogspot.com/2009/07/feature-team-needs-more-than-cross.html

You can find out more about SoundCloud at the Goto conference in Århus. Eric Wahlforss from SoundCloud will be speaking there.

On rewarding and performance systems...

noreply@blogger.com (Vasco Duarte) — Mon, 11 Jul 2011 13:49:00 +0000

The ideas of "pay-for-performance", and it's twin sister "management by objectives" exist to try and increase the performance of a group and ultimately the whole company. The basic idea is: promise them a carrot and they'll work more / better. But is that true? Can a company really perform better by promising people they will get more money if they individually perform better?

It is an appealing though. Instead of working with the people, managers are advised to put the right rewards in place and let people loose. Things will magically work out, or so the theory goes.

Although there is some truth to that, the fact is that this simplistic view of reality hides, or ignores, the deeper impacts of the individual performance reward culture:

First, by placing rewards at the centre of the performance system, the companies shift the conversation to rewards and away from work
Most people feel they perform above average, but reward systems tend to grade people on "the curve". This leads the lower performers to get a higher grade than they deserve (but still lower than they think it should be) and the top performers a lower grade than they deserve because of the need to "follow the curve". This has the notorious effect of leaving everybody unhappy.
Most importantly, the reward mechanisms that focus on individual performance completely miss the fact that a company exists in a complex environment. Especially non-trivial work (like software), is impossible to reduce to a set of repetitive steps. The immediate consequence of this is that, even if all the people perform at their best and get the top evaluation, the company could still totally fail to meet the level of their competitors. The performance of the system (the company) depends on the complex interactions between the different people in the company. If all try to optimize their personal performance, the system as a whole can perform a lot worse.http://www.blogger.com/img/blank.gif

What amazes me is that there are still people who advocate "pay-for-performance" in complex environments like software development.
The fact that we work in a complex environment all but ensures that "pay-for-performance" is at best indifferent to the overall company's performance and at worse an active value detractor for the company.

An additional bonus

Deming and Shewhart proved that in a stable system, trying to change it's performance from the outside can actually reduce the performance of the whole system. Deming called this "tampering": messing about with a system you don't understand (link to Deming and tampering).
"Pay-for-performance" and "management by objectives" are an instance of "tampering". Instead of messing about with a system we don't understand we, as managers, should focus our energy on understanding that system and changing the system through the use of small and controlled experiments.

This is not as easy as it sounds, but is the only way in which managers add value to their companies.

If you still want to have variable salary costs in your company, then use a profit sharing scheme: where everybody shares in on the success and pain, rather than individuals independently. Besides, can you really evaluate a single individual's contribution to the success of the whole company? (Especially when the company is not succeeding and that individual still claims their bonus?)

One question that is raised against the view I tried to explain is: "Fine, but how do I keep top performers? They certainly want to be rewarded by their good work, right?" My answer to this question is that people value many different things. While some people are influenced by short term gains, most people do not act consistently with that hypothesis. There's evidence that people react more consistently with (see this video):

"meaning", i.e., they are more motivated and committed when they feel that their work has meaning; or
"peer-recognition", i.e., people tend to feel more committed and motivated in an environment where their work is appreciated by their peers.

A better way to keep your best people is to work on creating an environment where people's work is recognized by their peers, and the meaning or nexus of that work is clear to everyone.

You, as a manager, have to focus on those things!

Photo credit: L2F1 @ flickr

LESS goes Stockholm for LESS2011, join us there in October

noreply@blogger.com (Vasco Duarte) — Wed, 22 Jun 2011 13:49:00 +0000

Last year I was involved in the organization of a unique conference. LESS2010 was a unique conference because it brought together different communities. We wanted to make sure that people with different points of view would discuss those points of view. The aim was to create a space for sharing ideas from different communities in the hope that new ideas would emerge. And emerge they did!

When the conference was done we had brought together the academic community which is involved in researching Agile adoption in the real world; the Agile community that is day-in-day-out applying Agile ideas in their own places of work; the Lean community and finally the Beyond Budgeting community that is sharing novel ways to manage and lead companies. This year we are doing the same, only better!

LESS goes Stockholm for LESS2011

You can check the details of the conference in the web-site, but here's a hint. We are working again on bringing different communities together!

The tracks that we have chosen are around the topics of Agile, Lean, Beyond Budgeting, Complexity Sciences, Systems Thinking and one topic that we deal with every day: Organization Transformation.

This year the trend is even more clear that LESS2011 is a conference for leaders in R&D organizations. Perhaps the only leadership focused conference in Europe at this point.

I do hope that more of these start happening because that's the next frontier for Agile and Lean adoption in our places of work.

So, I encourage you to submit a paper/session to the conference. Being there and talking to the the people with the experience and ideas is very important for us to continue our day-to-day work with new ideas and fresh energy!

See you in Stockholm!

Agile is about customer delight

noreply@blogger.com (Vasco Duarte) — Wed, 18 May 2011 11:28:00 +0000

Today on twitter I got into an interesting conversation with @jeffpatton. The discussion was about whether Agile, as a family of methodologies and a value system is (or isn't) directed at customer delight.

@JeffPatton's point was that it is not. Here's one of his replies to me on this subject:

Later on during the day I had a face to face conversation with @mvonweiss and tried to crystalize in my mind why I disagreed with @jeffpatton. And the point is this: I believe that one of the core values in Agile is exactly about customer delight.The third value of Agile reads that Customer Collaboration is a preferred way to work in a software project. That customer collaboration is there for a reason.

The idea is that only through dialogue with the customer can we understand their needs. That is achieved by having close and continuous dialogue with the customer and through the delivery of software early and often (see principles 1, 3 and 4, for example). This continuous delivery of a working product builds the feedback loops we need. These feedback loops are directed specifically at providing an opportunity for the customer to interface with the team and help us understand what needs to be changed in order to provide, you guessed it: Customer Delight!

Real customer involvement patterns

Of course, there are many different types of projects that we work on. Custom software, Integration projects, shrink wrapped software, web-sites, etc. All of these projects have different "distances" to the customer (see figure below). But those distances can be bridged with many techniques so that the Agile values and principles are still applied and we can still get feedback early and often.

I've worked on many projects of the shrink-wrapped kind where we have teams working in an organization away from the customers (consumers). In these cases, interacting with "all" customers is impossible. But we already have many techniques that help us understand our customers better even when we can't be in direct contact! For example: customer surveys, usability testing, requirement exploration techniques, user persona development, etc.

Some people in the Agile community have been pushing us to consider these methods, David Hussman (@davidhussman) is but one example, but there are many more (including @jeffpatton, of course).

If @jeffpatton's point is to emphasize the need to consider the customer more fully in Agile projects, then I am in total agreement. But one thing is for sure, Agile methods are much more directed at Customer Delight than many of the other methods available today.

You cannot transition to Agile. Stop and just embrace it!

noreply@blogger.com (Vasco Duarte) — Mon, 16 May 2011 10:44:00 +0000

I am writing this blog post to explore a concept. So bear with me, I'll probably ask more questions than I'll answer.

Why do most Agile fail in our companies (or government organizations for that matter)? My view is that we cannot actually transition from a command and control management paradigm to Agile / Complex management paradigm. The reasons are not fully clear to me, but I believe that it has something to do with the fact that we actually (typically) try to use a pre-determined way to make those transitions happen.

Case in point: When we try to move from Waterfall software development to Agile software development, we will typically draw a plan up for the transition with "steps" or "phases". Those "phases" or "steps" will typically be "stable points" in the evolution of our system (the company or organization). However, the Agile / Complex management paradigm assumes, at its core that software work is complex, therefore there is no predictable causality. The consequence of this is that the "steps" or "phases" in between the command and control paradigm and the Agile paradigm cannot themselves be "stable" in the sense that predictability can be recognized.

By following the argument above I'd state that: transitions fail because we try to move from a command and control paradigm to an Agile / Complex paradigm by applying command and control models. It is impossible to 'move orderly to a complex environment'.

What does it mean in practice for us? Well, for starters we cannot "plan" the transition in the same way we tried to plan our waterfall projects in the past. We can, and should have a goal or an idea of where we want to be. But after that we must embrace the new paradigm, or "Adopt the new Philosophy" as Deming put it. There are no intermediate steps between the "old command and control mindset" and the new "complex / agile mindset".

As this is an idea I'm still developing, I'll probably return to this subject and write some more, but in the meanwhile: what do you think? Does this make sense? What did you get from the above?

Photo credit: Marc Soller @ flickr

Kicking up dust for the Agile Finland 2011-2012 season

noreply@blogger.com (Vasco Duarte) — Fri, 13 May 2011 17:41:00 +0000

A big moment for the Agile Finland community is approaching. On May 25th we’ll get together and select the new Agile Finland Board for the 2011-2012 season.

There are many reasons why it is a big moment. In my opinion it is a big point in our history as a community. Agile Finland was started when Agile was still the ghetto, now Agile is not only out of the ghetto, but it is becoming the dominant software development approach in Finland. Sure, many companies are still going old-skool with their software projects, massively outsourcing the testing function or trying to get huge changes in before releasing a single version, etc. But Agile Software Development is, unmistakably the dominant approach in software development in Finland today.

This leads to an important point for our community. We started Agile Finland as a way to spread knowledge of Agile and support the learning journey that we’ve all been through since 2000. That phase is over. Although we do need to continue to support the spreading of the knowledge about Agile to other communities (like in this example), I feel that this does not need to be our main focus anymore. So I’d like to propose a new focus, a new phase for our growing community.

Concrete proposals for the next Agile Finland Board season

I propose that the next Agile Finland board should focus on helping the community share, expand and develop new knowledge in the field of Software Development and Product Development with focus on some key areas of practice. For this I propose the following structure in the Agile Finland activities for the next year:

Agile Finland must define what areas of focus it will have (see suggestion below) and arrange specific activities that emphasize those areas of focus. For that I propose the following areas:
Programming and testing in an Agile Software Development environment. This area of focus would cover the technical development of our community in programming and testing tasks. The Software Craftsmanship movement is a good source of inspiration for the content to be shared and developed in this area, but we also need to create an atmosphere of cooperation and sharing with the excellent testing professionals we have in Finland and in the AF community. The technical area of focus is an area where there is clearly a need for a better offering in our community, and Agile Finland has the network and expertise to start that work.
Project Management in an Agile Software Development environment. This area of focus would cover the Project concept, it’s applicability to different types of work and product development environments. We know that the traditional Project Management is not compatible with many Software Development environments, but we need to explore alternatives, share and expand our knowledge on what has worked in the past as well as the experiments that are going on right now. In this area of focus, I believe we must build a bridge with the already active Project Management communities(PMI, PRY). We have a lot to learn from each other.
Leadership and Management. This area of focus was already in the activities started during last year (see ACLA), but we need to continue to develop those activities. Many of the challenges we face today are because the traditional leadership and management models have failed in the era of knowledge work (like software and other areas). We need to share what is being tested in the world, bring in some world-class thought leaders in this area to enlarge the pool of knowledge for managers and leaders in our local community.

Conclusion

By focusing on these three areas (Programming and Testing, Project Management, Leadership and Management) I am suggesting that Agile Finland should also focus on specific activities for it’s major interest groups. It is not enough to arrange one to three generic networking events during the year, we need to start taking concrete actions for the development of our community. I hope that this post contributes to a discussion around how we could do that.

Photo credit: Patrick Keogh @ flickr

ALE Network in active discussion in the Agile Finland mailing list

noreply@blogger.com (Vasco Duarte) — Tue, 12 Apr 2011 05:00:00 +0000

Last Friday looked to be normal day. Too much work, too little time. But then it got better.After I sent an email to the Agile Finland mailing list announcing the Helsinki event to discuss the ALE Network vision, a lot of replies came in. It was a very active discussion.

Below is my (necessarily) short summary of what I saw and learned from that discussion.

Many issues were discussed in that email exchange from Motivations to how it can help energize the Agile Finland community. Here's a summary of the topics discussed as well as my view on how ALE network can help us in the European context:

What are some of the motivations for ALE?

As is to be expected in any network or community of people, there are wildly varying motivations. As we start to discuss the importance/significance of ALE for each of the local communities as well as for the individuals many view points surface.

I'd like to express my motivations: I see that we have many thriving Agile communities in Europe. I've been in direct contact with some of the nearby communities such as Ukraine, Estonia, Latvia and Sweden as well as Spain and Portugal. I see the huge amount of energy and willingness to explore the Agile values and principles in real Software work.

I also see many people that are extremely eager to learn and have a lot to share. These same people, for many reasons, are not traveling around Europe and learning from others outside their local communities. They participate mainly in the local events, get together in User Groups or local Agile community meetings (like we have the Agile Dinners in some Finnish cities).

These are people that want to be in contact with people outside their local communities but cannot do so for a variety of reasons. ALE can help bring these communities together, help people bridge the border gaps and get in touch with other practitioners to share and learn about their different experiences.

In Agile Finland we have had the luck of having people who have successfully helped our community bridge this gap, specifically through organizing the Scan-Agile conference. Together as a Europe-wide network we can do the same for the other local communities. How? Here imagination is the only limit :)

What is ALE's Vision?

Right now there are many different Visions for what ALE should/could/must be. In Helsinki we will talk about these different views on April 20th. Check the info here and remember: RSVP is mandatory!

While I do believe that the main focus of ALE should be to help the local communities thrive, that can be done in many ways and with different Visions.
I explicitly choose to listen to how our community's Vision develops. My goal is to help us collect that as a common Vision, one that we all share to some extent. Hence why I've decided not to write about my Vision at this point. I will of course talk about it at the event on April 20th along with all of those that can make it.

What is the link between Agile Finland and ALE Network?

The links between these networks are people. The people that participate in both networks are the effective links between these two networks.

In my view Agile Finland (AF) has a place as a stand alone organization, it is not dependent on ALE Network, but the people in AF can actively contribute to the ALE Network in many ways, and some of us are already active in the European scene.

As far as I am concerned ALE is an independent entity from Agile Finland, but benefits from the effort and contribution of the Agile Finland members that participate in both networks.

Purpose of the Open Space session on April 20th

On April 20th, our goal is to stimulate a face-to-face discussion about the possible contribution we can make as a community to the ALE Network, as well as what we think ALE Network should focus on.
What I would expect to see after the April 20th session is a collection of ideas of what we want ALE to be as well as what we don't want to contribute to. These ideas will then be discussed by a group of people from all over Europe in Madrid during XP 2011, where the ALE Network Vision will be iterated.

Interlude

These were only some of the many topics we discussed in the Agile Finland mailing list. The discussion was long and active. You can check the full archive here.

No doubt we will talk more about ALE network and the role of Agile Finland community, that dialogue is needed. We are a community after all: "one for all and all for one"!

Photo: Achraf AMINE @ flickr

What would a European Agile comunity look like? #ALEnetwork

noreply@blogger.com (Vasco Duarte) — Fri, 08 Apr 2011 06:42:00 +0000

Many of us have been involved in many different communities. Agile Finland for a start. But also other communities: our local kindergarten or school parent's group, the school or kindergarten itself; the local neighbors; the apartment building executive board ("hallitus" in Finnish), etc.

In fact, if we look back in history all of our history has advanced due to the association of different people, sometimes with similar goals, but much more often with different and sometimes only slightly related goals. The greatest example of all is our very own society which exists and evolves because of the myriad of small communities that interact with each other to achieve a quasi-infinite number of goals.

Why do we need an European Agile community then? Aren't we already in so many different communities? Why one more?

There are many answers to these questions, but perhaps one that is interesting because it is a true story is the story of Peter the Great (or Pyotr Alexeyevich Romanov for his friends). Peter went around Europe as a young man collecting knowledge, although his initial intentions were to gather support for war (who didn't, in those times?) he finally ended up touring Europe to learn. He worked in Shipyards, visited Greenwich, learned how to build cities by visiting Manchester (no kidding!). Peter's journey was one of learning by sharing. He learned by interacting with others, collecting knowledge from many sources and ultimately creating his own view of the world which he implemented back home. Some of it was cargo-cult, but some of it led to lasting changes that we can still see today.

The core of Peter's story, however, is that he understood that the world was larger than his own Empire, he understood that he had a lot to learn and took a step (literally) towards the communities that were surrounding him. Learned from them and became a better person for it.

How about you? Do you want to become a better Agilist? Join us in the ALE network Vision Helsinki event where we will explore the questions above and more! Check out the details and register here. NOTE: registration is mandatory and seats are limited.

Photo credit: ibnhusin @ flickr

Patterns of Agility, talk at Scan-Agile 2011 and Agile Riga Day 2011

noreply@blogger.com (Vasco Duarte) — Thu, 03 Mar 2011 06:30:00 +0000

Some time ago I wrote a post here about Patterns we can identify in projects and how they relate to the life-cycle model in use for the project.

Some patterns are definitely signs of an Agile project (release working software at the end of every *very* short iteration for example). Other patterns are clear signs that we are in the presence of a waterfall project (writing never ending power point presentations to prepare a project approval and then rushing with the actual coding).

There was quite a lot of good feedback on that post and @lebedev_dmitry even suggested that I present a talk at Agile Riga Day on the same subject.

So I prepared a presentation to explore this theme. You can check out the presentation in my slideshare page.

But I felt that a presentation was not enough. Yes, we need to introduce the idea of patterns and how to recognize the context in your project, but we also need to reflect on the actual patterns we see in our projects. So I decided to end the presentation with a short reflection/retrospective exercise: the Agility Score Sheet.

Try it out. Read the presentation, then take the sheet and score your project. What did you find? What thoughts came to your mind after completing the exercise? What will you change tomorrow?

Feel free to edit the Agile Score Sheet. I've opened it so that anyone with this link can read it and edit it directly.

PS:
If you attended Scan-Agile 2011, you can rate my talk here
If you attended Agile Riga Day 2011, you can rate my talk here.

Photo credit: Bill Gracey @ flickr

Another job opportunity for 31337 h4x0rs that love testing!

noreply@blogger.com (Vasco Duarte) — Tue, 22 Feb 2011 07:30:00 +0000

F-Secure is hiring! And they have some interesting positions as well. Check out this one:

People who have experience in “SW Engineer in Test” type of a role. This is a fairly new role and not well established in Finland. The discipline is young and top notch professionals rare. An excellent niche to put yourself into in the job market.

This role is key in the setup for continuous integration. At F-Secure we test 1000's of unique system builds in each sprint. Results show on radiators in each team room immediately. Top that, if you can. For instance, nothing prevents testers to check out the product code, find the problem and alone or with the team fix it. And this does happen!

This is a great way of developing software. The feeling of community is tremendous, the drive is inspiring and the results exceptional.

Hellow World, wake up, and smell the raw unrefined source code.

Photo credit: roland @ flickr

Job opportunity for awesome people in Tampere, Finland

noreply@blogger.com (Vasco Duarte) — Sat, 19 Feb 2011 18:51:00 +0000

Our good friends at Leonidas are hiring. Not, not the chocolate people, the software people ;)

The company looks very interesting. I especially liked the "one week from idea to prototype" service they have. A true agile service! :)

Take a look at their web-site and check if you are one of the awesome people they are looking for!

Judging by their art work on the site, it will probably bee a good preparation to review the movie 300 before going for an interview! Enjoy!

Photo credit: anthonykvalley @ flickr

To all my friends and colleagues at Nokia, my contribution

noreply@blogger.com (Vasco Duarte) — Sun, 13 Feb 2011 11:47:00 +0000

Without a doubt many of you have read the news about Nokia taking Windows Phone 7 as their main Smartphone platform.

That decision by Nokia has a tremendous impact in my local software community: Finland. Nokia mobile phones (as it was known before) has always been a major employer of software development professionals in Finland where I live. It is expected that this decision will significantly reduce the number of software professionals that Nokia employs. This is nothing short of a blow to the local software community. However, this is not a tragedy. Far from it. Ironically there's never been a better time for software professionals in Finland. Many industries are adopting software as a key part of their products. From forestry to fleet management to network elements to health care, you name it.

This is why I've decided to start posting interesting software related job opportunities. I want this to be about the software industry globally, not just Finland. But, of course also about opportunities in Finland. If you are interested in posting the openings you have in this blog just drop me a line at SoftwareDevelopmentToday@gmail.com. Here's what you can gain:

This blog is read weekly by ~200 and monthly by ~790 unique visitors, from mostly Finland, United States, United Kingdom, India and Brazil. As this is a blog for software professionals, you will be reaching people that are already in this industry, but better yet you will be reaching early adopters who are interested in improving the way software is developed. This can be a competitive advantage for your company!

NOTE: i will not charge for these posting but I do reserve the right to select which ones I post, so make them interesting and as buzzword free as possible. Remember you are reaching a crowd that already knows a lot about software development, you want to focus on making your job opening as enticing as possible interesting for this crowd.

If you are looking for fresh new opportunities you get a filtered list of job openings. I'll personally read all of the posts and contact the companies to make sure they are legit and not just a fake interesting post.

So, I hope this is a contribution to the next career path for all my friends and industry colleagues at Nokia. I wish you the best of luck!

Photo Credit: streetart @ flickr

SWAT Team, a Pattern for Overloaded, Multi-project Organizations

noreply@blogger.com (Vasco Duarte) — Fri, 07 Jan 2011 11:49:00 +0000

We all have seen it in our projects. Some teams are overloaded and can't deliver what we need while others are not so busy and could even tackle more work if there was a need for that.

This type of partial overloading is easily understood if we picture the work flow as a network of nodes. The throughput of the overall organization is limited by the nodes that are overloaded, even if not all nodes are overloaded.

The situation is even worse in multi-project organizations where many projects compete for staff time which leads to optimize for staff-loading optimization and ultimately to overloading the organization by creating certain bottlenecks that block all work for one or multiple projects.

Why does this happen? and How to tackle it?

Below is a short pattern description of one of the possible ways in which we can tackle this type of situations.

Problem and Contribution

As explained above, the problem symptoms are typically that some teams are overloaded and cannot take on more work. This work is essential to meet a particular deadline or to get a project started.

Other symptoms may include:

Line Managers requesting more resources on a regular basis.
Long meetings with two or more people where the allocation of one person is discussed at great length.
Projects are started officially but no progress is achieved due to ongoing projects having higher priority.

A typical result is that some project gets delayed or a project that is started gets starved for resources. The problem can generically be defined as a resource allocation problem. In computer science literature this is also sometimes called a Scheduling problem.

In this pattern we outline a simple strategy to tackle this project starvation in an overloaded multi-project organization.

Context

This pattern is applicable to any organization that has several teams and/or multiple projects (typically a non trivial number) and where the symptoms can be seen, but the root cause cannot easily be found or solved.

An example is a large software development organization where many teams contribute to multiple parallel projects. In these cases it is perhaps possible to find the root cause for the delays and starvation of competing projects, but it is either not practical (no people with enough knowledge of the overall organization or no people with experience in large complex network management) or not economically feasible (the time and money it would take to find out the root cause can better be used applying a simple pattern like this).

Forces

In an organization Line Managers (people that coordinate and prioritize work at a sub-level, typically a team or subset of teams) are motivated to show that their teams are busy. Given this constrain it is typically very difficult to assess the actual load in all the teams in an organization. This is because even if one line manager would be honest and inform that their teams have some bandwidth, there would quickly be more work assigned to those teams so as to overload them.
Alternatively, other managers would complain that their teams are overloaded and require that the available teams be assigned to them, therefore assigning the "busy" line manager more power in the organization, which in turn re-enforces the message that "it is not OK to say that your teams are not overloaded".
Teams themselves have no incentive to publicly state that they are not overloaded because that leads to job insecurity or scorn from surrounding teams (see also above).
In any mid- to large-size organization (more than a few teams) it is very difficult to unequivocally identify which are the teams that are overloaded and which may have some bandwidth. This is because changes to the software may cause a previously free team to become busy and assigning more work to that team may jeopardize the work needed when future changes are recognized.
The larger the organization the more specialized the workers tend to be, which in practice makes it very difficult for teams to help each other by sharing a common work log (aka backlog) or for one team to help another that is working on a different component of sub-system.
Many organizations start multiple parallel projects. This typically leads to overloading the organization even further and putting more pressure on certain teams that are in practice bottlenecks for the flow of work. Multiple projects dependent on one team become therefore "stuck" and their requests cannot be completed. This often leads to other teams being stuck as well because they depend on the bottleneck teams. Finally the organization may have multiple teams that cannot deliver their work because of one single bottleneck. This is a common feature of networked systems such as the Internet.

Solution

In this post I try to present a simple solution. The goal with this solution is not to optimize staff utilization, or to explore complex mathematical models. Rather this solution focuses on something that is easy to understand albeit more expensive than other possible competing solutions.

As explained above, mid- to large-size organizations tend to build complex networks of teams through which the work flows. These networks tend to be complex as well as unstable (i.e. the node links change frequently due to rerouting of different types of work).

A simple solution will have to work independently of the characteristics of that network, thereby being network agnostic.

Create a team of generalists and assign those to one of the ongoing projects and make it report to the project management team as opposed to the line managers. This way the project management team can assign this team of generalists to help some of the teams that may be blocked on some piece of work. Additionally this team will collect tacit knowledge about the prevailing bottleneck areas and will therefore also be useful in debugging and investigating specific problems in those areas later on.

This team must be staffed with people that can easily touch any component or subsystem and ideally these people will be very well networked in the organization in question, allowing them to quickly tap into more specialized knowledge when needed (say over the lunch break or on a quick IRC chat).

This team, which I'll call SWAT team (for SoftWare Action Team) will work under the guidance of one person with Project Management responsibilities and will answer only to the project management team, not the respective Line Managers. The reason for this is that the project management team is motivated to solve specific problems that allow the project to progress and have access to the information about which areas/teams/sub-systems need more work to make that happen.

Resulting context

When the SWAT team is nominated it must be staffed out of the best software specialists (Architects, testers, designers, coders) in the organization. This means that other projects will lose some man-power and potentially lose people that helped those projects progress faster. For this reason it is important to be flexible at first in the nomination of this team and consider every individual assignment together with both the software development teams and the project management teams.

A possible consequence of the nomination of this team is that the team is kept together for a very long time, therefore reducing the staffing levels indefinitely for other software development teams or projects. This is not a desirable situation. The SWAT team should be a temporary team, brought together only to help the previously-starved project progress. Once that project raises in the priority list or is not starved then we must consider stopping the SWAT team's work and returning them to their original teams.

Another risk that should be considered is the loss of specific knowledge on the part of the SWAT team. This is particularly problematic if some of the individuals work in highly specialized teams within a specific knowledge that evolves fast. Therefore the SWAT team should be as short lived as possible but put together whenever needed.

When selecting the individuals for the SWAT team one must also consider the motivation of those individuals to participate in a generalist team. Some will undoubtedly be happy to do so, but others may not.

Queuing Theory and Throughput

The basic systemic impact of the SWAT team is that it transfers people from the day-to-day work (which is typically optimized for staff utilization, i.e. getting everybody busy) to a sporadic or ad-hoc work which is assigned on a need basis. This effectively creates a staffing "buffer" by which we reduce the number of people that are constantly kept busy or in full-utilization. We then use this SWAT team to tackle particular bottlenecks.

Finally, the SWAT team as a very little impact on the organization utilization (only a few individuals compared to many teams), but it creates a small surplus capacity that can be applied to any bottlenecks to solve the problem of a starving project.

A Question for you

Have you seen this pattern applied in your organization? What were the results? Share those with us in the comments below.

Pattern format description

In "Name" I give a name to the pattern.
In "Problem" I describe the problem the team is facing in the form of a root cause and a set of symptoms that may be detected and lead to this problem.
In "Context" I explain where the pattern is applicable.
In "Forces" I try to describe the constraints or forces that the solution has to take into account.
In "Solution" I try to describe the instructions and practices to be used to solve the problem as described.
In "Example" I briefly explain the case of one team at work that has faced this problem and how they solved it.

Photo credit: Dunechaser @ flickr

My Agile adoption story, and why it matters to you

noreply@blogger.com (Vasco Duarte) — Mon, 20 Dec 2010 12:45:00 +0000

Every person has their own different story of how they found out about Agile and how they came to experiment and ultimately adopt it in their projects.
Mine is also different than most, I started as a skeptic. I was one of those that said "it will never work". But I did come around. Here's the story of how it happened

The downfall of traditional waterfall

As many of the people that entered the software development industry during the 90's, I also had my first job in a small company. A start-up that was growing very fast and exhibited all the usual growth pains: more projects than people, lots of extremely hard-working but not experienced people, egos to match, etc.

As it happens, the typical way start-up companies deal with the growth pains is to hire a couple of experienced people that come in and "install the process" that will deliver us from all problems. And that's what happened to us. The company hired a few experienced project managers, they slashed the number of projects and created a process to structure and organize our work. We badly needed it.

However after a while we figured out that the new process was not helping us finish projects on time or with the right features or quality. It was better than chaos but not really that good. At this time I got interested in processes and organizational issues. My thinking was: "there must be a better way".

Re-discovering the wheel

What followed was something many of us in the industry have gone through and will continue to go through in the future. I started reading about other companies that had faced the problems we faced and discovered that it was not only us, and especially it was not only the software industry that was trying to apply the same old ideas and finding that they failed when applied in real projects.

I discovered Deming first, then Toyota, Six Sigma, the whole nine yards. I started understanding some of our problems: focusing on schedule and forgetting that quality is more important; separating work and creating handovers architects to designers, to developers, to testers, etc.

It was clear that what we were doing at that time (Rational Unified Process) was not a good option for us. That's when I started experimenting with different approaches.

My Path to Agile

I started by using simple RUP and focusing on managing the scope, but this not your garden variety of scope management. This was aggressive scope management, negotiated from start to finish of the project. The whole idea was to plot the progress against expected progress and remove content every time we saw a deviation.

This solution was OK for schedule-driven projects, but we still had the same basic problems of leaving risky or valuable things to later in the project, our teams were still very much silos working on partial features which lead to a lot of work partially done. This was not the ~~droid~~ solution we were looking for.

Agile appears on the scene

At that time a local research institute was pushing for more research on Agile Software Development projects. As luck would have it I was switching projects and the new project was selected as one of the pilots. Now, keep in mind that this was 2004, not the heyday of Agile yet, and I was a skeptic. I decided to take the project and prove conclusively that Agile was not the success story we were being told it was. Boy, was I wrong!

The Agile pilot project

We decided to do everything by the book to ensure that we really learned from the project execution and would then be able to find better ways of working based on that experience. A new team was hired, and we started slowly designing the process based on Scrum. Other teams were using XP for comparison's sake.

Then, a funny thing happened. As I read more and more about Agile, I started to find similarities between Agile and what I had read in Deming and Jeff Liker's work. There was the uncompromising focus on the customer, the respect for people, the empowered team with a Product Owner to steer the scope (which I had learned could work well), and more.

I was starting to feel that Agile was no longer a small thing to improve a dead wrong process. It was much more. It was, and is a paradigm shift the consequences of which are still dawning on me today, a good 5 years after the first project.

This is my story

I wanted to share this story with you because I know that many have had similar experiences or are going through that transformation right now. There are a lot more of us, going through the evolution and learning from our application of Agile. That collected knowledge and learning will hopefully improve our industry in the long run.

Agile Finland, a Finland based non-profit association wants to support more of these transitions and that's why we put together a program to support those of us that have started the Agile transition process.

Agile for the experienced

Myself and a group of other Agile Finland members decided that we would create a program to support those of us that have started the transition to Agile and are at a cross-roads, looking for improvements that cannot be found in the available literature. We also don't want to visit every single conference on Agile Software Development we can find. We want to learn from each other and from the top practitioners and researchers in the industry.

The Agile Coaching and Leadership Academy was created from this cooperation. But this is no longer a project by a small group of Agile practitioners. Agile Finland was able to attract a much bigger training institution to help us and vouch for the curriculum that we are putting together.

University of Helsinki joins the effort

Together with the Computer Science department at the University of Helsinki we created the basic program for the course, but now we need the most important ingredient: you, the people who want to learn and improve the performance of your organizations. We want to offer this opportunity to 15 people interested in not only listening to the best minds in the field, but also actively contributing by sharing your experiences and learning from other's experiences.

Check out the program and the details of the training program here and join us in improving our Agile knowledge.

Photo credit: jillclardy @ flickr

Patterns of Agility. How to recognize an Agile project when you see one...

noreply@blogger.com (Vasco Duarte) — Mon, 29 Nov 2010 06:44:00 +0000

Instead of fighting about "who's agile" or "who's more agile than whom", it would be useful to create a set of patterns, that once recognized would help us define if we are or have been able to successfully implement an Agile life-cycle for our project and portfolio.

These patterns or symptoms are useful for us when analyzing a project (e.g. for a retrospective) and assessing the progress of a team or a company from waterfall to Agile software development. These are necessarily only a small collection of patterns. Many more are needed to create a complete language that would help us define better what an Agile project should feel and look like.

Before getting deeper into the patters let me define at the outset what I mean by life-cycle. In my context life-cycle refers to a stage/phase in the life of a project. Example: a project that is "about to end" is in a different life-cycle phase than a project that is "about to start" or "ramping up". I define the following useful, although not exhaustive, life-cycle phases: Start, Middle, End.

In the following text I try to define what different types of projects (Waterfall, Linear Iterative and Agile/Incremental Iterative look and feel like.

Waterfall

Life-cycle phase: Start

In this life-cycle phase a waterfall project is typically in a phase where only the project management team is assigned to the project and the goal is to create a plan. The plan is typically composed of a set of requirements, an architecture target (maybe an architecture plan or just a high-level picture to be developed further), a budget and (most importantly) a project plan.

You know you are in a waterfall project when in the life-cycle phase Start you are mostly spending time in front of a presentation or word editing software and have some meetings (maybe weekly) where scope, budget and project plan are discussed. This phase typically ends with a "gate" where the project plan and Requirements + Architecture are approved.
A dead give away of a waterfall project is that, in this phase no one asks or worries about writing a single line of code. Some sophisticated waterfall projects may include a "prototype" in the life-cycle phase Start, but it will usually be a throwaway and developed by a sub-contractor who will not actually work in the project (after all the other teams are busy with the other projects).

Life-cycle phase: Middle

In this phase the project is in "full speed", which usually means that teams are working with very little coordination (after all they have a "plan" to follow). Typically components are assigned to teams and they work on those in isolation.
A dead give away that you are in a waterfall project is that your team does not integrate code with the other teams at all. Some sophisticated waterfall projects may have "sync-points" or "integration camps" where the component teams come together after a long period of development to integrate their code. These are grim affairs with much overtime and gritting of teeth.

Life-cycle phase: End

In this phase the waterfall project is "code complete" and aiming to "code freeze". There is usually a milestone/gate that was passed exactly at the start of this life-cycle phase called "code complete" or "feature complete". It is at that point that the teams of testers (typically many and in some far away country) are assigned to "test" the product. Obviously what they will be doing is a rather superficial sweeping of the floors to check that everything works. It is only after that that the project can pass the "code freeze" milestone/gate and the real testing can start.
You know you are in a waterfall project when the project runs out of time before it has quality enough to be released. The number of bugs being found is still very high, but probably at about the same level of the bugs being fixed. This is when "management" comes in and pushes all the teams to fix as many bugs as they can (pulling all-nighters or all-week-enders if needed). Much motivational language is used but the count of bugs being fixed stays about the same. The project will eventually ship something, but the actual quality level can only be vaguely understood. Business takes precedence in the decision making.

Iterative, aka Linear Iterative

Life-cycle phase: Start

In an iterative project the Start phase will typically be called Inception and will, like the waterfall projects focus mostly on defining requirements and creating/approving the project plan.
You know you are in an iterative life-cycle project when people start actually coding, but only a few features. Programming is still being "ramped up", but there's no milestone/gate that formalizes "start-programming" order.
In some sophisticated Iterative projects people will mention Use Cases, customers, experience, business cases and may even have a prioritized list of Use Cases to be implemented. Typically you will find that the Requirements document is quite shallow, delegating the clarification of most requirements to the actual "design" phase of the project.

Life-cycle phase: Middle

Now the teams are working very clearly on the code. Some Iterative projects may even have several sync points (see above) within this life-cycle phase. They will be easier than in a waterfall project, but "integration camps" are still common (although less frequent) and teams actively discuss the "code-line" policy (i.e. version control is an active part of project management.
A dead give away of an iterative life-cycle is that there will be several iterations of about 2-3 months in length at which point many teams try to integrate their code. In some sophisticated Iterative projects the teams will actually try to hold demonstrations of the existing code and in some (far fetched) cases there will be a project-wide retrospective at this point.

Life-cycle phase: End

You'd be tempted to think that Iterative life-cycle projects would have an easier "End" phase, but you would be wrong. Just like in waterfall, the teams develop a lot of their code in their own version control systems and integrate seldom (although much more frequently than in a waterfall project). In large iterative projects there will be "vertical" sub-projects (typically less than 100 people) that will actually integrate their code frequently but the multiple concurrent sub-projects will only really integrate their code at the end.
In this type of projects you will still find a very hectic "test and fix" phase at the end, but it will typically be focused around "complex use cases" as many of the simple use cases have already been tested during the "Middle" life-cycle phase.
You know you are in an iterative project because just like in waterfall Quality is an after-thought and you will find many, many bugs in the end of the project. The defect/error metrics will be the main focus of the project management team in this phase, up to the point that sophisticated statistical models will be created to try to predict when the project will end.
Don't be fooled, in a project where error/defect metrics are used as the main project management tool no one is in control. The project end date is essentially unpredictable and typically management will decide (arbitrarily) when the product should be released.
In some sophisticated Iterative projects I've seen that a length is pre-set for this life-cycle phase based on history and, ironically, that seems to hold pretty well (although not for the reasons you may think! -- stuff for another post)

Agile, aka Incremental Iterative

Life-cycle phase: Start

In an agile project this phase is typically extremely short. A product manager will present a proposal for a new product or a new version of an existing product. This proposal will be discussed and approved. One or more teams are assigned to the project for a short period of time (called Sprint or Iteration -- confusing, I know) and produce a running product, called a Product Increment.
You know you are in an Agile project when the team talks about "releasing" the software starting from day one. Each development team will include testers and each Requirement (aka story or feature) will be discussed in order to create acceptance criteria (aka conditions of satisfaction, aka test cases). These will typically be agreed before the team sets out to design the implementation but can also be updated during the Sprint/Iteration.

Life-cycle phase: Middle

In this life-cycle phase you will notice that the teams start to gel (if they are new) and the project gains momentum. The teams demonstrate regularly what they have accomplished and some teams will have stopped holding retrospectives, because they "have nothing to improve". The pressure is always high in an Agile project, but never too high, and in this phase of the project the team is already used to the pressure level, they know how to tackle their stakeholders.
You know you are in an agile project when the Product Manager is not the Product Owner and is never or almost never present in the Sprint/Iteration planning meetings. That work is delegated to someone in the team that knows the technical product and works with guidance from the product management to help the team manage and prioritize their backlog (aka Technical Product Owner).

Life-cycle phase: End

This is the life-cycle in which the Agile project will differ the most from the other two life-cycle models. In the end of the project the team will still be developing new features at full speed. No one will talk about "code freeze" or "feature freeze" in the project, but the testers and project management team will closely follow the Defect list.
You know that you are in an Agile project when the defect/error list is short and the selection/prioritization of defects/errors is easy. Some teams will just start their iterations/sprints by picking the most important defects out of the defect backlog, others will reserve some time/bandwidth in iteration/sprint planning specifically to improve the quality of their product.
The most noticeable difference however, will be that people will feel the pressure to add more features at the end, rather than the pressure to avoid changing any code. Agile projects typically deliver a large amount of "test" code (i.e. code that is there to test the production code) which makes them confident that they can change the code up to the last minute of the project.

Conclusion

I hope that this collection of patterns from different types of projects will help you talk about the level of agility in your project with your team.
We should really stop bickering about "how agile we are" and start defining how an agile project "feels" like. What patterns do we see, what benefits and constraints we have, etc.

At the end of the day, what matters is that you understand your context. That's the first step to changing it!

Photo credit: Bill Gracey @ flickr

this is a test post with a twist...

noreply@blogger.com (Vasco Duarte) — Sat, 13 Nov 2010 18:25:00 +0000

As it is a test post I decided to include a nice picture for you enjoyment. Hope you like it! ;)

What can we learn from illusions that helps us manage projects better?

noreply@blogger.com (Vasco Duarte) — Fri, 22 Oct 2010 18:54:00 +0000

Just had the opportunity to watch a BBC documentary about illusions.

The show went on to detail how we as humans get deceived by our own senses. There were 3 things that opened my eyes in that documentary:

The things that caused me to think were:

when we mix senses one of them tends to take over: this is the case when we are watching a magic act. The example on the documentary was a magician throwing a ball in the air for a few times, and then making the same gesture but keeping the ball in his had. Although the subjects eyes stayed on the face of the magician, the brain perceives the movement of the ball and later realizes that the ball has vanished.
some of our senses are completely/100% contextual (see image above): the example they had here is a cube with many small squares on it's faces. Some faces are lighter, others are darker. When asked about the difference between 2 specific squares in the faces of the cube people would clearly state that the colors were different. However, when you moved one of the squares to the other face of the cube, you could see that the colors were exactly the same! Our perception of color was completely dependent on the colors surrounding the colors we were comparing.
we can learn new senses if we are exposed to the right stimuli: The amazing examples they had for this was a blind-person that had learned to use sound and echo to see and used that learned sense to ride a bike (while blind!) The second example was quite amazing. A person would use a belt what was wired with buzzers/vibrators (like mobile phones) so that they could constantly feel where the magnetic north was. Later they would use that learned sense to navigate their way in a place while blind folded!

All of these observations from the documentary point to one thing. We are not wired to perceive reality. We jump to conclusions far too quickly, but we can also take advantage of that if we train our brain with the right stimuli! That was the most interesting find from this documentary.

The implications are huge in a software project setting, where it is quite common that people use only a very small number of stimuli (some reports, a couple of graphs, etc.) to jump into conclusions. We need to "learn" how to sense the status of a software project, and that can be done by following the example of the person who was taught how to "feel" the magnetic north...

Can you think of applications of this knowledge in your project?

Short multimedia review of LESS 2010 conference

noreply@blogger.com (Vasco Duarte) — Wed, 20 Oct 2010 16:56:00 +0000

The LESS 2010 conference just ended on a positive note of shared knowledge, bridge building between different communities and celebration of great work in the area of Software Development.

LESS was started with a great ambition of combining, from the starting point three different communities globally. Those communities were the Agile community, which is focused on the improvement of the software industry. The Lean community with both people from manufacturing as well as from software industry. And the Beyond Budgeting community, which comes from large financial and industrial companies and represents a turn in the way those companies tackle the problem of managing large organizations.

I hope that you have the chance to dive into each of these communities' body of knowledge as there are great contributions from each of those complementing what we have been doing in the Agile community for nearly a decade.

There was one piece of data that particularly impressed me. That data does emphasize something that many of us have felt, but putting a number on it does make it even more impressive. The first keynote presented a figure from an evaluation of work done in a company. The amount of tasks that were blocked (could not progress) was 62%. This is amazing, most of the work in that company was blocked, and so people would start new tasks and, guess what: get blocked on those. The queuing theory's prediction of "the more tasks you start the less you finish" was quite clear here.

There was one talk and one paper that were highlighted by the organizers as the best in the conference. These selections are always subjective, of course. But it's worth highlighting them as they were very good sources of information about Agile adoption (the paper) and new ways of looking at the organization and inform the way we adopt Agile and Lean software development (the talk).

Maarit Laanti received the award for the best paper of the conference. Here's Maarit receiving the award.

Paper: Agile Transformation Study at Nokia - One Year After

~~Here's Maarit receiving the award:~~
UPDATE: This video has been removed

Jurgen Appelo received the award for best talk in the conference. His talk: "Complexity vs. Lean, the Big Showdown". You can find Jurgen's slides here.

Here's Jurgen receiving his award:

Jurgen Appelo receiving award for best presentation at LESS2010 from Vasco Duarte on Vimeo.

Finally the conference ended with the gala dinner, which I thought was a wonderful way to end the event where we meet so many new people. We celebrate the fact that we spent time together trying to understand the issues that we face every day, but with the help of different points of view and mental frameworks.

Very good 3 days. I'm already looking forward for next year's conference!

PS: Watch this space as I'll publish an amazing surprise that the LESS2010 organizers prepared for the participants! :)

Short video introduction to my sessions at Agile Eastern Europe 2010

noreply@blogger.com (Vasco Duarte) — Mon, 20 Sep 2010 13:34:00 +0000

In about 3 weeks I'll be flying to Kiev and meeting some of the best Agilists in the planet. But it won't be just fun and games for me. I'm already stressing about my sessions.

Check out the video introduction of my sessions at Agile Eastern Europe and, while you are at it why not book your flights and hotel and joining us there?

See you at Agile Eastern Europe in Kiev!

Introduction to my sessions at Agile Eastern Europe 2010 from Vasco Duarte on Vimeo.

Software Development Today

Story Points Considered Harmful - Or why the future of estimation is really in our past...

The Flat Earth Society

Estimation soup

The Human condition

This is when things get Complex

Why did this just happen?

Solving the the lack of internal coherence in Scrum

The alternative prediction device

The Experiment

Claim 1: The use of Story points allows us to change our mind whenever we have new information about a story

Claim 2: The use of Story points works for both epics and smaller stories

Claim 3: The use of Story points doesn’t take a lot of time

Claim 5: The use of Story points is tolerant of imprecision in the estimates

Claim 6: Story points can be used to plan releases

Claim 4: The use of Story points provides useful information about our progress and the work remaining

The real-life use of a simpler metric for project progress measurement

The climax

Story Points Myth: Busted!

OK, I get your point, but how does that technique work?

Final words

Kanban vs Scrum, the ultimate fight? Don't think so, here's why:...

Kanban innovation

Scrum innovation

Wrap-up

XP2012: The Extreme Challenge

The XP2012 challenge!

Kanban in a networked process -- Visualise the network!

Adapting to a different country and culture - a story

Dude! Where's my manager? or Why you should attend LESS2011

Guest post: Building and scaling a startup - Feature or component teams?

Building and Scaling a startup - the Feature vs Component teams debate

Guest post by: Alexander Grosse from SoundCloud

On rewarding and performance systems...

An additional bonus

LESS goes Stockholm for LESS2011, join us there in October

LESS goes Stockholm for LESS2011

Agile is about customer delight

Real customer involvement patterns

You cannot transition to Agile. Stop and just embrace it!

Kicking up dust for the Agile Finland 2011-2012 season

Concrete proposals for the next Agile Finland Board season

Conclusion

ALE Network in active discussion in the Agile Finland mailing list

What are some of the motivations for ALE?

What is ALE's Vision?

What is the link between Agile Finland and ALE Network?

Purpose of the Open Space session on April 20th

Interlude

What would a European Agile comunity look like? #ALEnetwork

Patterns of Agility, talk at Scan-Agile 2011 and Agile Riga Day 2011

Another job opportunity for 31337 h4x0rs that love testing!

Job opportunity for awesome people in Tampere, Finland

To all my friends and colleagues at Nokia, my contribution

SWAT Team, a Pattern for Overloaded, Multi-project Organizations

Why does this happen? and How to tackle it?

Problem and Contribution

Context

Forces

Solution

Resulting context

Queuing Theory and Throughput

A Question for you

See Also

Pattern format description

My Agile adoption story, and why it matters to you

Patterns of Agility. How to recognize an Agile project when you see one...

Waterfall

Life-cycle phase: Start

Life-cycle phase: Middle

Life-cycle phase: End

Iterative, aka Linear Iterative

Life-cycle phase: Start

Life-cycle phase: Middle

Life-cycle phase: End

Agile, aka Incremental Iterative

Life-cycle phase: Start

Life-cycle phase: Middle

Life-cycle phase: End

Conclusion