What if you don’t?

Introducing agile into a new organization, big or small, requires careful thought on how to do it. One important aspect is to determine why the organization needs agile. (See, for example, http://www.marcusoft.net/2012/06/experience-report-from-rolling-out.html).

However, this could also be viewed from another perspective.

Let’s assume that you have an organization that is not doing agile. Your organization is not team-based; instead it is running in a classic matrix organization with resource managers owning the resources that project managers are requesting for their projects. Your projects are using some kind of a waterfall model, with requirements analysis, development, testing and deployment as separate, sequential phases. When a project is done, the result is delivered to the end user and to another part of the organization responsible for maintenance.

Your organization is doing okay. Sure, things could be better, but this is the way it has always worked.

You’ve heard about this agile thing, but determined that this is not for you, not for your organization.

 

It’s about the people

Around you, companies and other organizations are changing their way of thinking. Being first in a rapidly changing market place counts, as well as being able to respond to changes in consumer and technology behaviour. For these other organizations, agile methods are necessary to survive. And so they adopt it, run with it, reach various stages of agile maturity.

But your organization do not. It is not for you, and perhaps you do not need to move that quickly; you have your product or niche and that has been working for you so far. Why fix what ain’t broken?

Your employees quit occasionally and you hire replacements. From where? Well, typically, you hire them either fresh out of school or they have been working for another of those organizations. In both cases, chances are your new hires have some experience with agile.

Also, it is very likely that your existing employees will see and hear what is going on in those other organizations, and hear positive things about agile and working in teams.

business-19156_1280So, what is likely to happen over time? Will you be able to keep your best, high-performing employees, or will they quit and start working for one of the other – agile – organizations? Who will want to work in your organization? Will you, after a time, only receive applications from those that did not really like working in a team? Are those the individuals that you want in your organizations? How will you be able to attract the best competence? How much will it cost you?

There are many other arguments that could be made, in the same way – but I’ll stop here, at least for now. For me, agile is about people and their motivations. The point is that this works both ways – just as it is important to find a why (as in ”why should we”), it is important to answer the question what if you don’t. 

The Backlog Team Incompatibility

In theory it is simple. You form a cross-functional team, you set it up with a visual, prioritized backlog, and away you go on your journey towards agile.

In theory, your team can handle anything you throw into the backlog. The team is a software factory that churns out quality code with regular intervals and everybody in the team is happy with their new role as a team member.

Theory – meet Reality. Reality – this is Theory, that I’ve told you so much about.

In reality, all team members cannot – because of skill set or experience or role (or even, in some cases, their long term career plan) – handle (and not even contribute to the completion of) the work items that goes into the backlog. Regardless of the reason, I call this the Backlog-Team-Incompatibility (BTI).

There might be several causes for the BTI to occur – perhaps the team was originally formed for some other purpose, or the team has members with some competence that is no longer required – but it does not matter. Somehow, the BTI must be handled, and sooner rather than later.

The short time span

Depending on the team, it might be the scrum master or the team members themselves that becomes aware of the BTI. A team member suddenly has no more suitable tasks, and the new tasks on the board are simply not a good fit. Do not worry! This happens to all teams, all the time. Take this as an opportunity to pair program, learn new things, share knowledge, work on that system documentation, set up a build server or test routine or something else that the team will benefit from.

The average time span

If a team member consistenly is suffering from BTI, and the team feel that they have exhausted their possibilities of resolving this situation, the product owner must be notified. Perhaps there might be suitable tasks with currently a lower priority that could be worked on? It is in the best interest of both the team and the product owner to keep the team both intact and productive, and if that means that the team temporarily does not completely work on the highest priority items, the trade-off might be worth it.

The slightly longer time span

If the BTI persists over time, the issue must be brought to the team member’s manager. Remember, it is not because the team member lacks

thermometer-309120_1280competence he or she lacks suitable tasks – it is just a ”case of BTI”. Again, it is usually preferrably if a solution can be found without making changes to the team. Perhaps the team member can use training or coaching to find suitable tasks.

The longer time span

If the BTI still exists over a longer period of time, the team member’s manager must take action, and remove the team member from the team. Again, it is not anyone’s fault – it is just an incompatibility.

 A final word

It is important that the issue is discussed early with the product owner and the manager – exactly when depends on your situation, the severity of the BTI and the economy of the project (for how long can you afford to not utilize every team member?). The team or the scrum master can and should try to solve a BTI by themselves, but this might prove to be very difficult. And if the BTI is not resolved, the delivery, the team, and the team member will all suffer.