My article highlighted two key areas where trust and relationships are built using Agile development:
- Between the team and the business (customers and/or stakeholders).
- Between members of the team.
James Shore and Shane Warden explained this issue in their book, The Art of Agile Development:
“Many organizations I've worked with have struggled with an ‘us versus them’ attitude between customers and programmers. Customers often feel that programmers don't care enough about their needs and deadlines, some of which, if missed, could cost them their jobs. Programmers often feel forced into commitments that they can't meet, hurting their health and relationships.”
The business side has its drivers; sometimes they are the ones dealing with an imposed date – like meeting regulatory requirements. Other times, the business is responding to a competitive threat where delay is costly in very real terms, such as revenue and market share. And in other cases, there is an opportunity that the business wants to capitalize on to drive growth – a “first to market” scenario. Whatever the situation, the DATE that customers have in mind is very real.
On the software project side of the fence, other dynamics can come into play. In response to the business pressure, for example, a software project team can be driven into “optimizing” a tradition, plan-driven project before the project has even started. Why? Because the schedule – and indirectly, the team – isn’t trusted. Typically, it is management that is examining project schedules, and they are usually responding with one or more of the following motivations:
- A strong desire to complete the project as quickly as possible so that the team can move on to other, pressing projects.
- Pressure to meet the business needs within certain timeframes to win the business and drive revenue (or prove the worth of an in-house organization).
- A strong desire to ensure that the team is motivated by “just enough” schedule pressure to work up to their potential.
Let’s face it, after months of dialog, reviews, and eventual sign-off to “get the requirements right,” customers are still going to feel uneasy, particularly in the early software construction phases when there is nothing to see. And despite everyone’s best efforts to fully comprehend the needs of the business, there will be questions during the development of specific features, and some of those questions will reveal changes – or even new features – that should have been a part of the requirements, but weren’t.
What can happen next is “the case of the imposed date” from a development point of view. The customer thought that they had expressed what they needed to development, and development provided an estimate. The problem is, as the team gets into the project, a deeper understanding occurs and the original estimates are in need of revision.
It is at this point when someone (usually a manager) reminds the team that they created the estimates – which are now considered cast in stone and not the approximation that they really were – and the team is held to its “commitment.” Doubt starts creeping in, and the question that is on everybody’s mind is: Will this project make it?
These days, it is no secret that a great many projects suffer schedule overruns. And when projects become challenged, conversations invariably begin about trimming features from the planned delivery or extending the delivery date, even before the customers have seen much – if anything – of the software that is under construction. At this point the customer’s fears are realized, and trust takes a hit.
If customers can see it, they can believe it – and ultimately trust those producing it. This is precisely the point that my article made, the benefit of trust that Agile development provides: “Through early and often delivery of working software to the business – even if this is nothing more than demonstrating the features – the business will grow to trust the development team. In addition, the continual dialog and the ability for the business to adjust and adapt the software gradually changes the ‘us versus them’ dynamic into a ‘we.’”
Referring back to The Art of Agile Development, James Shore and Shane Warden summed this up nicely: “Stakeholders don't know how to evaluate your process, but they can evaluate results.”
Customers don’t understand all of the ins and outs of software development, but they do measure us. Their ultimate measure is the end result – working software that either meets or fails to meet their needs. Their satisfaction can be – in part – a direct result of how much participation and input they experienced during the software project.
This is where Agile development lends itself to establishing trust and relationships. Agile development expects and embraces continual customer involvement with the development team. Instead of a large amount of time spent up front defining and refining all of the requirements, Agile development spreads this involvement out over time, accomplishing the same goal, but in different ways. Agile development also includes regular iteration reviews that demonstrate new features to the customer – a very visible display of progress that is much more convincing than reaching a milestone marker on a project plan.
This increased trust and improved relationship provides a couple of other benefits. If the customer wants add new features that affect the schedule, the trust and relationships that are built allow for candid conversations about what the customer will receive and when, including discussing trade-offs because new features are being added.
Even if the development team is struggling with a feature that is proving to be more complex than anticipated, the visible progress and constant contact with the team makes the “we’re struggling to deliver this feature” conversation is much easier to have. Because of the connected nature of the relationship, the customer has a greater appreciation of the effort involved.
The other benefit of trust and the frequent delivery of working software is that a significant amount of documentation is simply not required. In sequential projects, mounds of documentation exist to inform and guide development efforts because it is assumed that conversations will not occur. The requirements document is intended to capture all that there is to know prior to it being handed off to development. Continual conversations cut down on the need for comprehensive documentation; and contrary to what some contend, Agile development does NOT mean no documentation.
Building Trust between Team Members
The traditional, plan-driven approach to development organizes and optimizes its work functionally – with formal hand-offs between functions. People can start to identify with their area of specialty and not with the project or worse, not with the customer. The notion of specialists and optimizing work isn’t bad, and this model does work. Given that work centers around human beings, problems can and do arise.
When I first became a development manager, one problem that our organization had was that there was a wall between Development and QA. I worked hard with the QA manager and everyone involved, breaking those barriers down.
This involved coaching – casting QA as a benefit by focusing attention on the fact that our job was to prevent defects from getting out the door and into our customers’ hands. I began working on setting higher goals for our developers, asking more in terms of design, code reviews, unit testing, and the like. The QA manager worked at raising the QA game and pointing out that developers weren’t being sloppy just because bugs were showing up – at least not if they were using sound practices like conducting design and code reviews.
We also held project meetings that fostered and encouraged more open dialog. Eventually, everyone began to gain an appreciation for the skill and work required on both sides of the fence, and despite that fact that at the time we were still a plan-driven, functionally-oriented shop, the teamwork and rapport significantly improved between the Development and QA organizations.
Agile development takes building teamwork and rapport to a higher level. Project work matters more than a functional role, and as I noted in my article, “Agile teams make the most effective use of the team members as dictated by the needs of the team to meet its commitments. The shared goal becomes more important than each individual working strictly within his or her area of expertise, with defined policies and procedures for handing off work between functional roles. This breaks down barriers between functional disciplines, enabling the team to reach higher levels of productivity.”
This means that a developer can and should help test (particularly if that testing involves creating automated tests) to help the team finish its work. Meeting an iteration commitment shouldn’t be an individualized, “I’ve completed my tasks,” but a, “How is the team doing in meeting our commitments?” With Agile development, there is a strong expectation that the work is all about the team getting across the finish line together.
Because everyone is working closely together – preferably co-located – and focused on completing the team’s highest-priority items first, trust is established through continual interaction and delivery. The daily stand-up meeting reinforces individual commitments to accomplishing meaningful work each and every day, and the expectation that Agile development places on continuous team and individual improvement builds trust as team members and teams improve their game.