Tag Archives: Jeff Sutherland

Scrum without XP?

Posted on by

My team built an XP practice before introducing Scrum. The desire for change arose within the developers and was about sharing, becoming better at our craft and making our productivity and quality more consistent.

Scrum became necessary when our biggest problems were no longer within the team but in how we took on work from the business.

I started thinking about that at the last XTC-NYC when Mike Roberts wondered aloud if Scrum software development can work when a team doesn’t practice at least some aspects of XP. In a similar vein, Scott Bellware has a post about XP deserving more credit for Scrum’s success.

At XP-Spin, Jeff Sutherland said the success you build on is delivering working code at the end of each iteration. To even begin you need work described in achievable stories with acceptance criteria and daily builds.

Oxygen Standup

Mike and Scott are definitely right when I look at my team.

Our present challenge is aligning our development with a clear and achievable business objective. Scrum is the tool for that. One of the things about Scrum is that you can use it for almost any kind of work requiring cross-functional teams.

But that challenge only exists because we were highly productive at creating quality software. The team’s XP practice with its low formality and high discipline gets the credit for that.

Retrospectives and the Hair Shirt

Posted on by

Scrum is really simple, barely a process, more a framework. The hard work in using Scrum is fixing the things that it exposes, actually inspecting the things that it makes transparent and adapting to optimize the results and the organization that produces the results. — Ken Schwaber Scrum and NonScrum

My team embraces retrospectives. Every two weeks we list what we’ve done well and what we didn’t. We choose one or two things to do differently in the next Sprint. We revisit those commitments over time to see what progress we’ve made.

My team exists in a larger company.

In Waltzing With Bears, the one irrefutable reason to not do risk management is when no one else is doing it. If you are the only one presenting costs and possible negative outcomes management will assume your projects are troubled and you are a negative thinker. They’ll fund proposals that by comparison look cheap, safe and promise outstanding success.

I don’t exist in that extreme situation. But my team’s willingness to acknowledge mistakes is sometimes taken for negativity. Our willingness to admit the possibility of failure sometimes provides support to skeptics. Our willingness to question assumptions is sometimes seen as stone throwing.

Leading Change

In order to build something new we straddle two realms. In one we cultivate our aspirations and in the other we struggle to attain them.

At times we need to set aside our skepticism to see the world as it should be and people as we hope they are. Other times, we need to see how far we are from where we aspire to be, dig our feet into the soft earth and push.

Jeff Sutherland has a simple exercise for spurring organizational change

  • Setting aside all the obstacles in your path, picture one thing you would like to change. Write down what it looks like.
  • Now, go back to where you are. Look at that outcome. List things you can do in the short term that get you closer to it.
  • Which of the items on that list are achievable and most effective. Put those at the top of the list.
  • Identify what you can do in the next week to to achieve the items at the top of the list.
  • Assign each of those items to someone in the room with you.

You’ve just planned a Scrum.

The Hair Shirt

There is a difference between justifying one’s mistakes and reflecting on past performance in order to improve. There is also a difference between acknowledging one’s fallibility and dwelling on it.

We developers are crafts people not monks. Our job is not righteous contemplation — it is thoughtful and rightful action.

So as reflective developers, we do not wear a hair shirt. Our goal is not to dwell on our own or other’s failings.

We are idealists.

We embrace grand visions, ambiguity, contradiction and change. We believe good people deliver the best results in environments of trust and honesty.

.. And we are pragmatists.

We believe believing doesn’t in itself make it so: success requires discipline, determination, and ingenious problem solving.

And as we embrace both the outcome to which we aspire and the given circumstances that surround us we will acknowledge mistakes. We will shine a bright light on obstacles in our path. With humility and tenacity we will challenge ourselves, our teams, and our companies to do better.

Trust, the Product Owner, and the Team

Posted on by

KnotWe are currently working on a consumer software product named Ript. 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?

Knowledge Creating CompanyInnovation – 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, Gerry Laybourne. This initiative is her idea but she partnered with the development team to craft the concept and feature set for our first consumer product, Ript.

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.”

The Manager and Scrum

Posted on by

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.

  1. provide strategic vision, business strategy, and resources,
  2. remove impediments surfaced by Scrum teams that the teams cannot remove themselves,
  3. ensure growth and career path of employees, and
  4. 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.
The Oxygen team and management

[the oxygen team and management]

I’ll go into this in more detail in later posts.

About

Posted on by

I’ve been working in IT for fourteen years and developing software for eleven.

My first development job was in a startup working alone and crashing for a deadline. Classic code and fix. I was pretty successful at it. I generally delivered on time. Often through sheer force of will. My big weakness was not reaching out to learn from other developers. A sure sign of a new or just bad self-taught coder is that they bang away at a problem like no one has ever solved it before. I’m embarrassed by some of the old code that has my name on it. Luckily, I wasn’t a cobol developer so all that work is long since trashed.

As I moved on to larger companies, I suffered under well-intentioned but corrosive attempts at waterfall. Craig Larman’s Agile & Iterative Development has a great description of how these attempts at perfectable planning and design are based on a misinterpretation of W.W. Royce’s writings.

Some of these projects were successful but the process prized simple agreement over trust. At it’s worst it created false hierarchies which hid incompetence and fetishized heroics. I was burning out. My friends were quitting. As if that wasn’t bad enough, even our success often fit Mike Cohn’s description of delivering the wrong software on time and on budget.

Meaningful products can emerge from horrible process. But a way of working that tears down talented people’s desire to work is tragic. To repeatedly participate in this is to sap the world of it’s limited supply inspiration, creativity and joy. This is evil. Now that I have authority, my main goal is to avoid this evil.

About seven years ago, I took my first training from Stephen McConnell’s Construx. Stephen McConnell inspires me. He is open to different practices, sets high standards for performance, and champions a code of ethics for our profession.

Over time I learned some techniques for effective iterative planning, risk management, and estimation. I learned how to work with others to deliver quality software. Through Earned Value Planning, regular inspection points and risk lists we built transparency into our practices. With realistic schedules we were able to maintain a reasonable work-life balance.

Still, the weakness I saw in my team and in my leadership style was relying way to heavily on the abilities and day to day motivation of individuals. I had to manage the project. My best developer had to work on it. If one of us had a bad day the project might grind to a halt. Our whole wasn’t adding up to the talents of the individuals.

It took me a while to really grok that excellence isn’t about adopting a shared set of practices. It’s about rallying around a shared set of values. I shifted from mentoring my team on how I did things to a conversation about why we do what we do.

We all want to make a contribution, we want to deliver business value for our employer, we want to be proud of our work, we want to learn, we want to be honest, we want time for our family’s, friends and outside interests.

Over the last four years, we have adopted coding practices and a management style that supported our values. Specifically, Extreme Programming (XP) and Scrum. My recent focus has been on the management side. My short list of thought leaders is Alistair Cockburn, Mike Cohn, Ken Schwaber, and Jeff Sutherland.