We, Agile Coaches, preach experiments, inspect and adapt / short feedback cycles, and that early failure is good (although we don’t really mean “failure” in this context). In this way of working we discover new ways of delivering software, forever improving our profession.

On other hand, most of the daily challenges we encounter in software development are already solved by some previous team. In fact, these solutions are already documented in many great books and articles. So, why don’t we just read these patterns books and simply apply the solutions for any of our problems? Why experiment if somebody has already done it for us? I can assure you that your current problem and experimental solution has already been solved by somebody else in an enough similar context.

This dillema can be summarized by a frustrated developer who said to me once:

Why don’t you just tell us what to do, so we can get over this and just do it?!

But, the point is not to do what I suggest, but learn to think, understand what can be achieved and make self-motivated decision to experiment, try, and see why some practices are good and work, and others are counter-effective. This mindset and behaviour is a difference between teams that follow, and craftsmen / craftswomen. The last group only follows prescribed practices as part of an experiment, ready to change or ditch it if needed. It is the difference between teachers who claim that we are wasting our time with rediscovery of existing practices, and teachers who show us the real gold in the way we use knowledge, experiment, inspect, and adapt. It is a false dichotomy that one should learn from gurus in past, or keep rediscovering.

Of course, less experienced teams also ditch practices they barely started to follow. These are unfortunately not replaced by something better, but ditched because they are hard to follow or lack mindset for continuous learning and improvement. A real and deep mindset problem this team has, is the actual reason for not following practices.

Expecting a team of “followers” to start experimenting on their own is not feasible. These teams need guidance where practices are more imposed in a friendly manner. This is the way they know how to learn new things. They need to learn, feel the practice and follow instructions. The main difference with usual way of learning something new is type of practices. Therefore, e.g. do not impose tools for software development, unless they really hate their current ones.

Instead, the practices that push them towards “mastering” level, like sprint goals, definition of done, retrospective meetings and daily scrum will slowly start to empower team to take ownership of their process. In other words, they will start the process of continuous discovery for achieving what is expected.

Experienced teams need fundamentaly different way
of coaching than less experienced teams.

After certain time, team will noticeably move from being a group of followers that execute as being told, towards self-managing masters of their profession and process. A coach should be careful in correcting them in proper usage of a certain practice or even introducing new practices. It usually suffice to make them aware of a practice, and someone will pick it up. In fact, this kind of team is helped by enouragement to discover its own practices, maybe based on existing one. E.g. retrospective plans become very unique, only partially based on a known plan, custom-made for the current need. I’ve seen teams doing 2 or 3 standup meetings a day for a better synchronisation, and so on.

Any practice needs context

I’m an Agile Coach and do my best to bring true value to my customers. It is the value that I wish I had myself in the beginning of my career and I still ask for occasionally. Learning practices from books is great, applying those effectively in real world is a totally different level.

There a two major problems with using existing practices directly:

• If a team is more a group of followers than masters, they are likely to apply it wrongly. I’ve never seen an Agile team become really good without someone’s help who at least behaves as a coach and has experience and knowledge. Intent behind a practice is often overlooked. E.g. status reporting daily scrum is a very common problem. Teams are often unable to distinguish between “reporting” and “synchronisation”. The second one is more a two-way conversation between team members where you actually listen to each other and care. TDD is a famous one. Wether you are big believer or complete disbeliever of TDD, majority of people write crappy software. TDD does help reducing number of bugs and write better code, as long as you really learn the way of thinking behind TDD, and not stuck with only high code coverage.
• There is no such thing as a best practice. “The proven best practices” is the reason we failed so miserably with “state-of-the-art” processes and methodologies. Context defines if a practice is great or useless, and in which way it should be applied. Each context has also always space for discovering completely new practices suited better for the situation than any existing practice. It is the usage of this space that makes good teams become great.

Despite the potential waste of time, it is for experienced teams better to spend time on discovering own practices, at cost of trying to find and apply existing ones. In other words, from systems thinking perspective, effect of discovering own practice has more positive impact on self-managing behaviour of a team, compared to negative impact of wasting time.