Reflections on being agile, before Agile was a thing

In this post I pay tribute to the achievements of an extraordinary team and reflect on what our experience, years before Scrum, XP and the Agile Manifesto says about the state of Agile today…

Like many before it, this particular project had all the potential to be a disaster. In 1993 document driven waterfall was the default approach with Big Design Up Front and all the testing at the end. And yet it was a great success, delivering a suite of innovative application software, on time with amazing quality and to industry acclaim. So why did it succeed when so many were failing? What were we doing differently?

Back then, we didn’t have a team board or daily stand-ups. We sat together and would talk often about what we were doing, how it was going and if we were struggling. When necessary we would pair up to solve problems. We were all fanatical about C/C++ and Object Oriented Analysis & Design. Ideas were white-boarded as a team and we would take turns to study and present design patterns to each other.

There was no build or test automation. We were just one small team and would manually pull each other’s changes as soon as they were committed, incorporating them into our individual development and testing. SourceSafe didn’t support branches, forcing us all to work on the mainline/trunk. Consequently, bugs and broken builds were quickly spotted, communicated and fixed as a matter of pride (or shame!). We had no testers and in addition to testing each other’s code as we went, we would all test prior to a release.

We didn’t have a backlog or use User Stories. Thankfully we were able to collaborate directly with a first class domain expert and resident user of the tools we were creating. We could discuss and understand the requirements with the minimum of fuss and documentation. Our project plans were kept simple, mostly a hand sketched outline on one side of A4. Just sufficient to set our stakeholder’s expectations, but leaving us enough room for manoeuvre. Beneath this we took a prototyping approach, exploring technical risks and enabling our domain expert to validate new functionality quickly. Because of the team’s discipline and technical skill, these ‘prototypes’ were of shippable quality.

We didn’t have time-boxed iterations or retrospectives. If people thought of better ways of doing things we would discuss them. Every Friday we would have lunch at the local pub and reflect on our week and chat about whatever. People would be gently ‘ribbed’ for their screw-ups and we would celebrate our achievements.

We were not a self-organising team. We were directed by our Team Leader, an exceptional individual with considerable technical ability. This enabled him to assemble a highly competent team and provide a strong architectural vision. Technical excellence aside, he nurtured a culture of curiosity, commitment and openness. He led by example, sharing his knowledge and giving us courage that the task was achievable. Whilst doing much of the ‘heavy lifting’ he also shielded us from the nonsense surrounding the team, in what was a very mixed up organisation.

It was challenging work but this experience showed me that software development could be successful, satisfying and at times even fun. With hindsight, the key factors contributing to our success are clearly visible and familiar:

  • Customer collaboration enabling us to “build the right thing”
  • Engineering discipline and excellence enabling us to “build the thing right”
  • Incremental delivery enabling better risk management and stakeholder engagement
  • Great leadership nurturing a team culture of openness, collaboration and learning

So what can this experience tell us about the state of modern Agile? Out of curiosity, I tried to mark up Christopher Webb’s epic “Agile Landscape v3” (shown above) with the practices that I believe contributed to our success, and that we would have identified with at the time. The only one I could find, before giving up with a headache, was “Onsite Customer”. The behaviours described in my story, as well as the four key success factors, aren’t represented on ‘the landscape’ anywhere. I’m not saying we wouldn’t have benefited from many of the practices illustrated, just that we didn’t actually need any of them to find an effective and more agile way of working.

Over the years, the mind boggling proliferation of Agile methods and practices has prompted many to try and bring people’s attention back to simple principles and values. This reflection, on a team being agile long before it even had a name, underlines the importance of keeping sight of what truly matters.

What does your team value?

We all want to be able to do a good job and get paid, but what else is important to us? Is there any value in sharing this with each other? I discovered that talking about this together had a surprising benefit.

A while ago I learned how helpful it can be for teammates to take a little time out to discuss what really matters to them, as individuals and as a team. We all want to be able to do a good job and get paid, but what else is important to us? Is there any value in sharing this with each other? I discovered that talking about this together had a surprising benefit. Recognising common values led to a greater sense of connectedness within the team. Recognising values which were not commonly held, and were causing frustration for some team members, led to greater understanding and empathy. The simple list produced from that discussion became our Team Values and marked the beginning of the team’s journey towards self-awareness and greatly enhanced performance.

Bringing everyone to a common understanding of what a particular competency means is the first step in enabling the continuous exchange of meaningful feedback within the team.

Since then, I have applied this learning to discussing the competencies that matter to the team. To help this discussion I like to use the cards (shown above). Each one has the competency name and a brief description on the front and some example behaviours on the back. Teammates can pass them around, talk about their relevance to the team and ultimately vote or in some other way select the ones they think most important. In addition there should be some blank cards, to allow the team to come up with their own competencies as they wish.

We go on to establish team agreements around the other aspects of our competency feedback process e.g. cadence, conversations and inspection point, however I believe the discussion around competencies is of value in its own right.