I was reading some posts on the Scrum Alliance LinkedIn group as I usually do and I read another thread on a person asking for help with trying to figure out the right balance between stories and more detailed specifications in their Scrum software development efforts.  The advice given ranged from zealots bashing the person for doing too much documentation to suggestions for the right people being involved and the analysis techniques that are used by the Business Analyst’s role.

The one thing I’m always fascinated by when I hear about the challenges teams have through such posts, talks I attend or just speaking with teams, it’s nearly always a look at the process, techniques and tools they use for answers to their problems.  You just don’t see the discussion of the dynamic of the people doing the work, how high functioning they are as an overall product development team and the culture of the organization in which they operate.

Process takes shape as a by-product of these forces.  The team’s ability to establish continuous improvement is most impacted by these forces.  If there is low or no trust on a team, people will want to write more things down, and they will be much less likely to share the information. When you have a retrospective, you don’t get to the root cause of issues.

The same goes for the culture of an organization.  If agile teams live under the illusion of control of management, often characterized in the governance systems of command-and-control organizations, the challenge of building trust between management and teams is often very difficult.  Regardless of this challenge, many will just change process and techniques and ignore this root cause of problems — and then wonder why they aren’t successful when others are enjoying success with the same processes / frameworks.

Let’s face it, Agile processes are fairly simple and lightweight, so even if you start with an ill-conceived process or technique for analysis or whatever, it could improve if you had a high functioning team and an organization open to change, both of which are enabled when trust exists.

I know, this is all touchy-feely that folks don’t like to discuss, but if it is addressed it is the thing that, in my experience, can lead to the greatest gain in capability for a team and it truly engages people to commit as a team to the delivery of value.

If you can truly achieve trust within your team and with the organization, watch how fast things improve.

Join the Discussion

    There are currently no comments.

    − 3 = 2