Why Scrum Developers Should Get Paid More!

Peter Stevens has a nice write-up on the differences in responsibilities between Scum projects, and traditional project. As can be expected, responsibilities are distributed broader in an Agile team, with much (or all) of the responsibilities of a project manager being spread over the Product Owner, Scrum Master and the development team.

Especially interesting is that they found some responsibilities not being clearly defined in a traditional team (ROI, process improvement), while it was there in Scrum. I’m not sure whether that’s quite fair, since tracking ROI is only rarely actually done in Scrum projects, but the responsibility is explicitly there.

Scrum Breakfast: Responsibilities in Scrum, or Why Scrum Developers Should Get Paid More!.

Wave goodbye!

The retirement of Google Wave is pretty big news. There’s a lot of discussion on how Google failed. Failed because they misjudged the acceptance, failed because they overhyped, and failed because they waited too long before finding out whether users would actually like it. And all those things did happen, and some of them were probably mistakes.

But the main thing that I get out of this, to be honest, is quite a bit of respect for Google in how they handled this. They had an idea, followed up on it, saw a possibility of creating a product out of it, experimented, poured resources into it, tried it out in the wild, publicly supported it… And when the time came, they admitted it wasn’t working out as hoped for, and in a timely manner pulled the plug. Writing the whole thing off as something that generated some useful technology, and hopefully some valuable insight in end-user wishes.

This is how you innovate. You take risks. You try new ideas. You get feedback from your (potential) users. You fail.

And if you don’t fail enough, you’re not trying hard enough.

For a company of Google’s size, failure is necessary on a larger scale.

Now if you’ll excuse me, I have some failing to do…

Update: I just love it when people back me up: Eric Schmidt said: ”We celebrate our failures. This is a company where it is absolutely OK to try something that is very hard, have it not be successful, take the learning and apply it to something new.”

The Role of the Manager in Scrum

Pete Deemer has written an article on InfoQ, Manager 2.0: The Role of the Manager in Scrum which disucusses the role of the manager in an Agile organisation.

The situation sketches that he gives are all too familiar, and anyone working on a transition to Scrum (or any other Agile practice) would be well advised to read this article.

The quote that rang the most bells for me was:

“If there exists a fundamental belief in the effectiveness of the “command and control” approach within the management and executive ranks, and a heavy dependence on intimidation, threats, or punishment (such as shaming or humiliation) as a management tool, it is going to be particularly difficult to make the transition to a new way of thinking. As a result, an adoption of Scrum risks being incomplete and dysfunctional, producing little if any improvement for the organization.”

The warning not to have (ex-) managers as Scrum Master is another important lesson, though. The habit of following orders is just so very hard to break.

EA Survey: talk the talk!

Scott Ambler is in the habit of doing some very interesting surveys. One that caught my attention this morning was on Enterprise Architecture.

The interesting part is the tables on success and failure factors. The highest rated success factors are about involvement and communication with both business, management and the development teams.

The highest rated ‘reasons for cancelling enterprise architecture programs’ are getting insufficient time, not being able to prove any benefit, and rejection of the EA work (and sometimes the EA) by the development team. Again, all factors of involvement and communication.

So there you have it: If you want to get some architectural improvements off the ground, the important thing is that you need to talk about it. Sell it to the business, by providing them with convincing arguments on how this change will benefit them. Talk to the development teams, and get them involved. Not just in execution of the idea, but in improving the concept and generating alternatives. You can’t know everything, and even if you did, you’ll get more done if the teams are involved in defining the needed changes.

Product Owners and business value

In Agility, Or A Pig On Roller Skates? Ken Schwaber comments on the role of product management / ‘the customer’ in Agile projects: The backlog is the result of actual work managing a product, and should be used to increase agility (ie. flexibility in getting higher value items out first), not just to adapt to a different development process.

Usually, the introduction of Scrum is initiated by the development organisation. Whether it is completely bottom-up, initiated by the developers to get more grip on their process, or more top-down by development managers interested in increasing productivity and work satisfaction, the initiative is mostly from development. This is both odd, and something of a problem: The main focus for Agile is to get the most value for the customer as soon as possible. This should be of huge interest to the customer, usually product management. But it often isn’t. Perhaps because the principles are not very well understood, or perhaps because any project manager has now been trained in distrusting development teams and their management because what is asked for is usually not delivered.

Years of waterfall, with very high penalties for changing or adding requirements after a project has started development, have conditioned product managers everywhere to create requirements documents in which every possible little thing that might ever be wanted is listed. And of course everything in those documents is Must-have, or at the very least Should-have (MoSs grows, CoWs get eaten), otherwise you might as well not put in there at all!

Going from that requirements document towards a backlog is easy, simply make a separate user-story for each of the requirements in there. Strict priorities are a lot harder, and you notice a lot of attempts to wiggle out of having to make those choices. However, to go from that big document towards a backlog, and then doing some reality-based release planning is very hard, especially when trying to determine minimal sets of features that are actually useful for your users. Simply going through the full list (even when leaving the CoWs out in the pasture) to get to the full release ‘1.0’ is not going to give you all the advantages that you could be having from adopting Agile. Thinking in smaller feature sets, and smaller releases is needed to get to the type of flexibility that well get you the competitive edge that you are (should be) after.

Ken Schwaber Tech Talk

I’ve just finished watching a Google Tech Talk by Ken Schwaber: Scrum et al, through the ‘running agile blog.

This was the first time I’ve seen Schwaber talk, though I’ve been reading his blog. It was a good talk, with plenty of humour, and some very recognisable stories.

Some highlights (paraphrased from memory, I’m lazy):

“In Scrum there’s this role called the ‘ScrumMaster’. Otherwise often known as ‘the prick’. This is the guy who needs to ensure that the team does not compromise on quality. He’s the one that has to say, when some item has not been finished to the agreed level of quality: ‘Sorry, this is not going to be demoed’ to the team, and ‘Sorry, this will not be delivered until the end of the next sprint’ to the Product Owner. You can imagine how popular this makes this guy. They usually burn out after 12 to 15 months.”

Thanks for that last bit, Ken. And I was really liking my new career, so far…

Another very interesting bit was the part (starting at arounf the 35 minute mark) where he talks about how companies can be held back by the state of their ‘core functionality’, the wrong distribution between people working on new functionality, and those maintaining (and extending) the core, and how you can get there. Of course, the how you can get there is more familiar to most of us then we would like to admit…

He explains how you normally get to this state, using a very normal process of overcommitting (pressure…), quality declining, velocity declining… Rince and repeat!

Very much worth watching.

TDD and Emergent Design

I’ve been reading up on Test Driven Development, starting out with Kent Beck‘s book, then finding his screencasts, first the teasers at vimeo, and later the official release through the pragmatic programmers. There’s also a nice free example available on vimeo from Bret Schuchert of ObjectMentor, of which I watched the ‘Getting started with TDD in Java using Eclipse‘ one.

The nicest introduction on TDD, and on why you should use TDD, and how it helps you create better designs, emerging from the test driven approach, has been Neal Ford‘s articles on IBM’s DeveloperWorks: Evolutionary architecture and emergent design: Test-driven design, parts 1 and 2. I can thoroughly recommend those articles to any developer interested in improving their code (and design). I’ll certainly be reading his other articles in this series.

Is Agile always effective?

Ron Jeffries has a nice new article on whether agile implies effectiveness, and vice versa. The way he describes this is that an agile approach gives more opportinity for effectiveness, but if you can’t follow the agile approach you can use non-agile measures to still reach a certain point of effectiveness.

I think this resonates with some other things I’ve been reading and thinking about. The road to creating a full working agile implementation can take quite a few turns before ending up with the type of completely self-organising team that we’re aiming for. A lot depends on the people in the team, the support in the wider organisation, and the experience with agile processes. Scott Ambler has been talking about his Agile Maturity Model which promotes that ‘you should strive to be as agile as you need to be, and that will be driven by the situation that you face’. Jeff Sutherland has been emphasizing that new teams should start with a complete and structured Scrum implementation before they start adapting it to their specific situation, to avoid team (and whole companies!) to ‘adapting’ Scrum towards their previous way of working.

All things said and done, I prefer starting with quite a strict way of applying Scrum, so that when you are changing an organisation, it has something substantial to change to. Of course, this can be interpreted as being against the first value of the Agile Manifesto: People and interaction over processes and tools. But if the process is all about enabling people and interactions, then not sticking to it will be worse than the alternative, especially if that means a return to a non-agile process. 

Adrenalin rush, it’s not just for parachutists anymore

In A Successful Manager But Never A Successful Project? Bruce Benson writes about a rather thought provoking idea: People might actually like being in firefighting mode!

The next time I’m in a situation where I’m having trouble understanding why management is not encouraging improvement, but completely focused on dealing with the craze of the day, I’m going to remember this post. And perhaps arrange some panic theater to keep everybody happy…

Deliver business value, yes. But what should the business value?

Paul McArdle of Global-Roam writes about an interesting article by Roger Martin in the Harvard Business Review (which ca be found here, but requires payment for the full article): ‘The Age of Customer Capitalism’.

The main drive of Agile processes is to deliver business value as effectively as possible. For anyone working in a more complex environment, this automatically raises the question of what business value is, and how it should be prioritised. Things like ROI can be clear, but in my experience is hardly ever used with any kind of rigour. The maximising of profits is very nice, but can not often be linked directly to the particular feature that is being developed.

So why not focus on the customer value? As the articles above state, this is usually a pretty good way to ensure long-term profitability for your company. And though there can always be different points of view on how to serve the customer best, customer satisfaction is certainly a measurable quality!

If you are working on software ‘visible’ to the end-user, it is wise to always consider how that customer is affected by your choices. If you’re prioritising a backlog, keep in mind what features are really needed for your customer, and which are coming from a different source. When implementing some new functionality, imagine how this (rare, they’re always rare!) error condition will appear to the user. Or how much he will be helped by simply ordering this list in that pull-down menu alphabetically, even if that was not explicitly in the spec. The end-user rules.