Goa State, India, Lifting the load: Martin Harris

Project Management Offices really serve no purpose in scrum. You are either a product owner, (not a manager), scrum master (not a manager either) or your in the team, (no technical leaders here either). So what about all that useful controlling and reporting stuff they used to do?

• Program management functions should be moved into the team.
• Team support comes from Agile coaches, or scrum masters.  They are not managers, they guide and do not tell the team what to do.
• Responsibilities of release, budget, tracking reporting etc, are the Product Owners domain, once again the Product Owner is not a manager.

Its a bad idea to keep the PMO and attempt to re-brand it under Scrum.  Keeping the unit and asking people to be scrum masters is a recipe for disaster.  Its hard to change team culture over to scrum.  Teams find it a big challenge to throw off the old and become self directed.  If you have your old manager coming to your team the roles stay right where they were.  So if you want to keep members of the PMO and they are technical, make them part of the team or remove them from the process.

Educate the Fake Scrum Master

Along similar lines, have you met a Fake Scrum Master? Its common for an organisation to take existing managers and ask them to be scrum masters.  Often with little or no training, rarely assigning mentors.  Its a very difficult thing to do, to change within your own organisation.  Michael Watkins exposes this as a potential area of failure for new leaders in his book the first 90 days.  A manager is typecast by his existing interactions within an organisation, so being promoted within his existing unit to a more strategic role is possibly one of the hardest things for a manager to do.  So moving from the role of manager to one of coach, mentor and guide with the same people is nigh on impossible.  People just put you back where you were despite your best efforts.  Its a big ask turning a team self directed, its tempting as a manager to tell the team how to do it.  So you see the paradox.

To help you spot a Fake Scrum Master, think Cargo Cult Programming but with a process slant.  These are typical behavior characteristics.

• Produces the Sprint Backlog on their own.
• Decides how long the tasks will take.
• Assigns tasks to people.
• Chases around the team (outside the scrum) requesting status updates.
• Takes on the role of co-ordination with other teams where dependencies lie.
• Takes the heat when the pressure is on.  What a hero!

All these things the team should do.  Those tasks teach, pressure and form the team into an efficient unit.

Things you can do with project managers to help them transition

Get external help.  Find good, skilled facilitators who can come in and pair with the new scrum master.  They should help with the new meeting formats, show how to guide instead of manage, and jump on any of the fake symptoms.  Its not always the scrum masters fault but a facilitator will be able to spot when the relationship is reverting to type and break it up.  If you recruit facilitators to the organisation you can often share them amongst projects.  Let them move around the teams from week to week and be on hand if anyone wants “emergency support”.  Sometimes its important to get something resolved before it develops into a habit.  Remember, support not control.

Other signs that your project managing

• Sprint lengths are project lengths.
• Teams are broken up people moved around frequently.  Teams need to change but give them time to settle and grow.  Only change individuals infrequently, keep the team.
• You have a matrix structure in software development.  It was an idea to reduce load on managers, no longer needed if the team shares the work.
• Scrum managers are shared.  How could a genuine scrum manager have the time.

So save some cash and spend it on facilitation and budget for development.  Disband the PMO, give people support and new scrum roles.

                          

Clip from Switch Change book

The experiment in the hospital, reminds me of what happens when I am pair coding.  When you are working in a pair, people are less likely to interrupt you.  I think it contributes to the extra throughput for pairs.  This book is going on my reading list.

                          

Cambodia, Phnom Penn, the water festival: Martin Harris

Probably one of the most common mistakes in Software Development is to allow Estimates to become Commitments.  I am sure you know the following scenario all too well.  The development team is called into a meeting room and asked the following question.  We (the management team) have had a look at the estimates, and your tasks on average are taking longer. The insinuation is that the development team is, stupid or perhaps lazy.  Worse still, an individual is called in because the stats show their work is “Behind Schedule” as judged by the estimates.  The problem is none of this though, the problem is believing that estimates are anything other than an educated guess.

The most likely outcome of this is a dissatisfied manager requesting for more hours to be worked.  This pressure normally results in dissatisfied team members and a drop in morale.  Its likely outcome a drop in productivity.  Extreme cases result in high turnover of staff as they leave in search of more enlightened projects.  In addition developers drop quality to meet the deadline.  This code is unmaintainable in the future as corners have been cut just to get it working.  So the initial surge in productivity results in slower progress ongoing.  Watch the defect rates, your teams will spend more time fixing than producing new work.

In actual fact what does the business require of our Software Development services that has lead to the belief in estimates?  We need to know when something will be delivered.  In some cases we demand that at all cost something will be delivered.  The book Peopleware by DeMarco and Lister describes this as The Phony Deadline.  Poor delivery is the result of picking a phony deadline.  Yes you got something, but it might not work quite as expected.

I still want that delivery date, what can be done?

Have it you shall, but not straight away.  Now I have spent the last few paragraphs showing how estimates poison the team and reduce product quality.  In the next section lets look at the relationship between our team and the sponsors.

A collection of estimates can be used to provide the paying customer with an inaccurate delivery date.  So given that the average customer has problems with the definition lets re-brand estimates as guesses, educated or otherwise.  There are two important things that a software development team needs to provide the business.

1. The contents of a delivery.
2. A delivery date.

There are only three variables in delivery, time, cost and scope.  Cost is most often set in stone at this stage, scope can be negotiated and time has an awful habit of not sticking to the rules.  The trick is to use our guesses to address the content of the delivery instead of the go live date.  For delivery date we will record story velocity over the first few tasks and use that to extrapolate the delivery date.  We will carry on tracking velocity and the cone of uncertanty will get tighter, leading in turn to a more accurate date.  Commitments can be made on that date once you move into the cone and the variance diminishes.  This can be problematic to the business at first because the date is non existent at the start, and as you begin to track reports will vary.  This will settle down, especially if you try to keep other variables consistent.  So stop mucking about with the team makeup and the iteration size, concentrate on tracking the work accurately.  Once you have a few releases over, you will find that velocity is a much better way to work out delivery dates.

The business I currently work in uses techniques like this in many financial metrics.  Take a look at how interest rates are set for a year.  Obviously its impossible to know what will happen to interest rates over the course of a year.  We might start at 2% and rise to 2.5% or perhaps not.  News on the economy gives some indication in the short term as to what might happen to the rates.  These news clips cause the market to react and the closer we get to the end of the year, the more likely we are to be able to guess the final rate across the year.

So what is so bad about using story velocity metrics to gain more accurate estimates of how many stories a team can complete in a delivery cycle?  To further improve things we might also consider smaller delivery cycles and standardizing story and task sizes as much as possible.

Estimates guesses still have value don’t they?

So where do the guesses come in?  Lets use a relative estimation system instead of a time based one.  In scrum these are known as story points.  Please do read that link it is probably the best description I have ever come across.  Many thanks to the authors.   The idea behind point-based estimation is to agree that at the beginning we have much uncertainty and ambiguity.  Even if we spent extra time on analysis of the problem, we would still be uncertain and much ambiguity would remain.  Points are relative to each other and are all about size of stories over time.  This is much easier to deal with as a developer.  People are comparators, we do that all the time.  This makes us much better at saying if one task is bigger than another.  Especially if we have done similar stories before.  So points are a weighted system to grade stories into a set of different sises.

Now we need some kind of system to help us standardize the size of the boxes.  In scrum a technique knows as planning poker helps with this.  Planning poker gives us a set of cards representing the relative weight of a story.  Normally 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.  When estimating your thinking goes something like,

Mmm well I have done something a bit like this before, that was a 20 but this is a bit more complex, now is it a 40 well that’s double…and this feels a bit bigger but not double.  So I will plump for a 20.

So as you see the numbers are important as the weighting is designed to help grade the story into standard size boxes.  The other important thing is the whole team takes part in the planning so you get a graded average.  This has a side effect, the team members start to appreciate the effort involved across the full spectrum of work.

So then, that delivery date?

If your able to try and run an iteration or two before giving a delivery date.  Track how many stories you can complete in an iteration and use that to project forward and arrive at a date.  Explain to the business that you will review this date with them on a regular basis and that it will get more accurate as velocity settles down.  A little like the speculation over the next interest rate announcement.  One problem is the initial project stories are often very different from latter ones.  Usually due to building and setting up initial architecture and development environment.

Another idea at the initial stage is to break out a random selection of stories into tasks and estimate / guess those.  Calculate an estimated velocity and explain to the business that you can’t commit to this date and once more accurate statistics come in you will review the new date with them.

So finally your left with no fixed date.  The honest thing to do is to explain how consistent velociy will ultimatly give a better reporting picture This is going to be a sticking point I assure you.  In the past it might have been easy to just give a date to the business.  Chuck in some contingency for good measure.  This is a very bad practice indeed.  If you do miss that deadline you loose the customers confidence.  If you manage the politics better by de-scoping your just going to erode that confidence slower.  At first explaining your system will give them a date that gets more accurate the nearer you get might not go down that well.  I can assure you though that once you get more accurate velocity and that date moves around less the business will gain a profound confidence in the system.  After all soon your dates will be the best ones they have ever had.

                          

Groundswell shows a way to tool up your Product Owner?

One of the most important scrum principles is to assign a Product Owner.

Tool me up, Temple, Ho Chi Minh City, Vietnam: Martin Harris

This person should have a very good understanding of the business.  At first glance is seems like a good idea for that person to be an active part of the business.  For a single dealer platform it looks like a good idea to recruit someone who actively deals or for a legal application a senior member of the law staff.  The problem with this is a dealer is likely to be too busy looking after money, and the Lawyer is in and out of court.  Active members of the business have better things to do, so we have to look elsewhere for our product owners.

Some links if your interested in the problems a product owner deals with and how to find a suitable candidate:

Being an effective product owner

Product owner – Choosing the right person for the job

So instead another option is to appoint a business proxi.  Perhaps a Business Analyst or a traditional Project Manager.  There is nothing fundamentally wrong with this and I have seen it work well but at the end of the day this person needs to tune into their sponsors and customers.  This is where the book Groundswell comes in.  Groundswell has several documented cases where Social Technologies have been used to garner information from communities, check out this blog post for some idea of the mechanics.  Some such cases have been in areas where it would normally be very difficult to get any feedback from the community i.e. a pharmaceutical company setting up support communities for cancer patients.

There is one great example of Credit Mutuel a French retail bank who asked of their customers “If I were a banker” and collected responses on what the customers thought the bank should be doing.  A huge wave of Groundswell resulted in the bank making changes and in Credit Mutuel benefiting from increased competitive advantage.  They were able to respond to customers quickly and make the changes they deemed sensible.  The customers loved it.  There is a caveat to this though.  You have to be able to turn around changes quickly, and now we are back to scrum.  A development system that done well can implement software changes quickly in reaction to a clients demands.  What I am suggesting is that correct use of Groundswell could make the product owners job easier.

In particular within organisations who have trouble getting the right kind of requirements from the users of the applications we write.  I have worked in several industries where getting access to your users is a real problem.  Lawyers and Traders who are just phenomenally busy and expensive, highly dispersed users of global applications where the logistics of visiting them all is impossible.

In the book there are several documented cases where companies like Communispace or Passenger setup and manage systems to recruit and manage a comunity focused around a product or idea.  I think it would be great to try out ideas like this to gather information about an important software product from its internal and external users.  The end game, is to gather the best ideas, then put them back to the community for voting and prioritisation.  Yes, you get a ready made backlog off the back of this.  How incredibly handy is that!  Take a look at this, its pretty much a community fed backlog used by Salesforce.com: http://sites.force.com/ideaexchange/. Here is another that Dell use based on the same Crispy News system: http://www.ideastorm.com/

I think that doing something like this has these benefits possibly more:

• It helps the product owner get a more representative view of what the customers think is important.  What requirements they put at the top.
• The customers feel more involved in the evolution of the product.
• Your scrum team is likely to find out some things that all the experts and analysis have missed.

Its powerful, but as with any power tool be careful!

• You will have to show both the good and bad feedback.  Are you ready for the honesty required?  Make sure all your sponsors are prepared.
• The scrum team should be ready and established, if you can’t turn around the best ideas quickly the mood will quickly turn sour.
• It takes a great deal of skill and a degree of humility to make this work, but the closer alignment with your customer will soon show results.

So why not give it a try?

                          

The spring integration project embodies principles found in the Spring Framework and Enterprise Integration Patterns (Hohpe and Woolf, 2003). The book and project are worth a look for anyone working in that space.

• Spring Integration Project
• Spring Integration in Action, Manning Early Access Program