Tag Archives: framework

Review: Introduction to Disciplined Agile Delivery

9200000046318020Scott W. ambler and Mark Lines are the creators of the Disciplined Agile Delivery framework and the authors of the book Introduction to Disciplined Agile Delivery – a small Agile Team’s journey from Scrum to Disciplined DevOps (2ndedition).

Disciplined Agile Delivery (DAD) is one of the four elements of Disciplined Agile (DA). The other parts are Disciplined DevOps, Disciplined Agile IT (DAIT) and Disciplined Agile Enterprise (DAE).

DAD is characterized by the following aspects:

  • Hybrid: combines Scrum, Agile Modelling, XP, Unified Process, Kanban, Lean, Outside-In Development (OID) and other methods
  • Full delivery cycle. Scrum offers only a development cycle. DAD starts from team initiation all the way to delivering the solution to its end users
  • Supports multiple lifecycles based on inception, construction and transition: an agile/basic version that extends the Scrum construction lifecycle with proven ideas form Unified Process to support early mitigation of risk and lightweight governance; an advanced/lean lifecycle based on Kanban; an agile continuous delivery lifecycle; a lean continuous lifecycle; and an exploratory lifecycle based upon a Lean Start-up approach
  • Complete: DAD includes advice how development, modeling, documentation, and governance strategies fit together
  • Context-sensitive: instead of prescriptive frameworks like Scrum, DAD promotes a goal- or object-driven approach.

The core of the book is a case study. We follow a team on their journey to use DAD and more specific the Scrum-based agile/basic lifecycle. It starts, after the introduction of the team and other stakeholders, with the Inception phase. The goals of the Inception phase are: form initial team, develop common vision, align with enterprise direction, explore initial scope, identify initial technical strategy, develop initial release plan, secure funding, form work environment, identify risks and develop initial test strategy.

In the construction phase the team uses, as described in the release plan, ten construction iterations to produce a potentially shippable solution. Every iteration starts with an iteration planning cycle. Every day there will be a coordination meeting and the iteration ends with the iteration review/demo and the retrospective. Additional to scrum, DAD will have a proven architecture and the sufficient functionality milestone reviews too and you have to pass both successfully before you can go into the Transition phase.

The focus of the Transition phase is for a team to release/deploy their consumable solution into production successfully. To ensure that the solution is ready to deploy the team focusses on the final testing and fixing, the support training of the helpdesk staff, the finalization of the deliverable documentation, the support of the development of end-user training (videos), and the validation of the deployment scripts.

As a next step we follow the team on their road to Disciplined DevOps. In this case the team decided to have seven 2-week iterations. Some highlights of the iterations are the adoption of Test Driven Development (TDD), working from home, improvement tracking, the evolvement of the team, the usage of parallel independent testing, how to cope with vacations and the sharing of their learnings, ATDD or BDD training and adoption, requirements envisioning, quality and continuous integration and deployment. At a certain moment, after several releases, the release cadence was tightened, and their lifecycle evolved towards the lean lifecycle and the team stopped with sizing their work.

Conclusion: if you are looking for a comprehensive overview of DAD this is the book to read. The case gives a good overview of the Scrum-based agile/basic lifecycle and may help you to take the first steps to implement DAD.

More information can be found on disciplinedagileconsortium.org

To order: Introduction to Disciplined Agile Delivery

Disciplined Agile and Disciplined Agile Delivery positioned in my birds eye view on the agile forest

Grasp session (Scaling Agile T-Mobile, 2019 Q1) v0.1

 

Advertisements

AgileSHIFT an overarching agile framework

AgileSHIFTcoverMany organizations are struggling to implement agile delivery frameworks to increase their level of agility, and many organizations fail. One of the reasons is the culture clash between a traditional organization and the agile culture. Only implementing agile delivery frameworks in e.g. your IT department is not enough.

AXELOS has developed a framework (see attached Quick Reference Card/QRC AgileSHIFT) that prepares people for transformational change by creating a culture of enterprise agility. The AgileSHIFT framework helps organizations to undergo a transformational change, to adopt a ‘survive, compete and thrive’ mindset. It will help to bridge the gap between the current and the target state (the Delta in AgileSHIFT) by embracing a range of agile, structured and hybrid approaches across the organization. The existing severe split between ‘run the business’ and ‘change the business’ will vanish. Now called, in this framework, Run the Organization and Change the Organization. Everyone is a change-enabler, encouraged and empowered to make change happen.

AgileSHIFT (QRC, 181012) v1.0To download: AgileSHIFT (QRC, 181012) v1.0

The AgileSHIFT framework explains why we need enterprise agility. There is an increasing pace of change (VUCA: volatility, Uncertainty, Complexity, Ambiguity), the role of technology (from technology supported, via technology enabled towards technology centric), the delta between the current and target state of your organization and disruptive influences by enablers (as the gig economy, remote working, cloud storage and online presence), inefficient markets and black swan events.

To accommodate what we have to do the AgileSHIFT framework defines enterprise agility, principles and practices. Enterprise agility is the ability of an organization to move and adapt quickly in response to shifting customer and market needs. The five principles are: Change will happen so embrace the status quo, challenge the status quo, develop an environment where everybody adds value, focus on the co-creation of customer value and tailor your approach. The five practices are: Plan to be flexible and adaptable, engage stakeholders, build collaborative teams, focus on the co-creation of customer value and measure value.

The how (corresponds with the AgileSHIFT delivery approach) is expressed in the AgileSHIFT framework by the roles, the AgileSHIFT workflow and an iteration and by tools and techniques. There are three roles: the AgileSHIFT team, sponsor and coach. A simple iteration approach is explained but depending on the situation you have to choose the right approach. Tools and techniques include: customer stories and epics, relative estimating and story points, AgileSHIFT task list and roadmap, swarm, kanban, canvasses and agendas. For the last two there will downloads available.

To show your understanding of AgileSHIFT, foundation and practitioner certification will be possible.

In the next picture, I have positioned AgileSHIFT.Grasp session (Scaling Agile, 180526) v1.1

Jeff Sutherland launches the Scrum@Scale Guide

Schermafdruk 2018-02-19 18.55.08Jeff Sutherland has developed a concise guide that layouts the key roles and artifacts for Scrum@Scale. It’s free and available for your use.

Jeff Sutherland: “Scrum@Scale was created to efficiently coordinate this new ecosystem of teams in a way that optimizes the overall strategy of the organization. It achieves this goal through setting up a minimum viable bureaucracy

Scrum@Scale offers a scale free architecture.

Scrum@Scale is:

  • Lightweight – the minimum viable bureaucracy
  • Simple to understand – consists of only Scrum teams coordinated by Scrum of Scrums and MetaScrums
  • Difficult to master – requires implementing a new operating model.

Scrum@Scale contains two cycles: the Scrum Master Cycle (the “how”) and the Product Owner Cycle (the “what”), each touching the other at two points. Taken together, these cycles produce a powerful framework for coordinating the efforts of multiple teams along a single path. The Scrum Master Cycle contains the following modules: Team-Level Process, Continuous Improvement & Impediment Removal, Cross-Team Coordination, Deployment and Product & Release Feedback. The first and the last module are part of the Product Owner Cycle too. Besides these modules we find the following modules: Strategic Vision, Backlog Prioritization, Backlog Decomposition & Refinement, and Release Planning.

Schermafdruk 2018-02-19 19.47.47

To scale Scrum in your organization across many teams Jeff Sutherland works with high performance teams of 4-5 people as the optimal size. If you need more people working on a single product, a team of max 5 teams can be created. These teams comprise a Scrum of Scrums (SoS) with representatives from the different teams (often the Scrum Masters) to coordinate the work (the how) and they hold a Scaled Daily Scrum (SDS). The Scrum of Scrums is a Scrum team too with its own Product Owner and a Scrum of Scrums Master (SoSM, compare the RTE in SAFe). If 25 people or 5 teams is not enough to develop one product, max 5 Scrum of Scrums can work together with a Scrum of Scrum of Scrums (SoSoS) with a SoSoSM (compare the STE in SAFe) and this can continue. 5 SoSoS’s can work together and form a model with 125 teams. Depending on the size of the organization this can continue. The final Scrum of Scrums of an organization is called the Executive Action Team (EAT).

The same mechanism is applied for the Product Owners synchronization. The group of Product Owners who need to coordinate the backlog for the 5 teams is called the MetaScrum. This MetaScrum is a Scrum team too with its own Scrum Master and Chief Product Owner (CPO, compare Product Management in SAFe, or The Chief Product Owner in LeSS). In line with SoS’s that can grow into SoSoS’s the MetaScrums can grow too. For 25 teams we see a MetaScrum with a CCPO (compare Solution Management in SAFe). The final Meta Scrum of an organization is called the Executive MetaScrum (EMS).

In the guide several examples are given of organizational design with several soSoS’s and MetaScrums as well as the Executive MetaScrum and Action Team supported by separate teams focusing on Legal/Compliance, Customer Relations and People Operations (Agile HR).

Conclusion. If I look at the Scrum@Scale material available on www.scrumalliance.org there is much more detailed information available regarding the different modules within the framework but the two cycles are connected at Team Level Process and Strategic Vision (in the just published definitive guide this is now Product & Release Feedback and I would say that makes sense). There you could also find differentiation at with level the module is used (team, Department, organization). Probably an evolution of the framework and to keep it as simple as possible by only using Scrum teams and SoS/MetaScrums. The organizational mechanism to scale Scrum is added (My first reaction where have I seen this before: compare goal driven agile on my blog). If it makes sense to keep Customer Relations (is this not a PO or MetaScrum task?), legal/compliance, HR etc. out of the Scrum teams is food for discussion.

Have a look by yourself at www.scrumatscale.com were you can download the guide.

Lost in standards

Dia1In the last “projectie, edition 04-2014”, the bi-monthly magazine of ipma-nl, I published a Dutch article about the many methods and frameworks that are available in the field of portfolio, programme and project management. To download: Verdwaald in het standaardenbos IPMA Projectie magazine 04-2014 I created a sort of quick reference card with available standards and frameworks (It’s limited, there are many more). To download: standards-qrc-170129-v1-9

In the middle of the quick reference card you find a generic model with portfolio, programme and project management as horizontal boxes. Behind these boxes you will find vertical boxes with PMO, IT, benefits management, value management and risk management to support project, programme and portfolio management. And as the background I used two triangles representing the people and maturity of project, programme and portfolio management. From this model I made connections with several well-known organizations that develop and own standards. E.g. Axelos as the owner of PRINCE2, MSP, MoP, MoV, MoR, P3M3 and ITIL or PMI as the owner of PMBoK, The standard for Portfolio Management, The standard for Programme Management, OPM3, etc. You will also find AMPG, APM, IPMA and several suppliers of Agile/Scrum as well as some ISO models. dia1 In the Dutch article, I focus on the usage of these standards. It’s not that simple that you only have to select a project management method. Je must be aware that it will not be possible to implement all your ideas and ambitions. You have to select the right initiatives. This will ask for a portfolio management method. To realize your strategic objectives, you need more than only projects. You will run programmes too, asking for a programme management method. Besides temporary project and programme offices you probably need a permanent portfolio office as well as a centre of excellence to communicate, support and train staff to use these standards and best practices.

At a certain moment you want to know were you are from a maturity view, in comparison with others, and based on your own ambition you would like to know the gap you have to bridge. It will be beneficial for an organization if all these models or frameworks are connected to each other. As a rule of thumb, I would advice an organization to choose for either Axelos or PMI as the starting point and combine your choice with the competence baseline from IPMA. If you choose e.g. for PRINCE2, it makes sense to choose for MSP and MoP for your programme and portfolio management. For maturity scans you look at P3M3 because that’s in line with these standards. Your temporary and permanent PMO will be supported by P3O, etc. For supplementary techniques you could make use of the PMBoK from PMI.

Or, when you started with the PMI family, it makes sense to combine this with the project or programme board approaches from PRINCE2 and MSP and the usage of business cases as described in PRINCE2 9789401800068_CoverLR-541x850I am one of the authors of the book Global standards and publications, edition 2014/2015, Van Haren Publishing. You can download a free copy of this book. http://www.vanharen.net/file/PDF/9789401800068.pdf Please let me know if you are aware of new standards that are worthwhile to mention in this QRC.

for a comparison between PRINCE2 and PMBoK see the overview from KnowledgeTrain: Comparison PRINCE2/PMBoK

Update:

  • 17/01/29: Added PM2 Project Management Methodology from The European Commission
  • 17/01/29: Added Scrum @ Scale from Srcuminc.com
  • 16/01/23: Added Nexus (Scaled Professional Scrum) from Scrum.org
  • 15/10/04: IPMA ICB3 replaced with ICB4
  • 15/07/07: Added new Axelos framework PRINCE2 Agile
  • 15/05/27: Added Change mgt vertical + CMBoK (Change Management body of Knowledge) + CHAMPS2
  • 15/04/24: Added ISO 21500 project, 21503 programme, 21504 portfolio, 21505 Governance, 21506 Vocabulary
  • 15/02/24: Added CCPM (Goldratt), CMMi, Global Alliance for Project Performance Standards (GAPPS)
  • 14/10/21: Added Exin Agile Scrum from EXIN
  • 14/09/29: Added Agile Programme Management (Agile PgM) from APMG
  • 14/09/29: Added PRiSM™ (Projects integrating Sustainable Methods) from GPM
  • 14/09/29: Added Portfolio, Program & Project Sustainability Model (PSM3) from GPM