No More Iterations?

Here is an interesting thought: What if we could make iterations so short that each "iteration" contains only one story? What if we drop the term iteration altogether once we are there?

How would the development approach look like? Wayne Allen describes in his post what he tried with his team.

What would be the benefits?

Well, you might not need to think again about how to assign engineers to teams. Just create you teams once and then give each of them a board with a backlog that has a small number of slots. Once the team has finished one story you can add another one.

You can save the iteration planning sessions thus saving valuable engineering time.

By measuring how many stories each team can process per time unit (think nano-projects?) you might get to the point that you have a metric that you can use to measure through-put.

I haven't tried it yet, but it looks like something I would want to take a closer look at.

Variations on Pair Programming

Text book: Switch your programming partners frequently, preferrably more than once per day.

In this post I'd like to discuss variations on the topic that teams I work with have tried.

For instance, assume you have a large number of new people on the team. Everything is new to them, system design, technology, tools, and process. Where to start? To the newcomer the environment might be an insurmountable road block.

One option is to leave the newcomer on a story until the story is finished, and then swap the experienced person between stories. The benefit of this approach is that the newbie can stay focused on just what is needed to complete this story. The drawback is that the experienced person has almost learn from the start when swapping from one story to the next. Remember that the newbie isn't used yet to giving a 10 minutes run-down of what has happened so far.

Another option is to leave the experienced person on the story and swap the newbies around. Benefit: The experience person becomes the knowledge carrier and ensures consistency in completing the story. The drawback is that the newbie has to start all over again, which might add to the frustration.

A compromise might be to select stories in such a way that newbies can work as a pair by themselves on a simple story. They might be slower but they will make progress. If they get stuck they can get the coach or another experienced developer involved. The pair of newbies can stay on the story until completion.

Pairs that consist of experienced people can continue to work at full speed except when they need to mentor a pair of newbies.

This is by far a complete list. I wanted to show that there are variations on pair programming that are worth trying. And over time you will observe whether it works or whether you want to discuss with your team how to adapt.

Among my teams, there is not one approach that is used by all of them. Different teams use different approaches towards pair programming and inducting newbies. But that is ok as long as the underlying agile principles are followed.

Supplyside Agility

Relationships with suppliers can be organized in more than one way. For instance you could just buy certain components of the shelf. Or if you need a very specific component for your product or project you can gather the requirements and then create a formal RFP (Request for proposal) and invite potential suppliers to submit a bid for the work.

But there are many different factors to play with.

For instance if you have created an RFP there are still a lot of different ways how you work with your supplier. For instance you might decide that for a simple (software) component you specify the interface and a number of tests. These might be functional tests only, or they might also include non-functional tests such as performance or load tests. Then you invite different suppliers to bid on that work and based on criteria such as cost, speed, reliability, etc. you commission the work with a particular supplier.

A different option for the same type of work could be that you slice your system or product in such a way that a development partner becomes responsible for an entire functional area. This responsibility would include not only the implementation but also the testing, the user interface design, and the performance engineering. The development partner might also be required to acquire sufficient domain knowledge for that functional area.

Regardless which option you choose, the more options you have the better you can tailor the setup to your needs. Or in other words you adapt the working relationship according to the type of work, the type of supplier, and possibly other factors. Some work you might even consider to put on a site like RentACoder or similar. Other, more complex work you would either do in-house to preserve the capability or to protect your intellectual property.

The more options you have at your disposal, the more adaptible you are, the more agile you will be and the more likely your project to be successful. Agility is not only about JUnit or XP or Scrum. Agile principles can and should be applied to all other areas of project management as well, including the supply side.

Agile and Free Flow of Information

In his February 07 blog post ManagePro's CEO Rodney Brim discusses the relationship between being fast and managing information.

I like his post very much. However, ... in my post I'd like to discuss one particular aspect that I think needs some further discussion.

Rodney writes: "...the relationship between being fast or Agile and how..." - I think that being fast is not the same as being agile. I think that agile is about adaptability while being fast is about efficiency. Agile is about the ability to adapt for keeping the business fit in an fast-changing environment. Learning about changing environments and learning from past experiences requires the storage, retrieval, and distribution of information.

A lot of companies use paper or it's electronic equivalent for storing and transmitting information. While this has it's benefits for long-term storage - with proper backups it lasts forever - it has also it's drawbacks.

For instance, if I need a piece of information and I can easily recall it from my memory then this is the fastest to obtain it. If I have a colleague sitting next to me who I can ask and he has the information available then that's probably the next best solution. If I have to sit in front of a computer and enter a query I might get pages and pages of search results, even if I am fortunate enough to have a specialized search engine or even if the body of knowledge is stored in a good intra-corporate wiki. So this type of search tends to be very slow.

So depending where information is stored and what kind of access path I have, information is easy or harder to obtain.

But there is at least one more aspect. When two or more people communicate they again can choose different media to exchange information. After all, whatever one person is saying to a different person is nothing more than sending a small piece of information even if the content might be very simplistic. "How are you?" might carry the information about me caring about the other person. Saying "How are you?" in a face-to-face situation has a different effect than saying the same words on the phone, writing the same sentence in a hand written letter, or writing them in an email.

When I work with my people from my team or people from other teams, e.g. stakeholders, suppliers, customers, I am always on the lookout for difference in understanding of different people. When I spot such a difference I try to organize a face-to-face meeting of those people. I try to get them into one room and make them talk to each other.

I also share with my team as much information as I can. Although this certainly has it's limitations where privacy reasons of individuals or confidentiality of company information gets into the game, but it is an important factor for establishing trust.

Here is another way to describe my approach: In order to make my team more agile I try to "grease" the free flow of information. Only if the important information gets to every team member as quickly as possible the team can react in a timely fashion.

The same applies to reporting. I create reports on a weekly basis for the projects I'm responsible for. The stakeholders are informed at the earliest possible time of opportunities and challenges. Giving enough heads-up time with accurate information is probably one of the best things you can do to support your manager and other stakeholders.

So in that sense a lot of the information we circulate in my teams becomes tacit knowledge in the brains of the people.

As that is not always the best way to store information we also employ a wiki for information that we believe is valuable for long-term storage. And there are other media that we use as well such as spreadsheets, pion-boards, white-boards, etc.

So to become an agile organization it is important to use the most appropriate medium and channel for distributing and sharing information. As a collateral it is interesting to see that an organization that is very adaptible - that is agile - is at the same time also very lean and as a consequence very efficient and fast. In contrast a fast organization might be highly efficient and might be able to process service requests, product manufacturing, or software development tasks extremely fast. But if the environment changes that very same organization might have tremendous difficulties to adapt to the new conditions.

There is (at least) one more way of looking at this: Being fast is about optimizing towards efficiency while being agile is about optimizing towards adaptability. Both can be competing objectives at times.

In summary: I believe that an agile organization is very likely to be fast. But a fast organization is not necessarily agile. The other item I learned from practice: Free Flow of Information improves an organizations adaptability.

Monitoring and Tracking Projects

Need a template for monitoring and tracking your project? Here you go. We have created a simplified version of the tool we are using in our projects, too. The spreadsheet is prefilled with a sample backlog for a hypothetical project. It assumes sprints of 1 week and a release cycle with 12 sprints.

The template includes graphs for the actual velocity and a burn down graph. If you have questions and/or suggestions for improving the template please use the contact details at the Agile Utilities web site.

Oh, and here is the most important link, the link to Agile Tracker. And of course this template is free.

Software Quality and Tools

Being curious I thought I'd google for "software quality tools". There were approximately 23.8 million hits. I don't know how many tools this represents, or the type of tools, or the effectiveness and efficiency of those tools.

23.8 million hits represents a large number. Apparently there is no shortage of information and tools for improving the software quality. Why is it that we still have significant bugs in many software products (recent examples: here, here, and here)? Why are still many customers dissatisfied with the quality of software (indicators are mentioned here, here, and here)? Well, sometimes customeres might be satisfied because they have such low expectations which in turn were cause by poor quality in the past.

So, how to address this problem? I don't know the complete solution. I do know, though, that the longest journey starts with the first step. And here are two suggestions for what those first couple of steps might be for your organization. Introduce the following two rules:

1. Continuous automated build. Make sure your software system, component, etc. is built multiple times a day. Automatically. With feedback to all developers working on the code base. And if the build is doesn't pass (it's broken) then lock down the source control system until the build passes again. This might be quite disruptive at the beginning. But imagine what behavioral changes this rule might cause? For one you will notice that your people will start to be much more adament about the quality of their change set. Who wants to be the reason for a broken build? And then it also triggers off a continuous thinking about how to improve the toolset, the code, the tests, etc. so that it becomes easier for every engineer to produce quality code.
2. One automated per bug. Let's assume you are not happy with the number of bugs in your software. What if for every single bug your engineers fix (at least) one automated test has to be added to the automated test suite? What if that automated test reproduces the bug and when the bug is fixed the test passes?
   This rule makes most sense if each automated test is added to a test suite that is run as part of the automated build (see rule 1).

With the above rules you start building a comprehensive set of automated tests. Some may say, we have always been doing that. That might be correct, but my experience tells me that some organizations simply run the suite of tests only when they test the entire system, after the "development phase" is complete and just before the new version is shipped.

Also in some cases people claim that rule 2 cannot be used with legacy systems because writing such tests is too expensive. Again, that might be correct. If that is the case it would be an additional indicator for the (lack of) design quality. The system is too hard to test. Enforcing rule 2 will help to enforce a refactoring or redesigning of the system towards better testability. Also, lacking organizational discipline (or time) - bugs are simply fixed without writing an automated test and then simply shipped after a quick manual assessment. This is far from what is ideal.

By adding one automated test at a time to your automated build - now including an automated test portion - your system will increase in quality over time. A single test won't make a difference. But as your test suite increases in size it will cover more and more of your system.

And here is another observation: When a bug is reported which areas do they tend to be in? Typically you'll find them in frequently used areas or in areas that are particularly flaky. By adding automated tests in these arease you actually target those areas where you get the biggest bang for the buck.

Note that the two rules can be used for both new development and legacy code bases. There is no excuse for not even trying to improve the quality. It doesn't require myriads of expensive and complex tools. Simple rules like the above can help improving organizational behavior towards better (software) quality.

Setbacks

What do you have to anticipate when you have a large number of new members on your team? This doesn't necessarily mean that the new member are really "new". They might have worked for an extended period (several months) on a different project or product.

One likely consequence is that people may no longer be as familiar with how your team works. Or in the case that they are in your team for the first time, they don't know at all how your team works.

At the beginning of this month quite a few new people joined my team for the next release cycle. They are all good engineers, keen to deliver good quality. Yet, this week it happened that although the continuous build was broken, a few more commits of the code base were made.

This was definitely not their fault, and it also was resolved very quickly. The team leads chose a good way by simply talking to the people and explaining to them why it is important to stop committing more change sets if the build is broken. Apparently some of them came from a background where this was not as much encouraged as it is in my team.

In my view there are more than one lesson to learn from this:

• If there are new people - either from other teams or new hires - you have to expect setbacks, even if you conduct a proper induction to the new team members.
• By working in a co-located team, and by using pair programming as a default, such setbacks do not go unnoticed for very long.
• If you have helped your team to become self-organized, you don't need to step in. The team will take care of such issues themselves. They will find good approaches to resolve such issue immediately.

So, don't be afraid of such setbacks. It pays off to have the courage - one of the agile values - to delegate decisions to the team. They become much more self-sufficient, and setbacks are handled much faster and without your intervention.

I think my team did a great job here. Although they were not "hoping" that something like this would happen, they behaved exactly as expected. They simply helped the new team members to learn and that way to become even better team members.

A Nice Story On Estimates

The stereotypical conversation between a manager and a software engineer in a more traditional company goes as follows:

Manager: "I have this piece of work. How long does it take you to complete this?"

Engineer: "It'll take me about 2 months."

Manager: "That's great but let's push the envelope. I think you can do it in 1.5 months."

This is overruling the estimates, and in my experience a big no-no. It is ok and depending on circumstances even helpful to ask guiding questions. E.g. you might want to ask: "What if we implemented this using [xyz] ?" or "Did you consider [abc]?"

Guiding questions help avoiding over-engineering or misunderstandings in the first place.

Today I experienced a different dialog. The manager in the following scene was me:

Manager: "I have this piece of work. How long do you think will it take to complete this?"

Engineer: "It will take about 2 months."

Manager: "Ok, so to be on the safe side, should we say it takes 3 months?"

Engineer: "It will take about 2 months."

And then he went deep into the details to explain to me what tasks would be required for the job.

Bottom line: I observed something extremely positive here. The engineer insisted on his estimate, and I think he was right. He was the person closest to the problem and with the best expertise to make the call. How could I dare to question this if I didn't have better arguments?

Ben, who was the engineer in this particular case, showed me that the above rule also works the other way round. Don't just change the estimates if your best engineers give you an estimate. And this applies for both, decreasing and increasing the estimates. Thank you, Ben! I shouldn't have questioned your judgement in the first place.

Impact and Mitigation of Staff Turnover

In my last post I explored the reasons for staff turnover. Reasons can be monetary (e.g. salary) and non-monetary. In all cases the departure of a team member has consequences, some of which may become visible months later.

Example. For one release cycle a project team signed up for a backlog of 70 stories. Two weeks into the release cycle (12 weeks in total) the team got together and identified a few stories that were too large to fit into one iteration (1 week). As a consequence the backlog grew to 80 stories. The team asked the customer to re-prioritize the stories to identify the low priority stories that would have to be moved to a future release. Not surprisingly, the customer wasn't happy about this as it was perceived as "falling behind schedule". On closer investigation it turned out that the initial backlog contained stories that were too big for acceptance. These stories should have been split or re-scoped before the release cycle started. The person who would have spotted this had left the company just a few months ago. Other team members weren't sufficiently aware of the impact large stories could have. The team learned their lesson and it is unlikely that the same mistake will be repeated.

The important lesson to be learned is: The consequences of the departure of a staff member become apparent only as time passes, and sometimes this can be much, much later.

How could the mistake from the example be avoided? I think that it is important to re-emphasize the rules of the game as often as possible. You might sound like a "broken record". But consider the consequences if you don't repeat "the tune"...

The example also demonstrates that when a team member leaves, some knowledge and skills disappear as well. What are the options to mitigate the impact?

Agile methodologies provide quite a few techniques and tools that you can use. In particular all techniques and tools that foster communication, collaborations, and learning are suited to reduce or mitigate the impact to a large degree.

Release planning involving a good cross cut of different roles - developers, testers, customers, performance experts, technical writers, etc. - ensures that all relevant aspects are considered. Techniques like Agile Auction (aka Planning Poker (TM)) help to detect uncertainties or the need for further discussions.

Frequent reviews help to identify over- or under-engineering. Do you really need all these bells and whistles? Are the features implemented in a really compelling way?

Techniques and tools like Pair Programming, wikis and Show-and-Tells help fostering knowledge transfer and the acquisition of skills.

Keep it simple and try tons of different tools and techniques. Don't give up just because one tool or technique didn't work. If it didn't work, try something else. Learn from your observations. And always challenge your team for instance by asking questions like:

• Given this unsatisfying result can you think of a way how we can prevent a similar situation in the future?
• Given the suggested approach, can we think of an even better way of doing this?

Experiment and try new approaches. Doing that you'll have mitigate a large proportion of the possible impact of turnover.

Reasons for Staff Turnover

People are joining your team. People are moving on. Both can be good or bad. In all cases staff turnover has an impact on your team and also an impact on the relations to other teams, including customers and other stakeholders.

People leave for different reasons. In some cases it might actually be the best option for both the person and the team, if the person is leaving. Sometimes people simply prefer a different working style that is not compatible with that of the team.

A few years ago I had a team member who preferred to work alone and who preferred to work on very complex items. He saw these tasks as unique opportunities and challenges. He was an excellent engineer. The solutions worked and when you took a closer look they turned out to be excellent solulutions. Almost beautiful. However, the person was very introverted and he wasn't able to fully leverage his potential to the rest of the team. In addition the code he created despite being excellent from an engineering perspective as too complicated for the average engineer. The solution was complex, elegant, and still hard to understand as some of the concepts were too abstract for some people. In the end he decided to move on to a different company. It turned out a good development. He was better off because he moved into an environment more suitable for his working style, and the team was better off because the proliferation of the highly abstract code was avoided.

And even more years ago, I had a team member who wasn't able to adopt a new programming paradigm. It was when we introduced object-oriented programming. That was in the early 90s. The engineer tried for many months to come up to speed. Finally he and his manager had to realize that he wouldn't be able to make the required mindshift. We then decided to try finding a different role. Fortunately we found a solution that was beneficial for both the team and the engineer. Instead of simply developing software, he took on a role that contained elements from marketing and presales support. We preserved his experience for the company and at the same time opened up a development path for the struggling engineer.

Fortunately when people leave most of them leave for good reasons. For instance people may choose to move to a different country. Here in New Zealand it is part of the life style to go on an overseas experience (OE). Over several years I saw people leaving for Europe, US, Canada, Singapur, Australia.

Another reason to leave might be that people would like to pursuit a career that is not available within the current company. Sure, you probably would keep people within the company but sometimes it is simply not possible.

Compensation might be a reason as well. My personal preference would be that people don't leave just because of the compensation package. And similarly I don't want people stay just because of the compensation package. I guess I am trying to say that you should be very careful with the compensation package. You don't want just the geniuses (see example above) but on the other hand you don't want to pay just bananas and peanuts either (otherwise you shouldn't be surprise if you are surrounded by monkeys). Compensation is a hygiene factor. You have to have an eye on it.

In my next post I'll explore a little more on the impacts of staff turnover and how to mitigate them using agile principles and techniques. I wish you a Happy and successful New Year!

Some Thoughts on Bugs

The proper application of test-driven development yields in fewer bugs. This experience is share by quite a few people in the agile community. Still, there are bugs. This is not because your engineers have relaxed their quality standards. I think it is because expectations are higher. Customers can be more picky.

A few years ago people didn't dare to demonstrate software if it was only a few days old. After all it didn't go through a proper testing cycle, right? And to a degree - in particular in more traditional organizations - they were right. Quality was poor in some cases. Crashes could enrage even a mild mannered reviewer. But even if it wasn't a crash, bugs tended to be quite substantial in their impact. So showing the software created more uncertainty rather than excitement.

In a newer environment it is possible to show "brand new" software. Depending on your environment "new" means it's just a few hours or days old. Or just take the latest successful build.

When I look at some of the bugs raised today I see that they fall into the category "aesthetics". In the past people wouldn't have bothered raising them because compared to others they would have been negligable in terms of severity.

Does that mean that we should be happy about this? I don't think so. A bug is a bug is a bug. We shouldn't be proud of any bug. Each bug is an indication of a piece of unfinished work. If some bugs are a question of taste then it might be we will never be able to reach zero defects. In that case we should at least see this as an ideal towards which we work. Toyota - despite it's recent hickups (recalls of vehicles, even Lexus) - is seen as the well-recognized quality leader in the automative industry. Does this mean their products are defect free? No, not even close. They are subject to Murphy as well. But they have their unique way of dealing with them. They fix them one at a time. And not only that. They also try to identify ways of how to avoid the same defect from reappearing.

So where from here?

We should take Toyota's behavior as an example. We should still strive for reducing defects wherever we can. And we should do so by avoiding them in the first place. Communicating and collaborating closely with the customer is one of the first and most important steps. Writing your tests first and use them to drive your implementation helps, too. Keep your code simple, readable and maintainable.

And with bugs: Each time one slips through, follow these guidelines:

1. Try to understand the root cause for the bug. Prove your understanding by writing an automated test that fails because of the bug.
2. Make the test pass.
3. Refactor mercilessly.
4. Identify similar scenarios in your code base. Check whether they contain the same bug. If they do, chances are that you have identified another opportunity for refactoring.

Here is another aspect of bugs. Compare a bug to an ordinary story in your backlog. What is the major difference? Generally speaking, a story tends to be easier to estimate in particular if it is similar to a past one. A bug can be anything from "user misunderstanding" to "several weeks" of work. The point is that the amount of uncertainty tends to be higher for bugs.

So if you compile a single, consolidated list of all your work items, you will end up with a mixture of stories and bugs. The larger the proportion of bugs the higher the uncertainty. The higher the uncertainty the bigger the impact if one or more of the bugs require more than the "average" fix time.

So if you are interested to become more reliable (read predictable) then the suggestion is to keep the bug level as low as possible.

Does this mean you can't have crash parties any more? Under all circumstances, if the crash party helps you to assess the quality of your product and helps you to find more bugs, and you if you see value in this, then you definitely should have them. Not doing them because it keeps the bug numbers low, is cheating. You would be lying to yourself.

Also, if you don't fix bugs but keep piling them up, while you at the same time your are "completing" story after story, you are actually reporting a velocity (in stories per week) that is too high. Expectations for the next release cycle will be higher, and it will be even harder to negotiate time for fixing bugs or doing other items.

And more, if your approach results in a similar number of bugs your stakeholders may start asking the question whether your approach is really better than the traditional one.

I'm sure you don't want to let it come to that. So regardless how you look at it: Not fixing bugs and finding ways for avoiding them in the future doesn't help at all. Instead it can be the start of a vicious cycle. And by keeping the number of bugs low, the question of how to deal with bugs becomes a no-brainer!

Tools

No engineer can exist without tools. Tools come in many shapes and sizes. This is no different for software engineers. And there are tools for agile project leaders as well.

For a software engineer most tools are pretty obvious. For instance a compiler, an editor, or a test framework (e.g. csUnit, JUnit, etc.), etc. But then there are other tools that are less obvious. What about the index card that you use for writing your story? What about the cards you use for planning poker (TM)? They are all tools in a wider sense.

An agile project leader has tools as well. Again some are more obvious like a reporting tool that gives him/her the latest financials for his/her projects. But there are others such as if you detect that a group of people is not on the same page in terms of information sharing. Then your tool of choice might be to get these people into one room and get them talking. Communication and collaboration are agile principles and so getting people to do both of this is a tool that an agile project leader has at his/her disposal.

It is important to use a broader definition of the term "tools". If you do you will discover many more tools you are using. Experiment with them. Try out new ones. Drop the ones that don't work for you. Listen to your team members. Often they have the best ideas anyways. Don't put tools away completely that didn't work at some stage as maybe at a later stage their time might actually have come.

Equally important is to look for tools that are simple and easy to use. Keep them as simple as you can get them. No need for an elaborate version control system if you can get away with a simple one like CVS or Subversion which have essentially little more features beyond update, commit, label, or branch.

Simple and small tools are much more flexible. They are easier to learn. They are easier to integrate with your existing environment. They tend to be easier to operate. And you can combine them forming more powerful solutions. If you select a good set of light weight yet efficient tools you can almost use them like Lego (tm) blocks to build the environment you need. And still you stay flexible and can adapt as needed by recombining or reconfiguring your toolset.

An Example

As an example for a simple yet efficient tool let's look at how you evaluate the engineers on your team. Many options exist. In large companies I have found systems (probably running on expensive hardware) which the managers are supposed to use for their evaluations. But there are simpler options. First of all, are you as the manager in the best (or only?) position to evaluate your team? What if you would delegate that task to your team and perform a peer review? What if you could use a simple tool to do that, e.g. a spread sheet that you send to all your engineers to evaluate each other?

You can find such a tool for free here. And here are a few things you can try out:

• Before you send out the actual sheet ask you team to review the categories or the descriptions of them.
• Try out different cycles, e.g. once a year, at the end of each project, every three months, etc.
• Try to expand it to non-engineering roles
• Ask people to also fill in the column with their own name. Is there a big difference between their self-perception and how they are seen by the team?

I'm sure you can find more factors to play with. Let me know how it goes and whether you find this type of tool useful. And always remember:

"A fool with a tool is still a fool." (anonymous)

So always THINK before you start using a tool.

And finally: The agile community would love to hear about your experiences. So I'd like to invite you to participate in the tools stage at the Agile 2008 conference.

To Pair or Not To Pair

Although I have been using pair programming as a standard practice with my teams since 2001 once in a while I still run into the question - usually asked by an uninformed outsider - whether pairing really makes any sense. The naive view is that it appears that two people are doing the work of one so it doubles the cost for most of the items.

Initially I was extremely adament about pair programming. It's called EXTREME programming after all! Quite some time ago I changed my position slightly. Today, when I start working with a team I make it clear that the default for doing any software engineering related work is to pair with a second person.

Does this mean that the people in the team I work with pair all the time? No, not according to my observations. There are quite a few occasions when people work by themselves.

One such case is if people would like to explore a new technology or tool. Different people prefer different learning styles. And before they present their findings to the team for further discussions most people want to understand enough about a topic before using their colleagues time. This gathering of information could be just surfing the web or reading a book on the subject. But it could equally be running a few experiments on a development workstation.

Then there are the usual other activities that most people prefer to do alone, e.g. email, filling in time sheets (yes, there are still a lot of companies who have them), etc. Also, you might want to call your doctor or spouse or log in to your broker without a colleague sitting next to you.

Unfortunately there seems to be only few studies out there on the subject. Laurie Williams' work is available in different versions, e.g. here and here, and also as a book. But some people would like to see additional researchers/authors who come to similar conclusions. Some studies have been conducted in an academic environment, e.g. with students. These studies are easily challenged when you try to use them in an industrial context. (Please note that I'm not saying these studies are useless.)

More generally I believe that reasoning about pair programming using a linear approach doesn't help. System thinking should be employed. Pairing (or not pairing) affects too many other factors. A simple linear cause-effect thinking tends to exclude critical factors.

Based on my observations and experience I would describe pair programming as an activity that has a positive impact on quality, team learning, soft skills, communication, productivity, innovation, creativity, collaboration, training, and many more. To pick one, let's look at productivity.

While many people believe that productivity goes done (two doing the work of one?), I believe that productivity actually goes up (or at least stays the same). My reasoning for that is - again - manyfold.

First of all, some people confuse body time with brain time. Have you ever walked through a development department where people work solo? Run a little experiment. Peek at the screens of the people and take a note of the percentage of people not currently looking at your IDE (or other work related tool). Now, do the same experiment with a team that uses pair programming as a standard practice. Or even better work with a partner and try to track your stock quotes at the same time... I think, you my point. With pairing there is no way to back out or to just doze off. You're in it full time. The ratio of brain time versus body time is much higher than with solo programming.

Next, a pair can and will be much more adament about the quality of the change set they deliver if they are members of a properly trained agile team. They will merciless refactor trying to use the simplest possible design and implementation to get the job done. They will be creative and innovative in doing so. They will have automated tests in place preventing other people from accidentally breaking their code. And once they have committed their change set they usually can focus entirely on the next task without having to go back to some past work.

There are other factors that are worth exploring, but I'll save them for now. I'd like to come back to them in a future post in this blog. As always, I would be very interested in hearing about your experiences and also about your feedback to this post. Thank you!

More on MindManager

Thank you for the comments on my previous MindManager blog entry!

Granted, performance issues can certainly depend on many different factors. According to my information the majority of the users don't seem to have performance issues. But there also seem to be a non-negligible number of users who did experience those issues.

However it is no help to the latter group of users if the former group of user have performance issues.

In my particular case when I observed the performance problems

• There was enough free memory (hundreds of MBytes)
• There was enough free hard disk space
• CPU usage was less than 10%
• No network usage
• No disk I/O

That basically indicates that probably more than one thread is running and a lock conflict is happening with one thread waiting for the other. Eventually a time-out will occur and the software continues to run. This is just a guess based on my observations, and the real issue might be a completely different one.

If you have used and developed professionally many different software products over 15 years then you start to get a sense for when a software has an issue. If a promise is given several times ("Update and the performance issues are resolved...") then I simply stop believing it. Instead of asking me to pay for an upgrade that solves an issues I would prefer to get a properly working version in the first place.

Anyways. Too many words already spent on the subject. I will consider giving version 7 a try.

MindManager, Performance, and Other Issues

For gathering new, complex, and broad areas of knowledge I found mind maps to be a very efficient tool. Although drawing on paper is often faster, an electronic version has it's advantages, too. As a product I use MindManager.

I have been using MindManager from MindJet for a several years now. Performance has always been an issue, but admittedly the featureset has improved over time. Each time there was a new version the company promised that the performance issue would be addressed.

I can't remember which version I started with. I upgraded several times, and currently the version number is 6.2.399 Service Pack 2. The performance with a map of reasonable size is poor. My laptop has no CPU usage, no I/O, plenty of free memory, and no network activity. When pressing the "Insert" key to add a new topic, it is as if the product doesn't do anything at all. It can take many, many seconds until it does something.

Of course I did complain to technical support. The people were very responsive. They suggested to switch off hardware acceleration for the graphics adapter. I tried that, and it helps. Sometimes.

Some observations:

• Suggesting to switch off hardware acceleration is basically like saying "Yes, sure did you buy the Ferrari, but adding our add-on allows for driving in first gear only." I didn't pay for a laptop with graphics hardware acceleration just to hear from a software vendor that I shouldn't use parts of it. That's not what I would call protection of my existing investments.
• Why is it that other software vendors are able to write software that has no issue with hardware acceleration?
• When I disconnect from the network and/or run the computer with batteries, the performance becomes even worse. I have had instances where MindManager didn't respond to user input for 15 minutes or more. By then I decided to kill the program. What has the network to do with graphics hardware acceleration?

A more "minor" issue is the function "Balance Map". If I could only figure out, what it is good for... When I click it, it rearranges the topics, but I can't find that the map is more balanced... Usually I have to print it on larger sheets, or I have to use a zoom of 38% instead of 50% or so.

Now, MindJet has made available version 7, and they encourage me to upgrade. Of course I have to pay for the upgrade. Why should I trust them that the tool has really been improved? Why should I pay for an upgrade if I cannot even get the existing version in a status that allows me to fully use it?

Given my experience I might just go for an open source tool or try a competitor. Maybe there are competitive cross-update offerings... Maybe I try FreeMind. They even claim that their software is faster to use than MindManager.

And another story

Let's see who thinks this time that I'm telling his/her story...

Again, I met a friend, let's call him Peter. Does he really exist? I don't care as that is completely besides the point. It is more about the story which, again, I have heard more than once from different people. In this case the first and the last account are several years apart.

The story goes like this: Peter is working for a consulting company. They developed and delivered a system that collects certain information across large geographical area. Part of the solution is using mobile devices for this, and once per day the data is transferred back to the head quarter to a central server.

The problems started when they started to work on the part of the software that deals with the transfer of the data to the central location. The firewall settings and the security policy of the company didn't allow for a direct connection, not using SSL (or any other secure means) and not even to a server in the DMZ (Demilitarized Zone). Then Peter asked whether they could sent the data via email, e.g. as an attachment which could then be picked up by a server. This solution wasn't acceptable either. Peter's client started internal discussions, and the went on and on.

At some point the delivery date of the project was at risk, and Peter couldn't wait any longer for a decision to be made. He had to come up with a solution.

Peter discussed the problem with his team. After some lengthy discussion, back and forth, they found the solution:

• Print the data
• Fax the data
• Enter the data

Yes, you are right! Faxing was ok. And then some people in the headquarter of Peter's customer would take the received faxes and enter the data manually! Crazy, but it saved the delivery date for the overall system.

Update: In the meantime the customer has settled on a much better solution and the data is now transferred via SSL to the DMZ, where it is picked up and transferred to the server within the firewall.

Morale: Sometimes you have to be very creative and adaptive to make the deadline. I think Peter and his team were very agile!

Where my stories come from

Once in a while people ask me where I get my stories from. Well, there are many different sources but most of the time they develop as I talk to friends.

All the stories I tell in this blog are inspired by true facts and data. However, in order to protect people and companies, I never tell a story that is based on a single account only. I know people working for over 25 different companies from all over the world. Only when I hear a similar story at least twice from different companies I assume a pattern. Then I take the information and use it as an inspiration for my blog.

Sometimes there is also a large difference in terms of when I have heard the different stories. One story I might have heard many years ago, while a different one I just came across recently. Together they may suggest a pattern. One story might have been from a very small compay, and a different one may come from a very large one. One story might be from Europe, and the other from India or Australia. These stories are particularly interesting as they may reveal cross-cultural patterns.

I ask you for your understanding that to protect my sources I will not reveal any names, locations, times, or other specifics that can be used to identify a company or a person or a source. Only where I have the expressed permission from a person or company I can give more specific details. Generally the names I use are not the real names.

Or as they say at the end of the movies: all my stories are inspired by real facts and data, but any resemblance with actual people, companies or events is pure coincidence.

The ripple effects of moving in a release date

When a project is behind schedule several options are typically considered. The schedule is adjusted, the number of people working on the project is increased, or the scope is reduced.

A few days ago I met Susan, an old friend of mine. She is working for a very small software company, and she told me about a project that she used to work on until a few months ago. The project was an online reservation system for hotels, and as the hotel owner decided to go into business sooner than originally planned the schedule for the project had to be shortened by a few weeks as well.

This decision caused a number of ripple effects, mostly undesired side effects.

First it turned out that the staffing level wasn't high enough to achieve a sufficient velocity for the shortened time line. Additional engineers were required. As the company is only a very small outfit, they had reassign engineers from a different team to this project team thus sacrificing valueable work in the other team.

This in turn not only reduced the velocity of the other team. As a consequence the scope for the other team's deliveries had to be reduced.

Also, it turned out that in order to make the shortened deadline the project team had to take a number of short cuts, e.g. by using a less elegant design in some places or by not refactoring code to the degree it deserved.

There were many more impacts, but so far we have:

1. Need to increase staffing level in the project team: additional project cost
2. Need to reassign engineers from the other team: cost in the form of delayed deliveries in the other team
3. Need to clean up the "short cuts" caused rework after the release

Bottom line: Moving in a release date had not only the immediate impact but also cause a number of side effects, each of them causing a number of additional problems and/or cost.

The software has been released a few months ago, and the project team is onto a new project. My friend reckons that it probably will take a few more months until the effects of the changes have been resolved.

On the positive side, Susan's team delivered on time and with functionality and quality as specified. In addition the customer is very happy with her company's ability to adapt to the changed plans. Susan and her colleagues are, however, very aware of the price they had to pay.

Apologies from Agile 2007 Conference Program Committee

In case you have submitted a paper, tutorial, etc. for the Agile 2007 conference, you most likely have noticed that the submission system had a system error. Here is a message from the conference chair on that regard:

I am finding as many opportunities as I can to express sincere apology for an error in the Agile 2007 submission system which caused multiple
accept/reject messages to be sent out. While all of us have experienced errors in our software projects, this is one that inconvenienced many people... for this, I apologize.

We can point accusations at the software developers and testers, but it will not accomplish anything. Instead, it is more effective to correct the error and move forward. We have sent revised accept/reject notices (with an apology) and will make every effort to learn from this experience.

We hope that this mistake will not cause you to overlook the countless other things our hard-working team of volunteers are doing so well in order to make the Agile 2007 conference fabulous in many, many ways.

Mary Lynn Manns
Conference Chair, Agile 2007

Being a member of the program committee myself, there is nothing I can add.

Fingerpointing, however, will not help. Instead, it is important to look at the situation, make the best out it, and move forward. I think Mary Lynn and the other members of the committee are doing this. We all want the Agile 2007 conference to be a success!

A Really Short Release Cycle and An Impressive Quality

Just came across a blog entry by David J. Anderson. His company releases every 9.5 business days and with zero defects since January 2007! Impressive!