Dave is an experienced Agile Coach and Practitioner. For more insight, please see Dave’s presentation on Agile for non-IT executives.

 

The Context

Most of the IT organizations I work with are structured into “shared service” groups such as Data Architecture, Testing, Business Analysis, User Experience Design, Development, Database Administration, Network Engineering, Project Management… the list goes on and on.  On projects of any size or complexity the skills and expertise of people from almost all of these groups are needed to varying degrees.  Projects are temporary endeavours, and in many large organizations the people making up a project team may never have worked together before.

The Problems

One problem is that the people in these shared service groups tend to be physically located in different locations from other shared services, sometimes spread throughout large buildings, campuses or even across the globe.  On an average project, a team unites throughout the week for meetings but individual members of the team work independently in their shared service group’s physical location most of the time.  When individual team members contact each other on the phone, by e-mail or by instant messaging, few others on the team are privy to that conversation (and therefore cannot participate actively in the knowledge acquisition resulting from the contact).

Another problem is that each group tends to have its own “community of practice” or “centre of excellence” that strives for standardization among its own members.  Not bad concepts in theory, but the practices advocated by the CoPs/COEs are usually explained in the absence of the contributions of other groups’ practices.  When a project manager is charged with building a team, it takes significant time and effort to evolve the project’s way of working by assembling the various practices of the team members into something that works.  (As an aside, this reminds me of my days as a military officer leading a tank troop; 90% of our training was done in isolation of infantry, artillery, engineer and air support units, so when we operated jointly – as would almost always be necessary – the learning curve regarding each others’ procedures was steep and there were always hard knocks!).

Finally, in the traditional approach to developing technology solutions, sequencing of the phases (Planning, Requirements, Design, Coding, Testing) naturally lends itself to staggered project staffing, meaning that teams are Business Analyst-heavy early on and Tester-heavy towards the end.  It also means that when people are needed “out of phase” (such as Business Analysts being brought in to clarify requirements during the Testing phase) they might be working on another project already.  It takes them time to review work they may have done weeks or months ago in order to contribute effectively.  Additionally, the businesspeople who are actually going to use the system when it is done are consulted early on, updated infrequently for months, then presented the “complete” system and pressured to accept it as quickly as possible.

So we have a “normal” project situation in which communication and collaboration are hampered by the physical dispersion of team members who themselves have disparate practices and expectations regarding the project way of working.  And these team members are not assigned full-time to the project, sometimes working on 5-6 projects concurrently.  Worse yet, all this is by design, managed in matrixed organizations, which optimize personnel usage at the expense of project effectiveness.

A More Effective Approach

Let’s examine an alternative way of organizing a team in order to address the problems described above in the context of the top two reasons for project failure identified in the 2010 Standish CHAOS Report:

  • Incomplete requirements; and,
  • Lack of user involvement.

The problems described above directly relate to these reasons for failure.  How can we address them in a different and more effective way?  A few ideas:

  • Bring the team members together into a room designed comfortably for collaboration.  This is where they work most of the time.
  • Compose the team of people with all of the skills needed (which admittedly may change as they learn what it will take to develop the solution) and dedicate them to the project for its duration.  Apart from resource-constrained technical specialists, this is the only project they work for until the project achieves its goals.
  • Assign a business expert to the team.  This person comes from the business unit that will use the system being developed and must be empowered by their leadership to make decisions on behalf of that business unit.
  • Have the team run through a short (2-4 week) sequence of all of the phases so that they get to know each other’s ways of working while developing something real.  Encourage them to pick something small enough that can be accepted by the business expert by the end of the period.

 

That’s it.  At this point, there is no need to start introducing the management practices of agile development (e.g., SCRUM) or even the technical practices needed to sustain agile development (e.g., Continuous Integration, Test-Driven Development, Refactoring).  If the people selected for the team have the right characteristics (more on that later), I expect that the following will happen:

  • During that first 2-4 week period, the requirements for whatever is developed will change significantly as they progress through design, coding and even testing.  The team will have to negotiate with each other in terms of what changes can be made within the short period and what must be left for later.
  • Members of the team will listen to and become involved in discussions that other team members are having.  Because they are close enough to hear each other and probably have something to contribute (or question), the entire team will collectively gain a better understanding of both the business problem and the solution.
  • The business expert will be drawn into many conversations… initially about requirements but then also about test scenarios, test data, user interface design, and the information model.  Their contribution will be valued considerably by the rest of the team, which is used to waiting hours or even days for questions to be answered.
  • The project manager will be confused about their role.  As the team learns more about what is needed and about what the solution looks like, they will begin to volunteer for tasks and collaborate instinctively with each other in order to complete the work.  More on the role of the project manager on an agile team later.

 

Whether all goes well or not, by the end of that first short period the requirements and test cases will match what is actually built, and what is built will have been greatly influenced by the business expert on the team.  Complete requirements and deep user involvement.

Next… how a team continuously improves its way of working.