Making Agile Work with Offshore Teams

One more excellent question I got at the Valpak presentation last night was regarding “Making Agile Work with Offshore Teams” Here’s a brief response…There are a lot of difficulties and you have to be willing to accept a lot of compromises from an ideal Agile team. Here are a few examples:

  1. Commmunications is a major challenge. I was in a situation where the entire development team was in India and only the customer-facing people were in the US. In a normal Agile environment where the team is collocated and on the same time zone, a brief Daily Standup may be sufficient; but if that is the only (or primary) form of communications with the team throughout the day, it can be very difficult to limit the Daily Standup to just a brief 15 minute session. You have to learn to adapt the communication practices to the situation.
  2. Tools are essential to help close this communication gap and maintain coordination. Where you might be able to use “stickies” on a board with local, collocated teams; that just doesn’t work very well at all with distributed teams to keep everyone informed about what everyone else is doing.
  3. Cultural ChallengesThere are several significant cultural challenges:
    • There are a lot of good developers in India, but it can be very tough to find a lot of senior-level developers. In the Indian culture, someone may be perceived as a failure if they haven’t moved into a management position by some point in their career. For that reason, becoming a very senior-level developer who is not in a management position may not be regarded very highly. The impact of that is instead of having a team of peers who are self-organizing and all individually capable of self-directed work, you may have to compromise and select a few senior-level Team Leaders to provide direction to the rest of the team.
    • Indian people are also very polite and respectful and somewhat regimented (probably due to many years of British rule). In an ideal Agile team, that also works against being a totally self-directed team and you may find that more direction needs to be provided to the team.

Those are only a few of the more significant challenges, but the Indian people work very hard and are very committed to their work. If you go into it expecting that you’re going to be able to setup an ideal team as if they were collocated and from the same culture, you’ll probably get very frustrated; but if you learn to make the best of the situation and make a few compromises, you will find it to be a pleasure to work with the people in India – it just takes a bit of adaptation to make it work.

Tips and Tricks for “Selling” Agile (Superseded)

This post has been superseded by a new version. The new version can be found here:
How Do You Go About Selling Agile?

I visited with Stephanie Stewart and Tom Loftus at Valpak last night and gave a presentation on my new book to a Tampa Bay Agile Meetup. We had a great audience and they asked some great questions that stimulated me to do a couple of blog posts. The first question was “Do you have any tips and tricks for ‘selling’ Agile to management?” That’s a great question and I’ve certainly learned some lessons about that (the hard way) that I can share.

  1. First, you have to look at it from an overall business perspective , not from a more limited development process perspective. It’s very easy to get “tunnel vision” with Agile – we get so enthusiastic about the benefits of Agile from a development process perspective that we assume that what’s good for the development process must be good for the company as a whole and that’s not necessarily the case. Agile is most beneficial to companies whose success is driven heavily by product innovation (see my prior blog on corporate culture).But what if you work for McDonalds? How does becoming more Agile benefit the company? McDonalds is not known very much for leadership in introducing new products. They have improved in introducing new products in recent years (for example, their McCafe coffee has helped them take business away from Starbucks) but rapid product innovation still may not be the most important driver of their business. Rather than attempting to force-fit a company to an Agile approach; you may have to craft an approach that is more well-aligned with the primary success factors that drive the company’s business and becoming more Agile may or may not be the most important factor in the company’s overall business success.
  2. Second, you have to recognize that some companies are scared to death of Agile – they’re afraid of losing control and that fear is not totally unfounded if the Agile approach is not well-designed and managed. So, you may need to start off with more of a hybrid approach as an initial first step to demonstrate success rather than going full-bore into a complete corporate Agile transformation. You also need to recognize that an Agile transformation can take a long time and demands a lot of patience and perseverance.

Finally, nothing sells better than results. Work on developing good results and that will sell itself.

I hope that helps some people avoid learning some of these lessons “the hard way” as I have.

The Relationship of Agile and Corporate Culture

It’s important to understand the relationship of Agile and corporate culture. Adapting an Agile development process to a corporate culture can be a very difficult thing to do because changing a well-established corporate culture is not easy. If you ignore this problem and implement an Agile development process without attempting to integrate it with the overall business environment that it is part of, it’s not likely to be totally effective. The predominant thinking seems to be that you have to force the whole company to be Agile in order to adapt it to an Agile development process; I don’t believe that is the best solution in many cases. A company’s culture should be designed and optimized around the business and markets that company operates in.

One of my favorite books on this subject is “The Discipline of Market Leaders” by Treacy and Wierzema. It identifies three primary “value disciplines”

  1. Operational Excellence – Companies who focus on operational excellence succeed or fail by offering products and services more efficiently than their competitors can offer them. McDonald’s and Walmart are examples of companies whose primary value discipline is operational excellence. They do the same thing repeatedly at a low cost; that is what “operational excellence” is and it is reflected in their culture.
  2. Product Leadership – Companies who focus on product leadership succeed or fail primarily by innovating products to meet market needs faster and better than their competitors. Apple and Samsung are examples of companies whose primary value discipline is product leadership. Constant innovation is very important to these companies and they might be dominated by engineers who wear jeans and sweatshirts to work.
  3. Customer Intimacy – Companies who focus on customer intimacy succeed or fail primarily by providing a high level of personalized service to their customers relative to other competitors. Ritz Carlton Hotels is an example of a company who is driven by a culture of customer intimacy – their employees are trained that customer needs and customer service always come first and their processes need to be flexible to adapt to customer needs.

The idea of value disciplines is that a company can’t be deficient in any of the three areas; however, no company can be all things to all people and the company needs to choose one value discipline as the primary area of focus to excel in. The value discipline that is chosen as the primary competitive differentiator tends to define the whole company and its culture and values.

How do these value disciplines align with an Agile development approach? Obviously, the Product Leadership discipline has a very strong alignment. Companies who are in a business that demands Product Leadership as a critical success factor will have little difficulty in adapting to an Agile development approach because there is a natural alignment with the primary success factors in their business. Operational Excellence is probably the one that is most difficult to align an Agile Development approach with. In these companies, there are several alternatives:

  1. Ignore the misalignment and just implement Agile as a development process without attempting to align it with the business. That’s not likely to deliver optimum results, in my opinion.
  2. Attempt to force the company to change its culture to be more Agile. That may not be successful either and also may not be the best solution for the company’s business
  3. Develop an “Adaptation Layer” between the Agile development approach and the company’s business environment. This approach is probably the most practical and most likely to be successful in many cases. It might consist of putting a thin plan-driven “wrapper” around an Agile development approach to integrate it with the company’s business.

My Agile Project Management Training provides more details on this approach and provides some case studies of companies who have taken different approaches for solving this problem.

What’s the Right Level of Detail to Put in an Agile User Story?

Questions frequently come up about “What’s the Right Level of Detail to Put in an Agile User Story?” – I want to share some thoughts with you on that subject:

There is no absolute right/wrong answer about how much detail a story should contain – the best answer is “it depends”. The level of detail in the story depends on a number of factors including:

  • The complexity and nature of the story itself
  • The level of interaction available from the Product Owner to explain what is required
  • Where the story is in the overall lifecycle – there are at least three levels of detail required depending on how you plan projects, releases, and sprints:
  • Project-level Planning – Least detailed, suitable for very high-level project planning
  • Release-level Planning – medium detail, enough detail to do story point estimates
  • Sprint-level Planning – most detail, suitable for actually starting development and planning development tasks

Here’s what I recommend as some guidelines:

  • It is always best to err on the side of less detail rather than more detail as a starting point – Agile has a concept of “Just Barely Good Enough” which means you put a sufficient level of effort into the task to accomplish what is needed and nothing more – anything more than that is waste
  • Use a top-down, functional decomposition approach to progressively elaborate the level of detail in stories:
  • Start at the top-level to identify epics and story titles only
  • Once that is done and approved, write the actual stories, but only to the level of detail required
  • Rely on the developers and others on the team (QA) to tell you when the story is good enough – a lot of collaboration and face-to-face communication is essential – we need to get away from the Waterfall approach where a BA writes detailed requirements (stories) and then hands those requirements off to developers

Again, the key thing I want to emphasize is that there is no right/wrong answer about how much detail a story should contain…some general guidelines and models can be developed to guide the effort, but the real test of whether a story is well-written or not is based on feedback from the people who have to use the information in the story for whatever purpose it is intended for (estimation or development).

What Does it Take to Become an Agile Developer?

What does it take to become an Agile developer? I recently was in a situation where the development team was completing tasks required for a sprint, but the overall stories were not being completed. The team allocated development tasks to individual developers and also allocated overall responsibility for each story to individual developers. However, for several sprints, the development tasks were completed but a number of the stories were not.

I don’t think the developers on the team clearly understood what it meant to be responsible for a story. I think most saw their primary responsibility as completing development tasks. Completing stories was seen as kind of an administrative coordination function. It’s more than that, in my opinion – a developer who takes responsibility for stories in a sprint needs to be responsible for:

  • Understanding the business purpose of the story and defining and analyzing possible alternative ways of satisfying the business purpose of the story
  • Planning and estimating development tasks with other developers that are required to fulfill the story
  • Working directly with the Product Owner to clarify and further define the details of how the story should be implemented
  • Providing guidance to other developers as necessary who are engaged in development tasks associated with the story
  • Taking overall responsibility for “shepherding” the story through the process all the way to (and including) UAT. The developer responsible for the story should lead the presentation of the completed story to the Product Owner in UAT (or Sprint Review)

I think it’s sometimes taken for granted that any developer can easily move into an Agile project – I don’t believe it’s that simple and my experience is that some developers have a hard time making that transition. Some developers just want to write code and are not even interested in taking on these additional responsibilities.

Overcoming Misconceptions About Agile Teams

There are a lot of misconceptions about Agile teams. There is no doubt that “Agile is a team sport”, but have you really thought about lessons learned from team sports that can be applied to Agile teams? Many people have the view that an ideal Agile team is a team of peers where there is no specialization among people on the team, everyone on the team is capable of performing any role, and everyone on the team is also responsible for everything. That’s a very idealistic view and may not be the best way for Agile teams to work. For example:

  • Is it inconsistent with Agile for a more senior-level Tech Lead to provide direction to other more junior-level developers? My experience in the real world is that you don’t often find teams who are all peers and it may not be practical or cost-effective for a company to staff a development team with all senior-level people who are all self-sufficient. The key thing is that you can have people at multiple levels of proficiency on a team without creating a formalized hierarchical structure that inhibits individual productivity and initiative.
  • Is it inconsistent with Agile for individual people on the team to have defined roles like QA testing and does that limit the ability of the team to be cohesive? Think of a football team – each player has a role that he specializes in and is good at that role. A football team probably wouldn’t be very good if there was no specialization and everyone did a little of everything. The center might be a 300 pound gorilla and might be very good at blocking and tackling, but he may not be very good at throwing touchdown passes. Imagine the 180 pound quarterback attempting to play on the front line and blocking and imagine the 300+ pound center attempting to play the role of the nimble quarterback throwing passes.Specialization on a team doesn’t preclude developing high-performance teams with very cohesive teamwork. Having someone on a team who is skilled in QA testing and is specialized in playing that role is a lot different than having a separate QA group outside of the development team who specializes in QA testing.
  • Some people seem to think that having well-defined individual roles and accountability is inconsistent with having overall team accountability – shouldn’t everyone on the team be responsible for everything? Think of a football team again – everyone on the team, as a whole, is responsible for winning; but what if everyone on the team just ran around without defined roles that they were responsible for and without defined plays trying to figure out what to do to get the ball across the finish line? It wouldn’t be very likely to be a very high-performance winning team. Teams where “everyone is responsible for everything” and there is no individual accountability for anything are not likely to be very effective.

Agile Is a Lot Like Playing Golf – It Can be Very Difficult

Agile Is a Lot Like Playing Golf -there are a number of things about Agile that remind me of playing golf.

  • In the game of golf, if you didn’t have to get the ball in the hole, my golf score would be a lot better.  Imagine if the requirement in golf was only to get the ball somewhere near the green – if you didn’t actually have to get it in the hole, my score would be a lot better, but that would be very misleading, wouldn’t it?That’s equivalent to a team that doesn’t have a clear definition of “Done”. On the surface, it may look like they’re completing sprints successfully, but when you look deeper, you sometimes discover that there is not a good process to validate that the work is really complete and really meets the business need it is intended to fulfill.
  • The reason golf can be such a difficult and frustrating game to master is that it requires a fair amount of discipline, lots of practice, and lots of patience and persistence to be good at it – Agile is the same way.
  • Golf also requires some planning and strategy – the best players carefully consider every shot; They don’t just go out there and whack the ball around.

Blending Agile and Traditional Project Management