The book An executive’s guide to disciplined agile – Winning the race to business agility written by Scott W. Ambler and Mark Lines give a good overview of Disciplined Agile.
Disciplined Agile (DA) provides light-weight guidance to help organizations streamline their Information Technology (IT) and business processes in a context-sensitive manner. DA provides the process foundation for business agility.
There are seven principles to highlight the discipled agile mindset: delight customers, be awesome, pragmatism, context counts, choice is good, optimize flow and enterprise awareness. To stress the ability of being disciplined there are additional principles: master your craft, technical excellence, collaborate, measure wisely, transparency, lean continuously, purposeful experiments, deliver continuously, visualize workflow, whole team, stable team and trust and respect.
DA consists of four parts (and are covered in chapters 3-6, the main part of the book):
- Disciplined Agile Delivery (DAD). DAD addresses all aspects of solution delivery
- Disciplined DevOps. This is the streamlining of IT solution development and IT operations
- Disciplined Agile IT (DAIT). DAIT addresses how to apply agile and lean strategies to all aspects of IT
- Disciplined Agile Enterprise (DAE). DAE is able to anticipate and respond swiftly to changes in the marketplace.
Within DAD we see the following roles:
- Primary roles: Stakeholder and Team roles (Team lead, Product Owner, Team Member and Architecture Owner)
- Secondary roles: Specialist, Independent Tester, Domain Expert, Technical Expert and Integrator.
The non-prescriptive DAD lifecycle consists of three phases inception, construction and transition. There are several versions of this lifecycle:
- Agile/Basis lifecycle based on scrum. This lifecycle starts with the inception phase where modelling, planning and organization takes place and the initial backlog and release plan will be created. The other phases are similar with the Agile continuous delivery lifecycle (see below)
- Lean/advanced lifecycle based on Kanban. This lifecycle starts with the inception phase where modelling, planning and organization takes place and the initial backlog will be created. The other phases are similar with the Lean continuous delivery lifecycle (see below)
- Agile continuous delivery lifecycle: a single permanent agile team using Scrum giving a continuous stream of development (construction phase), released at the end of each iteration (short transition phase) and no need for an inception phase
- Lean continuous delivery lifecycle: a single permanent agile team using Kanban giving a continuous stream of development (construction phase), and short transition phases and no need for an inception phase
- Exploratory lifecycle based on Lean Start-up. This lifecycle starts with Envision, followed by Build a little, Deploy, Observe and Measure and Cancel or Productize the idea. I would say this is not a complete delivery lifecycle. To productize you have to use one of the other lifecycles
- When you need more teams to build the service or product you need to coordinate the effort of the different teams to ensure they work together effectively towards the common goal. This is called in DA program management for large agile teams with the corresponding leadership team roles like a Program Manager/Coordinator, Product Delivery, Product Ownership and Architecture Ownership. The book doesn’t describe that much but, on the website, you can find much more information about program management.
The non-prescriptive set-up is emphasised by goal diagrams. Mindmaps to summarize the goals of a specific activity, e.g. addressing changing stakeholder needs, explore the initial scope or continuous improvement to mention a few.
Real life examples are missing in this book but can be found in their book Introduction to disciplined agile delivery
Disciplined DevOps explains what it means to bridge the gap between the agile teams and IT operations. In the book the workflow between Solution Delivery and IT Operations and other departments like Business Operations (BizDevOps), Security (DevSecOps), Data Management (DevDataOps) and Release Management and IT Support are explained. Reasons to adopt a Disciplined DevOps approach are faster time to market, improved market competitiveness, improved customer service, increased dependability, increased staff retention, improved governance and lower cost.
Disciplined Agile IT addresses how to apply agile and lean strategies to all aspects of IT. The workflow of Disciplined Agile IT is explained with a focus Disciplined DevOps, IT Operations, Release Management, Support, Security, Data Management and IT Governance, Reuse Engineering, Enterprise Architecture, People Management, Product Management, Continuous Improvement and Portfolio Management. On several place you get goal diagrams.
Portfolio Management addresses the following issues: spend IT investment wisely, balance exploring new business with exploiting existing value streams, monitor and guide ongoing activities, rolling-wave budgeting and planning, prefer small initiatives over large initiatives, cull “failures” quickly, invest in quality and enable team effectiveness.
To become a Disciplined Agile Enterprise, you have to embrace the following fundamental ideas:
- Your organization and your people must be agile
- It’s all about value streams
- There is no one right answer
- You need to sense and respond
- You must be a learning organization
- Self-organizing teams need fast access to resources.
In the workflow for Disciplined Agile Enterprise we see besides the ones mentioned in the Disciplined Agile IT workflow, Marketing, Sales, Control, Finance, Procurement and Legal. The authors explain the Disciplined Agile approaches in the different functions.
Next the authors give some insights what it means if you want to transform your organisation from a traditional structure and culture to one exhibiting true business agility. This will be very hard and will take a long time. Focus will vary over time in the following areas: executive education, executive coaching, middle-management coaching, agile training, agile/lean pilot teams, delivery team coaching, IT coaching, business coaching, skils training, agile centre of excellence, communication, experiments and communities of practice. The chapter ends with an example of a transformation and adoption roadmap anf how to measure your way to success. A separate chapter focusses on the final step in the transition, your organization has to become a learning organization (continuous improvement) and this will never end.
Conclusion: If you are not familiar with disciplined Agile and you want to get a clear overview of this framework, this book is a very good start. Looking at the different delivery cycles, there must be ones that have the right fit for your projects. If you want to implement disciplined Agile you probable need more information (as explained in the book too), and training and coaching too.
Positionering of Disciplined Agile in my birds eye view on the agile frameworks forest: