Some of the hardest work I've ever had to do as a coach is convincing teams how to collaborate (interact) when they develop a product. But if an organization REALLY wants to be agile, they have to learn and accept that developers will work better if they collaborate than if they work independently.

So, first things first, how do we convince management? The typical concerns are that 2 or 3 people working together means 3x times the cost for the same output. To get management on-board, we need to create a new paradigm to consider -- like this one: when a coder makes a mistake in their coding due to a lack of understanding of the requirements, the cost to solve this mistake is compounded as more and more code is added. Similarly, if a coder misses scenarios or test cases in their solution because they were unaware of them, and then compounds the problem by adding more and more code on top of the invalid assumptions, we create a problem. That same coder, sitting down with team members handling testing and analysis, collaboratively, going through the requirements and the test cases, revising as they discover new ones and correct misunderstandings as they go is going to produce much a higher quality product in the same amount of time. Analysis and design (and thus, code) is emergent -- we learn as we go. When we assume that developers (e.g., coders, analysts, and testers) should work independently, we're suggesting that, once the team has a solution, nothing is going to change so much that we can't afford to make changes later to correct. Unfortunately, that assumption fails miserably when you consider how much more time it costs to fix things hours or days after we break them as opposed to fixing them immediately as we go (which a collaboration of coding, testing, and analysis skills allows). The increasing cost of these mistakes has been put at an exponential increase in effort every time more lines of code are added in parts of the product that are related to the defect. My experience over 30 years bears this out.

Having suggested a new way of thinking, we now have to prove its truth in action. The most successful way to do this is to pilot something. Something small, but important enough to not be shrugged off as an invalid test when good things result. We need to convince a Scrum team to try it. We need to give them enough time to learn how to do it (a couple of weeks at least of real practicing), and then we need to let them do it without interference. You should see defects decrease as soon as the team learns how to collaborate. You should then start to see productivity increases as the skills of the team improve.

Sometimes the trick to proving to the team that even a really small PBI can be worked on at the same time is to do the following:

1. Make sure you have a comprehensive DONEness definition.
2. Ensure that the team is only working on SMALL PBIs (something that they could complete, working collaboratively of course, in less than 5 days)
3. Make sure you have a good test strategy and test infrastructure (if the team doesn't know how to test, collaboration might not be your biggest problem).
4. During Sprint Planning, solve and task out the PBI (ensuring that ALL elements of DONEness are accounted for).

At this point, it should be clear that there's enough work for a couple people to get involved in (beyond simply writing code, writing tests, and updating specifications). Get the team members working side-by-side, communicating, confirming, checking-in code and tests and running them over and over again when changes are made. Don't open up defect reports (yuck!), just get your colleagues' attention when something breaks and then fix the code and the tests to cover the failure from ever happening again. Pass documentation and specification changes around to make sure everyone is comfortable with the changes. Keep a whiteboard, flip chart, or an online remote whiteboard-type feature nearby for the collaboration to update their solution as they go.

MOST IMPORTANTLY!!!
Give them time to practice and learn but don't let them back off because it isn't immediately successful --- if every musician stopped practicing because they weren't amazing on day one we would have a very boring world indeed.

Our Certifications