Agile Is Easy to Understand But Hard to Practice

Agile is the recent buzzword that many organizations are trying to preach and practice. The approach to getting transformed to Agile is different across organizations based on their own expertise. They are trying to ride the wave of Agile to pursue its advantages like ease of embracing change, decreased cycle times, evolutionary product development, and so on. It looks lucrative and simple, but practicing has its own roadblocks which might go wrong if not handled with caution. Before jumping on the Agile bandwagon, we need to understand that Agile is more of a journey and not a destination. This article focuses on how to practice Agile in building software with the right mindset by knowing the pitfalls and how to fix them so that the organization can succeed. 

Agile is more of a mindset that is defined by four values, described by 12 principles, and manifested through different frameworks like Scrum, Kanban, XP, DSDM, etc to create products of complex and uncertain nature. Moreover, the integration and balance of PEOPLE, PROCESS, and TECHNOLOGY are important to succeed. 

Agile Planning: Always Plan for a Product, Not a Project!

Planning in Agile involves so much more than a simple checklist.

Today in organizations, we plan and estimate to make effective decisions that help us stay competitive. We engage in this activity to get answers for simple questions like:

  • What needs to be built?
  • When can we complete?
  • How much will this cost?
  • Who needs to do it?

In traditional software delivery, we have been planning and estimating by following a sequential plan-driven approach. As these projects are short-lived once completed, there is no long-term connection between the product and the teams who built it. Also, more of the unfinished work and technical debt is left behind.

Is My Product Backlog Just a Laundry List?

What's on your list?

In simple terms, a product backlog is a list of everything that needs to be done in relation to the product. This is the key artifact that helps in translating the high-level product vision and serves as the foundation to initiate the development of the product.

The product backlog includes features to be built, enhancements, fixes, quality attributes, etc. in the form of user stories.

This is beneficial in comparison to the waterfall approach of creating multiple pages of requirement documents because it provides prioritization so that the team has a direction, has the necessary details required by the team, and it keeps evolving and responds to change.

We Really Need to Talk About Agile Contracts

If we really want to be Agile, we need to make sure our contracts are, too.

We all are aware that Agile software development has been in existence for about 18 years now, so it's clearly been enough time for organizations to adopt Agile processes for the complete development lifecycle.

But when it comes to writing contracts, I think most of us who have been working in software consulting companies will agree that there is still reluctance, and most of the time we either go back to waterfall language of writing or succumb to a mix of both the traditional and agile way.