Understanding Agile Practices

In recent days, I've engaged with numerous Agile methodologies and assessed their effectiveness. This exploration revealed how individuals often misinterpret Agile principles by overanalyzing features, neglecting to observe results, and confining iterations solely to coding.

Photo by Yiran Ding on Unsplash

This week, I had the opportunity to serve on several panels reviewing final projects from software engineering students. To my astonishment, many were still adhering to Waterfall methodologies. Even those who claimed to practice Agile often failed to iterate even once.

It’s surprising to observe that students replicated the same challenges I encounter in my consulting work. Despite Agile being around for over two decades, traditional Waterfall approaches remain prevalent.

You might be thinking, "That doesn’t apply to us; we’re implementing Agile and iterating effectively." But are you truly?

Among the students who professed to follow Agile, there was a broad range of expertise. Some didn’t iterate at all, instead claiming to generate documentation or conduct interviews as iterations. Unfortunately, that doesn't align with Agile principles, which emphasize delivering functional software rather than merely producing documents. The result for these students was a collection of documents with no tangible product to show.

Another, larger group did manage to deliver software every few weeks but strayed from the essence of Agile. They created a task list on day one, committed to it, and followed it rigidly without reassessing or adapting. This approach meant that their misunderstandings only compounded over time, resulting in a flawed final product. They missed opportunities to learn and improve at each iteration, simply adhering to their original plan.

Identifying the Core Issues

You might attribute this to the students’ lack of experience, which is partly true. However, even experienced advisors can sometimes overlook critical aspects. The crux of the issue is that until we have a product in hand, our understanding of its implications is often limited.

Some students did iterate genuinely, adjusting their plans as they progressed, and their results were remarkable.

True iteration goes beyond just delivering working software every two weeks. It requires reevaluating the project at each step. Rigidly following a backlog is merely dividing work into chunks. While this is a positive step, it doesn’t constitute true iteration. We should assess our progress, refine our strategies, and adapt as if we are initiating a new project with each iteration.

It became clear which students genuinely embraced Agile methodologies and reassessed their projects continuously. They didn’t just deliver a functioning product; they tackled nuanced issues that truly mattered to users—issues often overlooked until the final stages. As a result, their projects matured significantly in a short timeframe.

The Importance of Iteration Speed

However, a common shortcoming among all students—and many companies I know—is the failure to iterate quickly enough.

There exists a well-known metric that analyzes project success based on size. It categorizes projects into two groups:

• Large projects (over $10 million): Typically, they are at high risk of failure. Data shows that 38% fail, 52% face challenges, and only 10% succeed. This is alarming. It suggests you might need to invest $100 million to secure a successful outcome.
• Small projects (under $1 million): These projects generally see a higher success rate, with only 4% failing, 20% facing challenges, and 76% succeeding.

It’s evident that smaller projects are statistically more likely to succeed than larger ones.

Transforming Large Projects into Smaller Successes

This raises the question: Can we leverage Agile principles to break large projects into smaller, manageable ones? This is precisely why we must iterate on everything, not just coding. By breaking down large, risky projects into numerous smaller ones, we enhance our chances of success. Each iteration should be treated as a new project, allowing for continual reassessment and adjustment.

When considering the ideal size for iterations, we must reflect on project scale. Larger projects inherently carry a higher risk of failure, while smaller projects boast a better success ratio. Yet, we can’t assume that simply dividing projects into smaller tasks guarantees success.

Another critical factor to consider is the cost of failure. Low-cost failures enable experimentation and learning, while the high cost associated with large projects can be prohibitive. Conversely, tiny projects can often fail at minimal expense, making it easier to pivot and learn.

The Three-Hour Iteration Challenge

When asked about the ideal iteration size, I often suggest three hours. This may seem arbitrary, yet it reflects extensive experience. I recommend that teams limit coding to three hours a day. You might wonder what to do for the remainder of the day—replan.

Post-delivery, our comprehension of the problem expands, revealing new insights that enhance the value of the backlog. We should ask ourselves, "What can we achieve in just three hours that will make a difference?" This encourages a focus on core values while also learning from previous outcomes.

I recognize that this may seem counterintuitive. Three hours is significantly shorter than the typical one- or two-day task. Yet, we need to shift our mindset. Tasks have become larger to simplify planning, which isn’t the most effective approach.

Moreover, the emphasis should be on evaluation and replanning rather than solely on coding. By allocating just three hours for coding and dedicating the rest of the time to project evaluation, we enable the opportunity for a fresh start and proper iteration.

This year, I introduced the three-hour challenge to my students. I encouraged them to code for three hours, publish their work, and then reassess. While I don’t expect universal adherence, I am eager to see how their final projects evolve in the coming year. I hope these insights inspire them to adopt better Agile practices and produce more mature projects. Even if just one student embraces this approach, the outcome will be rewarding.

Thank you for reading. I enjoy crafting narratives that prompt reflection on our understanding and application of software engineering, encouraging us to consider areas for improvement. If you appreciated this article, explore my most popular stories on Medium for further insights. You can also support my writing by sharing this Medium referral link.

Chapter 1: The Challenges of Agile Misinterpretation

While many claim to follow Agile practices, a lack of true iteration often hinders their success.

Chapter 2: The Impact of Project Size on Success Rates

Exploring the correlation between project size and success rates reveals significant insights into Agile practices.