Key challenges in Agile implementations

Agile methodology was supposed to be a solution to solve all of our problems. But it looks like it’s not. Some issues appear when companies start to implement Agile in their organizations. A research has been done on seventeen companies using Agile methodology (People over processes: Key people challenges in Agile Development). Authors chose nine of the most often reported issues. I’d like to focus on four, in my opinion, most important.

#1 Developer fear caused by transparency of skill deficiencies

The Progress of each team member’s work is usually reported on daily basis (e.g. on meetings, such as stand-ups). Therefore, every member knows how long it takes each person to do it. If for some reasons, a task took you more time than it should, you can have a feeling that everybody is judging you. Furthermore, design discussion with a whiteboard can highlight technical skill deficiencies or lacks in communications skills. Research has shown that many developers have a low self-esteem because of that.

To prevent such problems team members should feel safe to expose their weaknesses. A good idea would be a second meeting in a small group after the main one. Second thing is that developers should know that they can get help to improve their skills. Junior developers should have a mentor who would help them with their daily issues. Pairing is also an excellent practice. More experienced team members could share their knowledge with those less experienced.

#2 The need for developers to be a ‘master of all trades’

One of managers said, that: “To be a successful agile [developer] you need to be a coder, a tester, an architect, a customer, a quality assurance expert and a multitude of other things software-related”.

It’s true, but how to manage all that in complex projects? How can a tester be an architect and db expert at the same time? Simple he/she cannot. Many companies (according to the research) were sending their employees to all sorts of trainings. But it was expensive and not as effective as they thought it would be.

The solution is not so obvious. Some balance between “master of all” and “master of none” should be obtained here. A team leader should choose team members carefully. Developers should have a broad knowledge of all aspects of the software development as well as business knowledge, but at the same they should be specialists in certain areas (e.g. db experts, architects, and testers). This could be easy within a small team but in case of larger ones it can be extremely difficult.

#3 Increased reliance on social skills

Because of the constant communication in Agile, team members should have good communication skills. Quite often we can see a great developer with poor social skills. This is a great issue when a team member can’t express her/his thoughts to the rest of the team. Developers can often talk to each other but they can’t get along with customers. The Agile methodology assumes that devs should contact their clients directly and talk about specific features.

The most intuitive solution is to send employees to social trainings and, as the research showed, it is the most effective solution. Also recording stand-up meetings and analyzing them seems to be a good practice.

Instead of an individual contact with clients, a group of people can be chosen to talk with them. Furthermore, when creating an agile team, each member should have good communication skills right on the start to prevent problems in future work.

#4 A lack of business knowledge among developers

It is a very common problem in case of larger teams and more complex software. Because each team member can get knowledge from the client directly, the knowledge is later spread throughout the team. After a while it appears that every member of the team is a specialist in a narrow area of software which is being created. And what if one member is on holiday?

Next thing is that not every member has the same knowledge about the domain as the client. This can cause misunderstandings when a different than usual team member has to speak to a specific client. It may even end up in losing customer’s trust in the team.

One of the managers claims that one time his client said: “the team knows nothing about our business so they won’t deliver anything of value to our business”.

It is extremely important that each and every member of the team has some basic business knowledge, in order to speak with clients on equal basis. Differences in the knowledge between team members can be aligned by pair programming and short trainings (inside a company). While pairing there is a knowledge flow between the devs.

Inviting domain expert, as research showed, it is a great solution to lift team members’ knowledge to an upper level of understanding. An overview after each cycle creates an opportunity to talk about the features that each member made and learn how he made them.

As you can see, Agile isn’t the solution to all of our problems. It’s a solution but it has flows like any other. However, in most cases we can do something to deal with them. And remember Agile is for people and people create Agile, not the other way round!

Have you ever experienced any of the mentioned issues? Or maybe you have had other problems? Feel free to share with us, leave a comment below!

Tags: Agile, Scrum