Tag Archives: review

Review: An executive’s guide to disciplined agile

DAThe 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 (QRC, 190407) v1.0DA 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.

To order: An executive’s guide to disciplined agile – Winning the race to business agility

Positionering of Disciplined Agile in my birds eye view on the agile frameworks forest:Agile (50 shades of gray NTTP, 190415) v0.1

 

 

 

Advertisements

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

 

Review: DevOps a business perspective

9789401803724-480x600Oleg Skrynnik wrote the book DevOps a business perspective. It’s the core literature for the EXIN DevOps Foundation certification and gives a good overview of DevOps.

Definition DevOps: “DevOps is an evolution of the ideas of agile software development and lean manufacturing, applied to the end-to-end value chain in IT, which allows businesses to achieve more with modern information technology due to cultural, organizational and technical changes

The book is built around 6 chapters. The first chapter explains DevOps in general. Next, we get key facts and challenges of lean production and agile as the foundation for DevOps. Followed by an explanation of the five DevOps principles.in a next chapter DevOps is compared with traditional practices and 10 DevOps practices are explained and ends with the practical application of DevOps.

The evolution of Agile software development methods created the need for a new approach to IT management. Management of IT infrastructure as a code enabled by virtualization and cloud computing provided the opportunity for the same new approach to IT management. This new approach was the inspired emergence of DevOps.

Why DevOps:

  • reduce time to market (business idea testing, hypothesis evaluation)
  • Reduce technical debt (the debt occurs when a programmer chooses a non-optimal way to solve a problem in order to shorten the development time)
  • Eliminate fragility (fragile systems first and foremost need stability, they need to be changed as little as possible, and changes should be carefully checked both before and after the intervention)

DevOps is based on five principles:

  • Value stream. Creating value in response to a customer’s request
  • Deployment pipeline. The most automated transition of changes through all steps of the value stream, starting from the Development is complete’ point, down to ‘Deployment into operations’ (including continuous integration, delivery and deployment)
  • Everything should be stored in a version control system: source code, tests, scripts, artifacts, libraries, documentation, configuration files, development tools
  • Automated configuration management. Any changes to any environment can be made only by scripts stored in a version control system
  • The Definition of Done. Creation of new functionality is done only when the application is running in the production environment and all the assembly, testing and deployment activities are done automatically.

Ten DevOps key practices:

  • Unusual teams: not a temporary construct, responsible for a small domain, full time, cross-functional, small, versatile professionals, self-organizing, collocated, responsible for the tool in use
  • Work visualization: helps to build a pull system, improves visibility of tasks in progress, remaining amount of work, prioritization, reduces the number of hand-offs and helps to identify inefficiencies
  • Limit the WIP: helps to build a pull system, improves estimating of the lead time, identification, visibility, evaluation and elimination of constraints, decreases specialists’ work interruptions and work re-scheduling
  • Reduce batch size: reduces total amount of work, lead time and number of defects, and improves the rhythm of the flow, the quality of the products
  • Mind the operational requirements: the product owner as interested in the fully operational IT system, including both functional and other (or operational) requirements
  • Early detection and correction of defects: testers develop tests and the test environments correspondent to the production environment as accurately as possible to support fast detection of defects
  • Managed, not controlled improvements and innovations: banning any normal work during the time allocated for improvement, Kaizen Blitz (with a very definite and tangible result), hackathons
  • Funding that enables innovations: funding of products rather than projects would be more appropriate, and this means a completely different way of budgeting and resource planning
  • Task prioritization based on cost of delay divided by duration
  • Continual identification, exploitation and elevation of constraints

The last chapter describes some practical applicability and limitations of DevOps, consequences when using COTS (Commercial Off-The-Shelf), an evolving architecture towards a microservice architecture, DevOps and ITSM, Cargo Cutting (thoughtless copying), start where you are, progress iteratively and use a value stream as the core for DevOps.

Conclusion: If you want to understand what DevOps really means, this is a good book to start your journey and bring it into practice.

To order: DevOps a business perspective

Review: The Professional Product Owner

poDon McGreal and Ralph Jocham wrote the book The Professional Product Owner – Leveraging Scrum as a competitive advantage.

This book gives you the insights how you, as a product owner, can identify, measure, and maximize value throughout your entire product lifecycle.

The authors explain that you can call yourself a professional product owner if you can excite, can envision, can cause the product to emerge and you can manage and administer the product as it matures.

The chapters in the book are clustered into three parts strategy, Scrum and tactics. Every chapter starts with a little quiz (statement: agree/disagree) and at the end of each chapter you will find the answers.

The first part – strategy focusses on proper agile product management and maximizing the return on investment (ROI of a product by looking at the three Vs (vision, value, and validation) as a way to achieve this.

Vision creates transparency, value provides you with something to inspect and validation causes adaption. The authors explain why the world of product management a lot bigger is than Scrum. There are many types of product owners starting with scribe, proxy, business representative, sponsor and entrepreneur. Going from left to right the expected benefits from the product owner type will increase heavily. We got an explanation of the business model canvas, the added value of a good vision and what it means to deliver value. Evidence-based management with current value, unrealized value, ability to innovate and time to market is illustrated (in grey boxes you will find the corresponding text from the EBMgt Guide (see review on my blog). In the last chapter – validation, the authors discuss feedback, the usage of different types of MVP’s, the Kano-model and the build-measure-learn feedback loop (based on Eric Ries’ book Lean Start-up).

Part II – Scrum explains empirical process control and how Scrum is a tool for managing complexity and continuous delivery of value. In the text you will find, in grey boxes, corresponding text form the Scrum guide too.

It starts with an explanation of complexity. You get a certainty quiz to measure the uncertainty of your own environment/team. To visualize complexity a modified Stacey graph (categorization model) is explained as well as the usage of Dave Snowdon’s Cynefin model (sense-making) with the five domains obvious, complicated, complex, chaos and disorder. The empiricism of Scrum helps to address risks (misunderstanding of requirements, lack of top management commitment and support, lack of adequate user involvement, failure to gain user commitment, failure to manage end user expectations and changes to requirements and lack of an effective project management methodology). For the rest of this part the focus is on Scrum itself. The pillars (transparency, inspection and adaptation), The Scrum roles (product owner, development team and scrum master) and stakeholders, the Scrum artifacts (product backlog, sprint backlog and the increment) and not official Scrum artifacts (Definition of done, burn-down, burn-up charts), and Scrum events (sprint, sprint planning, daily scrum, sprint review, sprint retrospective). For every element the authors explain the relation with the product owner.

qrc (backlog items, 190121) v1.0To download: qrc (backlog items, 190121) v1.0

The last part – tactics introduces more concrete practices and tools for managing product backlogs (see the attached QRC) and release plans and concludes by examining what it means to be a professional product owner.

It starts with an explanation of a requirement and you get an explanation of the different items on a product backlog (feature requirements, non-functional requirements, experiments, user stories, bugs/defects, user cases, capabilities, …) and an example of a product backlog item template with acceptance criteria and common ways of writing acceptance criteria (Test that …, Demonstrate that …, Gherkin syntax (given, when, then)). How you can order a backlog based on business value, risk, cost/size and dependency including measuring value, risk and size is a next topic. The definition of “done” is defined as well the meaning of ready. A lot of other techniques are discussed e.g. story mapping, impact mapping, specification by example and agile testing. Release management is the next big chapter in this part. What are release management, reasons to release, release strategy, major, minor and functional releases? How can you use estimation and velocity to answer the question when will I get it? Scaling in terms of more products or more teams as well as a brief overview of the Nexus framework are introduced. This chapter ends with some more techniques like the Monte Carlo simulation to estimate a product backlog, velocity breakdown by type (features, bugs, technical debt and infrastructure), budgeting, governance and compliance, release kick-off and quality (definitions, product and technical quality, keeping quality). This part ends with the skills and traits of a good product owner.

Conclusion: If you are a product owner this is absolutely a must read. You get explanations, techniques, examples and real-life cases from the authors how you have to and can play your role as a professional product owner.

To order: The Professional Product Owner

Review EBM Evidence-Based Management Guide

schermafdruk 2019-01-19 17.32.18The Evidence-Based Management Guide was developed by Ken Schwaber, Christina Schwaber, Scrum.org, the professional Scrum Trainer community and the Engagement Manager community.

EBM is an empirical approach that provides organizations with the ability to measure the value they deliver to customers and the means by which they deliver that value, and to use those measures to guide improvements in both.

EBM consists of four Key Value Areas (KVAs):

  • Current Value (CV): Reveals the value that the product delivers to customers, today
  • Time to Market (T2M): Expresses the organization’s ability to quickly deliver new capabilities, services, or products
  • Ability to Innovate (A2I): Expresses the ability of a product development organization to deliver new capabilities that might better meet customer needs
  • Unrealized Value (UV): Suggests the potential future value that could be realized if the organization could perfectly meet the needs of all potential customers

qrc (evidence-based management, 190119) v1.0To download: qrc (evidence-based management, 190119) v1.0

To produce genuine and long-lasting improvements the guide explains a five-step learning loop:

  1. Quantify Value
  2. Measure KVMs (Key Value Measure)
  3. Select KVAs to improve
  4. Conduct practice experiments to improve targeted KVAs
  5. Evaluate results

In the appendix an overview of KVMs, clustered by KVAs, and how to measure them.

Conclusion an easy to read guide to get a better understanding of business value, how to measure and how to improve it.

To download the guide (for free): Evidence-Based Management Guide

Quick Reference Cards in 2018

As a result of my book reviews I created several Quick Reference Cards to summarize what I have read.QRC 2018

My 2018 book reviews

2018 was a fruitful book review year. I wrote more than 50 book reviews including corresponding quick reference cards and several personal insights, and views on specific topics in the field of project, program and portfolio management and I wrote the book Directing successful projects with PRINCE2 by Henny Portman

Book reviews 2018.pngAgility

Management

Project/Program/Portfolio management