The picture above, I recently added this picture to Continuous Digital for a discussion of teams. When you look at it…
Over 10 years on Blogger, I’m now merging my blog into a new site, you can read the rest of this post at www.allankelly.net - the new site is still under construction but will merge the blog, allankelly.net and SoftwareStrategy.co.uk (my commercial entity) into one.
“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias ... sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Frederick P. Brooks, The Mythical Man Month - Anniversary Edition (1995a, p.276)
This is one of my favourite quotes about software development.
Those of you who followed my management mini-series last year might remember some of my conclusions, specifically:
I can’t remember if I said it in that series or in another post: the quality of management in software development is often poor.
So now I’m going to do something about it.
Part of the problem is that very very few software engineers ever take time to learn about management. Sure they learn about Java, BDD, AWS, CSS etc. etc. but most people learn “managing” by watching the people who had the job before them. Unfortunately that tends to propagate poor management.
Why don’t people take the time to learn management skills the way they do technical skills?
A few days in the classroom learning about Java is great, why not spend a little time learning about management?
Now most readers probably know that I provide training, usually agile training to teams, but I have long felt that simply offering a two day training course for current and future managers wouldn’t be enough. I’ve long dreamt of offering a course that ran over a series of weeks, that allowed people to mix classroom learning and discussion of topics with hands on practice and, perhaps more importantly, reflection and group discussion.
Now I’m partnering up with Learning Connexions to offer just this course - I’m more excited about this than anything I have been in a while!
It’s going to run this autumn, September to December, half a day every two weeks.
In each session I’ll present some material but more importantly we’ll have discussions between people doing work. We’ll try and apply the material to real work. I expect group discussions will go beyond the stated subjects and allow everyone - me included! - to learn from one another.
Not only is this a new course it is a new way of approaching learning in work. Since it is new the course we are going to keep the price down. We’re running it on Friday afternoons so hopefully it won’t interfere with the usual work week too much.
Here are the hypothesis I’m testing:
The hypothesis you would be testing by coming along are:
I hope, I very much hope we can make this work…. - please get over to Learning Connexions and book Leading & Managing Agile today. Even if you cannot attend I’d love to know your thoughts on this, please give me feedback - comment here or mail me direct, allan@allankelly.net.
And apologies, I’m going to be talking more about this in the next few weeks as I put material together and get more and more excited!
My last blog, “Creating Beautiful Roadmaps - NOT!”, highlighted how the term “roadmap” is used and abused. While I’m probably in the minority in seeing a roadmap as long range scenario planning exercises to enhance learning there isn’t really a consensus on what a roadmap is…
To some a roadmap is a plan of how a product will evolve in the next few years. To others a roadmap is a set of promises with dates made to customers, higher management and others. Most of the roadmaps I see are little more than bucket lists with dates, fantasy dates at that.
Increasingly “roadmap” is used to describe a “release plan”, that is, a list of release dates and for each date a list of features that will be included in that release. Since these are usually based on estimates they are doomed to failure because very few teams can produce meaningful estimates.
Release plans made sense when releases were occasional, say every quarter but once they became fortnightly they loose logic. What is the point of planning releases if you release when the feature is ready? Many times a day?
So imaging how my heart sank a few weeks ago when a client said: “And I’d like you to run a road mapping session for the team next week.”
Worse still, there was no escape, I was visiting a client in Australia, I suddenly wondered if I’d done the right thing flying around the world!
So although I smiled and nodded inside I thought “Bugger!”
A day or two later I enquired about expectations, what did they hope to get from this exercise? Fortunately the answer was “An understanding of what the team will be doing in the next six months.”
OK, this wasn’t a full blown scenario planning exercise it was a mid-range scheduling plan. Normally I see little point in scheduling more than three months in advance - at most! Since this team was changing their work processes, personnel had been in a state of flux and there was no historical data this was going to be difficult.
My next stop was the Product Owner. He had a long list of things the customers - internal and external - wanted. Most of these were little more than headlines and they were all a long way from stories or epics so there was little to go on. The sheer quantity of ideas was so long that saying “No” and deciding what ideas not to work on was clearly going to be essential.
Given the vagueness and unreliability of inputs one could be forgiven for despairing but instead I saw opportunity. The problem was not so much one of road mapping or scheduling but deciding how the team were to divide their time up for the next six months. This was more big ticket prioritisation.
The vagueness of the requirements and specifications meant that once the time was divided up the team would mostly have a free hand in deciding what needed to be done and what they could do in the time allowed.
Without performance data there was no way estimation could be a reliable guide so there was no point in even thinking about it. But if one was to try estimation one would need something to estimate, which means the requirements would need fleshing out and with so many possible options that would be a lot of work. Not only did we not have the time to do such work but since we knew some items would not make the cut fleshing them out, let alone estimating them, was work which would be wasted.
Just as this was looking like mission impossible I remembered Chris Matts Capacity Planning approach. The roadmap request was actually a capacity planning exercise. Chris’ approach would need a few tweaks but it might just work…
In Chris’ version the product owners estimated the work. At first this sounds awful, product people estimating how long technical work will take! Help!
While Chris says this I’ve never seen these “estimates” as real effort estimates. I’ve always viewed them as “bids.” Each product owner wants to get as much time as they can for their chosen work. But they also know that the higher their bid the less likely they are to get what they ask for. So in “estimating” they are both bidding and self-limiting. Once they have a work allocation they will have to adjust what they ask for to get it into the time.
Rather than ask the product folk to estimate or bid I decided to ask them how many nominal days they would like to allot to each item. How would they divide the capacity between competing requests?
Secondly I decided to ask them to order request items. Thus, a line item could have a very high allocation of time but be late in the scheduling order; conversely a small effort item could be high up the priority list.
So…
The first task was to knock the wish list into shape as a series of line items.
For each line item we gave a short description and statement of anticipated benefits in a spreadsheet. Each item had a box for “days” and “order.”
Next we took a stab at calculating how many days team P had: six months for 10 people equated to approximately 1280 working days.
My plan was to have each manager allocate 1280 between the line items and assign each item a priority position. Then we would average the numbers and use the combined result as the basis of a discussion before finalising the allocations. Finally we would turn the allocated days into percentages and hand them to the team together with the priority order.
So far, so good. The meeting commenced: three managers, three techies, one team product owner and me. (Only the managers got to vote.)
To my surprise the managers readily accepted the approach: I had feared they would want detail on the line items and effort estimates.
While I had intended to hand out the printed spreadsheet, collect the numbers and average them someone decided we should put them on screen. So the whole spreadsheet was projected on screen and it became a collective exercise.
Very quickly about half the items were dismissed and allocated zero time. They were all good ideas but given capacity constrains they clearly weren’t going to win any time.
Some of the remaining items were split up and others combined. Before hand I had worried whether we had the right granularity and even the right items but the group quickly addressed such concerns without me needing to mention them.
(Anyway, I didn’t want fine granularity because that would hinder the teams ability to decide what it wanted to do.)
Next each line item was discussed and assigned an order. I had intended to order them into strict 1, 2, 3, …. but these quickly became buckets, there were several #1 items, several #2 and finally some #3.
With the “order buckets” decided we moved onto allocating nominal days. We quickly decided to simply work with 1,000 nominal days. I quickly calculated how many points equated to one developer for one sprint, how many points equalled the whole team for one sprint and a couple of other reference points to help guide the process.
The days were allocated - including an allowance for technical investment - and we were at 1300 nominal days committed, 300 over budget. Now things got hard so we stopped for lunch.
After lunch I expected a fight. But I knew that if the worst happened when we converted to percentages everything would be cut by 30%. Moving to percentages would force any cuts the meeting couldn’t make.
Maybe it was the effect of lunch but these hard decisions were taken quickly, to my immense surprise. The managers concerned could easily see the situation. Once the capacity constrain and work requests were clear the competition became clear too.
Most of all I had succeeded in preventing managers from arguing over who was doing what. There was no attempt to say “Peter will do X and Fred will do Y.” The team had a free hand to decide how to organise themselves to meet the managers’ priorities.
I was delighted with the way the whole exercise went, having tried capacity planning once I expect I’ll be doing it again - I may even build it into some of my training courses!
What do you think? Anyone else done this? - please leave me a note in the comments
