What Drives Agile Teams to Become Agile Organizations

Last week I moderated a panel at nGage's Enterprise Transformation Exchange on Developing an Agile IT Organization: Concepts, Culture and Concerns. The message from panelists was clear. Organizations looking to transform need to go beyond scrum practices and improving IT project execution. CIOs and other IT leaders are looking to agile practices to transform operations, develop new products, drive a stronger collaboration between business and technology organizations, and to establish a more agile mindset from employees up to executives. That means evolving from agile practices to an agile organization, culture, and mindset.



But there are stumbling blocks along the way and problems every organization needs to solve on their own. Here are some questions we received and how we collectively answered them.

How do you help developers adopt agile coming from a ticket-based support practice?


Development teams that were largely supporting enterprise systems are being asked to automate more processes, integrate more data, and develop more substantive changes to enterprise workflows. They are being asked to innovate and not just fix things. These business needs are a mismatch with ticket based IT systems that were more designed to help IT track and respond to incidents and small changes requests made by end users.

Practice changes aren't easy to implement and you can't just push the gas pedal to drive change faster. I recommended to the person asking the question that he start with the basics by getting his team committing to what they could get done and having a daily dialog to answer technical questions or issues. This is a lead in to agile, sprints, and standups but can be less intimidating to people than approaching them with a significant practice change. 

Handling different levels of scope creep


This is an interesting question. Since agile enables the product owner to adjust priorities every sprint, has agile made the notion of "scope creep" obsolete?

The answer is a matter of scale. We want product owners to adjust priorities especially when there is strong feedback from customers and end users on the desired behavior of the product. We want teams to find faster and more simplified ways to implement a user experience. These changes might require teams to to take two steps backward in order to leap six steps forward.

But what if the product owner wants to change the release dates, restate the definition of MVP, add requirements that requires a significant architecture change, prioritize implementations that require additional investment, or make significant compromises on security or quality requirements? We can all recognize that these are major shifts in strategy or attempts to work around standards - even when these aren't well defined.

It takes maturity to have practices to help address these issues when they come up. Teams should have a vision statement for every release and feature that help set boundaries. Technical standards need to be documented. And there should be a process (or dare I say, a governance model) for reviewing, resolving, and sometimes compromising when more strategic changes need consideration. 

Running scrum with very small teams


A third question came up about how to run scrum when teams are very small and people have to wear multiple hats. When talking about scrum, people hear about the need for product owners, scrum masters, team, leads, business analysts, developers for different skills, and testers. That might be hard to pull of when small organizations are supporting many products and platforms.

One way to address this is to start with small ambitions. Small teams may require different people writing stories based on subject matter expertise. For some stories, a developer may be coding and another is testing. The responsibilities of the scrum master may have to be shared across team members.

Starting with small ambitions allows team members to learn different responsibilities and adjust to different roles.

Agile and scrum are not cookie cutter practices


While agile has a set of basic principles outlined in the agile manifesto and scrum has some defined practices, there isn't a one-size fits all approach when applying it to different organizations and business drivers. In fact, it's an evolving practice that needs maturity and realignment as priorities and organizational needs advance. Even when you have certified scrum masters onboard, or are using agile coaches, or if you are adopting a framework like SAFe or LeSS, you have to build and adapt the practice based on many factors.

So once teams get used to the basic practices, they need to learn to mature them over time. They need to bring outside help when useful, but learn to drive the practice on their own. That's what separates teams that are practicing agile, to ones that are becoming agile organizations.

1 comment:

  1. If you liked this post, consider reading my next agile post on capturing agile meeting notes.

    ReplyDelete

Comments on this blog are moderated and we do not accept comments that have links to other websites.

Share