What agile is vs is not ?

I was recently talking to a former colleague who was explaining her uphill struggle with?“quiet resistance from teams that see what they think “agile” is and don’t want to be a part of it” as part of a culture change needed to support a larger digital transformation.

??

So first things first, what is the "agile" method. In simple terms, it's a way of developing software that emphasizes flexibility and adaptability.


Now, I know some of you might be thinking, "Wait a minute, I thought software development was all about sticking to a plan and following a set process!"?


Why do so many people think in either/or many times called black or white thinking? Who said sticking to a plan and following a set process can’t be flexible and adapt?


The "agile" method is all about being able to adapt to changing circumstances and requirements. It's not about blindly following a plan, but rather about being able plan in smaller chunks to be able pivot and adjust “the plan” as needed. Think of it like a game of dodgeball - you need to be quick on your feet and ready to change direction at a moment's notice, but you are still following the rules and working within the game’s boundaries.


So, what exactly does "agile" involve? Well, in its simplest form it's all about breaking the development process down into smaller chunks called "sprints". These sprints are typically two to four weeks long and involve a specific set of tasks.


During each sprint, the development team works closely with the client or end user to make sure they're on the right track. This allows for feedback and adjustments to be made to “the plan” along the way, rather than waiting until the end of the project to find out that you've been going in the wrong direction. The type of development lifecycle where the whole plan is made at the beginning and not veered from?is called Waterfall.


Now, let's talk about what "agile" is not. This is very important. It’s not a free-for-all where you can just do whatever you want and hope for the best. There's still a process involved, and it requires discipline and focus. I have seen many bad actors use "agile" as their excuse for not communicating requirements, to other teams, and expecting them to jump to comply. That’s just BS, and gives "agile" a bad name, and is the cause of resistance by those used to disciplined waterfall projects(even if at the end the result of the long project didn't make its customers happy).?


"Agile" is also not an excuse to skip out on documentation or testing. In fact, these things are just as important if not more important in an "agile" environment as they are in a traditional one. The difference is that they're done in smaller chunks, rather than creating an inflexible plan at the beginning, and then waiting until the end of the project to first see what went awry.


In conclusion, Agile is a way of developing software that emphasizes flexibility, adaptability, and collaboration. It's not about blindly following a plan, and its not about having no plan at all, and working by the seat of your pants, but rather about working and planning in smaller chunks to able to pivot and adjust as needed. Just because it's Agile doesn't mean you can skip out on the important stuff like documentation and testing. The balance between the extremes of doing all planning upfront and not deviating, vs doing no planning and going by the seat of your pants, takes discipline, and is what Agile is really all about.


And no need to worry ,there are many frameworks, coaches, trainings, etc to help people on their Agile journey. The benefits to your product or the outcome of the project more aligning to your customer needs, because you listened and can pivot adjusting along the way rather than sticking to the original plan , and having the project not meet the customer needs, make?the shift to following an agile development lifecycle well worth it.

??? Paul A Mohabir

Global IT Business Executive | Digital Transformation | Strategic Planning | Business Process Transformation | Product Management

1 年

Richard, Thank you for sharing ..

回复
Vishnu V Nair

Leader in Next-Gen Observability, Digital Transformation, Cloud & On-Prem Operations, ServiceNow ITSM & CMDB, Operations Orchestration, Service Delivery & Operations, DevSecOps, People & Stakeholder Management.

1 年

Well articulated,????,????

回复
Mike Fowler

Payments Leader | Card not Present | Card Present | Consultant

1 年

Thanks Richard. So many product teams still think in linear ways. We need to ensure that we design for incremental outcomes vs. a final outcome. The incremental outcomes add value along the way allowing us to prove our cases in reality and not at dream state. Few sprints have designed this in and thus miss the feedback loop and reality tests.

Lindsay E. Haddock

Transformational Technology Leader | Specializing in PMO Leadership and Strategic Business Innovation

1 年

This is the way!

Krishna Chaitanya Ponduri

SRE & Observability | SERVICE LINE LEADERSHIP

1 年

Great foundation to build upon!

要查看或添加评论,请登录

社区洞察

其他会员也浏览了