In January, I had the privilege of meeting, John Maeda. One of the perks of working for is the circle of associates she can bring to a wicked problem.
By coincidence, Mr. Maeda and I both grew up in Seattle. My mom is Japanese and I remember visiting his family’s Star Tofu Bakery. The whole Maeda family worked together to make the tofu the authentic Japanese way. Served as hiyayakko, chilled and fresh, it was the best tofu I’ve ever tasted.
In a grand display of traditional Japanese customer service, John described how his father would open the door for his customers as they arrived and again as they left.
This image struck Gerry as a deep truth her company should strive for in its relations to its customers.
As my team works on a consumer software initiative for Gerry, we need to embrace the guiding principle that our work is all for the end user. Business value derives from serving their needs. We have tried to embrace this principle by using our agile practices to rally around our product owner’s vision, testing our software with prospective end users and listening to them. Feedback from prospective users has changed both our feature set and our release roadmap.
In how we approach our customers we must always welcome them with courtesy, listen to them respectfully, serve them as best we can and thank them on the way out.
Mr. Maeda’s observations about Oxygen.
What do you do when the fundamental assumptions behind a software project change mid-stream?
My experience before adopting agile practices was people often plugged away at the original plan drifting farther and farther off course.
I’ve been on projects that failed simply because no one had an honest conversation about who had authority to drive changes. How many of us have built something only to have the launch postponed because a senior executive got their first look and over-ruled their under-powered product manager? How many of us have had a project declared failure as a result? How many have seen work shelved? Me. Me. Me.
I’ve found Scrum does a great job of surfacing these issues and forcing the team to deal with them. Product owner is being over-ruled? Sprint integrity not being honored because interruptions and changes? Believe me, a performing scrum team will raise the alarm as quickly as this occurs and force a conversation about who is the product owner and what are the criteria for success.
One possible result? “Stop the line” interrupting the current sprint. Meet with the relevant managers and make the person setting feature priorities accountable for the backlog and the business outcome of the project. Plan a new sprint and re-commence work. The cost of mid-sprint changes is made explicit and responsibility is aligned with authority.
This can benefit everyone. First, the hidden product owner now has the regular feedback and control that reduces the urge for mid-sprint intervention. Second, the team knows who to rally around and why. Third, difficult conversations about what is driving changes and what defines success for the project happen earlier rather than later.
I’m not saying that these changes ensure success. Honestly, a project with mushy business ownership and vision is troubled. What I am saying is that with frequent inspections and a culture of honesty these seeds of failure become very clear to everyone much earlier.
I’ve found that once a team becomes used to satisfying the customer with early and continuous delivery of valuable software. They fight like hell rather than get caught in a familiar pattern of failure.
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].
We are currently working on a consumer software product named. I feel extremely lucky to be a part of this project as does every member of my team.
If there is a single reason for this sentiment it is the deep collaboration between our product owner and the development team.
The Manifesto for Agile Software Development asks us to value:
Customer collaboration over contract negotiation
Contract negotiation within a single organization arises in conditions of low trust. One or both parties feel they need to explicitly document expectations to protect themselves.
A low trust environment is Hobbes state of nature as practiced by the software industry. Promises are prized more than outcomes. Authority and responsibility don’t reside in the same person. Incentives are not linked to outcomes. Blame brings more consequences than failure. Success is virtually impossible. Agile practices if they can be adopted at all are simply a mechanism for failing fast which has the virtue of saving the company money and sending talented people off to hopefully more rewarding jobs at other organizations.
Rising above this coding purgatory is an organization with some mutuality of sentiment and interest. A capable development team exists and business owners are both empowered and accountable. Here the organization can aspire to partnership.
But not all collaboration is equal.
In What’s Worth Fighting for Out There?, Andy Hargreaves and Michael Fullan describe the concept of bounded collaboration:
Bounded collaboration rarely reaches deep down to the grounds, the principles or the ethics of practice. It can get stuck with the more comfortable business of advice giving, trick trading and material sharing of a more immediate, specific and technical nature. Such collaboration does not extend beyond particular units of work or subjects of study to the wider purpose and value of what is taught and how. It is collaboration, which focuses on the immediate, the short-term and the practical to the exclusion of longer term planning concern.
This concept is applicable to the software setting which, like learning, is fundamentally about knowledge creation and sharing.
Bounded collaboration exists in software when the developers do not invest themselves in the business outcome of a project. This can occur through no fault of their own if the plan is vague, not shared with them, or if their input is not invited or listened to. Some managers simply don’t consider it important that technical staff buy into the vision or features of the software they’re building.
In such situations, developers shut off part of their brains. (for those of us who love our craft, a more apt description is cauterize part of our brains)
“I’m not personally invested in the business plan or priorities but I will execute on them as you (product owner) define it. Since I have no authority or meaningful influence on the plan or priorities, as long as I produce reasonably error-free code I refuse to be judged by how the product fairs in the marketplace.”
Scrum allows for success on these terms by assigning responsibility for the business outcome to the product owner and technical execution to the team. If the product owner has a thoughtful strategy and deep insight into their customers a well-executed piece of software stands a chance.
But what price does an organization pay for bounded collaboration?
Innovation – A company that does not engage fully with its workers diminishes its ability to think deeply about a problem and to surprise itself with unexpected solutions. It therefore fails to be what Ikujiro Nonaka and Hirotaka Takeuchi describe as a Knowledge Creating Company that can sustain success through its own invention.
A television company building consumer software – that’s audacious!
Our product owner is our CEO,. This initiative is her idea but she partnered with the development team to craft the concept and feature set for our first consumer product, .
Gerry has allowed us to fall in love with the project by leading us while listening to us. She’s given us the gift of high expectations demanding that the product be original, useful, and fun. She’s treated us as peers despite the fact she holds much more authority than we do. She’s shared her excitement for the product while sharing credit for it. She’s championed her priorities while allowing us to question any and all aspects of the product. We’ve both had the pleasant experience of disagreeing and realizing the other was right.
Yes, the product owner is the single wringable neck – she’s championing an entirely new line of business at her company – but I’ve never seen a team fight so hard to get in the noose with her. That’s trust.
To quote Jeff Sutherland, “Great scrums require great product owners.”