agile development

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…

Next Stop Agile: All Change?

“Before we become agile, do we really need to change everything?”

I was recently asked this question by a client who is just starting on their agile journey.

The potential of agile to change everything often leads people to think that they have to change everything before they can become agile. Instead of seeing opportunities and potential they see obstacles and barriers, to the extent that they’re sometimes too scared to even dip their toes in the agile waters.

The introduction of agile values, and in particular agile practices such as iterative planning and backlog-driven development, will lead to changes in the quality and timeliness of the software produced. This in turn will provide you with lots of opportunities to improve other things such as organizational structures, communication channels, and funding procedures.

To get started there are a few things that definitely need to be changed. These will be focussed in three key areas:

  • Resourcing teams – the agile and iterative approach requires cross-functional teams. Testers for example will now be needed through-out the project, as will test environments;
  • Reporting progress – the regular iterative assessments can be used to replace monthly or other reports. There will be a switch towards concrete measures and away from “pseudo-measures” such as earned value;
  • Planning projects – projects will now be iterative and incremental rather than waterfall. The number and nature of the milestones will change, although you may choose to start your initial agile projects with a “requirements” phase and end with and “acceptance testing” phase. Note: the development will still be done iteratively with testing done every iteration - there will just be some priming of the pump before the iterations start, and some additional acceptance testing once the development is complete.

Once the teams have developed the capability to produce high quality software quickly and effectively, the door opens for even more improvements – in particular:

  • Just in time and just enough requirements – affecting the product owners, product managers and the business
  • Progressive funding models – affecting how you fund your projects
  • Agile contracts with suppliers – affecting your supplier relationships and contracts
  • Improved team cohesion and longevity – affecting line management and resourcing
  • Agile business change – affecting business projects and business programmes
  • Tools and infrastructure – affecting licensing and environments

And finally, opportunities are opened up for an agile organization, with further improvements to:

  • Line management
  • HR
  • Governance
  • Organizational Structures
  • Company Culture

It is always a good idea to brief all the management and business people involved in the projects and teams as they will be affected by the initial round of change, and will benefit from seeing the opportunities that an improved, agile, software development approach will provide.

The good thing is you don’t need to change everything at once, or even at all in many cases. Personally I would always bed in the first round of changes before worrying about the second and third lists of things. This approach values individuals and interactions over processes and tools, as it enables the development teams to improve without dictating to the other parties involved in the business. Once they see the opportunities opened up by agile development practices they will also want to embrace agility and improve their own ways of working.

The Journey Toward Self – Organizing, Self-Directing Agile Teams: The Role of the Agile Coach

The agile ideal is for a team to be composed of equals, peers who neither direct each other nor oversee each other, but who work collectively toward a common goal. Team members are self-directing in the sense that they, seeing the goals of the team, choose to work on things for which they are most capable. Since many teams start from a traditionally managed, externally directed world, the journey toward this idea takes time and adjustment for everyone involved. A team typically cannot become instantaneously self-directing.

Typically the journey is assisted and facilitated by a coach who helps the team learn new techniques and overcome barriers. The very existence of the coach suggests that the team is not wholly self-directing, at least not yet; the coach will naturally provide some direction to team members during the learning process. The degree to which the coach will "direct" depends on the progress the team has made toward becoming truly agile.

A typical problem is reflected in a recent question raised by a client. We recommended use of a particular newer framework (SOAJ) in place of the Hibernate/Spring framework familiar to the team, based on our understanding of the goals of the project and the skills of the team; in short, the new framework would reduce coding and increase code quality while improving performance. Some team members felt more comfortable with their familiar framework, however, and the team was divided on the use of the new framework. If the team is self-directing and self-organizing, who makes the decision in the event of a split decision?

It often falls to the agile coach to make these decisions. The coach generally has greater experience and is better equipped to make the choice when the team lacks experience. Coaches must be careful not to become dictators, however benevolent, and teams must take care not to become over-reliant on the coach. Over time, the incidence of coach intervention should decrease as the team gains experience and confidence.

Coaching is more than mere facilitating new practices: there is always an element of leadership in successful coaching engagements. Teams learn best by doing, and the coach must lead by doing as well. Over time, team members step forward and the coach steps back until, one day, the team is leading and directing itself. At first, however, the coach takes more of a directing role.

Page 2 of 212