E-Book

Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications In this eBook, experts deliver advice on handling many of the problems that result from working with enterprise-scale projects in an agile environment. Planning, collaboration, ALM tools, outsourcing and transitioning from a traditional environment are all areas that need to be carefully considered before embarking on large-scale agile. If your organization has already made the switch, but is experiencing growing pains, this e-book will help get you back on track. Whatever stage of agile transition you are in, the following expert advice will give you the information you need for successful project implementation.

Sponsored By:

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

E-Book

Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications Table of Contents Keys for Agile development: Planning and team collaboration on large or small projects Large-scale Agile: Making the transition to Scrum Resources from IBM

Sponsored By:

Page 2 of 11

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

Keys for Agile development: Planning and team collaboration on large or small projects By Lisa Crispin Whether your application is big or small, the first step of any project is planning. In this tip, Agile expert Lisa Crispin gives some good advice about planning and collaboration on agile projects of any size. However, with large-scale or complex applications, there needs to be extra considerations in your planning efforts. Most likely the project will consist of multiple teams, and the makeup and assignments on those teams will be crucial to the overall success of your large project. Collaboration between teams will be an additional challenge. The larger the project, the more coordination between teams and integration points there will be. Find out what advice Crispin has for strong project planning in a multi-team agile environment. If you‟re just starting out with Agile development, you may be puzzled by how planning gets done on an Agile project. You‟ve heard that “big design up front” is bad, but diving right into the coding with no forethought seems foolish. How does an Agile team achieve the right balance of “just enough” planning in order to maintain a steady pace and deliver business value frequently? Whether you're working on a large-scale enterprise project or a small Web application, planning cannot be overlooked in an Agile environment. Here are some key practices that I've found are essential to success in planning in an Agile environment. “Just-enough” preparation When you have a complex new project (or “epic,” as some Scrum teams call them) coming up, schedule one or more brainstorming meetings one or two iterations in advance. Timebox the meetings to an hour each. If an hour isn‟t enough, schedule another meeting. It‟s essential to have time in between brainstorming meetings to think about the business problems to be solved, and mull over the pros and cons of various design approaches. During the brainstorming meeting, have the product owner explain the purpose of the new project. Invite other stakeholders as needed. Help the business experts focus on the business challenges -- they should refrain from proposing a technical implementation. Talk

Sponsored By:

Page 3 of 11

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

through design options, diagram them on a whiteboard, and think about how they could be tested. Ask the domain experts for examples, and work through them on the whiteboard. Propose ways to slice the project into manageable stories, and how those stories would be prioritized. You may decide to spike a design solution, writing just enough code so that you can test to see if your approach will work. This can provide information to plan and estimate user stories for your project. On my team‟s current project, performance of the code was paramount and we needed a spike to tell us if the design would perform well enough in production. Make sure that all team members can participate in this advance planning. Since our team has a senior programmer (and manager) in India, plus other team members who work remotely some of the time, we plan brainstorming meetings for a time when everyone in every location can be present. A virtual tele-presence device with a good webcam and microphone allows remote attendees to interact as if they were in the room with us. We take advantage of time zone differences by having the team member who‟s half a day ahead do research and preparation to help us speed up our brainstorming, estimating and planning meetings. For example, we recently planned a major project to rewrite a core part of our system. Before the first brainstorming meeting, the programmer in India studied the old code that would be replaced. The morning of the first meeting, we had an email from him with a write-up explaining the legacy code‟s design. This information gave our meeting a jump-start. On large, multi-team projects, it usually makes more sense to have each cross-functional team meet for brainstorming, then share information and coordinate dependencies by having representatives from each team get together to work through each team‟s design ideas and plans. Planning for collaboration Whether you decide to spike a design solution, or are planning the first sprint of a new project, you have to balance collective code ownership and pairing with the realities of

Sponsored By:

Page 4 of 11

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

having remote team members. You must accept the limitations of a distributed team: sometimes it‟s counter-productive to have a remote team member work on a particular story and you must find ways to divide the work up sensibly while keeping everyone informed about all stories. Other times, remote pairing works well and the whole team can work on one theme. It‟s all about experimenting. My team will try an approach for a particular theme, and if it doesn‟t seem to be working well, we adjust. Use technology that promotes collaboration, such as wikis, video and audio. This keeps everyone on the same page, regardless of location. If my team has planning or design discussions when the remote person isn‟t available, we take notes and draw pictures on the whiteboard and post those on the team wiki, and bring everyone up to date during or after the daily Scrum. These technologies are critical for teams in disparate time zones, where it‟s impossible for every team member to participate in every meeting. Larger projects, especially those with distributed teams, may need more sophisticated online project tracking tools that give people in every location the most up-to-date information. Be wary of organizing your project by expertise. For example, having programmers in one location and testers in another impedes communication and results in lots of wasted time. Cross-functional teams with a diversity of roles and viewpoints have the best chance at finding a good design solution and anticipating future needs. For example, if no testers are present in the design sessions, the team may neglect to plan for essential resources such as realistic test data, adequate test environments, and the need for different types of testing such as stability, security and usability. Planning the work When we planned the first sprint in our most recent project, we discussed the results of our design spike, diagrammed flows on the whiteboard, and talked about the best approach to various coding and testing challenges that surfaced. There were still unknowns, which made it hard to write detailed task cards. Instead, we wrote general cards with big chunks of hours, planning to break those down into specific task cards as we learned more.

Sponsored By:

Page 5 of 11

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

Don‟t waste time trying to map out the whole iteration in the planning meeting if your team is venturing into new territory. Plan time to learn and experiment with coding and testing solutions. As you learn more, you can plan more. Even if you‟re doing Agile development, business deadlines are a fact of life. Work with business stakeholders to manage scope and prioritize user stories. Keep everyone grounded in reality. If the project seems too big for the specified drop-dead date, the business experts will have to prioritize the “must-haves” and postpone some business value for later. Agile planning success Don‟t get bogged down in long planning meetings, but don‟t forge ahead without any thought either. Make sure you understand the needs of all your stakeholders. If your team includes people in different locations, put some extra thought into your planning process. Experiment with different approaches, and use retrospectives to evaluate whether the experiment is working. Remember that what works at one stage in your team‟s journey may not work later on. Make sure your team has all the roles it needs to anticipate different types of risk. Find the right balance for planning and collaborating that keeps your team feeling productive and communicating well.

Sponsored By:

Page 6 of 11

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

Large-scale Agile: Making the transition to Scrum By Matt Heusser If you've got a technical staff of fifteen people, a Scrum conversion isn't that hard. You get everyone in one room, lock the door, give them a problem and say "solve it." Ok, ok, it's a little more work than that. Still, in that environment, switching to Scrum is mostly a matter of mindset and culture. With fifty people, though, it's not so easy. Five hundred or more? Forget about it. Large organizations have policies, organizational structures, politics, and just plain inertia that will hold them back from an overnight overhaul. In other words: "big bang" Scrum projects are expensive, cause the team to slow to a crawl for weeks or months before improving performance, and are likely to fail. Let's look at an alternative to "Everybody comes in on Monday and does Scrum." A typical Scrum scenario As an example, let's look at a large software development organization. Specifically let‟s look at a software company that has grown through acquisition, off-shored some of its development and test operations and also needs to integrate with some third-party applications. Changes in the software will now require “ripples” to other teams and the communication costs for a single change skyrocket. Yet on every large team I have ever worked with there was a small team trying to get out. This small team did the core of the work -- the analysts, developers, and testers who were going to work on the core components. In many cases, everyone else's job was to translate the core work, push it to include their sub-products, or integrate with the new core engine. Ken Schwaber, co-founder of modern Scrum, claims that, over time, the core work tends to

Sponsored By:

Page 7 of 11

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

be considered „legacy,‟ or at least less interesting. This means that the staff capable of doing the work tends to leave or move on to other roles within the organization. Over time, the core engine becomes the bottleneck. Suddenly performance falters and a large-scale Scrum conversion looks appealing. Start with a tiger team Before we jump to a big conversion, let‟s consider a series of small refinement, starting with the core development team. It‟s likely this „team‟ is actually a half-dozen to a dozen people, scattered throughout the organization. Instead of re-organizing six departments, we temporarily borrow the people we need and create one tiger team. To fund the tiger team, all we need is a single war room, a little consulting time, and a little management attention. Perhaps we send the team to Scrum training; if we do, this costs us twenty person-days instead of two hundred. We allow the team to self-organize and self-direct while insulating the team from politics and providing it some sort of interface to work with other, more traditional organizations. Another way to do this is to respond to an emergency, crisis, or big piece of software that is needed in a hurry, taking volunteers. In either case, we have now created a single multi-disciplinary product team. At the same time, we have found the bottleneck holding up development and massively decreased its communications delays. So this new big project, be it an upgrade, a migration, or some change to comply with some law, is going get done faster than usual. By the end of the project we now have a high-functioning, multi-skilled team. Instead of breaking the team up, we formalize it, creating a sort of special-missions team that operates differently than the old functional teams. If you can get this far, pat yourselves on the back. You‟ve won. You can now sit back, resting on your laurels, certain that you have improved the organization in a real and specific way.

Sponsored By:

Page 8 of 11

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

Expand Sure, you could stop at one Scrum team. You might consider the Scrum team some sort of elite unit, and the other teams „mere humans‟ or „doing it the old way.‟ If the new Scrum team appears happy, if they appear successful, if they get the promotions and recognition, well... it‟s likely the other teams will start to feel ignored, or maybe a bit jealous. So take volunteers to form Scrum team number two. Once this second team completes its first project, we give it a formal manager and transfer the team members, thus creating another independent unit. Lather, rinse and repeat. Now it‟s unlikely that every single team member will want to move over to a Scrum team, and that‟s okay. In addition to new development, the team will have maintenance requests, ongoing operations and support, or what some call MOOSE work. The people that stay back are likely the ones who take pride in straightforward, repeatable work, and there will likely be plenty of that kind of work to “keep the lights on.” Meanwhile, over time, the Scrum teams eventually become the primary drivers of new feature development. How do I staff and manage this transition? The newly-formed Scrum teams will need Scrum-masters, coaches, some sort of product manager, and possibly a director or two to report to. So there will be plenty of opportunity for traditional managers to transition over time to the Scrum side of the house. At the same time, the groups those people manage will be shrinking. That means that as leaders transfer over to the Agile “side of the house,” few managers are needed to control the MOOSE work. As the MOOSE work becomes more administrative and easy to measure, it will make sense to merge teams and have fewer managers of those teams. Eventually you‟ll end up with two organizations: The development staff and the systems support staff. Or perhaps not; you can always stop somewhere in the middle with a few

Sponsored By:

Page 9 of 11

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

active Scrum teams, and other organizations largely untouched. In a heavily outsourced or distributed organization, that might be the best win possible, at least for the time being. Conclusions This friction between those who want a new way to do things, and folks who prefer the old way, is the cause of a fair amount of conflict, strife, and failure in Scrum adoption. Some people want to have explicit goals and defined process, and won‟t be excited about an edict to “Start Scrum on Monday; figure out what needs to be done and do it.” On top of that, groups organized by function will have a number of functional managers whose role may be disrupted by a Scrum transition. My advice for Agile transition is not “big bang” but instead incremental, done in a way that respects people and gives them options. This kind of focusing on people isn‟t limited to Scrum adoption. It turns out that every time you change the process, you get to decide if you want to focus on people sitting in the same room and talking or churning out documentation. You get to decide if you want to manage to plan or to outcome -- and if you‟d like to plan every action of the team up front, or enable them to make good decisions in the moment. Choose wisely.

Sponsored By:

Page 10 of 11

SearchSoftwareQuality.com E-Book Scaling Agile – Beating challenges in large-scale Agile development for enterprise applications

Resources from IBM

Agile Development at Scale Powered by Jazz Agile Development Powered by Jazz One’s Enough for Agile Application Development Management

About IBM At IBM, we strive to lead in the creation, development and manufacture of the industry's most advanced information technologies, including computer systems, software, networking systems, storage devices and microelectronics. We translate these advanced technologies into value for our customers through our professional solutions and services businesses worldwide.

Sponsored By:

Page 11 of 11