Developing an Agile State of Mind
--
One would think, in this day and age, almost all intending organizations have successfully adopted Agile practices and principles — or some hybrid version — for software development teams within.
Program Manager
projekt202
Furthermore, some might assume organizations are working successfully at producing quality software iteratively without having issues aligning themselves to the core values.
But it may be surprising to know that, in working as a Program Management Consultant, I have seen numerous teams across multiple organizations still wanting to “go Agile as soon as yesterday” that are struggling to adapt to enhance delivery efficiency.
Let’s delve into Agile transformations, uncover what types of approach work best, and discuss common challenges facing Agile teams.
WHY AGILE?
Two of the most important questions at an organization level to ask are, Why Agile? How does it serve our purpose?
If an organization’s product, solution, or service can be developed or enhanced by incorporating the Agile way of getting things done, then by all means. But if an organization’s solutions have a fixed set of goals, then it is probably best to question how well Agile fits their needs.
I realize that no matter what kind of product or service an organization provides, everyone wants to “go Agile” these days. Is this stemming from an insecurity that everyone else is doing it? A fad of sorts? Or is it truly because Agile has a power to help every kind of organization? I’d like to believe it’s the latter.
Agile is a discipline, a commitment to delivering in small increments, taking end users’ feedback into account, improving over time, and making better versions of our software builds.
Rather than going Agile, I believe the focus should be on “being agile.” It is a mindset of continuous improvement and constant course correction, thereby building something that is truly appreciated and utilized by the end user.
These principles can be applied to not only software development, but truly to one’s own personality. If we want to change something about ourselves or develop a new habit, we can do that by making small, incremental changes and improve over time. It helps us in all walks of life as well; that is why everyone can develop a mindset of “being agile.” What is built over time also has a power to sustain longer and become better.
So, what are the success criteria for a good transformation?
TOP-DOWN APPROACH TO TRANSFORMATION
Many published papers and articles say organizations, people, processes, and tools are various categorical levels where change is necessary.
There are two kinds of recommendations mentioned in published material on Agile Transformation: one is bottom-up and the other one is top-down.
The bottom-up approach has its bottlenecks; without the support of top-level execs and their advocacy on our mission, it is practically impossible to adapt a change across the organization. This sets the change agents up for failure.
In my opinion and experience, Agile transformation has to be trickled down from C-level. Change agents need to bring about the change from the top — training the executives who are key to advocate for a successful transformation throughout the organization, training the practice leaders, and engaging an executive-level sponsor to champion the cause is key to success.
Training has to be provided to all functional groups in the company interfacing with the software development teams, not just limited to software teams. We cannot silo software teams to being agile and expect the rest of the company to understand what is going on. Training key customer-facing teams such as sales, IT, marketing, support, and training is critical in the process of “being agile.” This helps close the gap by building a seamless bridge of understanding and trust between various teams within the company. This helps others to truly understand the nature of your development methodology and thereby co-operate by relaying the right kind of information to their key stakeholders and clients.
TEAM-LEVEL TRANSFORMATION
The teams that I have worked with at some companies have “daily stand-ups” that resemble more of a status call. For teams like this, where do we begin with transformation on a team level? I suggest starting by interacting with teams to get them to elicit and elaborate on their pain points with a retrospective pattern. This can be a simple whiteboarding session with Post-it notes with “What can stay?” and “What can go?” and seeking suggestions on what needs to be improved. This generates action items to address team pain points and will help steer them in taking one sure step at a time towards becoming an agile team.
KEY CHALLENGES
Some of the most common and excruciating pain points for team members that bring about low morale and an unhealthy attitude are:
- Product Managers stretched too thin between multiple projects and hence not helping with a vision, and prioritization of the product being developed
- As a result of a lack of product leadership time: incomplete and unclear user stories such as missing design elements, missing or no acceptance criteria, and unclear testing conditions
- Lack of collaboration between cross-functional teams, leading to missing perspectives
- Lack of testing and deployment environments, and processes
Training the teams alone will not solve these inefficiencies. Change agents such as Agile coaches and scrum masters should continuously work with the team to address and mitigate the issues by forming efficient processes where the teams become self-organized and software releases become more predictable for customer-facing teams.
Happy companies breed happy clients; the happiness stems out of knowing what’s coming next and when. Being agile, when done right, will help build the happiness quotient of any organization iteratively and incrementally, one step at a time.
