Building Good Teams

Alpha State Cards in Practice: Experiences from an Agile Trainer

Having had the opportunity to incorporate the Alpha State Cards within some recent training classes I have been delighted to see the enthusiastic reaction they receive. The cards are great at bringing what can sometimes be complex and difficult concepts to life and making them of real practical value to people.

In each Agile training class I deliver now, I use the cards to support an exercise that challenges the groups to determine the current status of a sample software development project. In the discussions afterwards, the groups have consistently reported:

  • They were really impressed on how the cards enabled more effective team communication and collaboration
  • The cards demonstrated in both a tangible and visual way that significant progress was being made, as the Alpha State Cards made it quick and easy to cut through the “noise” to the heart of what mattered
  • The whole experience showed how quick it was to come to a useful conclusion and each group found it an enjoyable way to work

When asked how the cards might support other team activities the feedback included the following:

  • The cards offer a great set of objectives to assist with task identification, task planning and  prioritization activities
  • The states on the card provide a basis for simplifying governance objectives and evaluation criteria, as well as making the whole process leaner
  • Revisiting the card abacus during iteration reviews to demonstrate iteration progress from a state perspective
  • They recognize the ability for the cards to advance and retreat along the abacus, to reflect significant change impacting one or more Alphas

I get a lot of satisfaction from using the cards in these courses as they really act to break down the barriers early in the course by helping the attendees to relax and to build their confidence working collaboratively together. They also gain a sense of experiencing something not only new, but highly effective too, and something they can easily apply back on their own projects to add value and improve ways of working.

For me as a trainer and coach, the cards significantly contribute towards an enhanced learning experience, and in so doing, increase the knowledge retention for the key learning points. The bottom line is it’s best to use the cards in a group situation to truly appreciate their value.

The Alpha State Cards, games and further guidance is available here if you want to try them yourself.

Also there is now a Alpha State Card LinkedIn group which is a great place to share ideas & ask questions about using the cards.

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.

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

Countdown to the 2010 Olympics

Countdown to the 2010 OlympicsI noticed the other day on my local newscast, that the opening ceremony for this year’s Winter Olympics is only a few weeks away. The newscast showed a sports team working together, training to win one of the most coveted prizes in their career. As per Wikipedia, team sport refers to sports where players interact directly and simultaneously to achieve an objective.  When we put this at an Olympic scale, it combines 10,500 competitors from 204 countries. The stakes are high, preparation and training is intense and the cost of failure has tangible and not-so-tangible results. This newscast made me reflect on IJI’s daily interactions with IT teams and I had to conclude that perhaps the similarities are quite strong. Olympic athletic teams, like IT, which includes the study, design, development, implementation, support /management of computer-based information systems, particularly software applications, is all about working together to achieve one same goal, either win the medal or in the case of IT have the software work seamlessly within an organization. Both teams consist of individual experts working together for a common goal to be the best. The stakes are high in both cases and the costs are equally high with real tangible dollars tied to wins or failures. Read More