Modified by ScottAmbler
I'm happy to announce that A Practical Guide to Distributed Scrum by Elizabeth Woodward, Steffan Surdek, and Matthew Ganis is now in print. I've been talking this book up in presentations and with customers the past few months and promised that I would let everyone know once it was available. I was one of several people who wrote forewords for the book, Ken Schwaber, Roman Pichler, and Matthew Wang also did so, and I've modified my foreword below to help you to understand a bit better what the book is about.
If you’re thinking about buying this book, you’re probably trying to answer one or more of the following questions: “What will I learn?”, “Should I spend my hard earned money on this book?”, “Will it be worth my valuable time to read it?”, and “Is this a book that I’ll refer to again and again?” To help you answer these questions, I thought I’d list a few user stories which I believe this book clearly fulfills:
As a reader I want:
a book that is well-written and understandable real-world examples that I can relate to
quotes from actual people doing this in the field
to understand the challenges that I’ll face with distributed agile development
As someone new to agile I want to:
learn the fundamentals of Scrum
understand the fundamentals of agile delivery
learn about what actually works in practice
discover how extend Scrum into an agile delivery process
As an experienced agile practitioner I want to learn:
how to scale agile approaches for distributed teams
how to overcome the challenges faced by distributed teams
how to tailor existing agile practices to reflect the realities of distribution
bout “new” agile practices which we might need to adopt
techniques so that distributed team members can communicate effectively
how to extend Scrum with proven techniques from Extreme Programming, Agile Modeling, and other agile methods
how to address architectural issues on a distributed agile team
how agile teams address documentation
how agile teams can interact effectively with non-agile teams
As a Scrum Master I want to learn how to:
lead a distributed agile team
facilitate a distributed “Scrum of Scrums”
facilitate the successful initiation of a distributed agile project
facilitate communication and collaboration between distributed team members
As a Product Owner I want to learn:
how to manage a product backlog on a distributed team
about different categories of stakeholders whom I will need to represent
about techniques to understand and capture the goals of those stakeholders
how to manage requirements with other product owners on other sub-teams
what to do during an end-of-sprint review
how I can streamline things for the delivery team that I’m working with
As an agile skeptic I want to:
see examples of how agile works in practice
hear about the challenges faced by agile teams
hear about where agile strategies don’t work well and what to do about it
I work with organizations around the world helping them to scale agile strategies to meet their real-world needs. Although this book is focused on providing strategies for dealing with geographical distribution, it also covers many of the issues that you’ll run into with large teams, complex problem domains and complex technical domains. An important aspect of scaling agile techniques is to first recognize that’s there’s more to scalability than dealing with large teams, something which this book clearly demonstrates.
At the risk of sounding a bit corny, I’ve eagerly awaited the publication of this book for some time. I’ve known two of the authors, Elizabeth and Matt, for several years and have had the pleasure of working with them and learning from them as a result. Along with hundreds of other IBMers I watched this book get written and provided input where I could. The reason why I’m so excited about it is that I’ve wanted something that I could refer the customers to that I work with and honestly say, “yes, we know that this works because this is what we do in practice”.
IBM is doing some very interesting work when it comes to scaling agile. We haven’t published enough externally, in my opinion, due to a preference for actively sharing our experiences internally. This book collects many of our experiences into a coherent whole and more importantly shares them outside the IBM process ecosystem. Bottom line is that I think that you’ll get a lot out of this book.
Contrary to popular belief, agile development teams do in fact model and yes, they even do some up front requirements and architecture modeling. Two of the best practices of Agile Modeling are Requirements Envisioning
and Architecture Envisioning
where you spend a bit of time at the beginning of the project doing enough initial modeling to get you going in the right direction. The strategy is to take advantage of modeling, which is to communicate and think things through without taking on the risks associated with detailed specifications written early in the lifecycle
. In this blog posting I will focus on requirements envisioning, in a future posting I'll cover architecture envisioning.
The goal of initial requirements envisioning is to identify the scope of your effort. You need to do just enough modeling early in the project to come to stakeholder concurrence and answer questions such as what you're going to build, roughly how long it's going to take (give a range), and roughly how much it's likely to cost (once again, give a range). If you can get the right people together in the room, which can sometimes be a logistics challenge but not one that you couldn't choose to overcome, there are very few systems (I suspect less than 5%) that you couldn't initially scope out in a few days or a week. I also suspect that most of the remaining systems could be scoped out with less than 2 weeks of modeling, and if not then I'd take that as an indication that you're taking on too large of a project. I'm not saying that you'll be able to create big detailed specifications during this period, and quite frankly given the problems associated with "Big Requirements Up Front (BRUF)
" you really don't want to, but I am saying that you could gain a pretty good understanding of what you need to do. The details, which you'll eventually need, can be elicited throughout the lifecycle when you actually need the information. A common saying in the agile community is that requirements analysis is so important for us that we do it every single day, not just during an initial phase. I'll discuss just in time (JIT) approaches to requirements modeling in a future posting.
To envision the requirements for a business application, you might want to consider creating the following models:
- High-level use cases (or user stories). The most detail that I would capture right now would be point form notes for some of the more complex use cases, but the majority just might have a name. The details are best captured on a just-in-time (JIT) basis during construction.
- User interface flow diagram. This provides an overview of screens and reports and how they're inter-related. You just need the major screens and reports for now.
- User interface sketches. You'll likely want to sketch out a few of the critical screens and reports to give your stakeholders a good gut feeling that you understand what they need. Sketches, not detailed screen specifications, are what's needed at this point in time.
- Domain model. A high-level domain model, perhaps using UML or a data modeling notation, which shows major business entities and the relationships between them, can also be incredibly valuable. Listing responsibilities, both data attributes and behaviors, can be left until later iterations.
- Process diagrams. A high-level process diagram, plus a few diagrams overviewing some of the critical processes, are likely needed to understand the business flow.
- Use-case diagram. Instead of a high-level process diagram you might want to do a high-level use case diagram instead. This is a matter of preference, I likely wouldn't do both.
- Glossary definitions. You might want to start identify key business terms now, although I wouldn't put much effort into settling on exact definitions. I've seen too many teams run aground on "analysis paralysis" because they try to define exact terminology before moving forward. Don't fall into this trap.
For small teams simple tools such as whiteboards and paper are usually sufficient for requirements envisioning. But what happens at scale? What if you're working on a large agile team, say of 50 people, 200 people (IBM has delivered software into the marketplace with agile teams of this size), or even 500 people (IBM currently has teams of this size applying agile techniques)? What if your team is distributed? Even if you have people working on different floors of the same building, let alone working from home or working in different cities or countries, then you're distributed (see my postings about distributed agile development
). Suddenly whiteboards and paper-based tools (index cards, sticky notes, ...) aren't sufficient. You're still likely to use these sorts of tools in modeling sessions with stakeholders, but because of one or more scaling factors you need to capture your requirements models electronically.
In January Theresa Kratschmer and I gave a webcast entitled Agile Requirements: Collaborative, Contextual, and Correct
which overviewed agile approaches to requirements elicitation and management, including requirements envisioning. We also showed how Rational Requirements Composer (RRC)
can be used to electronically capture critical requirements information, enabling you to address the needs of large and/or distributed agile teams, while still remaining lightweight and flexible. I suspect that you'll find the webcast to be very illuminating and RRC something that you want to take a look at (the link leads to a trial version). Of course RRC can be used in other situations as well, but that's not what I'm focused on right now.
Teams which find themselves in regulatory environments will likely need to do more than just use RRC, as might very large teams. Regulatory compliance often requires more complex requirements documentation, which in turn requires more sophisticated tools such as DOORS or Requisite Pro, and I would consider using those tools in the types of situations that warrant it. One of the things that people often struggle to understand about agile approaches is that you need to tailor your strategy to reflect the situation at handle. One process size does not fit all, so you will end up using different tools and creating different artifacts to different extents in different situations. Repeatable results, not repeatable processes
, is the rule of the day. Further reading:
I was recently in Bangalore speaking at the Rational Software Conference, which was really well done this year, and visiting customers. In addition to discussing how to scale agile software development approaches, particularly when the team is distributed geographically and organizationally, I was also asked about what I thought about a software factory approach to development. My instinctual reaction was negative, software factories can result in lower overall productivity as the result of over specialization of staff (I prefer generalizing specialists
), too many hand-offs between these specialists (I find close collaboration to be far more effective), and too much bureaucratic overhead to coordinate these activities. I initially chalked it up to these people still believing that software development was mostly a science, or perhaps an engineering domain, whereas my experiences had made me come to believe that software development is really more art than it is a science. Yet, the consistent belief in this strategy by very smart and experienced people started me thinking about my position.
Just let me begin by saying that this blog posting isn't meant to be yet another round in the age old, and relatively inane, "art vs. science" debate within the software development community. That debate is a symptom of versusitis
, a dread disease which particularly plagues the IT industry and which can any of us at any time. There is no known cure, although the combination of experience, open-mindedness, and critical thought are the best inoculation against versusitis that we have so far. In that vein, let me explore the issues as I see them and I will let you think for yourself.
On the one hand software development has aspects of being an art for several reasons. First, the problem definition is never precise, nor accurate, and even when we have detailed specifications the requirements invariably evolve
anyway. The lack of defined, firm requirements requires us to be flexible and to adjust to the situation that we find ourselves in. Second, teams typically find themselves in unique situations, necessitating a unique process and tool environment to reflect this (assuming that you want to be effective, otherwise there's nothing stopping you from having a "repeatable process" and consistent tool environment). Third, software is built by people for people, requiring that the development team have the ability to build a system with a user interface which meets the unique needs of their end users. One has only to look at the myriad UI designs out there to see that surely there is a bit of art going on. Fourth, if software development wasn't at least partially art then why hasn't anyone succeeded at building tools which take requirements as inputs and produce a viable solution that we can easily deploy? It's been over four decades now, so there's been sufficient time and resources available to build such tooling. Fifth, regardless of how much of a scientific/business facade we put over it, our success rate at producing up front detailed cost estimates and schedules speak for itself (see Funding Agile Projects
for links to articles).
On the other hand software development has aspects of being a science for several reasons. First, some aspects of software development have in fact been automated to a significant extent. Second, there is some mathematical basis to certain aspects of software development (although in the case of data-oriented activities the importance of relational theory
often gets blown way out of proportion and I have yet to see a situation where formal methods proved to be of practical value).
What does this have to do with Agility@Scale. As you know, one of the agile scaling factors
is Organizational Complexity, and cultural issues are the hardest to overcome. Whether your organization believes that software development is mostly an art or mostly a science is a cultural issue which will be a major driver in you choice of methods and practices. Organizations which believe that software development is more of a science will prefer strategies such as software factories, model-driven architecture (MDA),
and master data management (MDM)
. And there is ample evidence to support the claims that some organizations are succeeding at these strategies. Although you may not agree with these strategies, you need to respect the fact that many organizations are making them work in their environments. Similarly, organizations which believe that software development is more of an art will find that agile and lean strategies are a better fit, and once again there is ample evidence that organizations are succeeding with these approaches (there's also evidence that agile projects are more successful
than traditional projects, on average). Once again, you may not agree with these strategies but you need to respect the fact that other people are making them work in practice.
Trying to apply agile approaches within an organization that believes software development is mostly a science will find it difficult at best, and will likely need to embark on a multi-year program to shift their culture (likely an expensive endeavor which won't be worth the investment). Similarly, trying to apply a software factory strategy in an organization that believes that software development is mostly an art will also run aground. The bottom line is that one size does not fit all, that one strategy is
not right for all situations and that you need to understand the trade-offs of various strategies, methodologies, techniques, and practices and apply them appropriately given the situation that you face. In other words, it depends! If you are embarking on a software process initiative, and you don't have the broad experience required to effective choose between strategies (very few organizations do, although many believe otherwise), then you should consider Measured Capability Improvement Framework (MCIF)
to help increase your chance of success.
A few days later someone asked a series of questions that I thought would make an interesting blog posting, so here goes:How much of IBM's projects (in percentage) are agile at the moment?
I don’t have exact numbers, but I believe that 90%+ of our teams in SWG are applying agile techniques in practical ways that make sense for their projects. The primary goal is to be effective – in frequent releases, higher quality, and happy customers – not just agile. By the way, there is roughly 30,000 developers in SWG.Can all of IBM's projects work with an agile methodology?
It’s certainly possible, but it may not always make sense. Products that are in maintenance mode with few bugs or feature requirements may not benefit as much from agile practices -- those teams will likely continue to do whatever it is that they have been doing. Having said that, it's still highly desirable to apply agile techniques on maintenance projects.
Also, agile methods can be harder to use on some projects than others, for example, around hardware development. As a general rule, I believe that the majority of software projects can benefit from agile techniques. The primary determinant of whether a team can adopt agile techniques is culture and skill – not team size, the domain, or the degree of geographic distribution. That notion surprises many people who think that large agile teams
or geographically distributed agile teams
can’t succeed in adopting agile practices.Are agile projects sub-parts of large waterfall projects?
In some cases, that may happen. I’m sure it’s also true in reverse. We see many customers who are migrating from waterfall projects to a more agile way of doing things, and they often start this migration with smaller sub-projects. At IBM, we have tens of thousands of developers worldwide on hundreds of teams, so we have examples of pretty much any combination of agile, iterative, and traditional practices that you can imagine. There’s definitely not one size that fits all, which is a key aspect of the Disciplined Agile Delivery (DAD)
process framework.What do you think the impact of these numbers will be on the PM community?
The IBM PM community is embracing agile. And the reality is that a majority of development organizations around the world are moving to agile now as well (as much as 80% in some of the recent studies I’ve seen). I look forward to the increased adoption of agile methods by the PM community in general. The fact that PMI now offers an Agile Certified Practitioner training program certainly underscores the fact that agile practices are being adopted widely in the mainstream which is a great thing to see.
Again and again I've seen IT organizations suffering from what I call the "Bureaucracy is Discipline" antipattern. For example, filling out forms and reviewing documents are both bureaucratic activities, neither of which require significant skill nor discipline to accomplish. However, agile practices such as developing potentially shippable software every iteration is easy to say but requires great discipline to accomplish. Respecting the decisions of your stakeholders, particularly those pertaining to requirements prioritization, is easy to talk about but proves to require great discipline in practice (particularly when you don't agree with a decision). It's easy to talk about taking a test-driven approach to development
, but in practice it requires significant skill and discipline to actually do.
A "process smell" which indicates that your organization is suffering from this antipattern is a focus on following repeatable processes instead of focusing on repeatable results. An example of repeatable processes is following the same route to work every day regardless of driving conditions. An example of repeatable results is getting to work on time every day, but being willing to change your route as required, bicycling into work instead of driving, taking public transit, and so on. Nobody really cares how you get to work each day (the process), what they really care about is that you got to work on time (the result). Sadly, we've been told for decades now that repeatable processes are critical to our success in IT, yet when you step back and think about that's really a reflection of a bureaucratic approach. On the other hand, a focus on repeatable results is a reflection of a more disciplined approach. Interestingly, the DDJ 2008 Process Framework survey
found that given the choice that people would much rather have repeatable results over repeatable processes
when it comes to IT.
Mistaking bureaucracy for discipline, or rigour if you prefer that term, is a reflection of the cultural damage that has occurred over the years in IT organizations as the result of traditional philosophies and techniques. Unfortunately, this mistaken belief is a significant inhibitor to software process improvement (SPI) efforts, in particular agile adoption efforts
, which must be addressed if you're to be successful. Overcoming this challenge will require a significant cultural shift in some organizations, and many people (particularly the bureaucrats) will find this uncomfortable.Further reading:
I'd like to leave you with this parting thought: Bureaucracy is bureaucracy and discipline is discipline, please don't confuse the two
There is a distinct rhythm, or cadence, at different levels of the agile process. We call this the agile 3C rhythm, for coordinate, collaborate, and conclude (which is sometimes called stabilize). The agile 3C rhythm occurs at three levels in Disciplined Agile Delivery (DAD):
- Day. A typical day begins with a short coordination meeting, called a Scrum meeting in the Scrum method. After the daily coordination meeting the team collaborates throughout most of the day to perform their work. The day concludes with a working build, hopefully you had several working builds throughout the day, which depending on your situation may require a bit of stabilization work to achieve.
- Iteration. DAD construction iterations begin with an iteration planning session (coordinate) where the team identifies a detailed task list of what needs to be done that iteration. Note that iteration modeling is often part of this effort. Throughout the iteration they collaborate to perform the implementation work. They conclude the iteration by producing a potentially consumable solution, a demo of that solution to key stakeholders, and a retrospective to identify potential improvements in the way that they work.
- Release. The DAD lifecycle calls out three explicit phases - Inception, Construction, and Transition – which map directly to coordinate, collaborate, and conclude respectfully.
The agile 3C rhythm is similar conceptually to Deming’s Plan, Do, Check, Act (PDCA) cycle:
- Coordinate maps to plan
- Collaborate maps to do
- Conclude maps to check and act
Modified by ScottAmbler
IBM Rational recently published an update to my Agility@Scale e-book, which can be downloaded free of charge. The e-book is a 21 page, 2.3 meg PDF (sorry about the size, guess the graphics did it) . It overviews the Agile Scaling Model (ASM) (which has since been replaced by the Software Development Context Framework (SDCF) ), Disciplined Agile Delivery (DAD), the scaling factors of agility at scale, and ends with some advice for becoming as agile as you can be. In short it's a light-weight coverage of some of the things I've been writing about in this blog the past couple of years. Could be a good thing to share with the decision makers in your organization if they're considering adoption agile strategies.
A recurring discussion that I have with experienced agile developers is what it means to take a disciplined agile approach. The conversation usually starts off by some saying "but it already requires discipline to do agile", something that I fully agree with, followed by "therefore 'disciplined agile' is merely a marketing term", something which I don't agree with. The challenge with the "standard" agile discipline is that it is often focused on construction activities within a single project team, clearly important but also clearly not the full picture. There's more to an agile project than construction, and there's more to most IT departments than a single development project. In short, there are many opportunities for IT professionals to up their discipline, and thereby up their effectiveness, opportunities which we make explicit in the Disciplined Agile Delivery (DAD) framework.
Let's explore the many aspects to taking a disciplined agile approach:
You adopt "standard" agile discipline
. Aspects of agile which require discipline
include adopting practices such as test-driven development (TDD), active stakeholder participation, working collaboratively, shortening the feedback cycle
, and many more. These strategies are a great start to becoming disciplined IT professionals.
You take a goal-driven approach
. When we first started working on the DAD framework I didn't want to create yet another prescriptive framework, particularly given Rational's track record with the Rational Unified Process (RUP) framework. Rational has been pilloried for years for the prescriptive nature of RUP, which is unfortunate because there are a lot of great ideas in RUP that agile teams can benefit from, some of which we adopted in DAD and many of which are being actively reinvented with the agile community even as you read this. Furthermore, there are many prescriptive elements of the Scrum method that can get teams in trouble. For example, Scrum prescribes that you hold a daily stand up meeting, often called a Scrum meeting, where everyone should answer three questions. That's a great approach for teams new to agile, but it proves problematic in many situations due to it's prescriptive nature. Do you really need to do this once a day? I've been on teams where we held coordination meetings twice a day and others only once a week. Do you really need to stand up? I've been on geographically distrubited agile teams where many of us were sitting down during coordination calls. Do you really need to answer three questions, two of which are clearly focused on status regardless of claims otherwise? I've been on lean teams where we met around our Kanban board and focused on potential blockers. The answers to these questions depends on the context of the situation you find yourself in. The challenge, at least from the point of view of a process framework, is how do you avoid falling into the trap of being overly prescriptive. The strategy we adopted in DAD is to take a goal-driven approach. The observation is that regardless of the situation you find yourself in there are common goals your team will need to fulfill. For example, at the beginning of a project common goals include developing an initial plan, initially exploring the scope, initially identifying a technical strategy, and securing initial funding (amongst others). Throughout construction you should coordinate your activities, improve the quality of your ecosystem, and produce a potentially consumable solution on a regular basis (more on this below). So, instead of prescribing a daily stand up meeting the DAD framework instead indicates you should coordinate your activities, and gives several options for doing so (one of which is a Scrum meeting). More importantly DAD describes the advantages and disadvantages of your options so that you can make the choice that's best suited for the situation your team finds itself in (see this blog posting
for a detailed example of the types of tables included in the DAD book to help you through such process tailoring decisions). In short, our experience is that it requires discipline to take a goal driven approach
to agile delivery over the prescriptive strategies in other agile processes.
You take a context-driven approach
. There are many tailoring factors, which I describe in the Software Development Context Framework (SDCF)
, which you need to consider when making process, tooling, and team structure decisions. For example, a large team will adopt a different collection of practices and tools than a small team. A geographically distributed team will adopt a different strategy than a team that is co-located. You get the idea. Other tailoring factors include compliance, team culture, organization culture, technical complexity, domain complexity, and project type. It requires discipline to recognize the context of the situation you find yourself in and then act accordingly.
You deliver potentially consumable solutions
. One of the observations that we made early in the development of the DAD framework was that disciplined agile teams produce potentially consumable solutions, not just potentially shippable software. Although delivery of high-quality, working software is important it is even more important that we deliver high-quality working solutions to our stakeholders. For example, not only are we writing software but we may also be updating the hardware on which it runs, writing supporting documentation, evolving the business processes around the usage of the system, and even evolving the organizational structure of the people working with the system. In other words, disciplined agilists focus on solutions over software
. Furthermore, "potentially shippable" isn't sufficient: not only should it be shippable but it should also be usable and should be something people want to use. In other words it should be consumable (a concept DAD adopted from IBM's Outside In Development
). Minimally IT professionals should have the skills and desire to produce good software, but what they really need are the skills and desire to provide good solutions. We need strong technical skills, but we also need strong "
such as user interface design and process design to name just two.
The incremental delivery of potentially consumable solutions on an incremental basis requires discipline
to do successfully. DAD teams focus on repeatable results not repeatable processes
You are enterprise aware
. Whether you like it or not, as you adopt agile you will constrained by the organizational ecosystem, and you will need to act accordingly. It takes discipline to work with enterprise professionals such as enterprise architects, data admistrators, portfolio managers, or IT governance people who may not be completely agile yet, and have the patience to help them. It takes discipline to work with your operations and support staff in a DevOps
manner throughout the lifecycle, particularly when they may not be motivated to do so. It requires discipline to accept and potentially enhance existing corporate development conventions (programming guidelines, data guidelines, UI guidelines, ...). It requires discipline to accept that your organization has an existing technology roadmap that you should be leveraging, building out, and in some cases improving as you go. In short, enterprise awareness requires a level of discipline
not typically seen on many agile teams.
You adopt a full delivery lifecycle
. Empirically it is very easy to observe that at the beginning of an agile project there are some activities that you need to perform to initiate the project. Similarly at the end of the project there are activities that you need to perform to release the solution into production or the marketplace. The DAD process framework addresses the effort required for the full delivery effort, including project initiation, construction, and deployment. Our experience is that it requires discipline on the part of IT professionals to include explicit phases
for Inception/Initation, Construction, and Transition/Deployment and more importantly to focus the appropriate amount of effort on each. One danger of explicit phases is that you run the risk of taking what's known as a Water-Scrum-Fall
approach, a term coined by Dave West the person who wrote the forward for the DAD book, where you take an overly heavy/traditional approach to inception and transition in combination with a lighter agile approach to construction. Water-Scrum-Fall occurs because many organizations haven't made a full transition to agile, often because they think it's only applicable to construction. Our experience is that you can be very agile in your approach to inception and transition, experience we've built into the DAD framework. Having said that it clearly requires discipline to keep inception activities short
and similarly it requires discipline to reduce the "transition phase" to an activity
You adopt a wider range of roles
. An interesting side effect of adopting a full delivery lifecycle is that you also need to adopt a more robust set of roles. For example, the Scrum method suggests three roles - Scrum Master, Product Owner, and Team Member - a reflection of the Scrum lifecycle's construction focus. DAD suggests three primary roles - Team Lead, Product Owner, Team Member, Architecture Owner
, and Stakeholder - as well as five secondary roles which may appear at scale.
You embrace agile governance
. Governance establishes chains of responsibility, authority and communication in support of the overall enterprise’s goals and strategy. It also establishes measurements, policies, standards and control mechanisms to enable people to carry out their roles and responsibilities effectively. You do this by balancing risk versus return on investment (ROI), setting in place effective processes and practices, defining the direction and goals for the department, and defining the roles that people play with and within the department. It requires discipline to adopt an agile approach to governance
, and that's something built right into the DAD framework.
I'm happy to announce that a revised version of the Lean Development Governance
white paper which I co-wrote with Per Kroll is now available. This version of the paper reflects our learnings over the past few years helping organizations to improve their governance strategies.
There's a more detailed description of the paper here
Modified by ScottAmbler
A common misunderstanding about agile software development is that it’s only for co-located teams. Things are definitely easier for co-located teams, and as I found with both the Dr. Dobb’s 2007 and 2008 Agile Adoption surveys (www.ambysoft.com/surveys/) co-located agile teams appear to have a higher success rate than distributed teams, Having said that, many organizations are in fact succeeding at distributed agile development.
I’d like to share some strategies that I’m seeing work in practice, and in this blog posting summarizes generic strategies for distributed teams whether or not they’re agile. These strategies are:1. Do some up front planning. Distributed development is higher risk than co-located development, and one way to address that risk is to think things through. That doesn’t mean that you need to create a monolithic, 1000+ task Gantt chart, but it does mean that you should identify your major dependencies and milestone dates. Effective teams do this planning with the distributed developers actively involved (they are part of the team after all), they strive to consider all associated costs, and in particular they don’t overlook the low probability/high impact risks which often prove to be project killers.
2. Organize the team effectively. Once of the practices of Lean Development Governance (https://www14.software.ibm.com/webapp/iwm/web/preLogin.do?lang=en_US&source=swg-ldg) is to organize your team structure around either your architecture or the lines of business (LOB) supported by the programme that you’re working on. Ideally each sub-team should be responsible for one or more subsystems or modules, something that can be difficult if some of your team works alone from home, to reduce the amount of information sharing and collaboration required between disparate teams. In other words, maximize the responsibilities of the “offshore” team(s) as much as possible. A very common mistake is to organize the subteams around job specialties – for example the architects are in Toronto, the developers in Mumbai, and the testers in Singapore – because to support this team structure you have to create a phenomenal amount of documentation to support communication between the teams.
3. Do some up front modeling. The implication of organizing your team around the architecture (or LOB) is that you also need to do a bit of architecture envisioning up front. Your architecture efforts should provide guidance regarding the shared infrastructure as well as critical development conventions such as coding guidelines and data naming conventions. Architecture envisioning is also a good idea for co-located agile teams too. See http://www.agilemodeling.com/essays/initialArchitectureModeling.htm for strategies to get the benefits of architecture modeling without the costs of needless documentation.
4. Recognize that communication is critical. GDD puts many barriers to communication in place, increasing overall project risk. To overcome these risks you will first need to be aware of them and act accordingly, and second, you’ll need to write more documentation than you would likely prefer. The risks associated with long-distance communication include cultural differences, time-zone differences, and the challenges with written documentation (which is the least effective way to communicate information). I make it a habit of asking open-ended questions so that I can determine whether or not the other people understand the topic under conversation. Particularly I will never ask a yes/no style of question because the simple answer of yes can mean a range of things depending on the culture. It may mean “Yes, I heard you”, “Yes, I understand what you’re saying”, or “Yes, I understand and agree with you”. When you’re dealing with people at other locations it’s good practice to ask them to summarize the conversation in writing, in particular to identify key action items and ownership of them, to ensure that everyone agrees with what was discussed. A good approach is to have the team lead on other end to do the summary so that they own it going forward.
5. Put a good technical infrastructure in place. Automate, automate, automate. In a GDD environment you need to work with collaborative multi-site tools such as ClearCase, ClearQuest, and Jazz Rational Team Concert (www.jazz.net) which enable you to share and evolve your work products (i.e. test scripts, code, documents) effectively.
In my next posting I'll describe a collection of agile-specific strategies for distributed software development teams.[Read More