10 Signs that Your Team Isn’t Really Agile

[UPDATE – This post was recently translated by Choepidiui (I hope I got the name right) into Korean. For the Korean version of this post, please go to his site]

With all the hype in the software industry about Agile, Scrum and so on, it is no surprise that many companies hear or read about the virtues of these methods, perhaps at a conference or in a technical white paper, and think “we need this here”. Unfortunately, some organizations are not as ready to make the mental shift required to embrace the agile way of doing things…

Below is a (by no means conclusive) list of signs that your team waded in toe-deep, rather than going the whole nine yards:

You might not be truly agile if…

1. Your team is not responsible for the entire story

Perhaps the most important aspect of an agile team is that it is cross functional. This means that the team, as a whole, have all the skills required to deliver a valuable product increment. If a team has only client developers, then all server-side tasks are probably relegated to a different team. In this case, the team is not handling a story from end to end; when they complete their work, no value has been added to the product – not in the eyes of the customer! Teams that work like this resemble a factory where the product sits on the conveyor belt and different layers are added to it by different teams. At no moment till the last team does its thing is the feature (or product) done.

It is possible to have a successful development process without cross-functional (feature) teams, but it simply isn’t agile.

2. Testing is done by another team

Another equally important quality of an agile team is the ability to deliver a working product increment. If the developers call a feature that has merely been coded and not tested “done”, then there is a serious flaw with their definition of done. This is often another example of not being cross-functional: QA is simply another team. In order for a team’s work to be considered done, it should be tested and integrated and ready to use.

3. You are not INVESTing in your user stories

INVEST, is a mnemonic acronym coined by Bill Wake that describes the values of a good user story: Independent of other user stories, Negotiable scope up to the sprint in which they’re developed, Valuable to the end user or customer, Estimable by the development team, Sized appropriately so that the team can complete a few of them in one sprint, and Testable so that the team can prove that they have successfully completed the requirements.

Only if the product owner INVESTs in the stories, will he be able to order them by their value to their customer, and be able to promise that when each is complete, the customer will receive a valuable increment to the product. Likewise, the team will be able to deliver these increments rapidly, and with confidence in their quality.

4. Tasks are assigned to team members by a manager

In a truly agile team, each member can pick which tasks he or she will work on next, as long as it pertains to the next most valuable user story. Traditionally, project managers or team leaders would assign tasks to team members, often months in advance. Even though this is done for the sake of optimizing a project schedule, it is a wasteful process that can’t possibly take into account how the entire project might change over time, nor what the team members’ skills and desires might be at the time.

A team member may want to focus on improving his skills, or try to learn to do something outside his comfort zone. A responsible, self-managing team will find a way to make sure the tasks get done as soon as needed and in line with the reality of the project as it is at the present. The best the manager can truly hope for is to get out of the way. Besides, he has more important things to do.

The only time a project manager should expend the effort of allocating resources is when a task requires a resource that the team doesn’t have. Those should be few and far between. If this is a recurring issue, it is a sign that the team isn’t cross-functional enough (see the first point, above).

5. Your team is told how much work to commit to

If a PM gives the team a certain set of resources (members), a deadline (release or sprint), and then tells them how much work they should commit to (or vetoes their commitment), then the project manager is guilty of attempting to break the iron triangle. A team should be able to commit to as much work per iteration as they believe they can (and should base their estimates on past experience).

If this isn’t the case, then there is nothing agile about the plan; the plan was set in advance, etched in stone, and you aren’t willing to renegotiate it, even at the implicit expense of quality.

For a team to be truly agile, it must be accepted that the plan might be delivered with less than all of the stories originally planned (and it should be the least valuable ones that get booted).

6. You are reporting rather than discussing your progress

A subtle and insidious sign that you aren’t really agile is that you report your progress to the project manager scrum master, not to the team, at the daily stand up meeting. The meeting is there so that the (entire) team will have a sense of what each other is doing, what they are stuck on, and what they are planning to do.

Despite the seemingly managerial nature of the three questions asked (“what did you do since then last meeting?”, “what are you planning on doing till the next one?”, “what might block your progress?”) , the questions are not there for the manager to keep tabs on the team, but to elicit another team member’s thoughts on the matter (“can I help?”, “does this affect my tasks?”, etc.).

Each team member should be addressing the rest of the team. The PM should be there to listen, and perhaps answer questions; he should not become the focus of the meeting.

7. You are not focusing on completing the most important user story

Sometimes, a team may divide their work into stories and break them down into tasks, but instead of swarming on the topmost story and divide the tasks among members, the stories are divided. This has two un-agile consequences:

First, at a given time, all of the stories may be partially completed (regardless of value), instead of part of the stories (based on value), totally complete. This transforms the team and the iteration plan into a waterfall-ish plan, rather than an agile one, as its success is based on the premise (hope) that everything will be completed on time, otherwise, nothing is.

Second problem is that each member’s work has less impact and import to his team members. It is not their story he’s talking about, after all. The other members have less of an incentive to listen and help. The daily meeting becomes a mere progress report that can easily be replaced with a query to the chosen ALM tool.

For a team to be agile, they have to be geared towards working on the same problem, and put all their effort into cranking out complete features, as quickly as possible.

8. You changed to agile last year, and haven’t changed a thing since

Here’s a tricky one – you think you nailed it; you may have brought in an expert way back then, and we worked out a plan, and it seems to work, and now it’s etched in stone and  nobody can change it. Well guess what – you’re missing on an important part of being agile: Actually being agile! Reality changes, new ideas and new influences come up all the time. There’s always something that could be done better.

An agile team holds retrospectives on a regular basis, where they put their heads together to think of what they did right since the last meeting, what they could do better in the next iteration, and what visible actions need to be taken to improve.

These visible actions most often manifest as a change to the work process.

Note: If you are using an IT-based ALM tool to manage your work process (e.g. TFS, Greenhopper, etc., Version One) you should take care to account for the impact of the change on the tool.

Time to Publish

Sometimes there are unforeseeable problems that mean you reach the deadline, and you haven’t completed all of your planned work. If you storm your stories and make sure you deliver one complete story at a time, ordered by priority, you will likely have a good enough product (yes I know I made this point before, but it’s worth repeating…)

So it’s time to post. I know I promised 10 signs in the title, but it turns out that I can’t. At least I came through with the most important ones, fully ready on time, no?

Well, if you don’t feel that way, and you think it is more important to deliver everything, than it is to meet a deadline, then here’s sign #9.

9. You are not ready to release on time with an incomplete scope

If you can’t organize your work in such a way that you’re ready to deliver the most important features, those you’ve completed, at any given moment (especially at the deadline), then your plan isn’t agile. You are likely building your product in layers, like a house, rather than in vertical slices, of product value increment.

An agile product is built one user story (or value increment, or minimal marketable feature – doesn’t matter how you call it) at a time. For more on it, read my post on how to plan agile releases.

Here’s another one:

You can always release the remaining features at a later date, with a minor release increment…

10. You are not getting customer feedback every sprint

At the end of every sprint, an agile team demonstrates the latest increment to the product. The audience may include any and all stakeholders in the project, it definitely includes the product owner / project manager and should, when relevant, include the customer. Some teams use this as some formal milestone to show their progress, and continue with the (original) plan for the next sprint – regardless of the results! This is not agile.

A truly agile team will leverage the demo to elicit comments from the stakeholders about the recent development, to make sure that they are on track, and that if the requirements or environment changed during the last sprint, these changes will be reflected in the product backlog and potentially in the upcoming sprint backlog!

Remember, and agile team embraces change, rather than avoiding it.

Summary

There. That’s 10 signs. I hope you found them enjoyable as well as educating.

So do you have any more signs that should be added to this list? Please add them in the comments.

Assaf.

[EDIT]

11. You’re not agile if you can’t deal with a change in the original scope.

Now, I know I said there’d be (only) 10 signs, but based on early, prerelease feedback, I was asked to add another one. I showed them to a friend of mine before posting, and he liked what he saw. In fact, he liked the idea so much, that he suggested another one that I might add. After the release however, he suggested I change the wording. I hope you like this one better..

Technorati Tags: Agile,Definition of Done,Scrum,User Story