Iterative Sprint Planning

I’m encountering a recurring theme in my agile coaching. Some organisations have a sharp divide between their business and IT functions. This always spins off a twin-track coaching path for me: on the one path let’s try and address the fundamental root cause of the dysfunction/divide and on the other path what can we do to ameliorate and get around the problem in the short term?

So far my experience is that most of the symptoms of this issue are revealed via the Product Owner role. Sometimes business folks just don’t understand the basics of either software engineering or software economics. It’s just a simple inevitability of the organisation and experiences/skills their career paths have taken them on. So they can be experts of the business domain, but appreciate none of the pain and realities of software development. That is not a trivial problem to solve and will likely take a lot of effort and time. So in the meantime, what should we do to minimise the impact? Well, for sure, this is going to depend on all sorts of factors surrounding what exactly the problems are being created by having Product Owners with no software experience.

I’ll describe what I have found works quite well at one particular client in regard of one slice of this overall challenge: Sprint Planning.

The difficulty faced by the agile teams was that the allotted time Sprint Planning was always reached before any kind of commitment to the content of the Sprint was close. On closer examination, there were (as so often is the case) a number of contributing causes for this and all need attention. As well as the common issue of developers being uncomfortable with the relative sizing of backlog items without knowing almost every line of code impacted (they may have got bitten in the past), the thing that seemed most acute was the compounding problem of unclear requirement. With the lack of an empowered and embedded full-time Product Owner, it was perhaps inevitable that even well-formed User Stories were insufficient in getting a shared understanding of the requirement to the agile team(s). In this circumstance, we have used a Business Analyst as a proxy Product Owner with regard to backlog generation.

Scrum and similar methods describe the Sprint Planning event in some detail. They suggest a planning meeting of around four hours per two-week Sprint. There is also a recommended ≤10% allowance in the Scrum Guide for backlog grooming and refactoring by the whole team. By converting that ≤10% grooming into more structured events, we are finding it much easier to contain the planning to the suggested time boxes. The structuring consists of three iterative parts to Sprint Planning:

  • GET-AHEAD sessions. The proxy Product Owner meets regularly with business (and other stakeholders) to discuss upcoming requirements a Sprint or two ahead of when the requirement needs to be delivered as a backlog item/ User Story. By starting these meetings ahead of the Sprint execution, it gives the diverse stakeholder community the opportunity to address issues and questions raised concerning the requirement. Typically, this was left until the Sprint Planning meeting previously, giving no time for issues to be analysed and answers to be gathered. This not only gummed up the Sprint Planning, it also blocked the subsequent Sprint execution. The agile team need not be involved in the GET-AHEAD sessions (it isn’t an effective use of their time) – this helps reduce the overall amount of time that the team spends in planning sessions.
  • CONFIRM sessions. Once the proxy Product Owner has established the requirement to a comfortable degree, the backlog refactoring would continue by discussing the requirements with the team. By this stage the requirement is largely understood by the proxy Product Owner so whilst business stakeholder attendance could be useful, it wouldn’t be mandatory. Discussions in the CONFIRM session are generally more technical and where the Product Owner is not of a software background, this is of limited interest to them and not a great use of their time. Whilst the proxy Product Owner would be able to answer most questions that the team would have, sometimes more questions may be raised and these are taken back to the next GET AHEAD session (hence the process is iterative). Typically relative sizing of the stories (through planning poker) starts in CONFIRM sessions but not task decomposition.
  • COMMIT sessions i.e. the Iteration Planning Meeting itself. Once the major issues have all been resolved in good time, the team can confirm the story content and sizes, do task decomposition and estimation, then commit to the delivering the work in the impending Sprint.

By following this process in an iterative way (just enough planning in just the right amount of detail), we have been able to get much more meaningful Sprint Plans produced just in time. There is still some way to go to get this working in an optimum way, but we have reduced one major impediment and can now move onto tackle others…

The Ship of Theseus

Readers from the UK mainly may remember the “Trigger's Broom” scene from Only Fools and Horses. Trigger claims he's been using the same broom for 20 years - but then states that it's had 17 new heads and 14 new handles in its lifetime! Some of the more philosophically aware among you may recognise this as Theseus' paradox or the Ship of Theseus. The question of course being: does an object which has had all its component parts replaced remain fundamentally the same object? What am I talking about you may well ask? Well, whatever your take on this particular paradox there is certainly a way we can apply this to the idea of teams and their agile maturity.

Consider a team of 5 who are developing a product. They are all new to this agile way of working but very much bought into the principles. After a period of intensive coaching they begin to display all the correct behaviours and, as such, demonstrate marked improvements over time in their delivery frequency, quality of delivery and general productivity – not to mention team motivation and morale. This team become, in fact, so good that they are soon completely autonomous (within the constraints and scope of their specified objectives) and are soon left to their own devices. The proof of their ability is, after all, apparent in the satisfaction of their customers and the quality of their product.

At some point, for no specific reason, one of the team members leaves and is replaced. Shortly after this the team lead is moved over to take on a struggling project and a new team lead is brought in. Two out of five of the original team have gone. Perhaps then a further team member is also swapped out for someone else. Now the balance has shifted and less than half of the original members remain. There is no guarantee that these new members are bought in to the good behaviours displayed by the original team but because the team has always been so successful they are left to continue with no intervention.

At what point is this team no longer the original, established and successful team? At what point should someone intervene to ensure the new team members understand and can adopt the previously embedded behaviours? If this is now a different team should it be treated as such and be given the attention and support that any brand new team would be given when forming and establishing its practices? If nothing is done until the effects are seen, for example in a drop in quality or productivity, then this is too late. At that point the bad habits have already crept in and, it's a lot easier to give up biting your nails if you never started in the first place.

Trigger's broom was not the same broom and a team where the majority or all of the team members have changed over time is not the same team. The onus is on good management to recognise the implications of these changes and ensure new members are introduced to the team's proven ways of working, behaviours and culture from the moment they join the team.

Giving Empowerment or Taking Autonomy – Part 2

Read Part One here.

Let’s explore another aspect. Imagine an individual or team where the desire for autonomy or empowerment does not exist. This may sound unlikely but there are more examples of this out there than you can imagine.

In a traditional command and control organisation, dependent behaviour for long standing employees is often ingrained into each employee’s behaviours. In fact, if you are an individual who craves independence and self-determination then you are unlikely to become a long standing employee at this traditional command and control organisation.

This behaviour manifests itself as more individuals, who want to be told what they need to do, when they need to do it, are brought into the organisation. These individuals do not want to be responsible for making decisions about how they should work, when they should work and what tasks they should be performing.  By no means am I condemning this kind of behaviour. The “mechanics” of a team can be very important and as long as they participate to a certain extent in the team “independence” then their ability to complete the tasks they are given can be extremely beneficial. Read More

MoSCoW Anxiety

According to Wikipedia MoSCoW is a prioritization technique and a core aspect of agile software development. Its purpose is to focus a team on the most important requirements, for example to meet a deadline.

I know of many project teams that struggle using this technique because their stakeholders are unwilling to do the prioritization or accept the technique itself. If you have participated on a project where all requirements were classified as must have, I am sure you know what I mean.

What can you do when this happens to you? Well, valid options that might come to mind are run and hide and performing a coup for a decent Product Owner. However, before you go to extremes you might want to try another option first.

Basically what we have here is a kind of anxiety, MoSCoW anxiety if you will.  Anxiety? Yes!  In my experience many stakeholders simply become afraid they will not get what they have asked for when they are asked to classify requirements below the must have level. This makes perfect sense when you reckon that many projects deliver only a (small) part of the promised functionality and a lot of stakeholders have felt let down by IT at least a number of times. Read More

Giving Empowerment or Taking Autonomy

Part One

I’ve been working as an agile mentor for a few years now. (This is a mentor of agile software development teams, not a mentor of all things bendy – just so we’re clear.) In this role, I’ve built up a fair amount of experience in helping teams overcome technical /process problems and I’ve recently become interested in the softer side of agile software development teams – the psychology behind agility.

It all started when I watched a video on YouTube “The Surprising Truth of What Motivates Us” which is a summary of the book of the same name by Dan Pink.  By pure coincidence, on the same day I watched the Youtube video, I read  some review comments on a paper that debated whether the term “empowerment” or “autonomy” should be used when talking about the goals for true agility. It was an interesting discussion and it made me question some of my previous assumptions.

The first question is – what is the difference between autonomy and empowerment? A colleague said that in the simplest terms empowerment is given whereas autonomy is taken. If you look at definitions of the two words in the simplest form, they are:

Autonomy - the power or right of self-government

Empowerment - the giving or delegation of power or authority; authorization

Read More

TUP Event – An IJI Day in Beijing

Dr. Ivar Jacobson was invited to present the keynote at this year’s TUP conference held on December 10, 2011, in Beijing, China. TUP (Technology/User Experience/Product) includes a series of events hosted by CSDN, the biggest IT community in China. The speakers invited for these events are famous IT experts; and attendees are IT and management people who are interested in IT product development.  I was very pleased to present lean and agile development sessions along with Dr. PanWei Ng at the conference. With three IJI members presenting it became an IJI day at TUP 2011.

Dr. Jacobson presented “Liberating the Essence from the Burden of the Whole: A Renaissance in Lean Thinking”. Ivar’s lively and TUP Event   An IJI Day in Beijingengaging session clearly demonstrated to attendees the new reasoning around lean and that to stay lean you need to stay lean from the beginning of a project rather than trying to eliminate waste later.  By presenting three case studies representing business, software product and process method, Ivar demonstrated the concept of a “kernel” --representing the essence of something as a good starting point for most things you build.  You start lean and you stay lean throughout the life of what you build.

Read More

Growing a Coaching Community

We’ve probably all been there at one time or another in our careers. We knew that change within our organisation had to happen. We were careful and we sought input before creating our plan. With careful consideration we built a plan that encompassed all our critical stakeholders; our budget was approved by management and our first critical new changes were implemented successfully.
Great first signs – right? But wait…our plan begins to die before it even takes off. Key stakeholders who appeared to be onboard are now complacent. And perhaps even worse, they are becoming large barriers to the success of the project.

Can it be turned around?

Implementing corporate change can be one of the toughest challenges for large organisations. Software development departments that want to scale their agile projects often run into this obstacle. The agile project that may have been extremely successful within a small team or department begins to crack and fall apart as the organisation attempts to scale Agile.  Read More

An Evening for Sharing Ideas with Friends

On the evening of November 14th, Ivar Jacobson International hosted an evening of camaraderie for our friends: staff, former colleagues, customers and partners at our office in Kista, Sweden.

It was an evening to share our experiences and update our guests on IJI’s recent activities and developments.

Ivar Jacobson, Svante Lidman, Graham Marsh and I presented IJI at the event and presented topics ranging from Scaling Agile to our new Use-Case 2.0 that our customers are currently using.

Svante Lidman presented an engaging and interesting presentation called “Learning’s from Large Scale Agile Transformation”. Svante discussed how a large client with thousands of developers and a large legacy system who was following a waterfall approach to software development is now making a successful transformation to becoming more agile.

Ivar updated attendees on Use-Case 2.0 (read Ivar’s previous posts for more info on this topic) and also presented Semat and Liberating the Essence from the Burden of the Whole: A Renaissance in Lean Thinking.

If you would like to be on our mailing list to be invited to one of our future events, drop me an .

Agile Grows Up: Agile Business Conference 2011, London

Another week, another event! This time it was the turn of the Agile Business Conference in London. It was encouraging to see an excellent turn out for this 3 day event, and an overwhelmingly positive attitude from delegates, speakers & sponsors. The thing that most struck me about the whole experience was that agile software development really is breaking out and growing up. This was a conference not just for people wanting to know what it’s all about and how to get started, but for people that want to improve and grow, and use agile in ever more complex and challenging environments. But in the words of the famous american baseball player, Casey Stengel: “The trick is growing up without growing old”....let's hope the agile movement is not just another fad in the development of the software engineering profession.

Quotation source:

Making the Next Wave in the Agile World – Finding the Kernel of Software Engineering

The 6th annual Agile China was held in Beijing from September 1 – 3, 2011. Agile China is a summit of agile world enthusiasts gathering in China. For the past five years, it’s attracted world-class agile experts, such as Martin Fowler, Kent Beck, Dave Thomas, James Grenning, and Mary Poppendieck et al, and tens of  thousands of attendees across China and overseas. It represents the highest level of development and adoption of agile development in China.

This year’s conference proved to be another successful event. The three-day event was packed by some 700 attendees. The conference was opened by Mr. Wang Jun, General Secretary of China System and Software Process Improvement Association, the host of the conference, and keynote by Linda Rising, the authour of “Fearless Change”, followed by parallel sessions on agile training camp, agile new trend, and agile testing and quality control. People gathered to share their experience and to explore new ideas and  trends. The conference atmosphere was full of energy and excitement. Particularly, I truly enjoyed the free style of discussions and presentations – in a real agile spirit. Read More

Page 2 of 41234