One college summer, I worked at a small theater on the Mississippi river. It was a drought year. I remember it raining once the whole time I was there. The river flowed way below its usual level and ran dirty. The corn crop was devastated.
The theater was within miles of a huge pet food rendering plant. When the humidity allowed a breeze everything smelled quite literally like death warmed over.
And then the shad flies hatched. Lumbering insects that flew just well enough for one night of frantic bashing into things and mating. The next morning, their bodies covered the ground like gravel. I crunched my way from my apartment to the theater.
All this proved an appropriate backdrop.
The theater was a paddle wheel tug cemented to the bank of the river. The repertoire had been selected by the parks department. It consisted of fifty year-old musicals which required large choruses and performers who could sing, dance and act. The theater didn’t pay well and had no reputation. So our company consisted of twelve teens and twenty-somethings. About fifty less people than the larger musicals required. As for triple threats, some of us could passably act and sing or sing and dance.
And so we shambled our way through the summer – performers versus shows. Each evening or matinee without fail the shows kicked our ass. The artistic injury alone should have knocked that tugboat loose to immediately and permanently submerge in the river mud.
And yet, matinee or evening, audiences were entertained. They laughed. They applauded. They even waited outside to thank the performers.
What does this mean? What should I take from this experience?
We must strive to be better at what we do, to do our jobs well as we see it, without concern for recognition.
Mastering craft towards a beneficial end is a noble human aspiration. It is a good in the world. Like all attempts at doing or being good we cannot expect others around us to acknowledge us for it or even to recognize the difference even if they benefit from the effort.
Thankfully, I’ve moved on in my life. I’m a manager, a software executive, and a father but like the hopelessly miscast kid that I was, I still struggle to improve.
Jeff Sutherland posted notes from an open space hosted by Jens Ostergaard on Nov 2006. The subject was the role of manager in a Scrum.
- provide strategic vision, business strategy, and resources,
- remove impediments surfaced by Scrum teams that the teams cannot remove themselves,
- ensure growth and career path of employees, and
- challenge teams to move beyond mediocrity
For me, introducing agile practices has been evolutionary not revolutionary – five years work, three title changes and counting. My role is to make sure the team’s accomplishments build towards something progressively more and more valuable for the company and the individual team members.
In my experience, this involves facilitating a conversation between the business and the team on at least three levels:
- Product owner and product team,
- Organization and employees, and
- Leadership’s grand vision and the team’s accomplishments.
I’ll go into this in more detail in later posts.
I started talking about the manager’s role in scrum as facilitating a series of conversations between the team and the larger company.
The first of these is the product owner and the team.
As a manager, I have to constantly remind myself I’m a chicken, not a pig. My main responsibility is to deal with issues escalated to me by my scrum master. I also coach around practices. This is often about challenging team members to find their way towards our expressed values and principles.
On occasion, I do intervene in the dev room. This is dangerous ground. Innovation springs from the ability of an organization to surprise itself. Such creativity finds its source in autonomy, accountability and necessity.
Software development doesn’t proceed down straightforward path. For each unexpected problem there is a wealth of possible solutions. Ingenuity can add wasteful complexity or differentiate and define a product. You want a team to keep momentum but you want them to think deeply.
I need my team to be open to the problems before them, purposeful and playful in devising solutions but determined to release. This takes more than good work for good wages and it’s profoundly more than good leadership from managers. Project success has to be the individual team member’s success. Tomorrow’s intellectual property is not code yet to be written, it’s the inventive potential of the coders.
If I step in therefore it should be to maintain personal investment and esprit de corps rather than to reverse any individual decision. I have a scrum master and I rely on him to maintain morale and productivity in sprint reviews and planning. Still, with my experience as a developer and unique observer role, I’ll intervene in conversations between the product owner and the team to:
- dispel misinformation
- surface contradictions
- flag intractable disagreements
Misinformation is toxic to the product and individual accountability. A misinformed team builds the wrong product. A pattern of misinformation leads a team to lose trust. They will focus on not failing in their narrow scope of execution rather than a successful business outcome. Playing safe eliminates surprise and invention and ultimately leads to failure.
Contradictions create opportunity. A solution that addresses both a value and its antithesis such as high quality and low cost can differentiate a product.
Some disagreements cannot be solved by conversation. Time and more information may resolve the conflict. Sometimes disagreements simply need to be acknowledged. In the spirit of “any decision is better than no decision”, the product owner or scrum master needs to be encouraged to move in one or other direction despite dissensus in the team.
All of this assumes the project in question is healthy. Intervention into a troubled project is a different animal [see my earlier post on stopping the line].
As a technical manager, what am I for? What are my core values?
Nurture a passionate, focused, autonomous team. Attract, retain and develop people who do right for their team.
Approach the manager’s work with humility. It’s not about getting people to do what I want. It’s about having a team that owns what they do and does it well.
Wed developers’ desire to contribute and love of problem solving with practices that minimize waste, reward learning and provide continual contact with customers.
Hold the team accountable for their commitments. Have them define their own standards of performance (estimates, quality practices, definition of done). Allow them to feel the inevitable disappointments. Celebrate their achievements. Always expect them capable of improvement. Treat their collective workspace, opinions, and time with utter respect.
Always seek out the next challenge and deliver on commitments.
Don’t wait for ways to provide value to my employer. Anticipate the next change or growth. If wrong, react to it.
Avoid make work. The goal isn’t to keep the team busy. It’s to keep them contributing.
Teach senior management the value of the team by what they do. Project success drives organizational change. It trumps reasoned debate. Project success can sometimes even win out over habit, emotional ties, and political ingenuity.
Treat all people ethically
Authority is a trust assigned to me for a purpose. A leader’s behavior shores up the workplace behavior of others and affects the health, happiness and family life of staff. Be accountable to that.
If there is a purpose in work and in life it is not to create unnecessary human suffering.
Our team just beta-released our. Along the way, they accomplished something of more strategic value. They matured into a performing, self-directed team.
A decent manager encourages software developers to do their best work while allowing them full personal lives. The heart of this effort is fostering strong teams. Individuals have bad days, make mistakes, lose momentum. A team watches each other’s backs, challenges each other, teaches each other. They build upon each other’s creativity.
The beauty part for a manager is — if you create the right conditions, start with the right people, trust them and hold them accountable — the team does the hard work of becoming. They deserve full credit for their achievements including the most ambitious achievement which is themselves.
That doesn’t mean it’s easy. Getting this consumer product to the general public has taken fifteen months. From our first study of agile principles to our current practice has taken the better part of four years of continuous improvement.