Tag Archives: Release Planning

Wisdoms from the Practical Agile Release Planning and Prediction talk

It was great hearing a product manager’s perspective on release planning and prediction. You don’t hear enough talks from product managers and the way they want and do things. Thank you Cliff Hazell for the talk and thanks to Unboxed Consulting for sponsoring the event.

Philosophy

#2 always gets promoted
I guess it depends how you look at this one. Who remembers Charles “Pete” Conrad and Alan Bean, the second guys to land on the moon? Sure I understand that you need to be second to become first. However what should you do when you become the president of earth?

That Steve Jobs quote about passion

Be passionate about your work, daily. If you lose the passion, you will lose yourself. I’ve started living this in the last year or two and it’s amazing. Frikkin love what you do, at work and at home. What’s the use you settle for anything less?

Maslow

We learned that wordpress > twitter > facebook > linkedin. See some slides section below.

That Einstein quote about solving problems and thinking

This made me think about a quote one of my friends always says: today’s problems are caused by yesterday’s solutions. We need to think and react about things at a deeper level. We have to change our way of thinking to a systems thinking way. The fifth discipline is a good read about this.

The Japanese inspect and moer the hell out of things

Mura Muri Muda – Unevenness, Overburden (over working), Waste (non value added). Running at 100% isn’t great as it leaves no space for anything else. I didn’t get the just of this section as the late comers distracted me :/

Say no by default and force people to sell the value to you

Process

Meeting = Massive waste of time

Implement No-Meeting-Mondays, slim down meetings and make them optional. Timebox it. Schedule meetings to end just before lunch time. I suppose this also depends on the type of meeting. Don’t make the daily scrum optional.

The sooner you get working software out, the better. Release often. Cliff mentioned that his company went from 4 releases per year, down to 4 releases per quarter.

Know where in the process you are at all times. This can be achieved by using processes and tools (because there is value in the items on the right)

Cliff uses Trello to track his product backlog and if I understood this correctly, Trello replaced the scrum or kanban board in his company

You are only able to predict what you know. He is able to predict with certainty what will be released within the next 3 months. He has a broader plan for the next 6 months, and that’s where it stops. Deadlines stays intact for 6 months He uses Liquid Planner to help with the predictions. There was a strong feeling from the audience that it’s a gantt chart. However Cliff has made it work for them. Inspect and adapt I suppose?

Strip down the product backlog as much as possible. If something is on it longer than 3 months and it hasn’t been started, bin it. If it is important enough, it will come up again. You will spend all your time grooming and too little time developing if you have a massive product backlog

You always need to get buy in from management. If you don’t have it, you are wasting your time. Cliff gets the execs involved in the prioritization part of the process. After this the teams can get going with minimal interruptions

Cliff mentioned that it’s better to do changes when it is cheap and early in the process rather than later in the process where an entire feature needs to be undone to cater for something else. In a way this sounds to me like bad architecture. My opinion is to think things through and build systems as generically as possible. Any change should then be easy.

People

Some one-liners here:

People is more important than process.

Share metrics with the teams. They need to see what the execs see as well. Show it live if possible

Know your customers and people working for you. Do happiness surveys on staff and customers. I’m reminded of a niko niko calendar here

Happy teams do great work.

If it’s rotten at the bottom, someone screwed up on top

Focus on the long-term rewards. What you do needs to be rewarding.

Book list

Gerald M Weinberg, check out his retro website. Not sure which book Cliff referred to, however on a quick search it looks like these are his more popular works:

  • Understanding the Professional Programmer
  • The Psychology of Computer Programming

People ware — Productive Projects and Teams (ISBN 0-932633-43-9) by Michael Lopp. Cool intro on Michael’s site

Drive – Dan Pink

There was another book he referred to, called meeting creatures I think, I didn’t get the author though. Cliff also mentioned something about churn- the silent killer. Could you please give some clarity on this?

Rework – 37signals

The Fifth Discipline – Peter Senge

Tools list

Trello

for kanban / scrum board

Liquid planner

Very gantt charty, however they’ve adapted it to help predict release dates and it’s been working well over the last 6 weeks.

Value graph

Some slides graphics

The pendulum process

Maslow’s hierarchy of needs

These are my opinions and observations only and not necessarily correct.

Peace and love and happiness

Event Report: Release Planning

For SUGSA’s first event of 2012, Patrick Vine shared his ‘just do it’ attitude to planning agile releases.

With an emphasis on simplicity & transparency, he starts with high-level release planning using magic estimation at a feature level to generate a gut feel release date, develops detail in backlog grooming, and uses a comprehensive set of spreadsheets for reporting. These and the talk slides are all available on Patrick’s blog.

The overall message was an emphasis on communication throughout the release.

Communicate that:

  • The first guess is just that – ultimately just an input into a “go / no-go” decision on the project,
  • Change will happen – make sure everyone understands that
  • Communicate all changes as more detail becomes known, and
  • Communicate alternate options so that decision makers are informed

I liked the point “the numbers rarely lie… but you may have forgotten something” – followed by a useful list of things we frequently forget to accommodate.

Discussion points:

  • How to handle large unknowns (epics and themes) – suggestion: use estimates as constraints when fleshing out the stories
  • Who should estimate, when (sometimes the PO’s gut feel can help clarify expectations)
  • In groups: how we handle release planning in our teams – lots of good sharing here
 
  

Cape Town: Release Planning with Scrum: Controlling the Chaos

Join SUGSA Cape Town on 2 February when we have Release Planning with Scrum: Controlling the Chaos.

When: 2 February 2012, 6:00PM

Topic: Release Planning with Scrum: Controlling the Chaos                    

Sign up: Please sign up here in order to help us with catering.

Venue:
Allan Gray Portswood office in the Presentation Room on the third floor. You can download a map here. Everyone parking in the Portswood parking area will have to pay for their own parking tickets. There is also parking available in Beach Road.

Synopsis:
The Agile Manifesto tells us that we should be responding to change over following a plan.  This encourages us to plan into the future at the last responsible moment.  But we still may need a plan.  A plan can help inform our customers what may be in the next release or by when their favourite feature may appear.  They can help inform stakeholders on the cost of the current focus and hence whether the investment makes sense at this time.  These are Good Things for a business.  The essence of agile planning is to understand that the plan may change.  The plan must be reassessed for validity every time new data comes into the system – usually at the end of a sprint. Plans often allow us to appear more certain than we may actually be.  The hardest part with planning in Scrum is ensuring that everyone understands that things change and we will respond as soon as they do.  Effective agile planning allows us to more reliably respond to the changing business and market needs as early as possible.

Objectives:
In this talk I will discuss some of the techniques that I have used over the last couple of years to do release planning.  I’ll touch on of some of the things that have worked for me and some that haven’t.  The ideas will range from some simple maths, to reporting release progress through a release burnup and overviews, to the how to deal with change and ensuring that people understand what it means.  I hope by the end of the talk I will have shared some ideas and generated some conversation around controlling the chaos that can surround a software development release.

About Patrick Vine:
Patrick VineI started my career more than a decade ago at Microsoft in Redmond. Since then I’ve moved through different companies as developer, architect and manager in diverse technologies and industries.  I first started to dabble in Scrum a couple of years back while working at Yellowtail Software where I helped the roll out of Scrum. While there I gained an appreciation for how well you can manage software using Scrum.  I’ve worked on Fixed Price, Fixed Team, Fixed Budget projects. I am passionate about working with Scrum, learning more about software development and helping teams get better on a daily basis.

 

Sponsored by

Growing Agile