Self Organization and Boundaries

Boundaries mater in Agile

Being a Scrum Master is hard work.  You spend a lot of your time helping others and many times wind up acting as a therapist for the people on your team.  You massage egos, help with nagging insecurities and keep fear and uncertainty at bay.  It is the most rewarding and the most frustrating things you can do.  The most interesting thing I have found over the last few years is it also requires some firm leadership and boundaries.  This week I would like to talk about that discovery.

As I usually do, I spend a great deal of time surfing the web learning about technology and gathering up new ideas to lead my team when I stumbled on to an article in Slate.  Laura Smith in her article “Why I Regret Being a Nice Boss,” spoke about her experiences running a coffee shop in Washington D.C. What struck me about the article was the realization that as a leader some things were just not negotiable.  Employees were expected to be on time and each employee had a set number of minutes for break time.  Those who violated these non-negotiable rules were written up and eventually managed out of the firm.

This made me think about agile principle number eleven, “The best architectures, requirements, and designs emerge from self-organizing teams.”  How can a leader set non-negotiable terms and still allow a team to self-organize?  This is when I realized that when a business or leader sets something as non-negotiable they are really setting boundaries.  Once a team understands what the boundaries are they can organize within them.  For example, a sprint is always a fixed length.  This means all work committed to by the team must be finished by the end of the sprint.  How that work is divided up and managed by the team is up to the team but the work must be finished and that is non-negotiable.

During a sprint the team decides what a good definition of done is.  For the teams I work on, it is the following; unit tests written, code which compiles, code checked into source control, and code pushed to our development environment.  If this this definition is not met then the user story is not “done” and the developers have to go back and finish the work.  This creates some tension with meeting all the sprint goals but it has saved my team numerous hours of headache over the months.

Once the sprint is done, we have used our retrospective to tweak the definition of done for the next sprint to make sure that we are improving.  This keeps with agile principle number twelve, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts behavior accordingly.”

So being a firm, fair therapist is what you should strive for as a servant leader of your software development team.  By setting boundaries, you give your team a safe place to experiment and thrive.  You also create an environment where everyone knows what is expected and how they can succeed.  This isn't always the nice approach but it will make everyone feel better at the end of the day.

Until next time.