This “Agile” Is Not Agile

In recent years, there is a rising pressure coming from the market. Customers are demanding Agile Delivery methods. My previous article 12 Agile Principles Checklist is about how truly agile project looks like. Unfortunately, not everyone who claims to be agile really agile is. Let’s take a look at some huge warning signs that indicate that this agile process is probably not that agile.

“Big Bang” delivery

The team is not able to deliver any user-valued increment of the product until the project’s end.

Agile projects deliver small increment ideally at the end of first iteration. They then continue in this fashion throughout the whole project.

They control change

They have a formal change management process.

Agile team uses Product Backlog to list all of the features which might be considered for development. Product owner is responsible for prioritizing the features. During the iteration planning meeting he makes an agreement with the team on what can be delivered during the iteration. Items are added into the backlog throughout the whole duration of the project. This product backlog is a living document which can be changed anytime until the project is closed. There is no formal process to make these changes and no additional costs related to them.

One release

The agile delivery method, like everything in business, must bring the business value . If the team claims to be agile but is not able to ship product increments into the production, then it does not bring a lot of value to the customer.

They have separate teams

They refer to their team of analysts, developers and testers.

Agile teams work in a cross-functional setting where team members have different area of expertise. You will encounter analysts, programmers, designers, and testers working closely together on a daily basis. The team is not composed based on their skillset, it is based on the user-valued features they work on.

The decisions are made by the PM

The project manager makes the decisions and assigns tasks to the team members.

Agile teams are self-organized and they solve the issues by themselves. They are provided with the necessary support but do not take orders and are not assigned with tasks by their managers.

A lot of documentation

There is a lot of documentation and sign-offs, especially during the phase closure.

Agile teams are focused on face to face communication and discussions. They utilize user story format of capturing requirements to achieve this goal. They have no phases or sequences in their development process. Everything happens inside of the iteration. This way the hand-offs are so small that there are barely noticeable.

They measure progress on activities

They tell you, that they completed 20% of their analysis.

Agile teams gauge progress based on delivered features. Anything finished that is not done and accepted by the product owner is not taken into account. Anything that has no value to the end-user is not considered as progress.

Relaxed beginning, stressed end

They are relaxed at the beginning and intensify their work at the end of the project.

Agile teams aim for sustainable pace. They are consistent in their effort throughout each iteration to deliver high quality product.

Delivering everything

They do up-front analysis, sign-off the document and then deliver everything what is specified inside.

Agile teams do not conduct a huge up-front analysis. They work with requirements captured in a user story format and deliver iteratively and incrementally. The product owner is changing the priorities throughout the whole project to make sure that just the highest-priority items are developed. Agile team never works in a pre-planned sequential manner, everything is priority based.

Team hierarchy

They have a team lead, test lead or dev lead.

Agile teams have flat structure, there is no one assigning tasks. Each of the team members is equal and needs to cooperate.

No adjustments, no behavior changes

The team never changes its process or behavior even if requested.

Agile team uses periodical retrospective at the end of each iteration. They reflect on their behavior and commit to specific changes for the next iteration to address these issues.