Scaling Agile to Create “Frictionless IT”

DZone 's Guide to

Scaling Agile to Create “Frictionless IT”

How to utilize Agile to create frictionless IT!

· Agile Zone ·
Free Resource

Creating a modern and flexible operating model for IT is no easy feat. Many technology organizations are still operating as a “service provider” to their business units, rather than a strategic partner. The moment this model becomes a problem is often when the business begins to move quickly or veer from the plan. For most companies undergoing a digital transformation, that time is happening now.

The foundation of much of enterprise IT is the budget under which they operate. Unfortunately, in many organizations, technology teams are still simply looked at as a cost center. This means they are seen as not contributing to the profit of the business. This is amplified when the tech teams themselves have this mindset.

In these organizations, traditional IT planning likely occurs annually, with fixed budgets allocated to a combination of projects and maintenance. The planning process is likely onerous, involving iterations of prioritization alongside business partners until a solid baseline of work is established. Then, the planned projects are resourced and work begins. Projects usually relate to an application or system — either enhancements to something that exists or the delivery of something new.

On top of this, a lot of organizations are still using traditional project management methodologies (read: waterfall) to deliver on planned work. Ramp up takes time. Roles are rigid. Requirement gathering is painful. Then, with requirements established, infrastructure needs to be stood up. In large organizations, this is likely a lengthy process involving estimation, order forms, and eventually, provisioning. For SaaS delivery, contract negotiations and vendor alignment to organizational processes are often time-consuming.

But What Happens If the Business Now Changes Their Mind? What If the Business Needs to Deliver Something Quickly? What If the Business Partners Want to Experiment With Technology?

Leaders in the digital era have recognized that tech teams are not only increasingly becoming a strategic partner for the business, but a major profit center to deliver value. For these companies, IT is looking at the success of start-ups and tech giants and replicating their norms at an enterprise scale.

Most companies undergoing a transformation will recognize that transforming the IT operating model to be more flexible and nimble is a pre-requisite and critical factor for successful delivery in the digital era.

Large companies; however, will often have a mix of agile and digital maturity within their technology organizations — early adopters who implemented new models and structures during the onset of the company’s transformation, and laggards who desperately need to catch up. This is a result of many factors including the business they support, the demographics of their workforce, skills, funding, and overall organizational culture.

Those groups who are looking to catch up need to transform themselves across multiple dimensions in order for Agile to work at scale.

Re-organizing Teams

In the past, teams were filled with constantly changing resources and aligned with applications — which are siloed from other areas of IT, and distant from the business they support. Resources from teams are assigned to projects, which have strictly set start/end dates and limited scope. Project teams deliver the scope, and hand-off to operations and support.

At the low end of the agile maturity spectrum, teams will dabble with Agile by delivering a few smalls projects using methods like Scrum. Maybe they will utilize Kanban boards to track their operational work. The hurdle here is that the Scrum team is still focused on delivery, and not on the actual outcomes.

This typically occurs when the overall operating model is still largely project-focused. Couple this with a lack of true business buy-in, and you’re setting yourself up for limited long-term success. Often, you will see IT employees stand-in for the product owner role, as a proxy for the business. This creates a whole slew of problems because the PO is not truly the owner of the business vision, and thus is susceptible to bad decision making.

To enable agility, entire teams need to be product-focused. A product is something (physical or not) that provides value to a consumer. What the product is, isn’t what is important, but rather the concept. Products can be anything from fancy digital systems delivered to customers, or internal functions supporting the organization and its employees.

If you’re wondering what this means for a team — it means dedicated team members from various functions, to deliver value end-to-end. Set aside the notions of strict roles and responsibilities. Product teams are jointly accountable for the success of the product.

This also requires a real “product owner” — a dedicated leader from the business who owns the vision and strategic direction of the product. The product owner is empowered by their leaders and delegated the authority to make decisions that impact the product.

Adapting Traditional IT Portfolios to manage Products vs. AppsProduct-based teams are ideally perpetual, without a fixed timeframe and tight scope. Instead of delivering “projects” and leaving support and maintenance as somebody else’s problem — the team also delivers support, bug fixes, and changes on top of feature development. This means that they’re staffed with cross-functional capabilities from various tech and business domains: ops, support, development, architecture, testing, delivery, etc.

Product teams can exist regardless of the Org structure. Enterprises often have product teams working as a matrix organization separate from their reporting hierarchy, which is fine. However, this means that leaders must understand their role in this model of work.

The Relationship Between IT and Business

Just as important as positioning the Tech Team in an Agile way, is freeing up the business partners to actively participate in the team. Closer collaboration alone is one thing, but operating as one unified team is often what it takes.

In this model, gone are the days of IT gathering requirements and taking them away for months of building, before unveiling the shiny new product to the business in a big bang fashion. That doesn’t play well with the culture of experimentation and collaboration.

Co-location is a big help in enabling teams to operate as one. When product teams can get together frequently — daily stand-ups, demos, retros — they form a bond.

Models from psychology like Tuckman’s “Stages of Group Development” tell us that high performing teams will go through a series of phases while working together. The sooner teams come to understand that cohesion between business and technology is a prerequisite to success, the faster they can cycle through the phases.

The “one team” model applies to leadership as well. When the business leaders are aware that technology can be a key driver to achieve their goals, they’ll be more inclined to work closely and co-create the future vision.

Norming vs. PerformingFunding Model

To be successful, organizations will need to fund teams to continuously achieve a particular business outcome. This is contrary to the traditional IT budgeting model mentioned above where funding is allocated to pieces of work and/or maintenance.

Annual planning will, for the most part, remain; however, organizations can adapt the process to better suit scaled agile delivery. Instead of injecting granularity into the plan upfront, leaders can agree on investment themes, opportunities, and problem areas to focus on for the fiscal year. The “themes” that are agreed upon are divided up into the various product teams within a portfolio, and teams are scaled up and down based on the needs.

From there, product owners and teams can further break the themes into tangible items and add them to the roadmap.

Long-term and detailed planning is counterintuitive to an Agile transformation because the whole premise of Agile is based on breaking out your work into short time-boxed sprints and then re-adjusting direction if needed. On the contrary, if your business is relatively stable and has a definitive long-term end goal that is unlikely to change — then a full-blown Agile way not even be required.

But What About Everyone Who Isn’t Directly on a Scrum Team? What About Info SEC, Planning Managers, Portfolio Leads?

An agile funding model needs to flip the traditional budget on its head. Resources — including the roles mentioned above — need to be funded in order to support cross-product portfolios. This can be implemented through a “top-of-the-house” or “tax” model, where each team “recovers” a portion of the overall allocation for these individuals.

Funding the Non-dedicated Supporting Resources for Product TeamsThe Role of Leadership

Leaders may be averse to enabling agile-like practices because they fear they’re relinquishing some power they exhibit over their business function, app, system, etc. If this type of organizational politics arises, all the more reason for needing Agile.

Leaders will need to adopt a mindset that allows them to delegate some authority in order for teams to be autonomous and trust that the Product Owner will steer the work in the right direction.

This doesn’t mean that leadership is out of the picture either. A key role of leaders in an Agile operating model is that of a mediator. There will certainly be roadblocks along the way, and the ability for a leader to use their position to help break them down is critical. Agile can’t operate at high speeds without the help of great leaders who do everything in their power to clear the roads for the delivery teams.

The setting of the strategic direction is ultimately still performed at a leadership level, but they must understand that they cannot control everything happening on the ground. Further to this point, they must know when to let go.

“Failing fast” and knowing when to pivot are key principles that allow successful start-ups to remain afloat. Not every strategy can be a great strategy, and outcomes are sometimes different than expected.

Finally, there is a maturity building. Leadership that not only buys-in to this model of working but actively grows and builds on the capability, will be more successful than organizations that simply follow the steps in the book. Great leaders invest in their team and will push them to learn new things in order to remain successful.

Managing “New” Work from Planning through to Delivery

Almost obviously, once “Investment Themes” have been put in place to focus on, this doesn’t mean things won’t change. Change is something that should be embraced, especially when change comes in the form of a brilliant new idea.

Because a successful Agile transformation will fund teams that are dedicated and empowered to get things done, they’ll also be empowered to make decisions on things that impact their product.

When “new work” surfaces in a portfolio — either in the form of ideas, feature requests, mandatory changes, or bug fixes — it goes to the appropriate product owners and added to their backlog. Optionally, in large portfolios, there may be an additional step whereas a team vets all new requests to ensure they’re aligned with the overall portfolio or business strategy prior to hand-off to a product team.

Unplanned work not only needs to be checked for “vision fit”, but blueprinted sufficiently for the PO and team to understand scope and complexity. This makes it easier to prioritize against the releases already planned. This is a paradigm shift from “do we have a budget for this idea?” to “is this idea as important as the rest of our planned work?”.

What Happens If the New Work Is Just as Important, and Everything Needs to Be Delivered?

Ongoing prioritization will cover off this dilemma. Portfolio or business unit level steering groups should be regularly available to prioritize and re-align investment themes as conflicts arise. If the budget for the investment themes is not very fluid (as most large enterprises are), then things need to be moved around. After all, Agile is all about trade-offs.

Leverage Technology, but Don’t Rely on It

There are thousands of great lightweight tools and platforms available to help organizations achieve better results during their transformation journey.

Spreadsheets and e-mails can be swapped for document collaboration platforms and team chats. Video is a great way to connect with individuals who can’t make it in person.

Organizations need to be cognizant of the fact that no combination of tools or technologies will work without investing in cultural change. Teams can absolutely adopt tools for working digitally, but where this fails is when they come to rely on them.

Communication tools are only as good as what you put into them. Teams should be open and transparent whether it is in person or behind the screen. Scrum tools are fantastic, but if Scrum isn’t being practiced there isn’t much need for the tools.

Working together, embracing the principles, and becoming open to the culture that Agile brings will get teams on the right track, with tools used as a supplement to close any gaps. This is the difference between doing agile and being agile.

Closing Sentiments and Cliché Quotes:

  • We’re not supposed to be good at something the first time we try it. We get better the longer we do it. “Practice makes perfect”.
  • Change is inevitable. Get in front of it and be flexible. “Become like water”.

    The mindset is huge. A hammer is useless without any nails. Tools (frameworks and technology) alone won’t drive change. “Mind over matter”.

culture ,digital transformation

Published at DZone with permission of Ryan Searle . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}