Can you make it right for everybody?

Yes, you can try as hard as you want. Don't we all try to provide an environment that allows people to grow and be their best professionally?

I think this is an important ingredient for a high-performing team. There are limits, however. For instance if you have a team member who isn't particularly keen to actively support changes. Not that I would be surprised by that. People have different personalities and while most are fine with change for a good reason occasionally there are people who resist all kind of change since they may have different preferences and experiences. And that's fine.

If you have a team member with an excellent skill set and huge amount of knowledge and experience that's fantastic. But what if that very person isn't able to proactively work with other team members to help them becoming better as well? What if you have a team member who doesn't attend the first daily stand-up meeting (aka daily Scrum) and comes in late once the meeting is over? What if on day two the same person comes in late but doesn't join the Scrum although it is still on? What if on day three the person is in the Scrum but doesn't participate actively? What if on top of that you observe that it even seems to have a negative impact on the rest of the team?

I think at some point you need to consider your options. Having one-on-one's for coaching is important and helps in most cases. Attempting to consider individual preferences is good, too. But once the overall team performance is affected, you need to act. And don't let anyone hold you hostage. As a leader and coach you need to keep in mind the future of the entire team and the project and objectives the whole team is working on.

An agile environment is not for everybody. There are organizations that work differently and it seems to work for them. Based on my experiences, however, I believe that agile principles work better if properly applied. In some cases this could mean that you may have an individual on your team who has a different perspective, and you should be prepared for that individual moving on. That's just fair and part of the overall change process for the team (and in fact for that individual, too!). Both the individual and the team are most likely better of.

If you have tried everything you can think of and still it doesn't work out, don't feel like a complete failure. You are not! Think of your team and about where you want to take them. And then adapt and move forward. Don't look back unless you want to learn from the past!

Some Non-Cash 'Carrots'

Leadership sometimes requires finding a 'carrot' to make things happen. Not always does the 'carrot' need to be cash or other monetary items. Let me give you two examples.

In one case I worked with development team that wasn't keen to try pair programming. However, I observed that they were using pretty old computers for development and they were not happy with the performance.

Therefore I purchased a couple of high-end workstation, shiny, brand-new and fast, along with really nice large flat panel displays. I also got a desk for each of them so it would be easy for two people to sit next to each other on those desks. And finally I announced the rule that these boxes are dedicated to pair programming hence the powerful machines.

It didn't take long for the 'carrots' to show an effect. Slowly first but then more and more people tried it. Some only for a short time, some for more. And eventually I had to get more such machines and the team was totally hooked.

In a different case I was working with a team that was sitting on very old C++ code. The available tool set was appalling, and so I gave the team the direction to get onto Microsoft .NET, in particular C# where a much better tool set would be available, including good refactoring support, unit testing, and better libraries. And all the memory management crap would disappear as well.

Again it was close to impossible to get there. And some of the reasons given were just fine. For instance there were significant technical obstacles to make that shift easy.

Therefore I asked one of the team members to find out how to move the native C++ code to Managed C++. Sure, that wasn't straight forward either but it was an enabler and good step in the right direction. As a consequence it became much easier for the team to mix and match Managed C++ and C#. And since the tool support in C# was much better, more and more code was eventually written in C#.

These are just two cases where using an appropriate 'carrot' helped the team to move faster towards a desired outcome. Sure, in particular the second example is a bit special. Yet, I am sure that you are able to find more 'carrots' which work in your particular situation. I'd be interested in what you find out!

Decision Making Styles

Making decisions is probably one of the most important activities of any leader. There are plenty of different ways to make decisions. I like the way how it has been described in Peter Senge's book "The Dance of Change":

• Telling: Make a decision and just tell the team.
• Selling: Make a decision, explain why you made that decision, then tell them to do it.
• Testing: Identify a problem, present your solution and ask for the team's comments.
• Consulting: Identify the problem, tell them you don't have a solution and ask them for their suggestions.
• Cocreating: Identify the problem, then come to a decision as a team.

While cocreating probably creates the most buy-in from your team, you may have to make decisions using one of the other styles occasionally. For instance you may have become the team leader only recently and a problem is so pressing that any further delay creates a lot of additional damage. Then it might be right to just make a decision, explain it and then have the team execute it (Selling).

One of the factors that may influence the style you want to use is maturity of the team. In very mature and homogeneous teams consulting or cocreating might be very fast approaches. On other teams different factions may simply not converge even if you give the team a generous time frame.

Again, it pays of to adapt to the situation at hand. The more of these styles you can easily work the easier it will be to select the most appropriate one, and still get decisions made both fast and properly.

Can Agile Keep You From Being Successful?

It certainly depends on what kind of career you are looking for. But sometimes if you want to become a leader you may find that being an expert on a non-leadership subject can actually keep you from being successful.

Some authors - I don't want to give reference here since I was looking at German authors - use a model that takes different thinking styles as a starting point. The knowledge focused thinker tries to become and stay an expert on a particular subject. And a person that is an expert may even have the fear that someone comes along who is an even better expert. So they frantically work on become and staying the "best". They may start to defend their beliefs and knowledge, ultimately coming across as defensive, academic, or even arrogant. Non of these perception will help if you want to become an agile leader.

As a leader you are still a subject matter expert. However, instead of being an expert on Crystal, Scrum, XP, or the like, you become an expert on agile leadership. You can delegate the agile practices to people in your team. After all: If you have coached your team over an extended period of time there should be more than enough methodology champions in your team anyways.

So you can let go without losing influence. You are no more under the pressure to create the perfect implementation of Scrum or XP regardless of what "perfect implementation" means. If XP or Scrum doesn't work perfectly it is not you who has failed. The team as such has not yet managed to adopt and adapt it sufficiently. Depersonalize the particular area from yourself.

A question that might help you to make this change towards re-inventing yourself could be: How do you define success? Is it to get pair programming rolled out through-out the organization? Or is it something different? Maybe you want to provide the best possible service to you customers. Maybe you no longer think in terms of black and white, right or wrong, works or doesn't work. Maybe you want to introduce a third category saying: it helps.

Bottom line: To make the shift towards an agile leader you might actually have to let go of trying to be an expert on an agile methodology to be successful!

Recognition: How do you share Fame and Blame?

A while ago I wrote about Staff Turnover (here and here). In this post I'd like to look at something that you can do for the people on your team. And maybe with this you can help to provide a better environment, a better place to work at.

In some cultures not complaining is equivalent to praising someones performance. The Southwest of Germany is such a place (For those who are familiar with it: "Net g'motzt isch scho g'nug g'lobt").

In other cultures rewarding has take on almost the shape of an avalanche. New Zealand is such a place (Remember all the awards, prices, etc. that you got at school? In some schools there are more awards than students!).

In other cultures appraising each other can become a group decease. The United States appear to me sometimes like that (Ever heard of the group cheering at Wal-Mart?).

So regardless where you live there are cultural differences in terms of how recognition is used to motivate people. And as a leader you can make the difference by sharing the fame with your team, and keeping the blame away from your team (unless they really screwed up in which case you'll probably have a private session with them that you don't want to share outside of your team).

So is recognition about affection? I think these are two different things. People certainly want to be liked. And if they can choose they will work in a place where they and their work is appreciated.

Recognition, in my view, is not about expression affection. Expecting being recognized for a good performance or result is not seeking to be liked. I think people can even "survive" for a while if they are not given recognition explicitly. If that's your style, so be it. Maybe you express your recognition in other ways, e.g. by giving your people a day off, or by giving them stock options, or by asking them taking on tasks that are critical and important for the company and come with more responsibilities.

There are many different ways to express recognition without having to express affection. Some of them are even free. Or how expensive is it to say "Thank you"? How expensive is it to mention people who over years showed persistent high performance despite all obstacles, hung on to the project and the team, and in the end made it happen?

All of this depends a lot of your style. Expressing recognition is important to keep your team motivated. It is certainly not the only means and it certainly is not sufficient. And if you use low-cost tools like saying "Thank you!" you must ensure that you really mean it. If you don't have the credibility of your team, just don't.

An entirely different question is if you give recognition, e.g. by company wide announcement, but don't include the people who had critical roles for the success. If you include only the ones that you interact with most frequently, or if you reduce other people's contribution, don't be surprised if people won't be as motivated next time round. Again this has nothing to do with the need to be liked. It's about ensuring that recognition goes to the right people. And it's not about what you intended to say. It is about what actually did say.

So the questions are: How do you share fame and blame? How do you give recognition to your team and the people on your team?

Hiring

Hiring people is important to the success of your team and project. I strongly believe that you cannot deliver great products if you have a low-performing team. I strongly believe that regardless what you want to achieve with your team, it heavily depends on the quality of the people. I'd like to discuss a few of the principles I use to select people for joining my team.

Elite Team

It is almost like a positive, reinforcing cycle. If you have an excellent team, people will learn about it, and then they want to join that team. This leads to a greater pool of people you can select from, which in turn provides you with high quality candidates you can select from.

So in that sense an elite team, thinking, or attitude is acceptable and even desirable I think. The challenge is certainly to avoid coming anywhere near arrogance. But if you are pushing your team all the time to become even better - to outperform themselves, and if you have hired people with good character and attitude than this is a no-brainer anyways.

Hiring Process

It is important to distinguish between trying to assess the quality of a candidate in general, and assessing how the candidate fits with your team. I think you should focus very much on whether a person fits your team. If a candidate is a perfect engineer but isn't a fit for your team, hiring that person will not do any good. Similarly rejecting a candidate doesn't mean that the person is a bad engineer. It merely says that the person wasn't a good fit for your team.

If given the choice of a) a candidate that is perfect as an engineer but has weaknesses on the interpersonal side, and b) a candidate that is a perfect fit regarding interpersonal skills but has some weaknesses on the technical side, I would always go for b).

Part of my hiring process is a programming task. This is a very simple task with about half a dozen stories. Good solutions typically fit on two letter/A4 sized pages including tests. It is amazing how good that filter works. I have seen "senior" engineers claiming to be experts in Java, C#, and C++. But when asked about the differences of generics (Java, C# - different in both cases) and templates in C++, I looked into a face that spoke a clear language: "I have no clue."

Sure that was an extreme case. But still. If a candidate cannot even do a very simple programming task it won't be much better if the task is part of a regular project.

Team Buy In

I believe this is an important aspect as well. When you hire a person always keep in mind who you expect the new person to collaborate with most of the time.

The technique I use is to basically ask two of my team members to run the actual interviews. At the end of the hiring process those two people then can make a recommendation who they believe is the best fit.

This does not take away your responsibility to make the decision. But it allows your team members to be heard and to voice their opinion about the candidate.

Once your team members have voiced their opinion and assuming you follow their advice, you will find that the buy-in of your existing team members with regards to a hiring decision is substantially higher. At the same time you ensure that you don't overlook something. When selecting new development workstations I ask my senior engineers to look at the specs as well. Why would I want to reduce the quality for the hiring process?

Hiring Managers

Admittedly I don't have a lot of experience in this field. Still I believe that the above principles apply to hiring managers as well. Even if you seek advice from your team the final decision is still with you. After all a commercial enterprise is not a democracy.

By not asking your team members for their thoughts about different candidates you basically reduce the buy-in, and potentially you might even overlook an important detail. You are missing an opportunity for building an even stronger team.

Certainly, your department is your "ship". You can run it any way you like. But I believe that with flat hierachies and with self-organizing teams, and given that we are now in the 21st century, and people are more self-directed and teams are more self-organized, it definitely is a good practice and pays off when you involve your team when hiring, including hiring managers. I don't see why the principles that work for engineers shouldn't work for managers as well.

Just my two cents. As I said I don't have a lot of experience so it might well be that I'm overlooking something here.

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!

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.

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.

Embracing Change: What Stays Constant?

My experience is that many people like to have something that doesn't change. Sure people understand that to stay in the game, we need to adapt as quickly to new situations as possible. Only if we are fast enough, the ability to adapt can be turned into a competitive advantage.

But then I observe the people I work with, I observe myself. And I discover that they as well as myself, we are still looking for something that stays a little bit more constant.

And when we take a closer look there are things that stay constant. We change the tools, we change the architecture, the designs of systems, and retire tools in favor of better tools. We change the techniques and processes. We create a flow of all these elements of software engineering. And yet, there are things that stay the same: It is the values and principles that we apply. The people I work with, and myself, we have chosen the agile values and principles as a guideline, as a foundation for how we work. They provide us with the foundation, with that sense of fixture.

Some of the more traditional projects and teams that I have seen in the past, they, too, have things that stay constant and things that change. They often have chosen the process to stay the same, for instance with all the artifacts that people create, but which sometimes don't provide as much value as they require effort to create and maintain them. And the thing that changes are the values. Sometimes they claim that they respect the human individual, their people's dignity. But then, during the execution of the projects, these are the things that go overboard first. With pressing deadlines people are overloaded, with a shortage of people, contractors are parachuted in, with problems popping up here and there, people are moved around (ever heard of a "Move Meeting"?). Should we as leaders really be surprised, if no hand shows up when we ask the question, whether people feel treated as being human individuals?

There is better ways, and one of the questions we should continuously ask and answer is which elements we want to keep constant, and which elements are the ones where we want our teams to be adaptable. If we decide to keep our values and principles constant, and want to change the way we work, the technology, the design, the tools, the processes, then we are usually in a much better position for success! And all people on our team and the stakeholders will have more fun, too!

P.S. I had a very good discussion today on this subject. Thank you Raymond, Mark, and Curt!

Reorganizing Agile Teams

When you work you most likely will go through a reorganization at some point in your career. It seems that in some companies it is almost a habit to roll out the next reorg before the current one is complete.

I often wondered whether frequent reorgs are a good thing or a bad thing. Until a few years ago I thought that because people are affected reorgs should be kept to a minimum. After all there is always someone who looses and someone who wins in a reorg, isn't it?

My team has helped me to learn better. The current project is now almost 20 months old, and I can't recall all the changes we had in our internal team structure. Many different factors caused us to change the team structure. Let me highlight just a few of them.

Scope: While the overall project objective wasn't modified a lot, the plan for achieving it changed a lot. Starting with a huge legacy code base (over 3 millions LOCs) we thought that using tools was a good idea to move to a pure Java implementation. So we organized the team in several smaller groups, each of which attacked the problem from a slightly different angle. For instance one group focused on how the code base could be restructure, and a different group was looking into converting screens from an old implementation to the new one. In doing this we learned that the automatic conversion wouldn't work for us for various reasons. So we decided for a new plan, and luckily we had the management support for now rewriting the application from scratch. Not an easy thing to do for a small company! As a consequence we changed the structure. I can't recall any major issues on the people side. The team understood that we had to adapt how we worked.

Team size: In August 2006 our little company was acquired by First Data Corporation. After the initial issues that typically follow an acquisition were solved, it was decided to increase the size of our team, and we started hiring. At that point the team consisted of two groups and each of them worked mostly independent, but we rotated engineers once in a while to keep the architecture and design of the system simple, and also to promote reuse across the groups. With the increasing team size we have realized that we had to change again, and therefore we regrouped again. Now some of the groups are almost too small (just one or two pairs). However, we have currently 16 openings (see First Data Utilities' website) and so the groups will eventually have a good size again. It's too early yet to tell whether the new setup will work for us.

Team maturity: Initially we had three co-located subject matter experts. Over time as the team matured and the interaction between the subject matter experts and the software engineers intensified, we realized that the subject matter experts were becoming overloaded, effectively a bottleneck. So we added two more, and we plan for another one or two over the next 12 months.

These were only three examples of what leads us to adapt over time. In essence, we reorganized as necessary and we are much more flexible than in companies I worked with previously. So agile teams seem to be different in that sense too: They continuously search for better ways to develop software. This teams has proved that it is capable to not only adapt architecture, design, toolsets, process, and technology. They have also developed the capability of continuously assessing the team structure, trying something new, discarding things that didn't work, and keeping things that did.

In closing I'd like to encourage you, the agile leader, to try this with your team as well. It's not easy initially, but it works and pays off!

Two Hour Technical Task Too Much?

Our recruitment process includes a programming task, which we give candidates as a preparation for the first one hour interview. The task is typically very simple and it is possible to complete it within roughly two hours. The intention is to assess whether a candidate is a) able to solve a simple task independently, b) able to demonstrate know of how to ensure quality (e.g. automated tests), and c) willing to invest that time for joining a team of highly skilled people.

In over 100 applications in the recent months we have never had any complaint by the candidates. Instead we see good results with regards to the performance of the successful candidates.

However, there was one case where a candidate sent an almost "rude" response after he received the programming task:

"IMHO only a fool will spend 2 hours sitting for a technical test without the employer having gone through some trouble to have a pre-selection round first."

And later he added

"I happen to be not only adept on the technical front, but also socially observant and capable of making (mostly correct) strategic decision."

Do we expect too much? I know of several other companies who use technical tasks for engineering positions as well, for example ThoughtWorks.

In this particular case we decided to not invite the candidate based on him not being willing to comply with some simple rules which are part of the policy of our company.

I wonder who else is using technical tasks as part of the recruitment process. It would be great if you would be willing to share your experiences.