Wednesday, April 17, 2013

Building trust on agile project teams

Do you want to know how to build trust? Make an agreement and keep it. Tell the truth. Be transparent. Be open and honest. Give without expectation of getting anything in return. Then do it all again.

In some engagements where I've worked to transform organizations, lack of trust was a big challenge. I've seen IT groups consistently miss commitments, leaving their business partners questioning IT's ability to deliver. Using the practice of incremental delivery with frequent demos & reviews is a great way to change this dynamic.

At a previous client we had to deal with business owners who were always trying to start every project idea they had, because if they didn't start it, in their minds, it wouldn't get done. They didn't trust their IT partners. The result of starting too many projects, of course, made it worse. We know, all too well, that having too many projects going at once causes longer cycle times across the board. The business didn't even realize their approach was a major contributor to the IT Group's ineffectiveness.

At this client, we started to turn the culture around quickly. How did we do it? It's simple; we changed the way a couple of teams worked.

We selected two teams and worked to get the primary team members appropriately dedicated so there weren't any significant outside drains on team member's time. This eliminated the effects of bad multi-tasking allowing team members to maintain focus throughout the development cycles. The second thing we did was reduce the work load on the product owner. How did we do that? We asked them to stop generating 50, 100, sometimes 200 page BRD's. This was not an easy sell. In place of the BRD we had the development team work with the Product Owner to create a backlog of deliverables - it was too soon to call them user stories, but that's essentially what we used. The last thing we did was tell the Product Owners that they should expect to see working software at least every three weeks. One unfortunate problem was that we weren't able to shake the constraint that the testers were only partially allocated to the project, forcing us to have them join near the end of an iteration to write and execute tests. Still this was better than what they had done before.

The Product Owners were very skeptical as we started the new approach - iterative and incremental delivery. This was one of those places where words mattered more than they should have and we couldn't quite go down the path of calling things by their right names.

So the teams started down their paths, one team starting before the other. The first team's iteration wasn't very successful. They didn't complete any of the deliverables they had signed up for. However the team was close. So in the next iteration they completed all the work they had planned for the first iteration and then completed one additional deliverable. For this team in 5 weeks they had something to demo. Contrast this with timeframes in months and you can imagine the business was happy. This team took the path of most new teams, dealing with a few ups and downs as they started their journey. But they settled in to a reasonably consistent pace and the product owner was hooked. Her quote, paraphrased was "I never imagined that we could get so much done so quickly and without having to write a big long BRD that usually took me months to prepare."

This team and the second team, which had a similar path, laid the foundation for the organization to increase collaboration between the business and transform the way they delivered value to their customers.

It was fun to watch as the trust level was incrementally increased with each delivery of working software. Not long after this we were able to start using the right words... Now that made us happy.




No comments:

Post a Comment