Buy Viagra Without Rx, Liviagra * Purchase Without Prescription

Poka Yoke, error handling for your process

Mendelt — Wed, 07 Oct 2009 06:00:46 +0000

Software engineering is still a very human endeavor. Its a complex process that requires our ability to create non-standard solutions for non-standard problems. But with this ability to creatively solve problems comes a tendency to introduce defects, one of the seven wastes lean production and lean programming try to eliminate. Jack Milunsky describes several ways to reduce the amount of defects in his article. I want to look at another idea from lean manufacturing for reducing the number of defects called Poka Yoke in Japanese and have a look at how we can apply this idea to software engineering.

Poka yoke is a Japanese term that means something like fail-safing or as I like to call it fool-proofing. The idea is that instead of just telling people how to do things you design your process, your tools or your product in such a way that it becomes harder to make mistakes and easier to do things the right way.
USB cables are a good example from manufacturing. It's impossible to accidentally connect two USB printers together because of the way the plugs are designed. You can only connect a USB device to a USB host. Another well know example are microwave ovens that turn off the moment you open the door.

Poka yoke in software engineering takes a bit more creativity. Software is incredibly flexible so it's often harder to define right and wrong ways to fit parts together. First lets look at a couple of ways we already do poka yoke without knowing it to get some inspiration. Later we can look at how we can fit more of it in our process.
We have a lot of practices that make it more difficult to check in faulty code. Unit testing and regression testing together with a continuous integration system makes defects very visible very fast. A similar but older technique is coding by contract. Defining pre-, and post-conditions for every function in your code making it fail fast whenever it is called in the wrong context or with the wrong parameters.
Another concept in API design that is gaining popularity is 'convention over configuration'. Instead of letting consumers of your API configure every aspect before they can start to use it you give them a set of sensible defaults that 'just work'

Of course it's easy to go overboard with fool-proofing your process. We know that for every fool-proof system the universe just invents a bigger fool. The trick is to just fool proof the parts of your process that repeatedly cause defects. The best way to do this is to bring it up as part of your retrospective. Try to find the weak spots in your system and make them more robust by setting sensible defaults or adding tests. Sometimes even improving names in your code can improve things.

The dirty secret of pair programming

Mendelt — Tue, 22 Sep 2009 06:52:53 +0000

Pair programming is one of the more controversial extreme programming practices. Having two people work on the same piece of code at the same time looks very unpractical and inefficient to someone not familiar with this practice. Pair programming proponents like me are usually quick to point out the benefits like improved quality, less rework, better communication and better knowledge sharing within teams but I think the biggest reason pair programming works is usually kept quiet.

People work harder when there is someone looking over their shoulder.

I'm going to be completely honest with you here. When I work alone I spend a considerable amount of time surfing the web, reading email, twittering (you can follow me at @mendelt) getting coffee and talking to coworkers. This means I'm spending less time working but it also means I'm constantly interrupting myself during the time I am doing work making me even less productive.

Now we don't tell our managers this because it wouldn't do anyone much good, the problem is a bit more complex than just people slacking off. What I've observed is most people have a hard time pacing themselves. We do really focused work for five minutes and then take a break. Unfortunately breaks have a habit of taking more time than they should and productivity goes out the window.

To solve this problem we need a way to maintain a sustainable pace. Pair programming is a way to do just this. Forcing yourself to explain what you do to your pair is a great way to maintain a sustainable pace and work a bit harder.

If you're not moving you're not agile

Mendelt — Tue, 08 Sep 2009 18:31:56 +0000

Lately I've seen a couple of doom scenario's scetched out for agile. It seems agile is dead or at least dying at the hand of the PMI. I don't want to bash the authors of these articles. I respect them and agree with most of their arguments but not with their conclusions. Agile is changing, sure, but it's not dying, we're all about embracing change right?

At it's core agile isn't a process or a methodology, it's a set of principles with a framework of practices to support them. One of the most important principles is about change, not just in our requirements but in our process, our organization and even in change itself. Agile is about improving your process, trying out new things checking them against our principles and core values and keeping what works.

Agile has never stopped evolving. We've been incorporating ideas from other fields into our set of practices like kanban and self organizing teams. And we've been trying out new ideas, we're going from TDD to BDD, we're branching out into agile software architecture with SOLID principles and emergent design. One thing that's important to notice is that many of the new ideas in agile aren't actually very new and come from other area's.

With that in mind it's not really strange to see agile practices being taken up in other environments too. Not every organization is willing or able to support the constant evolution required for real agile implementations so they do the next best thing and pick up our established ideas and practices. We've been supporting this ourselves for some time by supplying pre-packaged sets of practices in the form of Scrum, DSDM or Xp frameworks. And forces outside the agile community have been doing this too. Agile Rup has been around for some time and now the PMI is also picking up agile ideas.

It's easy to bash these agile hybrids as not being true to 'our' principles and somehow inferior and dangerous to 'our' movement. But I think the real danger comes from somewhere else.

The real danger is stagnation. If we start rejecting ideas because of where they come from we start slowing down. Don't bash the PMI because they use our practices out of context but learn from them just like they are learning from us. Take what we can use and grow. Don't let agile become the bearded conservative old fart that we set out to replace.

Personal Productivity on Agile Teams

Mendelt — Tue, 25 Aug 2009 06:00:26 +0000

Personal productivity systems like Getting Things Done or the Pomodoro technique are quite popular among agilists, and I'm not surprised. There are many parallels with agile practices, most of these techniques use practices resembling iterations, backlogs and frequent retrospectives to become more productive. I've been experimenting with a couple of these but once I started using these at work I found that these don't automatically work in a team setting.

Personal productivity isn't team productivity.
In an ideal world a team consisting of very productive individuals is automatically a productive team. Unfortunately the real world is far from ideal. Because teams are very interdependent optimizing the work of a single team-member will not automatically optimize the whole. In many cases local optimization like this might even be cause the team to become less productive. Lets look at what's causing this and how we can avoid it.

One of the ways to become more productive as an individual is to reduce interruptions. Making someone doing complex work switch between tasks a lot by interrupting them will make them far less productive, not only because the interruptions take time, the act of switching between complex tasks takes a lot of time too. A large part of personal productivity systems is avoiding interruptions. Unfortunately avoiding interruptions in teams often means avoiding communication. Communication is critical in a team.

Another way to get a big productivity boost is working with to-do lists. By listing and prioritizing tasks you can streamline your work. But in a team setting personal to-do lists can be problematic. People working from their own to-do lists instead of the team backlog can make coordinating work hard, it creates invisible work in progress and when people start planning their work too far in advance to-do lists can introduce rigidity into the team.

Aligning personal- and team-productivity
So should you only use GTD at home to organize your gardening duties? Of course not! There are a couple of things you can do to align your personal productivity with the productivity of the whole team.

Keep communicating.
The temptation to keep your head down and just steam through your own tasks is often big. For example the pomodoro technique gets is name from the kitchen timer used to time 25 minute periods where you need to do focused work without any interruptions. Pair programming can help to still get these periods of uninterrupted work without losing touch with your co-workers. You shouldn't count questions from coworkers as interruptions. They're part of your work. A way to deal with these is to add them as priority items to your lists.

Keep your todo lists short and up to date.
To-do lists are great for streamlining work. If you make your lists too long you're planning too far ahead. A list that contains more than a day of work probably contains work items that should be on the team backlog. Claiming too much work for yourself will prevent your team-members from working on high priority items.

Stay transparent, give coworkers access to your lists.
Try to keep your lists in a public place. Write them down and put them on a corner of your desk. Communicate the items on your list during the stand-up. It's important for the team to know what item is on who's list when priorities change. Work items may even become obsolete.

When done right personal productivity systems can become an asset in a team. I've been experimenting with these for some time. I noticed that reporting on work done and work planned during the stand up became easier because I was tracking my work better. Tracking time (or pomodoro) spent on a single work item also made it easier to spot potential problems earlier.

Fixed price part 2, Fix it with agile!

Mendelt — Tue, 04 Aug 2009 05:07:47 +0000

In my previous fixed price article I looked at why fixed price is not only bad for suppliers but also for clients. I also argued that contrary to popular belief using big design up front methodologies will not solve these problems. Fixed price is difficult no matter what methodology you use. In this article I want to look at why fixed price is still popular with many clients. Then we'll look at what we need to do to be a bit more successful at fixed price and how agile methodologies can help us do this.

To look at why fixed price is popular with clients I'll start with a comment I got on my previous article. Sergey Pyatigorsckiy commented "As to my mind, pure fixed priced project can be defined as a project nobody cares about. At best it's spending money, at worst - wasting money. That is why real huge governmental projects are fixed priced: Nobody really cares."

I tend to agree to some extent. Clients often don't care about the project, they often just want the software and be done with it and for them the easiest way to get this is fixed price. So fixed price projects and clients that don't care seem to go together. In most cases clients do care about the outcome of the project. Clients have a problem they want to see solved. Or, more cynical, in larger organizations, clients want a big successful project to show their manager. Often clients don't realize that in order to improve chances of a successful outcome they should care about the project. Most clients have experience with processes like buying a new car, they specify what they want, recieve a time and cost estimate, wait a few days and get their car. Why should software be any different?

Clients often don't trust the supplier enough to move away from fixed price to other contract types. Fixed price often seems a lot safer to a client because it allows them to push risk to the supplier. In practice this just isn't the case. The fact that a client can sue a supplier for breach of contract will not change the fact that the client doesn't get any software. Allowing the client to point fingers won't solve their business problem.

What do we need to improve our chances in fixed price?
Unfortunately we can't get rid of fixed price. But there are several things we can do to make the best of this situation.

We need to make the best estimates possible within the limited time we have available before the start of the project with the limited requirements we have at that time.
In order to reduce risk we need to keep a close eye on progress in order to detect problems as soon as possible.
We need to build trust with the customer. Without trust there's no way we can break the fixed price habit in the future.
We need to create a situation where we can break out the fixed price contract whenever requirements change without having to throw away lots of work in progress.

Agile fixed price
Fixed price projects will cause an agile team to make several compromises, up front estimation is not something we're used to doing, committing to those estimates even less so. Limiting scope is also not a very agile thing to do. But even within these constraints I do think agile has a lot to bring to the table in fixed price projects. Lets look at how agile practices will help us achieve the four goals I stated earlier.

Agile estimation
The hard part of fixed price is up-front estimation. You need time and a detailed set of requirements to create really accurate estimates. We don't have either so we have to make the best estimates possible with the least amount of resources. One of the best methods to do this is agile estimation. Even with the rough requirements you have before the start of a project it should be possible to create a set of user stories and attach rough relative estimates to them using something like story points. These can be transformed into a set of estimations using past velocity of the team. Keep in mind that it's probably a good idea to pad these estimates with a risk-factor. In my experience abusing agile estimation techniques like this will not bring you the most reliable estimates, estimates are never as unreliable as at the start of a project, but considering the circumstances it's the best option. Techniques that claim to be more reliable like function points analysis simply take too much time.

Agile risk management
Finishing stories every iteration is the best way to measure progress. A story is never 80% done. It's 0% done or it's 100% done. Everything in between is uncertain and will not allow you to measure progress. Agile forces you to finish stories every iteration giving you a clear picture of progress so you'll know early on when a project is behind schedule. This kind of risk management is very important in fixed price projects where missing a deadline can mean the difference between a happy customer and a lawsuit.

Build trust by showing working software
Actually finishing stories in every iteration also gives you the ability to show working software every time. In fixed price projects this does not seem very important. Clients don't expect to see software until the very end, and on the many non-agile fixed price projects I've been on that was exactly what we were aiming for. But when you want to build a relation based on trust with a client this is not the way to go. The best way to show a client that they can trust you is to be able to show them what you're doing. Show them working software.

Break out of the contract
Showing your customer working software has an interesting side effect. They'll want to change requirements. But because of the fixed scope this won't be possible without breaking out of the contract or by doing work outside of the contract, giving the customer features for free.
There are two things that make breaking out of a fixed price contract hard. First of all the supplier will want to bill the customer for the work that has already been done. But if you have lots of work in progress defining progress is hard, fortunately in an agile project progress is much easier to measure as we've already seen. Also clients will probably not want to pay for software when many important features are missing. Prioritizing work according to client business-value will make sure the most important features will be implemented first. It will be much easier to switch from fixed price to a more flexible contract type halfway through a project.

In situations where you can't get around working with fixed price contracts people often give up on doing things agile altogether. To me this is a bit like someone who is trying to stop smoking who, in a moment of weakness, smokes a cigarette, gives up completely and starts smoking one pack a day again. The fact that fixed price makes you abandon a couple of agile practices does not mean you should give up on agile altogether. I hope to have shown some compelling arguments for doing fixed price agile in this article.

Fixed price part 1, what's so bad?

Mendelt — Tue, 21 Jul 2009 06:00:27 +0000

In his excellent article 10 Contracts for your next Agile Software Project, Peter Stevens described 10 different contracts that are often used in software development projects. At the end of his article he singles out one contract-type:

"Fixed price projects and agile development are considered not to mix. I know from experience that this is not strictly true. I am also convinced that other forms are better."

I completely agree with him on this but since fixed price contracts are so common in software development it seems like a good idea to look at them a bit more carefully. In this article I want to look the problems with fixed price and why traditional software engineering methodologies are unable to solve these problems. In my next article I want to continue on a more positive note and show how agile practices will help you make the most of fixed price.

What's so bad?
The most obvious downside is of course lack of flexibility. Fixing project scope in the contract often makes it non negotiable during the project often preventing change altogether. In my experience stakeholders will change their minds during any non-trivial project and fixing scope at the start of a project will limit the quality of the end-product because it will not fit the client's wishes one-hundred percent.

Not only scope is fixed at the start of a project but price is also fixed, hence the name. Making the supplier to commit to price estimates even before the project has started forcing critical decisions at the worst time possible. The later you make a decision the more information you have to base that decision on. Agile tells us to make them at "the last responsible moment". Making them sooner is risky.

Fixed price projects are often more expensive than they should be. The rigidity of these projects often causes scope to be too large. At the start stakeholders in the client-organization will specify many requirements and features they probably won't need 'just in case'. They know it will be hard to get them in later. Fixed price projects also force the supplier to make very accurate estimates at the start of a project to reduce risk, the time spent creating these estimates are later often added to the price of the project. Suppliers often also add a fee for the extra risk they have to carry, a former employer of mine added 20% to fixed price contracts and seeing how much trouble fixed price was for them this was actually low.

Instead of aligning interests of the client and the supplier fixed price projects artificially opposes them. The client will want to stretch the scope agreed in the contract as wide as possible while the supplier will want to do as little work as possible. This often prevents good communication while increasing risk. I have yet to see a fixed price project where the client delivered an on-site-customer and I don't think this is a coincidence. Fixed price pushes stakeholders into roles that are not beneficial to the success of a project.

Fixed price and BDUF
I've heard more than once that these problems make fixed price problems especially to do in an agile way. A potential employer once told me when I asked him if they used any agile practices "We do fixed price so we can't do agile". When you look at the downsides of fixed price projects this seems logical. Fixed price has problems with some of the core agile values like flexibility and communication. The focus on up-front estimation also seems to point to big design up front or BDUF.

Unfortunately more traditional approaches won't help us either. Big design up front will not help with estimations. We need accurate estimations before the project has even started. There hasn't been time to gather anything resembling a complete set of requirements. Traditional estimation techniques like function point analysis are only as good as the data you put into them and unfortunately the data isn't very good at the start of a project. Problems with flexibility and communication are only hidden, not solved.

Fixed price has some big problems. Not only for the supplier as many clients seem to believe but also for clients. These problems don't go away by giving in to the traditional big design up front methodologies although some of the problems with flexibility and communication will be less visible. In the next article I want to look at how you'd do fixed price in a more agile way. This won't solve the problems but it will give some tools to see them coming and to make it easier to switch contracts during a project.

Hacking code ownership

Mendelt — Wed, 08 Jul 2009 06:00:36 +0000

Two weeks ago I wrote an article about the virtues of sharing code in teams. Just to confuse you, this week I want to tell about a situation where code ownership actually helped me introduce a couple of agile engineering practices in a team I worked with some time years ago. Here's the story. Facts, names and situations have been twisted a bit to ensure the client's privacy.

The project
When I got started on this project the team had already been working on the code for some time. They didn't have strict rules about code ownership but most developers had started on their own piece of code at the beginning of the project and had kept on working in the code they knew as the project went on. When I joined the team everyone had a well defined layer of the application to call their own. I got to work on the UI layer.

On previous assignments I had tried introducing TDD and pair programming. But I often ran into problems. Maintaining a set of tests is hard when your co-workers change your code and don't fix tests when they break. You end up spending extra time fixing the tests other people break and it's hard to convince people to do TDD when it's costing you so much work.

Introducing TDD
But now things were different, no-one touched code. I was free to start writing unit-tests. At first this wasn't easy. UI's are never easy to test. But I started slowly refactoring all the screens I worked on to extract the presentation logic to separate presenter classes that I could test. Slowly my test coverage got better and slowly my code got cleaner making it easier for me to implement new features.

Introducing Pair programming
Code-ownership also created extra dependencies within the team. Changes in the code usually went right across the artificial boundaries. This created an ideal opportunity for me to introduce pair programming. If someone wanted me to implement something I'd invite them to sit behind the computer with me to help me figure out what I needed to build. I was actually kinda surprised how quickly people picked up this habit.

Because I actually had the chance to be successful with TDD and because pair programming gave me the opportunity to show this off to my team members they started picking this up. The guy responsible for the data-layer actually had been doing TDD on his personal projects but had had difficulty doing it over here because most of his code was tightly bound to the database. I helped him separate the logic he wanted to test from the pure data-access code and helped him get started using Rhino-Mocks, a .Net mocking framework.

Because my contract ended I didn't see that project through to the end. I heard they started sharing code more when they got more comfortable with each others code through pair programming and they were experimenting with continuous integration now.

The retrospective
Lets do a project 'retrospective' and see what we can learn. Should or shouldn't we get rid of code ownership? I think we should, eventually, but whenever you get rid of something you should think of the value it brings first.

In his book Working Effectively with Legacy code Michael Feathers talks about using an anti corruption layer to shield our newly written code from getting corrupted by bad design decisions made in legacy parts of our system. These layers are a temporary fix, as the old code is upgraded to new quality standards, piece by piece it slowly move and eventually become unnecessary. Sometimes we also need an anti corruption layer in our teams and ironically code ownership, a practice I criticised in my article two weeks ago, gives us the means to implement such a layer.

Another thing that surprised me here was how easy it was to get people to do agile practices when they were introduced at the right pace in the right order. 'Refactoring' a team to agile instead of trying to become agile in one big leap actually has helped me more often. When you take small steps and be careful to take the step that brings the most value every time acceptance is easier and faster and that will make sure people will keep on improving even when you're gone.

Who's the owner? Shared code vs. code ownership

Mendelt — Tue, 23 Jun 2009 08:05:20 +0000

I think it's widely recognized that shared code is important in agile teams. It's an effective way to streamline your development process, making your teams more flexible and productive. Transitioning from code-ownership to shared code can be hard. Lets compare the two, look at the problems in transitioning from one to the other and see how we can ease this transition.

Shared code is only a corollary practice in extreme programming but most agile teams I've seen implement it successfully. Many other teams are still in a situation where team members have what I call code ownership, the code base is divided into parts that can only be edited by certain persons or groups within the team. Usually the code is divided along lines of expertise, for example database-professionals develop the database, the back-end and domain logic is developed by one or more experts, and interaction designers and UI developers are responsible for the user interface. The reasons for this division are usually efficiency, people work on the parts of the code that fit their skill set, and responsibility, when something is wrong it's easy to find the guilty party by looking at what piece of the code failed.

Why Share?
In practice things work a bit different.
Code ownership is actually not very efficient, most non-trivial features will take changes in most of the layers in the application. This will create unnecessary dependencies between team members and unnecessary delays.
Having people take responsibility for pieces of code isn't very useful either. Eventually implemented features are what count. I have seen many situations where no-one took responsibility for a defect in a feature because of code ownership. The database-guy blamed the back-end guy, the back-end guy blamed the UI team etc.
Code ownership is also risky. Specialization like that will create knowledge silo's in your team. If the database guy gets hit by a bus who will take his place?

So what's keeping you?
So if shared code is the way to go, how do we get there? Is just telling everyone to edit any piece of code enough? Of course it's not that easy. When you remove safeguards you'll have to replace them with other safeguards, there are a couple of things that need to be in place to enable shared code, responsibility and trust

Responsibilty
We already looked at responsibility, making individuals responsible for parts of the code is not the solution. In teams with shared code the whole team is responsible for the whole code base. But if more than one person is responsible then effectively no-one has responsibility.
But in parts of the code base aren't that important to our clients. Working features are, user-stories are. Most agile methodologies let people take responsibility for implementing features or user-stories at the start of an iteration. Dividing responsibilities along the same lines as the actual deliverables results in less finger-pointing and more cooperation.

Trust
In many cases developers themselves are opposed to the idea that any other team member can change the code they worked on at any time. Team-members need to trust each other in order for shared code to work, they need to be sure that every time a team member edits some piece of code the code will be better than before the edit. This means the team actually needs to agree on what 'better' is. So there need to be coding standards. It's also good to have a code-review process in place. Of course instant code-review in the form of pair-programming would be even better. A good version control system is a good safety net in case things do go wrong. Practices to get quick feedback on code quality like TDD and continuous integration also help.

Shared code is an important agile practice but getting there takes some effort. Getting rid of code ownership without a support structure can cause problems agile practices in order to guarantee consistent quality and to work in a responsible way. Agile practices like TDD, continuous integration and pair programming help keep quality high and responsibiltiy needs to shift from code to features in order to be successful.

Open Space, an agile way of meeting

Mendelt — Tue, 09 Jun 2009 06:00:44 +0000

Last year I went to the European Agile Open conference, two intense days of meeting interesting and interested people and talking about all aspects of agile. I don't think I ever learned as much in two days. The conference was held entirely in the open space format and one impression I left with was that lots of the ideas we talked about there were also applied in the organization of the conference.

This week I had the pleasure of helping to organize my own open space event. The Open Space Code day in the Netherlands. We copied this idea from Alan Dean who has been organizing events like this for some time in the UK. I got the same impression, the dynamics are different, the goal is different but the event certainly feels like an agile project. I want to have a look at the similarities and see what we can learn from it.

What is Open Space?
Open space is quite popular in the agile world. I think this is partly because it feels familiar to most agilists. But for people who haven't had the pleasure of participating in an open space event here's a short introduction. If you want to learn more about this you can visit the open space institute website or read Harrison Owen's book.
Open Space is a way of making conferences interactive and self-organizing. Speakers and sessions aren't pre-planned. At the start of the conference attendees take time to propose sessions themselves. Usually you get more session proposals than the available time and space allow. So sessions are voted on and the least popular sessions are cancelled or combined to form new sessions.

Focus on communication
This is what makes an Open Space feel like the coffee break in a normal conference. And I mean this in a good way. I went to the Microsoft dev-days last year and I even skipped some sessions to be able to talk to more people instead of just listening to speakers.

Open space sessions are interactive. There are no prepared sessions but when you have a room full of people interested in the same subject you don't need preparation. The combined knowledge of people the people in the room is probably greater than that of any one speaker. The trick is sharing that knowledge in an interactive way without anyone dominating. Open Space accomplishes this with the 'law of two feet'. People are encouraged to leave sessions they're not participating in or learning from. This makes sure sessions stay interactive or at least interesting.

Fast feedback
Fail Fast is a mantra often used in the agile world. Agile methodologies add many short feedback cycles to projects to make sure that when you're doing something well you know it and when you're doing something wrong you spend the least amount of time doing that before things fall over. The 'law of two feet' also helps sessions failing fast. Sessions that are not interesting any more bleed-dry to open up space for more interesting sessions.

Prioritized backlogs
Agile teams always try to do the most important work they could be doing at that time. They have a very simple and obvious way of doing that, the prioritized backlog. Just make a list of work-items and make sure that what's most important to the customer is at the top of the list at any time.
The Open Space planning process is just as simple. Sessions are planned at the start of the event and are prioritized by voting. During the event sessions are merged, re-planned and moved continuously to make sure all sessions are the most interesting sessions possible.

YAGNI
You aint gonna need it! Don't make assumptions about the future if you don't need them today. This is how agile teams keep themselves from making large investments of time and resources that will not pay off. Open space also does this. Sessions are not planned until the last moment. People don't like uncertainty so this might not sound like a good thing to you. But in practice this makes sure you don't commit to things that later turn out to be less than optimal.

Self organization
Self organization is of course everywhere. Any group of people will self organize into something, groups of football-hooligans are also self organized. The 'trick' is to steer this self organization and use it to accomplish your goal. Agile projects are very good at enabling self-organization within teams. Teams pace themselves and divide their own work.
Self organization is even more central in open space than in agile. Given a couple of basic rules all attendees will self-organize into groups for sessions. The

So what can we learn?
The biggest surprise for me was to see self-organization work in the formation of teams. Agile enables teams to self organize to do work. It was fun to see larger groups of people actually self-organize into teams to tackle a set of tasks and then re-organize for the next set of meetings. Many agile organizations are flat at the team-level but the teams themselves are actually organized hierarchically. Look at the scrum of scrums for example. I can't help but wonder if we can't be more effective by introducing self-organization on this level too.

Open space can learn from agile too. The only official planning session is at the start of the conference. This makes the session schedule less fluid than it could be. People are allowed to re-schedule sessions but because there is already a plan in people seem uncomfortable doing this. Agile only plans one iteration ahead and this makes the whole process more fluid.

Agile principles work outside of software development. Things may look different because time-scales, tasks or roles are different so things may not be immediately recognizable as agile but it's very informative to compare these ideas. Right now many agile teams are adopting ideas from lean production for example. But there are more practices that we can learn from. Open space is one of them.

Are you efficient or effective?

Mendelt — Thu, 28 May 2009 05:52:34 +0000

Efficiency and effectiveness are two words that are often used interchangeably. Many methodologies promise 'increased efficiency and effectiveness'. I find this strange because in a rapidly changing environment like software engineering these two are often mutually exclusive. I think in order to understand agility it’s important to understand the differences between these two and the tradeoffs you are making between them.

How to be efficient
Traditional production techniques based on Scientific Management developed by Frederick Winslow Taylor about 120 years ago focus almost exclusively on efficiency. They does this by standardizing methods for performing work so workers can be interchanged easily, simplifying tasks by splitting them up into many simple subtasks that can be assigned to specialized workers and by increasing batch-sizes so many of these tasks can be done in series.

These ideas have also been applied to software engineering. The process can be split into analysis, design, implementation and testing. Workers then specialize in one of these tasks. By making sure that the result of each of these phases are meticulously documented it also becomes possible to move people on and off projects to maximize the amount of work they do. By performing these tasks in big batches, first all analysis, then all design etc. efficiency can be increased even further.

This allows you to do the maximum amount of work in a minimal amount of time. Unfortunately there is no way to know if you are doing the right work and if you are delivering the right quality until the end of the project. And even then it's hard to see where the real problems lie because the client did sign off on the documentation after every phase of the project. Efficiency is easy to measure and easy to manage. That's why it gets a lot of attention but by focusing exclusively on efficiency effectiveness suffers.

Become more effective instead
If you want to do the right work instead of just doing a lot of work you need to address a couple of issues. Lets look at how agile addresses these

First of all we need to make effectiveness more visible. We need to get rapid feedback when about the effectiveness of the work we're doing at any time. Is the feature we're implementing solving the client's problems? In order to do this agile methodologies have several feedback loops built in. TDD allows us to check the quality of our code continuously. Pair programming provides instant code-reviews but most importantly by delivering working code often we get feedback from our clients.

In order to be more effective we need to be flexible. When requirements change we need to be able to change direction too. This can be done by minimizing work in progress. By working in small increments and finishing all work after each increment we're able to re-evaluate goals during the project.

Splitting up work and having different groups of people work on different phases of a project can also be ineffective. Information is lost between phases of the project. Even when an analyst has the right idea about what software needs to be built this information is worthless when not communicated to the rest of the team. Agile methodologies address this by collocating teams. Documentation should not be the only means of communication.

So what's it going to be?
So you can't have both. What should you choose? Effectiveness or efficiency? Like always it depends. But trading in some efficiency for effectiveness will often turn out to be the right choice. There's no use in running very fast if you don't know if you're running in the right direction.