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: ,

Aspire Blog Team

Aspire Systems is a global technology services firm serving as a trusted technology partner for our customers. We work with some of the world's most innovative enterprises and independent software vendors, helping them leverage technology and outsourcing in our specific areas of expertise. Our services include Product Engineering, Enterprise Solutions, Independent Testing Services and IT Infrastructure Support services. Our core philosophy of "Attention. Always." communicates our belief in lavishing care and attention on our customers and employees.

6 comments

    1. Thanks for you comment. Good point. As I mentioned in the heading, this article was inspired by research which involvs only first postulate of Agile Manifesto – People over processes. So, as subtitle of this research says, these are only challanges concerning people.

    2. Hi Octo, we also shouldn’t forget about the challenges at the business side. Being Agile might seem nice and easy, but the reality is a bit different. All parties involved will have to adopt to make an Agile process work. I will be presenting about this at the IT Academic days tomorrow and afterwards we will for sure post the presentation here on our blog.

  1. Very interesting!

    I am relatively new to Agile – I don’t necessarily have huge experience with the processes of the methodologies like XP and Scrum but Agile as a basis just makes sense to me. It’s the interpersonal skill requirements (and problems with those requirements) that really fascinates me.

    Do you get rid of your team if they are poor communicators and get a new team? Very costly for many reasons, and not very nice.  And can you guarantee everyone in the new team will be a good communicator?

    Or do you work with what you have and try to help everyone in your team to understand Agile? You can’t force people to communicate but the fear you mention in #1 can be seen as positive. A little pressure is good. We should try to get more out of our developers because it helps our project but it will also help them in their career.

    Of course you have to have a lot of empathy – you should be able to notice when developers are struggling and be in a position to step in and both reassure and help them. (And I recognise that I am someone with that fear – how can you not be when the range of technology we use is so vast)

    But I don’t think we should allow poor communicators off the hook and be allowed to disappear back to their desks and only stare at code. Being out of your comfort zone is (mostly) a good thing.

    And at the same time I recognise your point about some developers being great coders yet poor communicators. You have to think about how important they are as an asset versus driving them away with persistent Agile lectures.

    I have just written a blog post on my new website which I think describes some of the issues you mention.

    http://www.dormantechoes.co.uk/2012/02/the-i-in-agile/

    For me the things you mention can in general be seen as positive in terms of learning what agile means. Yes we should accept there are many issues with Agile but learning about the problems is part of becoming and being Agile. (As opposed to the alternative of giving up and saying Agile doesn’t work).

    I might write a response to your post on my blog soon.

    I always remember a quote I found in an Agile book when thinking about discussions about problems with Agile.

    *****
    “Often, people new to agile development think that if you are doing the twelve or nineteen or eight practices of a particular methodology then you are therefore Agile, or Extreme, or Crystal Clear, or whatever. But in reality, you are Agile, Extreme or otherwise when you know enough about the practices to adapt them to the reality to your own specific situation.”
    – Jim Highsmith, Agile Practice Director, Cuttor Consortium
    *****

Comments are closed.