Self organization and boundaries

Being a Scrum Master is hard work.  You spend much of your time helping others and often 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 thing you can do.  The most exciting 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 onan 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 consider agile principle eleven: "The best architectures, requirements, and designs emerge from self-organizing teams.”  How can a leader set non-negotiable terms and allow a team to self-organize?  I realized that when a business or leader sets something as non-negotiable, they are really setting boundaries.  Once a team understands the boundaries, 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 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 headaches over the months.

Once the sprint was done, we used our retrospective to tweak the definition of done for the next sprint to ensure we were 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.  Setting boundaries gives 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 a nice approach, but it will make everyone feel better at the end of the day.

Until next time.