BT

Four Must-Have Rules for Scaling Enterprise Agile

Posted by Ivan Kot on Sep 20, 2015 |

 

Agile methodologies long ago proved their efficiency with small co-located teams, hitting home with the flexibility and velocity that come naturally to such teams. But when it comes to moving past team level to organizational scale, Agile practices are up against enterprise development realities like distributed teams, multi-component projects and traditional resource management.

As a matter of fact, to adopt Agile practices, specifically Scrum, no organization is too big, complex or distributed. Scrum practices scale perfectly well to fit complex enterprises of more than 100 people, provided due attention is paid to organize the transition process. Here are four rules to follow when implementing Agile at the multi-team enterprise level.

#1. Clearly define what large-scale Agile means.

Misunderstanding Agile development causes numerous organizations to either avoid it or worse, dive headfirst into Agile in the absolutely wrong way. Some of the Agile-related misconceptions revolve around the belief that Scrum is unable to provide accurate project schedules to support organizational planning. The truth, however, is that Scrum development, with its just-enough up-front planning and analysis approach, supports organizational planning in a way that is more effective than the majority of other development approaches.

First, with an easily managed and prioritized feature scope, Agile practices make it easy to meet deadlines with fixed resources, making project costs more predictable. Second, completing features based on their priority rather than tying them up to planned phases eliminates the risk of ending up with a completed functionality that you want to change, extend or cancel.

Large-scale Scrum consists of all the features available with regular Scrum plus specific elements that have proven efficient in connecting Scrum’s building blocks in large multi-team, multi-site environments. Consider, for example, customer involvement at scale; with each Scrum team wanting different skill sets from a customer candidate, the establishment of a separate unit responsible for managing customer involvement may be required.

Another example is integrating the output produced by all teams working on one product into one potentially shippable product increment within one iteration. This can be achieved by:

  • Coordination of the ‘definition of done’ across the organization in order to define acceptance criteria for all stories, features and defects completed by every team;
  • Set-up of Scrum of Scrums meetings to help resolve cross-team issues and dependencies. A representative from each Scrum team should be designated to take part in a joint sprint review designed to increase overall visibility into the progress.

#2. Wave farewell to waterfall habits.

Even a clear-cut understanding of Agile practices doesn’t necessarily save an organization from trying to modify the basic rules of Scrum to mesh with long-established waterfall habits. This is doubly dangerous as it runs the risk of ending up with the worst of both with none of the benefits of either.

Agility is gained through continuous requirements analysis, design, build/integration and testing. Moreover, the borders between all of these activities are blurred, so any attempt at milestone mapping to the phases will be ineffective. Still, some organizations settle for the ‘upfront analysis, up-front design/continuous development’ modification of Scrum, introducing waterfall processes back into the development effort. I was once engaged in a project with a client who relied on Scrum to boost the value of the software product they were developing. Unfortunately, the company was reluctant to let go of the formal requirements approval procedure they had been using for years. As a result, while they did improve team performance, they lagged behind in increasing feature value with each sprint delivery. It was only once the company allowed flexibility in creating and managing the product backlog that it managed to assure delivery of valuable product increments at the end of each sprint.

Another common malpractice is slicing user stories along task lines, not functions, when splitting large requirements on a product backlog that is shared between several teams. A better method would be to think of each slice as an independently verifiable piece of a bigger function implemented across all layers of the application architecture: user interface, business logic, data access layer and database.

#3. Understand that Agile methodologies are not magic.

Moving to Agile definitely helps businesses potentially improve their bottom line by enhancing software quality and customer relations. It also helps organize the work, but it will not teach each member of the team to be aces in their respective spheres. Going Agile takes patience due to the effort required to invest in the intensity of team collaboration; a cross-functional team needs to run several pilot sprints before it starts hitting its stride. Moreover, all team members will need to learn new process skills, which will initially slow the team down.

And setting up Agile teams and processes is only half of it; a lot still has to be done in order to coordinate and stabilize operations. One way to meet this challenge is to collaborate with teams that are mature Scrum adopters. For example, one of our clients was in the process of converting to Agile at the time of project delivery. They had Agile teams up and running across the enterprise and were looking forward to gaining stable velocity and predictable releases. When the project processes synched up, we detected the company had issues with the product backlog management and release planning. The good news was that detecting the problem was the most complex part. After just two sprints, the company managed to strengthen the team, improve planning, and give its stakeholders a better idea of how they can evolve their products.

Do not rely on Agile as a management crutch either. Sure, managers will set the overall tone for the environment and will play a key role in forming, growing and improving teams through balancing traditional methods of managing a stable system and more innovative methods of managing a self-organized system. But when it comes to supervising self-managed cross-functional Scrum teams, the traditional world of project managers is turned upside down. They are now challenged with learning a new project budget determination process, team staffing, project schedule building, and coordinating assistance and support from other departments. In Scrum, the team itself decides on the scope of commitments they undertake for every sprint. The only job left for managers then is leveraging the Scrum process transparency to ensure no over- or under-commitment takes place.

#4. Put people first.

Scrum is not a development method, but rather a framework to help organize work and increase team efficiency. Scrum teams are organized in a way that enables members to accelerate to their greatest productivity. There are many factors that combine to make this process work:

  • Organization of work: 100 percent dedication to a specific team, uninterrupted operations during a sprint, and sustainable development pace with no forced overtime can prevent losses in employee effectiveness, quality and productivity;
  • Availability of tools: the power of Scrum comes from collaboration between team members, which is also true for remote and offshore large-scale product development. As such, collaboration tools are needed to support visibility of each team member’s progress toward the mutual commitment. There are also plenty of solutions designed for bringing non-co-located team members, offsite product managers and offshore teams together – from instant messaging solutions, Wiki servers and document repositories for sharing information, to web cams and shared desktops for product demonstrations;
  • Corporate education: bare enthusiasm and commitment to transformation are not enough to enable development teams and managers to work efficiently in an Agile environment. In order to consistently meet high standards that have been established organization-wide, a solid corporate education policy should be developed to provide initial and continuous development training.
  • Technical excellence: focus on achieving optimal team velocity and rapid delivery of working functionality shall not in the least compromise on the quality of the delivered code. Make sure all members of Scrum teams are proficient in – or at the very least familiarized with – such technical excellence practices and tools as test-driven development (TDD), peer code reviews, continuous integration and automated testing.

The Manifesto for Agile Software Development begins its declaration of better ways to develop software with putting individuals and interactions ahead of processes and tools. In this respect, interactions across development teams and among team members is the aspect that immediately comes to mind. But this also holds true for bringing interactions with customers to a completely new level. Intensified customer involvement requires the team to be attuned to the customer’s current mood, attitude, wants and needs. Should the customer show signs of frustration, the team could, for example, switch from a preferred high-interactivity discussion to a more reserved, interview-type discussion for the sake of preserving the intensity of future customer involvement.

Most importantly, always focus on the people. At the end of the day, it is employee productivity and customer satisfaction that are the most instrumental in reaching organization-level Agile goals.

About the Author

Ivan Kot is a Unit Manager at Itransition. He began his career as a developer, taking different positions in both web and mobile development projects, and eventually shifted focus to project management and team coordination. Among his current responsibilities are project supervision and establishing strong business relations with company clients. A certified Scrum Master, Ivan ensures project management is done in compliance with guidelines and best industry practices. His everyday motto is, “Iif something has to be done, it has to be done at its best.”

Rate this Article

Relevance
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT