The latest insights from your peers on the latest in Enterprise IT, straight to your inbox.
The methodology works best when you adapt it to your environment.
I really believe in Agile – I think Agile is the right way to go. In this era of constant change and digital disruptions, it seems to me that the traditional approach to development is of very limited value. However, I think it’s a mistake to assume that if you go through Agile training, learn Agile rituals, and start following them, you can expect positive results.
Agile is a methodology, not a prescriptive process, and you need to adapt the principles to your situation. In my current role at Western Digital and in my earlier development roles at McAfee, Cisco, and Tech Mahindra, I have always tried to adapt Agile to the actual environment, and overall, I’ve found that this kind of flexible approach works best.
For instance, core Agile philosophy assumes that you have a co-located team that is sitting in the room and working together. But that’s not how we work now. These days, most teams are spread out geographically.
In the traditional Agile model, you begin by going to a whiteboard, drawing diagrams and talking through the project objectives. But if part of your team is sitting on a conference call on the other side of the world and can’t see what is being written on the whiteboard, they cannot contribute. They will not get a sense of what's happening.
Global delivery, near at hand
To compensate for the challenges of geography, we generally begin a project with a kickoff call during which we share the objectives and the business goals and drivers. The team that’s not in your daily meetings needs to know what is important, and what is going to make the project successful.
I also ask my team members to put together something they can share with others in advance of the call – a summary of their main points or a small diagram or a PowerPoint slide. It doesn’t matter what the mechanism is as long as you create something that everyone can be equally involved in, rather than working on a whiteboard that the remote teams aren’t able to see.
We try to create structures and processes in my teams so that they are constantly talking to each other. With a co-located project, people are always having hallway conversations. These can sometimes involve trivial matters, but they're important to communicating the context of a project. You need to find a way to replicate these for your geographically remote team, to bring them into these side conversations.
That means having more ad hoc conversations, conversations without a pre-scheduled agenda. My morning and evening hours – usually from 9 to 10 in the morning and at the same time in the evening – I make myself and my architects available for impromptu meetings with anyone who has a concern, question or idea.
Similarly, sprint retrospectives can be improved if you bring more people into the meeting. Traditionally, sprint retrospectives are done within the execution team, but managers are left out. But in my opinion, that defeats the purpose of Agile. Including managers and sponsors into these creates a framework to discover any big unknowns or surprises.
We also learned that it’s a mistake to pretend that everyone has the same skills and that you can assign work to different teams and resources interchangeably. In fact, different team members will bring different strengths. Leaders need to identify the strengths in each team member and plan the activities around the strengths of the team. If you give a task to a person who is not at the right level of expertise, you will not get what you want. And you may spend more time reviewing iterations.
Finally, you need to engage in adaptive planning. In an ideal world, you would make adjustments needed on the basis of iterative feedback from the project’s owners. But in fact, if you need to make a change that is more than a tweak, you’ll be better off if you have already planned for some of these contingencies.
I learned about the importance of adaptive planning early in my career. I started out as a mechanical engineer, working with power plants and ship building, before I moved into IT services.
Some of the projects that I did were around refineries and electric furnaces – large, complex projects that took more than a year to finish. They sometimes involved 20,000 tasks and subtasks, and there were resource and cost constraints that had to be taken into account.
Those projects taught me that things do not go always as planned. If you are working on a one-and-a-half-year plan, you have to expect that there will be changes. The scale forced us to look at alternatives and backups, to think about what would work if a certain step fails and how you would adjust your plan and still meet the end date
So now I have a conversation with my team whenever we start on a project. We look at things that are known, things that are unknown, and things that are likely to change. Based on that, we build a plan that includes greater detail on things which are known and that allows for flexibility around things that are unknown. We try to think of alternative designs and plans that we would employ in different kinds of situations that might arise.
I do not advocate changing the rituals of Agile. I still think you should have a daily scrum. I still think you should have a sprint retrospective. But think about why you’re doing them. Are you doing those rituals just because they're part of Agile, or because they are helping you meet business objectives? If the former, you’re missing the whole point of Agile.
Agile isn’t magic formula for success. For best results, you should adapt the ritual to your environment.
If your teams aren’t co-located, you need to communicate more with the people working remotely.
Sprint retrospectives should include the project sponsors.
Make contingency plans if things don’t end up unfolding in the way you anticipate.