Does agile encourage bad behavior?

All agile coaches are familiar with projects that “do agile” but don’t really do it. Agile can be used as a license to not plan (throw out the master schedule), not coordinate (cancel all the formal meetings and expect ad hoc collaboration to just occur), have the team commit to a sprint backlog and yet allow the product owner to change the stories during the sprint while still expecting the team to deliver on their commitments at the end of the sprint. These are all known issues to all coaches, but these issues all have to do with behavior that is imposed on a team. What about team behavior? Do teams themselves mis-apply agile ideas in ways that are enablers for bad habits and dysfunctional group behavior?

It took decades for disenfranchised groups to get managers to understand that conversations on the golf course or in the men’s room leaves people out (e.g., women and those who are not personal friends with the boss). Now agile comes along and advocates a return to ad hoc conversations: are we risking a return to patterns of exclusion?

Let’s remember that agile was designed for software development. It should not be applied to general business processes without careful thought. Agile assumes that teams work in close proximity, and so if an ad hoc conversation starts, others can hear it and join in. If teams do not work in close proximity, ad hoc does not work.

Another dysfunction that I see a-lot is when teams do not keep meeting notes. Meeting notes? Isn’t that old-school? Doesn’t that sounds like those old pre-agile dysfunctional meetings where it took three weeks or more to schedule it, and lots of people sat around a table and no one said what they really thought, or there was very low quality discussion, or worse, someone in the meeting got mad because he felt that others had not included him in discussions that occurred prior to the meeting and he felt that the meeting was an ambush? (I have seen and lived through all these things.)

No. Effective meetings require that all participants have take-aways. One of the core practices of Extreme Programming is to document decisions on the team’s wiki: that is a form of meeting note. Meeting notes - in any form that is appropriate - are essential for remembering what decisions were made, and if the notes are done well, they also record why the decision was made. Meeting notes do not have to record what everyone said, but they must mention key discussion points, issues that were identified, and decisions. That’s it. Very short and sweet, very to-the-point, but sufficient for others to read and know and understand the outcomes of the meeting.

Even ad hoc meetings should result in meeting notes, in an appropriate form, and too often they do not: agile’s ad hoc philosophy is being misused to excuse bad business behavior and laziness.

Planning: isn’t that old-school too? No. Agile requires planning. The only difference is that an agile plan focuses only on what matters and not all the details; and the plan is reviewed and updated continually, as things change. But planning is essential. It’s just not about the plan: it is about the planning that is crucial. But the plan is important too, in that it needs to be an information radiator so that everyone can see the current plan and be aware when it changes. The plan forms a reference-able shared understanding across the team and other stakeholders.

Agile should not be an excuse to not plan.

I think you get the idea. Before we throw out every old practice, or apply an agile value to a new situation, we should ask ourselves what purpose existing non-agile practices serve, and make sure that we are improving things and not making them worse. Most traditional practices have an agile equivalent: simply abandoning old practices is not sufficient to become agile.