You are currently viewing Implementing Agile Across An Organisation

Implementing Agile Across An Organisation

Jeff Gothelf, UX leader and product innovator declares that software has eaten the world. It continues to consume new and diverse industries ultimately transforming the way business is done. We are all in the “software business” now, regardless of the product or service we provide, forcing us to reexamine how we structure and manage our organizations.

Managers, when asked if their organizations practice “agile” would almost always say yes. Probing a bit deeper reveals that most of this agility starts and ends with the product development teams – specifically software engineering. There is rarely a mention of “agile in the HR group” or “continuous improvement in finance.” And yet, it is in these infrastructural disciplines that agility must take root to support software-driven businesses.

As the nature of software continues to shift towards continuous delivery, we are able to create a new type of conversation with the marketplace – a continuous one. Deploying products, observing, measuring, interviewing, learning, and optimizing in hours, not months. Decisions are made quickly. Directions shift overnight. To support this rapid, iterative optimization of our business the internal organizations that staff, fund, manage, and reward our people need to exhibit that same level of agility. “The way we’ve always done it” starts to put the management tier in direct conflict with the potential of the execution teams.

Let’s take a look at HR first. The object around which most HR organizations operate is the job requisition. A traditional job requisition is usually nothing more than a list of tools and capabilities buffered by ambiguous language about “self-starters” and “team players.” These job descriptions are written to fill a gap in a discipline-specific silo (e.g., the software engineering team or the design team). Recruiters, incentivized to fill roles quickly, scour resumes for these skill sets ensuring that anything that makes it through to the next round has “ticked all the boxes.” Three years of Rails? Check. GitHub? Check. Candidates are passed on to hiring managers who are then pressured to make a decision – ensuring the HR teams hit their time-to-fill quotas.

This style of hiring doesn’t build organizational agility. Quite the contrary, it reinforces the barriers between disciplines and minimizes cooperation. Instead, HR teams need to start hiring for creativity, collaboration and curiosity. They need to seek out the non-conformists — the candidates that don’t easily fit into a box. These are the generalists with an entrepreneurial spirit. They’re the multi-faceted tinkerers who have specialized in a discipline like the design but turn out to be pretty good coders. They’re the sceptical members of the team. The ones always pushing back on the status quo and forcing the business to rethink the way it presents itself to its customers. New hiring practices have to be put into place to attract these candidates. Interview structures and exercises have to be completely rethought. It’s nearly impossible to assess a candidate’s collaboration skills in a one-hour Q&A. What do we need to change in order to learn if this new candidate is the innovator that will push our company forward? How do we ensure that our hiring practices continue to improve as the nature of our business evolves?

If we’re hiring ever-curious, entrepreneurial team members, the next logical question is how do we incentivize and retain them? In the past, we’d just assign them to a team; give them a project to build and if they shipped on time and on a budget (or at least close enough to it) they got rewarded in some way. That’s not enough anymore. Financial compensation is not the main motivator for these folks. Building something meaningful, something they can call their own holds much more value. Is there a way for us to rethink compensation structures to include equity (or at least upside) for the ideas our collaborative teams create?

Project funding is another monolith that must conform to our new reality. CFO’s want to know what will ship in return for funding an initiative. While there is never a shortage of answers (you are trying to get funded after all), the true answer is rarely given – we don’t know. There is an ambiguity in software development that renders the end state unknowable. Unpredictable levels of complexity, market turmoil, and shifts in customer behaviour put any product road map longer than four to six weeks at a high risk of quickly becoming an outdated artefact.

Taking a cue from the startup world, the CFO’s office needs to start treating each team as an in-house startup – a group of people tasked with solving a business problem. That business problem has an objective, measurable goal that ultimately determines the team’s success. At the end of each funding period, the teams must present their cases to the finance office for re-funding. This builds a cadenced resilience into the way the organization makes decisions, allowing it to make short commitments and then further those commitments or not, based on real-time market-based realities as opposed to lofty predictions of a future state that may never come.

Lastly, decision-making hierarchies need to change. Traditionally decisions are run past layers of management ensuring everyone is bought in before direction shifts. These processes are slow. They provide cover in the event that someone makes a mistake. Agility in the organization requires decision-making to be done as close to customer feedback as possible. The teams working on the products need to be able to quickly decide how to move forward based on the continuous inbound stream of market insight. Making mistakes shouldn’t be a capital crime. Instead, mistakes should be quickly analyzed and any new information should be incorporated into the next set of tactics.

Incentives should support measuring outcomes, making evidence-based decisions, and learning. The culture of software development allows all of this, but without organizational support, the teams can’t take full advantage of it. The day-to-day tactical decisions teams make should not be the concern of managers. Instead, managers should focus on the teams’ progress towards the strategic business objectives. To allay managerial anxiety and ensure broader strategic cohesion, the onus falls on the teams to communicate back to the organization as much as possible. They must proactively report on their tactics, learnings, progress, and next steps. However, without the safety to report the whole process, warts and all, most teams will opt for safety and predictability – effectively undermining their agility.

As companies turn into highly focused software organizations, we must change the way we manage them. A continuous learning environment fueled by round-the-clock customer insight and feedback demands teams, environments, decision-making structures, and funding models that exhibit the true meaning of the word agility — resilience, responsiveness, and learning.

By Jeff Gothelf- November 14, 2014

Leave a Reply