Adopting agile practices is not always easy.You have to be aware of the challenges that may arise. Let's find out together how to fully confront these challenges.
Using agile techniques for project management has undoubtedly become a trend in the latest years. A peek at the 13th State of Agile report by CollabNet VersionOne reveals that 97% of the organizations surveyed use agile for developing their products. However, adopting agile practices is not always easy. As the same report indicates, more than 80% of the respondents feel their organizations are below a high level of competency when it comes to agile management. So, although agile may be the way to go, this does not mean that it’s free of challenges. In this post I’ll try to lay down three of the most important ones, or, as I like to call them, the ‘three most usual suspects’ to search for when agile is not working for your team.
Probably the most common misconception about agile is that people consider it as just another framework or methodology. For instance, you might find people stating they’re going agile because they decided to use a Kanban board. However, agile is more than just a bunch of rules; it’s a whole philosophy. It has its principles and values, as outlined in the agile manifesto. Most people seem to know and follow continuous delivery and (relatively) fast adaptation to changing requirements. Apart from that, the manifesto also focuses on values like trusting your team and continuous collaboration with customers to achieve the best results.
So, when you say that you want to go agile, you need to train your team and even yourself to this new mindset. The business people and the technical team of your organization must learn to work together to produce high-quality software and at the same time, optimize the whole process. And, regardless if you like or hate retrospectives, you have to keep your eyes (and ears) open to the feedback of your team. By doing so, you will be able to maximize the output of your organization.
Ever-changing requirements is one of the most compelling reasons to choose agile in the first place, right? Well, yeah, however, there’s a catch. Although you should update user stories to satisfy your stakeholders, you must not forget that each development shift requires effort. And this is, of course, something to tell your customer upfront, before having to argue about incomplete or abandoned product features.
By the way, since we’re talking about requirements, let’s not forget that estimating the effort required for a user story may be tricky. Following an agile methodology requires spending time on your backlog, carefully designing and estimating your sprints, and then (finally) developing the features. Trying to take a shortcut may prove a costly practice. Your estimations for satisfying a user story must account for fully developing a feature, including quality assurance, which brings us to my last point.
Most team leaders would agree that their goal is to deliver a high-quality product. However, this is not always the case when you develop software using agile techniques. Unfortunately, it’s pretty common to sacrifice quality to fit one more feature to your sprint. Deadlines are pressing, the software has to include those new features, and the stakeholders need it delivered yesterday. So, what do you do? You do your best and try to ship as fast as you can! And, of course, this comes at a cost; you need to recover by taking control of the mess that was created, hunt down new bugs and possibly refactor your codebase. Not to mention the physical recovery of your team from the all-nighters…
Want a better outcome? First, monitor the quality of your project. Then, explain to the customers that they can have whatever they want as long as they give sufficient time for designing, developing, and, of course, testing each feature. If agile is a mindset, so is quality! Considering agile dictates true ownership of the product, which implies that you should care not only about delivering it but also about doing it right, these two are related.
Before closing this, let me say one more thing so that I’m not misunderstood. I like agile, and I think that’s the way to go when developing software. The moral of the story outlined above is not that you should not practice it. On the contrary, I believe one can fully confront these challenges by adopting an agile mindset and working along with the team towards the common goal.
So, that’s it; those are the three most important challenges I consider for agile software management. What do you think? Did I forget any other significant challenge? Do you maybe have similar or different ones? Choose the medium of your choice, Facebook, Twitter or LinkedIn and share your opinion about the challenges you consider essential and how you try to confront them!
Till next time folks!