Sustainable Pace - why it's important

Why We Have to Go Back to a 40-Hour Work Week to Keep Our Sanity - Alternet by Sara Robinson

One hundred fifty years of research proves that shorter work hours actually raise productivity and profits -- and overtime destroys them. So why do we still do this?

March 13, 2012  |  

Photo Credit: gfpeck 

If you’re lucky enough to have a job right now, you’re probably doing everything possible to hold onto it. If the boss asks you to work 50 hours, you work 55. If she asks for 60, you give up weeknights and Saturdays, and work 65.  

Odds are that you’ve been doing this for months, if not years, probably at the expense of your family life, your exercise routine, your diet, your stress levels, and your sanity. You’re burned out, tired, achy, and utterly forgotten by your spouse, kids and dog. But you push on anyway, because everybody knows that working crazy hours is what it takes to prove that you’re “passionate” and “productive” and “a team player” — the kind of person who might just have a chance to survive the next round of layoffs. Read more ...

Leading vs. Managing in a Scrum Environment

Alex Brown, Scrum Inc.'s Product Owner and COO, had some thoughts on the role of management in Scrum, as he's been working on a workshop for executives for the past month or so. - jj

It’s odd. A number of people have told us recently they don’t think management has a role in a successful Scrum implementation.  The comments have been things like team members saying that the role of management in Scrum is to “keep the heck out of the way,” or teams complaints about management requests for updates and delivery forecasts. On the flip side, some business leaders have told us they feel Scrum is “hostile to management.” 

photo by Eoin Gardiner (cc)

We couldn’t disagree more, as we think management support is critical for Scrum to work at its best. In fact, we’ve actually spent a lot of time recently developing a Scrum Inc. workshop just for leadership to show them how important their role is and how to make the most of it.

From our point of view, comments like these say more about the specific organizations than Scrum. They are all classic symptoms of a breakdown in communication between an organization’s leadership and the teams actually doing the work. But it’s a common enough misperception that I thought I should address it here.

A core Scrum principle is that the team should be able to determine how to work best, free from micro-management.  The team should also push back on management requests that threaten to interrupt the Sprint, since that gives leadership a better picture of how their actions impact the actual work.

However, that doesn’t mean that business leadership doesn’t have a vital role to play; it does, and it is far more active than just “staying out of the way.”  Teams that exclude management entirely miss an enormous opportunity for productivity growth.  Our research shows this quite clearly: effective collaboration with leadership accelerates velocity more than twice as rapidly as “Guerilla Scrum” run in isolation from corporate management.

More importantly, and I can’t stress this enough, conflict with or lack of support from management is the biggest and most often cited challenge to implementing Scrum successfully.

The key difference is Agile companies look to their executives for leadership rather than management.  This is a real change in mindset, both by Team members and also in how managers view themselves and their role. A traditional management team spends much of its time focused on telling teams what to do. An Agile leadership team is a positive force that works with teams in three important ways:

1. They set meaningful and challenging, but achievable, goals to help focus the teams’ effort on activities that create the most business value.
2.  They work with teams to identify and eliminate impediments that are beyond the team’s ability to remove directly.
3. They establish and maintain a system of incentives that reward teams not individuals. If everyone focuses on teamwork rather than personal benefit, more work gets done faster and better…and that needs to be encouraged.  

Answering Some Questions

Jeff had a great webinar hosted by SmartBear last Thursday. If you missed it, here's the link to the archived webinar and the slides. We got hundreds of questions from the audience, and SmartBear sent fifteen of them on, they'll be posting all of them on their site soon, but we thought we'd give you a sample of a couple. If you watched the webinar and want to get the full scope of Jeff's thinking on Scrum, you can sign up for our March or April Certified Scum Master courses that are coming up.

What size team is "too small" for scrum?

Zero is the quick answer. We’ve seen Scrums of three of two and even one person. But for most teams the rule of 7 plus or minus two is the way to go. This usually has enough team members to allow for cross functionality, but not too many to make communication and sharing difficult. The more common problem I see is that teams are too large. If you have a team over 9 people, your team is just too big. And the research shows a team of 5 will go faster than a team of 7.

How do you deal with product ownership and customers on the team with shrink wrap software where there are a wide range of different types of customers with differing needs?

We coach all of our venture company on developing “personas” which are user archetypes for the product. Product Owners should take our Certified Product Owner course to dive into detail on this.

There needs to be one “vision” for a product. Now, there may be different types of customers (personas) that will be buying your product for different needs, but there needs to be one person who is prioritizing all of the differing customers’ needs. Is it more important to implement X feature for a certain type of customer, or Y feature for another? These can’t be of equal priority. If the product is large enough that you have multiple teams and multiple product owners, there still needs to be a Chief Product Owner who can settle questions of priority among the product owner team. I strongly recommend that even in large projects there is ultimately only one backlog that is organized in priority order. The reason for this is that the whole group should be focused on the top priority items, rather than diffusing their efforts on whatever features they think are important, rather than what the product owner and the customers think is important. Read the Citrix Online case study to see how to prioritize releases of a portfolio of products at the enterprise level. This is another topic covered in detail in our Product Owner course.

That Product Owner course will be held in Boston on May 31-June 1.

How The C-Suite Hurts America

Steve Denning, one of the smartest guys today thinking about management and how companies are run, just pointed out a new Harvard Business Review article which should be required reading:

If some progressive journal were to write about overpaid CEOs, it wouldn’t be news. It would be just another “dog bites man” story.

But when Harvard Business Review, the pillar of the business establishment, writes that the C-Suite is so grossly overcompensated that US competitiveness is being systematically undermined, it’s big news. It’s a “man bites a pack of dogs” story.

Throughout HBR’s 90 year history, it has been a cheerleader for the C-Suite. Issue after issue, year after year, HBR has tirelessly nurtured the C-suite, tended it, encouraged it, cared for it, defended it, and celebrated it, as well as providing guidance for those aspirants who would like to gain access to the hallowed citadel.

So HBR can hardly be accused of any anti-business bias when it publishes an incisive article detailing how and why the C-Suite of US business is so grossly overcompensated that the practices are inexorably pushing the US economy into decline. In effect, the article describes in detail what the various Occupy movements have long suspected but never knew how the rip-off was executed.

You can read more on Denning's blog here, where he does wonder why the thing was published on page 124, and has a few other issues with HBR's thinking. Steve is the author of Radical Management, and is teaching a course on the thought and practice of it in D.C. on March 19-20.