With a wide range of Agile frameworks, models, tools, practices, values and principles to choose from and a highly complex organisation full of existing culture with its own values, prejudices and expertise, it can be hard to know where to start with a large scale Agile transformation.
Starting with a two person audit to:
- understand what the organisation hopes to achieve,
- what its value streams are,
- how agile the organisation wants to be,
- interviewing staff,
- reviewing processes
- finding the pain points
can provide an understanding of the current state and where the ambition lies.
Then, depending on many factors, such as current expertise, ambition levels, and reason for the transformation, the next step might be to choose a framework and start to implement it.
The frameworks of choice are a Kanban implementation, Scaled Agile Framework, Disciplined Agile Delivery, Large Scale Scrum (LeSS) or build your own hybrid.
As a Certified SAFe Program Consultant (SPC), my immediate choice was to look to SAFe for the framework, but SAFe has some gaps in its implementation, for example, it is assumed that projects are already in flight.
My client was starting a whole new set of product streams (8 per month) and therefore needed some sort of ramp up with regards to architecture, process, business validation, training, alignment and capacity, and of course an Agile framework to run the projects in.
One of the constraints for the client was that all product streams had to go through a number of steps and reviews before being allocated to either external service suppliers or outsourced development teams.
This is a 3 step process of:
- Prove business case (The what)
- Create Architectural concept, alignment and engage suppliers
- Perform high level planning and finalise supplier commercials.
At each step, there was a sign off from various boards and senior management.
The challenge was to reduce the overall cycle time of the initial stage, by time boxing it and limiting work done in both architectural and planning artefacts (inventory) that hang around waiting for development to start.
As a certified Yellow belt in DAD, I reviewed the Inception phase of DAD to see how this could be used to define the level of planning and architectural modelling. According to Scott, the average time of inception on projects is roughly 4 weeks. This suited my client well – so this part of DAD fitted nicely into our hybrid framework.
There were large architectural documents, sometimes 70 pages or longer, were replaced by whiteboard modelling and diagramming – as defined in DAD. This is where DAD really excels and provides architectural guidance, which other frameworks lack.
One of the pain points for the client was heavy governance requiring lengthy delays to produce documentation to put code live into production. Some of the steps as part of the governance was to include business people who ran the services on the ground (outside of IT). Using the DA model of having formal inception, it was very easy to include these people into the Inception phase and throughout development to ensure that collaboration and transparency allowed the necesary risk reduction and alignment to significantly reduce transition and deployment time, remove formal gateways, and to get working software to customers quicker.
After inception, we had Construction. Taking the Kanban principle of start “wherever you are now”, we kept the development teams as they were. With developers, a product owner, a package manager (read Team Lead in DAD, Scrum Master in SAFe), and an architect, we could see that the team now looks more like a DAD team than a Scrum or SAFe team.
The people missing from the DAD team were the stakeholders. With a large number of teams sharing stockholders, such a service directors, environment / release managers, support staff and customers, we needed a way of working out capacity dependencies between these people and the teams.
With a large number of dependencies between teams, in some cases with teams working on the same code base, it made sense to have a team of teams committing to the same features and goals.
Adding the Release planning activity from SAFe meant we could align all of the teams and individuals across the program and produce a feature mapping story board with dependencies and a commitment from the entire team of teams.
Once sprinting had started, all of the stakeholders could view and demo their deliverables as a cohesive team of teams to ensure the incremental slice of value could indeed be made live if desired. For example, the service readiness teams now work alongside the developers and present at the end of sprint demos to show how the increment met the criteria for service readiness.
Using ideas on Architectural governance from DAD, we used pull based metrics that do not incur time penalties on the teams and aim to support and guide the teams on best practice and quality rather than try to command teams to do better. Governance hopefully should become self-governing with a small amount of guidance around best practice.
Initially there was to be a large release time because of the client’s process and lack of automated deployment, and the sometimes lengthy service readiness process meant that a transition phase would be required.
Looking at the goals of this phase in DAD we see:
- Ensure the solution is production ready
- Ensure the stakeholders are ready to receive the solution
- Deploy the solution to production
The first one should be taken care of mostly during construction cycles as we had all of the people involved right from release planning.
The second one may come into play according to my client’s context because of the training and extra readiness required in this domain.
The third goal we are working on to reduce this time as better automatic deployment is created.
We will also collect feedback in a SAFe inspect and adapt style retrospective as well as results from the services about how objectives may have been met and also customer satisfaction (delightedness). Using elements from Lean and Kanban the whole processes cycle time can be measured and improved with visibility on where the work is getting stuck.
During the transformation and for some time to come (possibly forever?) we will maintain a transformation backlog to lead the improvement of the process, as well as a set of communities of practice around domain, process and technical learning. We can then focus on the bottlenecks and drive these out as capacity allows.
In conclusion, our client now has a mostly DAD implementation with a SAFe team of teams working together for alignment.
SAFe and DAD can work really well together. There are a number of architectural advances that we will need to make and I will be addressing these in my new book on Enterprise Agile Architecture.
My client’s name has been kept private for confidentiality reasons.
Learn more and get certified!
Learn more about creating a contextual approach for enterprise agility on our highly-impactful and certified agile training courses in London and online.
Read next: What Are The Scaling Agile Frameworks and How Are They Different?