Agile - Principles & mindset
#Agile #Methodology #PrincipleMapping #Culture #mindset #transformation

Agile - Principles & mindset

Recently, I was contributing to a collaborative article on LinkedIn about Agile software development. The way the article was structured made me realize the lack of understanding that still exists about Agile being a mindset and more of a culture, not just process. In this article I intend to explore further and highlight why mindset & behaviors can be a make-or-break for successful implementation of Agile and link all these to the principles & manifesto of Agile. Finally, I visually map these aspects to principles with SCRUM framework as an example.

Reflecting on my own journey of transforming from Waterfall to Agile more than a decade ago, I reckon our approach (with generous internet references) was implementing it as a methodology or a project management process with different set of steps to be followed, as opposed to understanding the philosophy and adopting an Agile framework that implements the philosophy comprehensively. Until one day a new CTO who came on board made us realize we were actually doing Waterfall execution under the guise of Agile!

I have seen other organizations or teams take the same route. So, how does it matter if the philosophy is fully understood as long as the process framework is followed? It matters because the Agile philosophy is designed around a few key tenets that promotes value delivery to Customers at frequent intervals, getting timely feedback, accepting & making changes right away, and empowering teams to drive innovation with continuous improvement. Without a good understanding & implementation of these tenets, following a few Agile execution steps is going to miss the mark in deriving the real set of benefits.

The end result is worse, you are left with an execution process that is neither a traditional one (say, waterfall) nor is Agile. The Engg teams claim victory on transforming to Agile, but Leadership is unable to see the promised gains from the expensive transformation. It's almost impossible to go back to the old process, but you can transform - again(!) as we did in my previous organization.

Pivots like these are expensive and disruptive, so how do we do it right from the get go?

Start with a good understanding of Agile as a philosophy and it's principles. Then align on why these principles are beneficial for your organization based on your own journey & goals. Once you understand the "WHY Agile is right for me", ensure rest of the org understands this Why. This understanding will drive alignment & commitment to implement the new approach. Thereafter choose the right Agile execution framework and follow it diligently. Be determined NOT to pick and choose what is convenient, as its not about convenience but adapting to a new normal. Its alright to take baby steps, but ensure you keep executing to the target state.

The other reason why many Agile implementations don't turn out as desired is the aspect of change in culture & mindset it needs. It is easier to change a process (following a new set of steps) but difficult to change mindsets in the organization, or to make something new as part of your culture. Let's go deeper into this aspect.

Let's take an example from one of the manifesto items, and analyse -

Manifesto: Working Software over comprehensive documentation

Principle: Working software is the primary measure of progress

The Agile principles hyper focus on development process to enable fastest way to deliver value to customer. And what better way to deliver value to Customer than working software? Making project plans and sharing progress is good, but the principle says delivering working software is more important & is true progress. Implementing this principle means tweaking your software development process to produce shippable piece of software at regular intervals, and letting the Customer get a feel for it. Taking SCRUM as an example, this would mean working software at the end of every sprint. For teams that are not used to this kind of rhythm or lack the dev process maturity, it takes a lot of conviction and a change in mindset to go the full distance to implement it. No doubt it is hard, as is every mountain trek - but when you persevere what you see at the end blows you away!

One more example -

Manifesto: Responding to change over following a plan

Principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage

If there is one word that people will relate to when you mention Agile is the word Change. At the core, the principle says its good and even highly welcome if customer wants a change. This ensures what the team is building is as close as practically possible to what the customer is looking for. Precisely the reason why the previous principle talked about delivering working software to the customer, so they can use it and give you feedback very early in the lifecycle of the product. Adopting this approach to change is not a process thing - its behavior, mindset and a change in culture goes a long way in getting people to harness change. For an organization & Sr.leadership that likes to see predictable project plans with long term milestones, adapting to an Agile mindset of constantly pivoting with every change can be very challenging. Therefore its important an Agile implementation has alignment from top layer of the org's leadership team, enables the cultural aspect and also trusts the product teams. Talking about trust, let's look at our next principle, last one I promise!

Principle: Build projects around motivated individuals.Give them the environment and support they need, and trust them to get the job done.

A command & control leadership style will struggle with this principle. Agile promotes ownership and empowerment to every single team member with the concept of self-organizing teams. Implementing such principles and letting the teams pivot & change as per Customer's evolving asks needs a huge change in the mindset and a big leap of faith to trust the team by giving them all the support and resources to get the job done. Therefore an organization's culture and leadership plays a huge role in creating an environment of psychological safety and the change (per the previous principle) needs to start right here. It is easier said than done, but I have seen organizations go through this change resulting in all time high employee engagement and phenomenal results, and innovation.

Let's summarize -

  1. Agile is a philosophy and is outlined as a Manifesto https://agilemanifesto.org and it's underlying principles https://agilemanifesto.org/principles.html . (See the flyer attached with this article)
  2. For any Agile implementation to be effective, across the organization, two aspects are very crucial - a good understanding of the principles and a comprehensive implementation of the framework. When I say framework, some examples - SCRUM, Kanban, Scrumban, XP, etc. We wont go deep into these in this article.
  3. Pay attention to the fact that an Agile implementation needs a change in mindset, which is best achieved with changes to the Engg culture and the broader organization, and an alignment from the leadership team

Finally, as a reference (see the flyer), I did a little exercise to map aspects of software development and various agile practices as defined in SCRUM methodology to the corresponding principles & manifesto. The idea is to demonstrate how each SDLC & agile step can be clearly tied to a principle, which is in turn derived from the manifesto. I would love to hear your thoughts and if you have additional items you think that maps to these principles.

I would also love to hear your experiences from similar transformation journeys, and the learnings that helped shape the course to desired outcomes.

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

社区洞察

其他会员也浏览了