Common Agile Adoption Mistakes05 Apr 2016

Nowadays most companies want to adopt Agile and work alongside the methodology. It's no wonder why, seeing how much positive change and productivity increase this generates, but there are some common pitfalls lurking there, that it is best to look out for:

Common Agile Adoption Mistakes

Poor Team Build

When teamwork cooperation method changes, the team structure is likely to have to follow. Naturally, if your organization has not been Agile previously, your team build was probably not either. A typical Agile team is cross-functional and secure. So, it will have representation of all skills needed to complete an item, and these sets of people will tend to work together on a regular basis. This ensures good quality of work and constant improvement of the cooperation, knowing that the more people work together, the easier their mutual understanding becomes.

The Planning Trap

Since you've just changed the methodology of work, it's unacceptable to assume that the way it is planned does not have to change with it. So, you're now expecting to be delivering more often and in smaller batches, but this shouldn't let you think you just halve the time that was previously needed to do twice as much. The everyday methods are about to change significantly, and this will create an adjustment period for the team. Not only will they have to learn cooperating in a new way, they will also have to readjust their estimations (if you use these at all). It's good to allow a few iterations for teams to learn what their new velocity is.

Not Listening to the Customer

Agile is not only about visual boards, story points and daily stand-ups. The wider concept includes an ability to quickly respond to a changing demand. This is why not listening to what the client is saying builds you a trap. It's normal that the requirements will change and evolve and - unless you're able to adjust and provide for a changing request - you are not only disappointing the client, but also failing to stay Agile and relevant on your market.

Not Letting the Team Have a Say

The relationship between the business-side management and production team is different within Agile organizations than in the traditional ones. From a productivity angle, it's most effective if team members pick their work items themselves, with only the priority level being assigned by superiors. This tends to create happier teams, and most importantly - develop a more responsible approach from the team.

Having said that, making an assumption that the team members will organize everything perfectly well and completely autonomously is also likely to be wrong. Try meeting the two opposites somewhere down the middle by empowering to self-organise, while overseeing the results on a daily basis. Keep in mind, that Agile-typical self-organization is not synonymous with a lack of discipline.

Stopping at a Tool Adoption

It's a typical first step in many an Agile adoption to set the team up in an online Agile tool, which is great, as it gets the team right into the new way of doing. What needs to be remembered here, however, is that the adoption should not end here. You do want the team to work in a suitable cooperation tool, but they also need to be informed of the Agile mindset changes that should take place if this implementation is going to work.

The Agile adjustment needs to happen on all levels, it is not enough to just change the way you assign work to people. Each aspect, from thinking about work items, through planning their build to testing, deployment and feedback gathering need to apply an Agile character, which is: welcome change and apply it with great flexibility.

The Old "Failing to Plan is Planning to Fail"...

You do always need to be prepared. In this case, be prepared that people will resist Agile, as much as folks resist any change. Making changes is tough, so not only would it be advised that you have someone assigned to overseeing the Agile adoption process, you should also consider getting prepared for failure and devising a worst-case scenario plan.

ANd Above All - Don't Idealize Agile

Yes, it can bring great change and improvement about, but it is no silver bullet that will strike a company and turn it around with no effort on anyone's part. It's possible, somewhere down the line, but it can only happen with people trying very hard to make it work. The upside is, from among many an organizational methods, this is likely to be one of the easier ones that you can go for.