Both require adopting a philosophy based on rehearsal, consistency, and focus not on the process but rather on the value that can be built for the audience or, in our case, the client.
Sergio Pozzetti, Agile Coach @SISCOG | 7 min read
___________
Dancers require years of practice, strength, grace and an incredible amount of coordination and control to become technically good. What is becoming great? It is mostly being technically consistent over time, so that the expression of one’s humanity flows through seamlessly while dancing, and the connection that is made is not through coordinated movements of the body, but rather through emotion and expression of those movements.
Take the Grand Jeté for instance. One could say it means to perform a split mid-air. However, maybe a better description is to perform the split remembering to reach its full expression at the height of the jump with the body weight pushed slightly forward. More detailed and step-by-step descriptions exist but are pretty much useless to our point: the great dancer will do it as a second nature. Consistency and having performed thousands of those jumps will pave the way towards moulding the dancer’s thoughts into flying, surmounting a precipice or expressing bliss. The process will no longer be the focus.
Agile as a philosophy
Pretty much anyone can adopt a process, apply it with perhaps a touch of this-is-not-really-necessary here, a sprinkle of anti-pattern there, mix it all in a cauldron with plenty of we-have-always-done-it-this-way and claim to be Agile. Like a recipe, if we diligently follow the required steps, our end result is supposedly guaranteed. Or music. Having chosen an instrument, if one learns musical notation, understands mathematically time signature, pitch and every other element written on the staff along with how to map them into the mechanical movements required to produce sound, no reason for not becoming a great musician, theoretically. Except for the fact that culinary arts and music have something in common: the central dependency on human factors. In all probability your first coq-au-vin will end up being bland, overcooked, stringy and chewy. Most likely, and with enough perseverance, you will learn to play an instrument but you will sound flat, unemotional and pale. Unsurprisingly, it is the same with methodologies belonging to the Agile spectrum. This is why becoming Agile should be, right upon its inception, considered first and foremost a human-centred challenge. This is why it is primarily considered a philosophy encompassing a different way of thinking. This is why at SISCOG we are not concerned with adding in a roadmap a milestone on becoming Agile that has to be checked at some point in time, but instead recognise each baby step we take is an evolution towards being consistently able to perform the Grand Jeté and focus on the value we built, rather than on the recipe we followed.
The Agile Manifesto
The renowned Agile manifesto is comprised of four foundational values and twelve supporting principles which make for some very interesting reading given all methodologies under the Agile spectrum apply them in different ways towards a common goal which may be summarised as iteratively delivering high-quality, user-centred working software through highly productive and motivated teams engaged in their continuous improvement.
As interesting as this sounds, and as much as all of those precepts should become an Agile practitioner’s mantra, we will use situational, archetypal stories to illustrate the mindset we are incepting. At the inception stage it is imperative that we look at people, teams and principles first, and at methodologies second.
Story 1: An informal chinwag at the watercooler:
“- So, we’re trying to have the client really adopt the new tool as soon as possible, because we believe in the end it will be a win-win.
- Excellent, so given this urgency, have you touched based with the client yet?
- No, we need to set up a meeting for that, but as long as we’re doing it, we may have to prepare the meeting a little better.
- That could make sense, do you need help setting up a demo?
- I was thinking we need the senior architect present, and perhaps someone from quality assurance just in case. Also, the version we have is not stable, I’d rather we just show PowerPoints. And this could take a while. I’m not sure we have a Jira card for that. And come to think of it the senior architect is on holidays.”
And through the wrong mindset, the opportunity flew away in seconds. It became more important to have a card encapsulating the required preparation work, to have more people present than strictly required, to build inexpressive PowerPoints rather than stitching whatever is required to make the demo version stable. In short, processes and tools prevailed over individuals and interactions. This is a classic Agile anti-pattern. Not that a proper set-up is not important, but it should never triumph over getting the job done, which could be one video-call away.
Story 2: Switch to the development of a business-critical software feature. It is going through the last iterations and generally looking promising. After every short iteration software is being delivered but all of the sudden, in the last demo the client informs of a structural change in their business rules. However, the project manager decides to hold the delivery of this change until all supporting documentation, including the contract, are up to date with the requested change. It is not that proper supporting documentation and contract negotiation is not important, however it should never be a priority over client collaboration which, in a user-centred world is the swiftest path towards firstly and fully understanding the needs. Analogously, holding deliveries because of a disrupted plan completely obliterates the responsiveness to change which is not only key, but expected in this new age. Taking the metaphor to another level, planning is vital, if you are willing to throw away the plan soon afterwards. Your plan is only as good as your ability to change it.
Story 3: “Working software over comprehensive documentation” actually becomes a no-brainer when you think about the aforementioned three principles we exemplified. Let us summarise: We want to favour personal interactions, collaborate and co-create with the client and be responsive to change, because change is inevitable. So, we reached the point when we are delivering an important software increment. It encompasses features which are crucial to going to production. A call from the client surprises us:
“- We need the technical specifications, updated governance matrix given the new user class who will be using the feature, user manuals, updated quick guides and the detailed design documents for this update.
- Yes, those deliverables were deemed to be not critical for the go-to-production, therefore in order to meet the deadline, even if it means having the update running in a staging environment for your own testing, we decided to take it in as technical debt for the following iterations.
- Unfortunately the business requires those documents before we go live in any environment.”
And we fall, head-first, into another well-known Agile anti-pattern: tunnel vision set on having each checkbox checked, rather than evaluating what can be done first to get early feedback and early exposure.
Being Agile about becoming Agile
The global industry is going through the age of the client. There is no more room for detailed specifications and stonewalling plans upfront unless the requirements are completely crystal clear to every involved party as well as immutable, which in software development is close to utopian. There is no more room for the near-sightedness of single-sided solution development. Collaboration and co-creation with the client are the foundation to meeting user expectations because they are instrumental to identifying unmet needs and, as a joint team, categorising development fronts and prioritising thereby identifying minimum viable products – or more generically, minimum viable developments on which we then iterate. There is no more room for being afraid to experiment, change is the best defence to ensure constant client satisfaction.
Becoming Agile is a collective effort within the company and with our clients. And while we know we have a long road ahead, we at SISCOG are not rushing the adoption of any specific methodology, but rather being Agile about becoming Agile: inspecting and adapting, constantly. And while our Grand Jetés may not be perfect yet, we have already performed quite a few and will continue to do so.