A brand new study throws holes within the Agile method – but is Agile in charge?

Projects using the Agile development process fail 65% of the time, in comparison with 21% for Lean Engineering and 10% for a brand new method called Impact Engineering, in line with a study. recent study conducted for the book Effect technology. I used to be intrigued by the study’s headlines – and by the clever marketing strategy of using a survey to sell a book. The marketing worked for me because I had just bought and browse the book.

The method itself or the implementation?

The agile development process was introduced about 20 years ago in response to more rigorous development methodologies. At the time, several rigid and highly serialized “waterfall” development methodologies were hottest. However, waterfall project management was not well-adapted to the needs of software development and lacked the power to regulate effort based on feedback throughout the event process.

Agile was revolutionary since it replaced the long development cycles of the waterfall model, which may need been planned months upfront. Agile is predicated on short development cycles – often two or three weeks – called sprints. Sprints are highly iterative and have multiple feedback loops built into the method, meaning changes and risks might be easily caught and stuck. The increased collaboration it fostered led to a more transparent management style that meshed well with software startups, which were early adopters of agile methodologies.

Over the years, Agile has change into more robust and several other variants (reminiscent of Scrum and Kanban) have been developed to satisfy the needs of various development teams. But each of those variants stays true to the unique Agile principles. Agile processes are actually the de facto approach to software development in lots of organizations of all sizes.

As I checked out the outcomes of the study and the book, I wondered if the issues were with Agile itself or with improper implementation. As someone who has experienced Agile success and failure, I actually have learned that failures are sometimes as a result of other aspects, not the strategy itself, so I remain somewhat skeptical of the study’s conclusion that a special approach is required. It also needs to be noted that the outcomes are from a survey of 600 developers from the US and UK, and subsequently don’t represent a world representation of Agile development.

Below are the important thing findings of the survey, followed by my very own thoughts on the validity of the study based on three of its key findings.

Problem No. 1: Being in a position to discuss and address problems quickly

I fully agree that practices that ensure psychological safety have a big impact on success. But the best way that is framed by proponents of impact engineering suggests that Agile doesn’t support psychological safety – which is just not true. The point of Agile is to get issues raised as quickly as possible in standup meetings and handled by the appropriate leaders within the organization via a well-communicated escalation process. So is that this an Agile problem or an organizational culture problem?

In addition, I actually have also seen waterfall implementations fail as a result of an absence of psychological safety. In my opinion, the adoption of Agile by leaders and developers should be accompanied by a complete recent level of transparency and trust. If a product team is working under the pressure of a deadline set too early in the method, or the team is penalized for unexpected setbacks, leadership can lose the trust needed to make any project successful, Agile or not. In other words, if developers do not feel secure enough to talk up, they will not share vital information to make sure a proactive solution might be found sooner moderately than later.

Problem #2: The project requirements are based exactly on the actual problem

I believe that poor requirements definition will impact a software development project irrespective of what development process is chosen. But Agile also has mechanisms to handle requirements gathering and refinement rather well. First of all, a key component of well-implemented Agile is the creation of “epics” and “stories” (that are proxies for requirements). While previous methodologies emphasized the role of a product manager owning a unified requirements document, Agile is a more collaborative affair, with team leads and designers involved early in documenting and prioritizing requirements.

Beyond the team, one other vital aspect of Agile is to involve customers and business partners in the method by holding product demos early and infrequently to collect feedback. This is totally crucial to be certain that the necessities are right. It helps the event team understand not only the necessities but in addition the varied nuances of problem solving. If the event team only relies on the words of the product managers and doesn’t interact directly with the external stakeholders, the probabilities of failure are much higher. Again, transparency and communication are the important thing to success.

Still, I believe I can understand why this perception exists with Agile because I’ve experienced it myself. In fact, poor requirements gathering was a key reason I used to be against Agile for some time too. In my experience, teams that are not well trained in Agile are inclined to focus an excessive amount of on the rapid development points. Another a part of the challenge is that Agile is commonly sold as being “faster,” which could be true overall as a result of the reduction in rework. But I feel that Agile is actually about being “more agile.” This misconception creates the challenge around requirements. Because the most effective strategy to get faster is to work in a vacuum. But the most effective strategy to be more agile is to listen and iterate.

Problem #3: Not having to work on a couple of project at a time

I used to be surprised to see this particular result. When I’ve worked with Agile experts and coaches, they’ve often identified that pooled or shared resources are harder to administer in Agile, and that developers themselves should tackle more testing and DevOps responsibilities. The idea is that the Agile team is small and athletic. Because of this, Agile can fail in larger organizations that work in functional silos. So on this case, I’d have expected Agile to perform worse – however it didn’t.

However, the book notes that there appears to be a degree of diminishing returns. Working on two projects directly is nice, but juggling greater than 4 projects directly seems to have a negative impact. This result also suggests that perhaps it is not a lot about having multiple projects, but about people being assigned multiple full-time workloads, which results in burnout and mistakes.

Again, Agile has capability management mechanisms in place, and a great Scrum Master will find a way to administer team capability using burn-down statistics to make sure a great balance – something that is just not at all times the case with other development methodologies. So, upon further reflection, this system could well delay.

My conclusion: I simply don’t consider Agile is in charge

I fully agree with the argument that Agile is difficult to implement in lots of environments and is just not the most effective solution in every case. In this context, it’s probably price mentioning that I’ve been snubbed by several leaders after I suggested that Agile was the improper approach for his or her group in certain circumstances. In my experience, these are frequently the identical leaders who wish to see work done faster but are unwilling to speculate within the change management – and the open feedback, including feedback on their very own decisions – that Agile requires to succeed.

In short, if you would like to improve the best way you construct products or apps, it is advisable consider every aspect of the organization and your goal before deciding on a way.

So what did I believe of the book?

As I said, the survey is a clever marketing mechanism, Effect technology ended up being less of a brand new approach and more of an indictment of Agile gone improper. This is unlucky because one other unique feature of the book is that it uses a fictional story a couple of project to convey its arguments. This would have been a really appealing way for the writer to convey the right application of Agile to a non-technical audience – moderately than making an argument against Agile.

Another flaw within the book is that after the completely satisfied ending of the story, there’s a really thin conclusion that comprises a really basic call to motion. It would have been way more powerful if there had been just a few more chapters after the motion with suggestions and tools on methods to improve Agile projects. Since the book did not have that, I’ll close with my top three suggestions for making Agile work.

Getting essentially the most out of Agile

First, there are a lot of variants of the Agile method and never all of them are best for you and your team. It’s even hard to say that one variant is healthier for this or that technology. What makes the most effective solution is definitely the connection between the team’s work style and the technology. I do know of a case where a team began with the Scrum method and failed. They very appropriately took a step back and switched to Kanban; with a little bit effort, the team was in a position to turn things around.

Second, get help – and not only from consultants. Consultants can enable you within the moment, but your team probably needs ongoing support. My suggestion is to rent an experienced Scrum Master as soon as possible. This person can arrange and manage the appropriate processes and act as an arbitrator in times of disagreement. Someone with experience can expertly balance the team’s capability with the work to be done, and it will prevent team morale and burnout in the long term.

Third, there are not any shortcuts. You need to obviously define the roles that folks are chargeable for executing. You must expect that things can be slow to start with and possibly go improper before you change into more flexible. And most significantly, keep in mind that Agile is just not only for the team, but for your entire organization. Command and control leadership from the highest is the most important danger to Agile efforts. I’d strongly recommend training in any respect levels and training for all leaders who touch the product. For this, I like to recommend anything from the Pragmatic Engineering ecosystem.

All in all, I discovered Effect technology and the associated survey is thought-provoking, however the try to indict Agile as a way has left me little convinced.

NOTE: Special because of Ryan Daws for publishing the article that inspired this piece.