Chief Digital Technology Officer & SVP
Share this article
- The Evolution of the C-Suite: Part 1
- Look who's coming for the CEO role
- i.c. stars Highlights Disruption in the C-Suite
- You're Competent, So Be Confident!
- Good news! A tech role where women are gaining ground
- The Transformative Power of Digital Innovation
- CDOs in NYC: 10 Takeaways from Today's Change Agents
- The Meteoric Rise of the #CDOCareer
- 1 Night, 100+ Powerful Career Lessons: A Recap of ARA New York's October Mentoring Forum
- The Importance of Facts, Figures and Faking It
- #HNCIOSurvey Webinar: 'INTO AN AGE OF DISRUPTION'
- A Lot of Disruption in the Happiest Place: Australia's CIOs Speak
- Balancing Business Vision & Technology Limitations
- Neutralizing IT Offshoring's Biggest Barriers: Time, Language & Culture
- It's Not the Disruption that Matters, It's How You Handle It
Using Agile On- and Offshore: It Can Work!
On June 22, Harvey Nash hosted one of our most popular Webinar's to date. More than 170 busy IT leaders, managers and developers joined online as we presented the challenges and opportunities of using Agile to develop software with blended onshore and offshore teams.
Agile has a strong and growing fan base in the software development sector — the attendance levels of this summertime Webinar alone are clear evidence of that fact. However, for Agile to succeed as a software methodology, rigorous dedication to the collaborative, iterative approach is required. Let's face it, you can't dabble in software development and deliver a topnotch application. The same goes for the development methodology: you can't dabble in any methodology — be it Agile, incremental or waterfall — and succeed in delivering well-crafted software and solutions.
So what's an IT organization with software development teams spread across multiple countries and time zones to do? Can Agile be successfully implemented when teams are both on- and offshore? As We explained in our Webinar, it can be done with smart compromises, excellent communication and outstanding ScrumMasters. To give you a taste of the insights he shared, I have listed just five of the many best practices discussed that day. I think this sampling provides good examples of the ways Agile must be adjusted to serve the needs of blended teams.
Agile Best Practices for a Blended Environment
Have ScrumMasters in Offshore Locations. Some organizations make the mistake of having only an onshore ScrumMaster and leveraging a project or site manager in their offshore location(s). Agile can only succeed among blended teams if all teams are being held to Agile standards. That requires a ScrumMaster in each location, leading teams, upholding the integrity of Scrum meetings, managing to burn down charts and teaching the methodology to new staff members. A project manager may be excellent at his or her job, but if he/she is not an Agile expert able to manage sprints and run Scrum meetings, onshore and offshore teams will not be working in synch and Agile will not succeed.
Use Externally Visible Tracking Tools. There are many good tracking tools businesses can leverage to give Agile teams direct insight into what is happening in the development process. In a blended development environment, these tools take on even greater importance as they serve as a primary way for development and business team members in separate locations to track progress of their peers and to understand their role in the greater project. Making these tools externally visible is an important part of upholding Agile's tenants of collaboration and transparency.
Keep Scrum Meetings Short & Local. Rather than trying to manage daily Scrum meetings across an on- and offshore team members and many time zones, keep them very short (15 minutes) and local. Each geography should manage its own 15-minute Scrum meeting and those results should be shared in a Scrum of Scrum meeting between ScrumMasters from each geography. Blending these meetings across locations is too chaotic, increases their length and becomes a serious drain on productivity.
Create a Message Board. By using a company intranet or open source tool, build a discussion board where all team members across locations can share issues and how they were addressed. This allows teams to maintain the collaborative spirit of Agile outside of Scrum meetings and despite time zone challenges. It also gives ScrumMasters a place to post issues identified in local Scrum meetings and share their resolution with the broad team to increase knowledge and performance across the entire organization.
Give Global Task Management to One Onshore ScrumMaster. Whether you have one or 10 onshore ScrumMasters, one of them must be the top ScrumMaster who manages all tasks and is able to report issues across the entire development organization and up to business stakeholders and leaders. Proximity to the business and business leaders make onshore ScrumMasters a better choice for this role as they can quickly gain business input on issues and questions and find out whether or not the solutions shaping up to meet business needs.
Remember, these are just five of many of the good lessons Harvey Nash shared for leveraging Agile in a blended development environment. We invite you to learn more through our Podcast and by reading the post-Webinar Q&A, which we have transcribed below.
Harvey Nash June Webinar Q&A Transcript
On June 22, 2010, Harvey Nash's VP of Technology Solutions, Anna Frazzetto hosted a Webinar for CIOs, CTOs and senior leaders of IT. During their presentation Anna discussed Agile software development and ways to successfully adapt the methodologies for offshore success. The presentation concluded with a Q&A session, where Anna was joined by Harvey Nash's IT Services Group Practice Director Eric Johnson. The following is a transcript of the session.
Q: Are there productivity metrics around the value of extreme pair programming?
A: That's a very good question, and again it comes back to the idea of this being almost a religious argument in several ways.
There are metrics and they will be colored by whatever direction that the person giving the metrics wants them to come from. I've seen metrics that paint a very rosy picture, and I've seen metrics that paint a very dire picture. It kind of depends on who you believe.
Pair programming certainly does work, it works in certain environments, but it's very difficult for a lot of teams to wrap their head around the proper way to do it, so very often you'll get back metrics that it fails, because team members don't understand it or they're not entirely bought into it.
In situations where team members are bought in, the kind of things that you see from pair programming is a significant decrease in bugs. If both people that are working on a particular piece are truly watching for what the other person is doing, and they're truly talking amongst themselves as they're working, the person that's coding will be kept honest by the other person that's looking over their shoulder.
So, again, it just kind of opens up discussion between team members. But as far as the kind of metrics that are available, they are available, but they're very swayed according to who's giving them.
I'm thinking of one particular study where I've seen a relative decrease in defects of something on the order of 35-40% of defects being introduced during the coding phase that are detected in initial system tests. But you've got to basically trade that off against your overall productivity for two developers versus one developer, and defect rates for a single developer.
Q: Would you recommend that offshore teams have their own product owners?
A: I would say no. In general, the role of the product owner, in my experience, is to prioritize the items of value to the business, in developing a release plan that meets a set of objectives for a product — the features and functionalities that need to be included in a release. At least in our business, the stakeholders are onshore, and you need the product owner to be close to the business and working with those folks hand-in-hand, and then able to communicate decisions down to ScrumMasters onshore and offshore. It is important for the offshore ScrumMaster to understand what the priorities are and have a very clear alignment in priorities with the onshore product owner.
Q? One of the things that we struggle with is overall transparency between teams and I'm wondering if you have any generalized tips to get teams to be as open as possible with one another.
A: One of the biggest pieces, if you're working with onshore teams, is physical proximity. Another piece is, a lot of times it's useful for various team members to sit in on one another's Scrums. Another idea is for dashboards to be written that merge together the work that's being done between different teams. Those are very specific things, but what I've also seen work, is if there are general meetings within the entire group that give some kind of an update as to what team members are doing, and what the different groups are doing amongst themselves.
Now, what I will say, a big piece of transparency is going to be watching for what one team is doing that could possibly affect another team. When you're doing that sort of thing, it's very important that at the very least different ScrumMasters sit in on one another's Scrums. The ScrumMaster needs to be responsible for being able to see what works and what another team is doing that could possibly affect their team. This works also with offshore groups.
So if you are holding a Scrum yourself, it's important that the offshore ScrumMaster be wrapped into that if there's any chance that if could impact what they're doing.
With distributed teams, one practice I've found to be useful is, out of each Scrum meeting, the ScrumMaster, or whoever is designated to take notes basically should be compiling the answers to the questions "What did you do yesterday?" "What are you working on today?" "Where are you having issues?" and "Where do you need some help?" In compiling those notes and posting them in a common place — a discussion board, there's open source software, TFS implements one — that can be helpful. Just post ad hoc or in-the-flow question and answers that need to be discussed between onshore and offshore locations so that everybody can see the questions that are coming up and everybody can see the answers. I find that helps a bit with transparency.
Even something as simple as having an intranet site that team members can go to with message boards or that opens up to dashboards that show even team successes or certain team challenges that are going on, that can be useful as well.
Q: How do you recommend handling bugs during a sprint? Enter every single bug as a task?
A: I've seen it done both ways. In general I think that it works better if there is a task that gets opened for each bug. Some teams will create just kind of a single bug-fixing task that's a single multi-day task that gets burned up as team members work on bugs. That works OK, but I find that doing it that way is a little bit inexact and at the end, you want to get as solid a set of metrics around how much time you're spending on bug fixing as possible. You can really only get that in my opinion, if you open up a separate task for each bug.
Q: In terms of sprint cycles, how do you determine how long the sprint cycle should be, and what are the key factors in determining that?
A: That's something that I see plague quite a few companies. It can be a little bit confusing to figure out. What will drive that will be the business itself. They will tell you, first off, how often they can accept new releases and also how often they want to accept new releases. I will say that in general, sprints should be kept to somewhere less than a month. Anything above that, I've found, tends to cause the team to wander off a little bit too far. You want to have releases happen often enough that you can get fairly continuous feedback from the business and from the people accepting the software, to tell you whether or not the software is meeting their needs. You don't want to make it too short, because it can be difficult to put in all the things that you need to do.
For example, one-week sprints, from what I've seen, have never worked because it's almost impossible to fit in the initial level of documentation, the actual coding and the bug fixing, and the release, all within a single week. What I've seen is teams generally try doing either two or three-week sprints at the beginning and adjusting that as necessary.
One of the key factors behind Agile being as open as it is is the fact that you can change things to suit what your company is doing. So, if you try three weeks and you find that it's not working for you, adjust it in or out as necessary.
Q: I'm curious about your suggestion on running Scrum meetings. We do have a team onshore and a team offshore, and with the time difference it's been very cumbersome. Do you have any suggestions of what you've seen work?
A: I've actually run into that problem several times. What I've often seen happen is that the teams will hold their own separate Scrum meetings, and the ScrumMasters are the ones that end up getting together and so in the environment that I saw, the teams were roughly 12 hours apart from each other. So what would happen is that the ScrumMasters would get together at 6 a.m./p.m. to talk out what the issues were between their two teams. So, on each team, one member ends up having to do some amount of shifting, it's generally not that bad to be able to meet with the other one.
I've seen teams run Scrum meetings over e-mail, but that generally isn't as good because the entire idea is to foster communication. So you want your ScrumMasters to be talking between themselves about things that have come up or things that could be possible problems in the future.
Generally, I would almost never recommend in situations like that, having the entire Scrum team get together because it's just too demanding on the team members. The whole idea is to get rid of meetings and to remove impediments from the team members who are actually doing the development work.
Q: One of the problems that I think most of us face in the software industry is, the fact is that, whether you're in a service industry or product — and especially in product — you have to make six-month, nine-month, long-term promises to customers, to analysts, to board members. That's how you do your business, and customers are not happy for you to say, you know, "In three weeks we'll tell you what we've happened to achieved." Scrum is incredibly more powerful than Waterfall. Scrum actually works. But it has to exist in a container where you make long-term promises and I heard nothing in this seminar and I see nothing in the literature that talks about how to resolve that conflict. I don't see how we can be frankly talking in good faith about Agile if we don't address the fact that our businesses do depend on long-term promises.
A: Sure, and that's very true. You often won't see a lot of that within the Agile documentation because that's not what Agile focuses on.
It's very true that within the day-to-day business world, you've got to make long-term promises. So, what I've seen happen within that is you'll make promises that are based on, as you were saying, three- or six-month engagements, and then work within that to produce whatever you need to produce within the two-week sprints that you're putting out. You've got pinned down the long-term goal, and then the sprints themselves are the ones where it gets adjusted day in and day out.
If the teams are being forced to pin down exactly what they're going to put out with each two-week sprint, that's going to make Agile very difficult to implement. If you can work to just pin down an end point that's out several months, you can do that with the idea of shifting between the individual releases. I've seen that work. What generally will happen is the last few sprints end up being a little more stressful in that situation because people realize that there may have been things that got pushed out that they didn't work in. So team members may end up doing a little bit more overtime in the end. You may end up seeing the burndown charts looking a little bit off. But it really can be done, and it ends up being better than a Waterfall methodology. It doesn't end up being true Agile, because, as you mentioned, you're not allowing teams to be able to put out what they need to. But, it can be done, and it does work better.
The thing that always gets brought up is the fact that if you were doing Waterfall, at the end of the six months, you'd be going back to them saying, "Here's what we weren't able to do" anyway. There's no methodology where you would at the end of six months go back and say "Here's exactly what we gave you." Agile is essentially just trying to get rid of as many of those "Hey, we weren't able to do that" as possible.
Comment from Webinar Attendee: Yeah, that's true. One of the things I say to my own crew is that Agile just makes us admit sooner the bad news we didn't want to have later, and that in fact is a positive thing because it gives us more options when there's still time to respond. The fact is that neither customers nor the most senior layers of management tend to appreciate that.
Agile just brings those kinds of things up earlier, that's exactly true.