An agnostic agile journey of a team new to agile

A bigger, but packed with learning read on a real case of an agnostic agile journey, from scratch.


The team was new to agile, and to each other and the organisation. They were asked to develop a new mobile solution that would be used on board of airlines. So, regulatory / safety aspects. There was an external hard deadline, and the organisation had lost a year creating a hefty traditional business requirements document through another, traditional (expensive) team without delivering any product, not even for evaluation, and now there were only a few months left. In a business workshop it turned out that a lot of the requirements had become outdated or even obsolete. The need for the product and the external deadline had not changed, though. Neither the business division that was client nor IT management were very warm towards agile – they were convinced that “agile does not work here”. They were also not very open to change their old (micro) management habits……They knew however that traditionally they had never delivered in such a short time, nor three times that. And maybe if it did not work, they could get rid of agile. A win-win? An interesting, challenging journey was ahead.


The team started with Scrum, almost from the book, so an (incremental) iteration based approach, using the most popular agile framework. They had never experienced the Scrum events, neither had the Product Owner, ne to product ownership. It was only the second agile project in that enterprise and the first agile project in that important business division. But the organisation realised that waterfall would not fit the time line anymore, would be too risky and they wanted to put agile to the test in a second pilot, in very challenging circumstances.

The team started sprinting after the business workshop that created the actual user stories. So, here they were already adding to Scrum: user stories from eXtreme Programming.

The user stories were not randomly discovered. This process was guided by a technique called User Story Mapping from Jeff Patton.

As it was a mobile tablet solution to be used by stewardesses and stewards on board, so supporting a key aviation business process, User eXperience played an important role. So, UX practices were added, e.g. wire-framing, and UX was already explored in the business workshop.

The team actually did not just start sprinting: there were existing backend systems to interface with in order to get the latest data, interfaces to be built by traditional teams as they were under third party supplier contracts and these suppliers did not want to change their delivery method. There were some challenging dependencies both on the IT and business side. So, the team did a disciplined Inception, from Disciplined Agile Delivery (now DA 2.0), of no more than a week, including the business requirements workshop mentioned.

During that workshop the team used MoSCoW prioritisation -Must, Should, Could, Would- for initial prioritisation, an approach used in DSDM (Dynamic Systems Development Method), another agile method. MoSCoW was helpful, albeit simplistic, as the client was used to “just throw everything in” in waterfall style and had trouble making choices in priority – “requirement hoarding”.

The team also used WSJF – Weighted Shortest Job First- from Reinertsen and used in SAFe (Scaled Agile Framework) for further initial prioritisation at feature level, to find out where best to start.

This was hard external deadline with fixed partial scope, so relative estimation, from XP, was used but not enough. At the same time, traditional task estimation of everything would be very time consuming and wasteful, as what would happen during development would change based on discovery or external changes, like it had enormously in the year before. So an extrapolation technique was used, as described by Mitch Lacey. Relatively estimate the known backlog. Task estimate just a few high prio stories of different sizes. Then extrapolate. Then use good old project management techniques including risk management and dependency management to distribute the effort and estimate a landing zone.

The team realised they needed Continuous Integration to manage quality, another practice from XP, and set up a CI environment.


The team started sprinting. One of the first thing was creating interface contracts – a practice traditionally used- so that the third party suppliers could start developing the required backend interfaces. Until each delivered, the team would use mocking/stubbing and real data dumps. Delivering the interfaces first was no option, as the suppliers were working in a traditional way under a traditional contract and were not willing or able yet to adopt agile. Timeline only allowed for parallel development and careful dependency and risk management and synchronisation at sprint boundaries. Else 5+4 months would not fit in the 5 months hard external deadline.

While sprinting, the team soon realised nothing was burning down to Done and understood the cause: too many stories in WIP. From then on they stopped starting and started finishing in priority and limited WIP, a Kanban principle.

In terms of documentation, the team used the practices and guidance of Agile Modeling, part of the Disciplined Agile Framework, using the most suitable way to artefact, e.g. depending on whether it is a temporary or permanent artefact.

Change happened in next sprints, for good reasons. While the core of the product did not change, seeing the product increment, the business found features of higher value. The team embraced change and as the hard external deadline did not change, the team used the Change for Free principle from Jeff Sutherland, and the business took lower valued functionality of the same size out.

Throughout the sprints, the team learned and got better and better. Their approach also became leaner. They became more aware of the principles of LSD (Lean Software Development) and the 7 Wastes. They had been T-shaping to reduce the dependencies on individual team members and reduce internal hand-offs. They had moved from too much WIP with longer cycle time -a Kanban concept- to lower WIP with shorter cycle time. Also, instead of waiting for feedback at the Sprint Review, they had moved to frequent feedback and stories were OK-ed by the Product Owner as soon as the team though a story was Done. They did less task identification upfront at or before the Sprint Planning and had moved to task identification when a story actually got pulled into development inside the sprint. As an overall result, the sprint event events became shorter and more distributed. The team was moving more to a continuous flow and could actually release individual stories mid-sprint, if needed. Release on Demand.


The MVP (Minimum Viable Product)* – a term not in Scrum or Scrum-focus, actually – was achieved ahead of the hard external deadline, and the schedule that had the necessary risk buffer in such circumstances – the risk buffer was not used and contributed to new high value functionality. The team had accelerated and kept their zero defect policy until the very end. Business division management, new to agile, insisted on a UAT (User Acceptance Test) before the production release, despite the fact that acceptance testing had been done in the sprints and full integration testing had been done as soon as the external interfaces were delivered. The UAT found 1 issue (!), a minor one and actually an oversight on requirement side, which was fixed the same day. This showed that when end to end testing is done properly sprint after sprint, a UAT is not needed and actually a waste that could better be used for earlier release or more valuable functionality. The MVP+ was successfully released into production. Business division management was extremely satisfied. The business started to sell agile internally, demanded an agile delivery approach from external suppliers and started to work with the team on other products, soon using 1 week sprints. So this second agile project helped generate desire for a larger agile transformation, across divisions, which soon followed. The team (and coach) actually won a national award with the product, an award for best business application.

Lessons and Conclusion

There were lots of lessons. Teams that finish early accelerate faster – a Scrum pattern formulated by Jeff Sutherland – was something hat actually happened here. The team delivered every sprint on forecast and often above. Technical excellence and a zero defect policy from the start is key. Of course, business and IT integration and working as One Team is essential. On anything new in the complex space that software product creation is, change will happen and should be positively embraced. Importantly, you can’t sell away skepticism, fear or resistance: you have to demonstrate ability and actual results and use an oganisational change approach.

But there is a big, less obvious lesson: what would have happened if the team had stayed within one framework, e.g. Scrum or Kanban? Instead of actively looking for the practices that were needed to succeed in the challenge in the given (difficult) context? What would have happened if the team had focused on mastery of that framework first, before looking beyond and adding practices, patterns and principles from other agile frameworks? The team would simply not have accelerated enough to achieve MVP creation in time. The team might even have gotten dulled mentally, straightjacketed within one framework or disappointed in agile, and the business may have concluded that agile does not work in their company. Instead the team luckily adopted an agnostic agile approach, not brainwashed into a single framework, but coached on the practices they wanted to pull in, based on the situations they were facing. E.g. they needed to prioritise, so they pulled in MoSCoW and WSJF from DSDM and SAFe. When they saw they were not visibly burning down stories, they pulled in limiting WIP, from Kanban. They did not care about frameworks, they cared about the practices they needed. They “killed” the frameworks and freed the practices. And freed their minds – from thinking strictly inside the framework box. Give it a try!

Adrian Lander,
Agnostic Agile Transformation Coach and Executive Business Coach


25 comentários em “An agnostic agile journey of a team new to agile”

  1. Good article Adrian. However, the challenge in large organizations is lack of knowledge of methods, tools and practices and deterministic thinking and expectations of repeatability and predictability based on “Best Practices”. It’s easy to understand mechanics of Scrum, so most large organizations go for those easy pickings… until one day they die from competition before they could really transform.

    1. Hi Srikanth, thank you for that.
      I agree. I do not see the BUT.
      Yes, of course large organisations lack knowledge on something new, they have never done and which is actually complex and takes time and guidance.
      As this was both a (second) pilot and a key business product creation, we had to maximize learning in a sustainable way within the constraints of succeeding at delivery.
      Also learning and demonstrating by real product creation what is possible and even in a short time frame.

  2. Hi Adrian,

    Excellent Agile article!!

    I have seen many product development adhering most of the practices at some point but they couldn’t carry on as they did them all wrong and stopped.

    Pankaj Pant

    1. Hi Pankaj,
      Thanks for the great feedback!
      Yes, I often see that too: organisations that said that they would adopt agile, making their first steps, but halfway waterfailing back. Simply, as they are not applying the right practices, the right way at the right moment. Thereby they incorrectly thought agile was not working.
      Best regsrds, Adrian

  3. Great article, Adrian, and a good reminder that in enterprise contexts, agnostic agile will be an easier sell as it is value-driven rather than compliance-driven than any prescriptive framework or method!

    1. It’s not about selling as much as it is about delivering, Kiran.

      I would think of AA as an alternative way of thinking how to create meaningful results with the means at hand, without succumbing to the arbitrary constraints imposed by specific frameworks.

    2. Hi Kiron,
      Thanks for the great feedback!
      Indeed, agnostic agile is value driven. The frameworks are not central and not the goal.
      Best regards, Adrian

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *