An Agile Journey Begins with “Why”
About a 7 minute read
Bringing an organization into and through an Agile transformation is one of the most challenging and engaging experiences in my career. Depending on where the limits are placed on what constitutes a “transformation”, I could say the transformation is ongoing, a perpetual work in progress. At the very least, the transformation instilled the mindset of continuous improvement to prevent practices from becoming stale and outdated. Personally, the challenges and learning opportunities created a journey that formed the foundation of my career and skill development. Over a series of posts, I will look at some of the steps undertaken to get the transformation off the ground and the skills I had to use or grow out of the gate.
When first approached by senior leadership to be one of the leaders of a new initiative to bring Agile practices into the organization, I only knew Agile from coursework and reading; I had not yet had the opportunity to put any of it into practice. (Quick aside: I refer to the practices of Agile as the proper noun “Agile” to differentiate from the quality of being “agile”, which I view as a synonym to “responsive” or “adaptable”. "Agile” includes, but is not limited to, the necessary mindset, the principles, and the various frameworks utilized to achieve agility.) Coupled with bringing forth an Agile transformation was the exploration and possible acquisition of a portfolio and project management tool, which was also something I had explored in theory but not had the opportunity to apply. While my experience with these new endeavors was light, it was easy to see the value and potential long-term benefits for the organization and employees. So, where to begin?
With any project, initiative, strategy, etc., connecting the dots to purpose and value are of paramount importance; that is how individuals buy in to find motivation and engagement for their efforts. So, what is the value in an Agile transformation and having a portfolio/project management tool? The overall benefits overlap and are cumulative, but for simplicity’s sake, I will focus on Agile for now.
First, there is one foundational reason for exploring Agile that can be applied to most workstreams: organizations - their work, their systems, and the world in which they operate - will continue becoming more complex, and they must evolve to stay relevant in their field. There is a commonly used adage that the rate of change will never be as slow as it is today. Despite the statement’s cliché aesthetic, there is no reason to believe it false. Hearing someone say, “That’s how we have always done it,” or, “That’s not what I'm used to,” should raise red flags and send the sirens blaring; it is a sign of an organization that is comfortable or resting on its laurels. That may be great for the present, but there is risk the rest of the world may have already passed by. Even if someone says, “Agile will never work for us,” or, “Our work doesn’t fit with Agile,” it is worth exploring. Agile can, and should, be a straightforward way to inject purposeful evolution into how people work, which can begin nudging an organization out of stasis. Agile’s focus on regular and frequent feedback, coupled with self-imposed continuous improvement, helps promote a culture and way of thinking where “how it’s always been done” is erased from the conversation. It is important to emphasize here, that Agile is not a silver bullet solution to solve what ails. Agile will dig a thumb into the pain points to ensure you notice. Implemented with other organizational evolutions, however, Agile can be the grease that helps the gears stay moving.
Next, agile ecosystems require focus. Focus will help turn initiatives, projects, or really any effort into realized value earlier. Having protected focus in place will benefit dev team members, product owners, leaders, and even stakeholders. If teams have multiple simultaneous priorities, they will never realize the benefits of Agile, because they will never fulfill their goals for an iteration and instead be in a constant state of catch-up. Likewise, product owners, who should be the shepherds ensuring teams have focus, cannot establish priorities or a proper backlog if they are not allowed to focus by the organization. Leaders must understand that resources are finite, and they cannot have everything on their wish list (is that not something we are already taught as children?). So, supporting a singular priority or a short, prioritized list of high-value deliverables, allows that focus to flow downhill to the individuals handling implementation. Stakeholders fall into a similar boat as leaders with why focus is important, understanding resources are limited, and stakeholders should also be allowed to home in on a very small pool of items when providing their input. Multiple feedback priorities can quickly waste stakeholder time and create confusion as to why they are involved and what they are supposed to be doing. Another point where focus earns its stripes, and this is a big one, having focus zeroes in on purpose and makes the defining of expected value easier. As a dev team member, with focus, there is no question of what you are working on and working toward, and you understand how you are contributing to the end goal. If good leaders are in place, they will have also communicated how the expected outcomes are important to the organization and will generate value. The best mindset for supporting an emphasis on focus is knowing whether, in a set period, it is more important to move ten items an inch or one item a mile. My view: it is unlikely ten items are all top priorities, so why should the effort of limited resources be wasted on lesser items; additionally, seldom will that one inch of movement generate anywhere near as much value as a mile of progress on the top priority.
Lastly, for today at least, Agile goes nowhere without people buying in, and the same goes for any organization. Agile can improve empowerment, generate new individual opportunities, and increase job satisfaction and engagement. Again, Agile is not a solution that will move mountains. If an organization has a lackluster culture, Agile can be seen as snake oil or a hollow buzzword and fail to get off the ground. Conversely, when organizations are earnest about giving teams the ability to self-organize, team members the empowerment to determine how work is going to be done, and priorities to be protected, people will embrace that purpose and be able to see their impact. While that does not inherently come with a pay increase or enhanced benefits, having more control over the output of one’s talent, knowledge, and experience can have psychological benefits.
Summary of 3 Value Points for Exploring Agile
· Helps keep an organization evolving and aiming to be better
· Requires focus, focus leads to earlier value delivery
· Gives teams and individuals greater ownership of outcomes
When I wrote above that Agile digs a finger into an organization’s pain points, that should be thought of as a good thing, because the curtain is pulled back and all can see where changes should be made. Those pain points are not going to disappear without therapy, the active acknowledgement and addressing of those pain points by an organization’s leaders (which is not exclusive to hierarchical leadership). Some of those pain points may include managers not being as involved in the day-to-day direction of work and not knowing how to adapt, or certain teams or departments feeling they should be excluded from playing nicely in the sandbox because their work is “different”, or work and projects simply not being prioritized or governed as they need to be. Like any pain, however, it could be a symptom of a greater issue, so it is important to not blindly solve for one pain point after another; that approach has the potential to become an endless game of whack-a-mole. Again, Agile is complementary to other changes that should be taking place.
Establishing purpose for and the value behind an Agile transformation is the keystone to finding success with the transformation, and connecting those dots must occur at multiple organizational levels. Understanding the “why” behind making a change opens the door to assembling the other key pieces of the transformation, which I will continue exploring in future posts.