Tag Archives: agility

Review: An Introduction to Evidence-Based Portfolio Management

portfolio 2Scrum.org wrote the whitepaper An Introduction to Evidence-Based Portfolio Management. Evidence-Based Portfolio Management is an approach that applies lean and agile principles to the challenge of deciding where to invest to derive the greatest business benefit.

It enables organizations to quickly test ideas by actually building and validating the smallest solution that will deliver a single outcome to a single set of customers or users.

Evidence-Based Portfolio Management takes a Principles Based Approach:

  1. Separate capacity-for-growth from focus-of-work
  2. Make the best decision you can, based on the best evidence available
  3. Invest in improving business impacts using hypotheses, don’t just fund activity
  4. Continuously (re)evaluate and (re)order opportunities
  5. Minimize avoidable loss
  6. Let teams pull work as they have capacity
  7. Improve status reporting with increased engagement and transparency.

QRC E-B PfMTo download the QRC: QRC E-B PfM

Evidence-Based Portfolio Management focusses on outcomes to produce better results. It states that the organizational mission, vision, outcomes, and strategy must be centralized, and the product vision, strategy, and execution must be decentralized.

The art of portfolio management is deciding what not to work on and the number of teams you have will limit how many ideas you can work on at once.

To download the whitepaper: An Introduction to Evidence-Based Portfolio Management

This framework fits in the Portfolio level block of my bird’s eye view on the agile frameworks forest (see also the complete article).

Grasp session (Scaling Agile, 190603) v1.1




The Agile Fluency model

The Agile Fluency model, developed by Diana Larsen and James Shore in 2012 and substantially updated in 2018, is a framework to help teams understand their current position and to help them develop an individual road map. Agile teams pass through four distinct zones of fluency as they learn (fluency evolves). Diana Larsen defines fluency as things that you do automatically without thinking. Each zone brings specific benefits:

  1. Focusing teams produce business value (agile fundamentals). The team thinks and plans in terms of the benefits their sponsors, customers, and users will see from their software.
  2. Delivering teams deliver on the market cadence (agile sustainability). The team can release their latest work, at minimal risk and cost, whenever the business desires.
  3. Optimizing teams lead their market (innovative business agility, agile’s promise). The team understands what their market wants, what your business needs, and how to meet those needs.
  4. Strengthening teams make their organizations stronger (possible future of agile). The team understands its role in the larger organizational system and actively works to make that system more successful.

Schermafdruk 2019-05-30 15.52.02A team’s fluency comes from the ability of team members to self-organize so that individual skills are applied to the right problems at the right times. A team is fluent in a zone when it’s fluent in all of the zone’s proficiencies, including predecessor zones.

The appropriate zone for your teams depends on your organization and can be different from team to team. It is not a ranking system, but is about understanding and working towards the appropriate level of fluency for your needs at a particular point in time. Delivering or Optimizing are often the best targets, but Focusing and Strengthening can also be good choices. Fluency is more a matter of habits than skills.

Video: The Agile Fluency Model Explained: A Brief Guide to Success with Agile

The Agile Fluency Model whitepaper

Agile Fluency Simulation — an educational, exciting board game

This model definitely fits into the culture-targeted block of my bird’s eye view on the agile frameworks forest (see also the complete article):Grasp session (Scaling Agile, 190506) v1.1


Agile NXT Future Friday retrospect

Schermafdruk 2019-04-08 15.16.29Friday May 10, 2019, I was one of the 40 participants of the first Agile NXT Future Day conference organized by Xebia.

It was perfectly organized, really interesting and next level topics, great food, and enough time to network. The conference offered seven thought leaders to sharpen our mind and to help to improve your own organization’s performance. The group was split in two to facilitate discussion and active participation. Four sessions of 1,5 hour that made it possible to get some theoretical background and workshop set-ups to learn by doing.

The first session – Why the Agile “Fixed-Team” Dogma is Wrong (Laïla Nouijeh & Laurens Bonnema) was somewhat controversial. Fixed teams are the ideal world and now they say this is wrong. Luckily, it’s not that black and white but the reality is that people are entering and leaving the teams on unexpected moments, sometimes due to management decisions, sometimes as a result of a team mismatch, sometimes on a person’s own initiative and in most cases it will have a negative impact on the team’s performance. If you take this for granted and accept that reteaming is inevitable, make sure you get good at it. To become good in reteaming you can look e.g. at techniques like pair programming or MOB programming to speed up the process of integrating new members or create a checklist to facilitate on-boarding and make sure the questions are definitely a lot of fun to answer. To build, reshuffle or reteam teams you can also make use of self-selection. This will speed up the process of teaming too and ultimately you will have more engaged teams. In the last part we had a workshop to discover how to implement dynamic reteaming experiments in your organization.72

An interesting book to read is Dynamic Reteaming: The Art and Wisdom of Changing Teams by Heidi Helfand.

The second session – Stop Copy-Paste Agility, Start Agile Problem Solving (Daniel Burm) focused on the question: Is your agile “copy-paste” or “problem-solving-specific? If you only imitate, you’ll never innovate. Daniel started the session with a video from David Kelley, founder of IDEO. How they countermeasure solution thinking (what is deep dive) about designing a shopping cart.

Based on this video the question was asked if this design thinking process could be used for organization changes too? In a workshop setup all attendees got the chance to practice some techniques which were explained upfront. E.g. the Design thinking process for change based on a holistic approach: Empathize (scoping, 360 research and synthesize), Ideate (impact mapping: goal – actor – impact – deliverable), Experiment (run controlled experiments, experiment canvas). We practiced the change urgency interview resulting in a first problem statement, we reframed problems into challenges, and we created an experiment setup including an underlying hypothesis. All attendees received a workbook including the used templates and tools and the advice to learn what it takes to solve your own companies’ problems, your way—the agile way.impact mapping

An interesting book to read is Impact Mapping by Gojko Adzic.

In the third session Structure Your Organization For Tomorrow (Roel Trienekens & Just Meddens) we learned how to confront the real challenges of current work-impacting trends. Gain practical knowledge for your organization’s future-fit toolkit. Referring to David Marquet’s book Turn the ship around and showing the Pirates of the Caribbean – At World’s End – Up Is Down Scene.

Using three-dot voting all attendees selected a few themes out of ten. We started to discuss pros and cons of radical transparency. What if you have access to …

  • everyone’s planning?
  • everyone’s experience?
  • everyone’s to do list?
  • everyone’s goals and targets?
  • the complete company finances?
  • everyone’s performance reviews?
  • everyone’s salary and benefits?
  • everyone’s e-mail communication?

There are organizations, e.g. Buffer or Semco, where this works, so why would it not work at your place, but you need for sure a mindset shift to accept this way of transparency.

The second topic we discussed was about a new way of decision making. How are decisions being taken? Do you know how much a reasonable decision costs in your organization? You can use an autocratic decision-making process, a democratic process (“The process of voting creates losers” – Rick Falkvinge), consensus and using the process of consent (holacracy, sociocracy). We experiment with consent decision making starting with the statement is this good enough for now & safe enough to try in stead of ‘is everyone in favor?

swarmwiseAn interesting book to read is Swarmwise by Rick Falkvinge.

height_90_width_90_DeToekomstVanOrganisatiesInteresting Podcasts: http://detoekomstvanorganisaties.nl

The fourth session When Agile Meets Culture … And Clashes (Ellen Barree) helps you to open your eyes to the “invisible elements” that often undermine transformations. If you want to change the culture you need alignment between the three layers: rituals and artifacts, exposed values and behavior and underlaying assumptions. What can we learn from how David Attenborough observes? Take e.g. how David explains The Software Developer.

We experiment how to make culture change more tangible and sustainable by using the corporate culture map (A3 placemat). Starting with the desired cultural change: What do you want to see and hear? What do you believe in and how do we act? What are they not telling you and truly feel, think, percept? Folowed by describing the current culture: what do you see and hear? What do we believe in and how do we act? What are they not telling you and truly feel, think, percept? And as a final step creating the movement from current to desired with care.

9789462760363-480x600Interesting books to read:9789462761759-480x600 De Corporate Tribe – Organisatielessen uit de antropologie by Danielle Braun, Jitske Kramer.

Building Tribes – Reisgids voor organisaties by Jitske Kramer, Danielle Braun

The conference ended with the keynote from Margriet Sitskoorn How Agile is Our Human Brain? Take a trip through the plasticity of your mind and gain insight into how you can express your talents and best accomplish your goals in the age of agility. Magriet explained what it means to live in a VUCA (Volatile, Uncertain, Complex, Ambiguous) world. How can you develop your executive skills to be successful in a VUCA world? These executive skills are related to your pre-frontal lobe and help you to change from puppet to master. We experienced working memory, inhibition and inhibition and flexibility. To develop your pre-frontal lobe, you have to do something new. For this purpose, she developed the EFFECT program (Enriched environment, Flow-focus training, Fixed sleep pattern, Exercise, Connect today with tomorrow, and Time).

Some interesting book to read:


When we left, we received a goody bag with a pair of Xebia happy socks and the book Agile NXT insights and foresights for your next step in agile.

The next Agile NXT Future Friday will be held Friday September 13, 2019. If it will have the same quality of this first one, it’s definitely a conference I would like to attend.

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





Schermafdruk 2019-04-08 15.16.29I give a lot of workshops and presentations and in many cases, attendees ask for the ‘silver bullet’ to become agile. It is far too short-sighted to think that you have to implement one agile framework and you achieve agility. First it is not about frameworks (despite my search which already resulted in 50 different agile frameworks. See my blog: A birds eye view on the agile frameworks forest). Also copying a successful way of working will not do (how many organizations copied Spotify’s tribes and squads’ organization model, bypassing Spotify’s own remark “if you want to use Spotify’s way of working, you have to become a Spotify”)? Achieving agility is all about the mindset of you as an individual or your organization and it’s the culture clash between the agile and traditional mindset that makes agile transitions difficult (reminder the picture I often use showing two rhinos looking at each other, as a metaphor for this clash). I have seen organisations firing project and program managers because they choose for the agile way of working and created a lot of agile teams because their competitor did the same and are now regretting that move. They have to hire much more expensive external program managers who lack the added value of the needed informal networks in the organisation to make transformational changes happen. Having only agile teams is not enough.

I got across the AGILE NXT FUTURE FRIDAY 2019 conference organized by Xebia. Last year I read the magazine AGILE NXT – Insights and foresights for your next step in agile so I was triggered, and the program looks awesome.

If I look at the program, I hope to get some answers or at least directions to my own thoughts. The conference offers seven thought leaders to sharpen my and your own mind and will help to improve your own organization’s performance.

  • How Agile is Our Human Brain? (Keynote, Margriet Sitskoorn): Take a trip through the plasticity of your mind and gain insight into how you can express your talents and best accomplish your goals in the age of agility.
  • Stop Copy-Past Agility, Start Agile Problem Solving (Daniel Burm): Is your agile “copy-paste” or “problem-solving-specific? If you only imitate, you’ll never innovate. Learn what it takes to solve your own companies’ problems, your way—the agile way.
  • Structure Your Organization For Tomorrow (Roel Trienekens & Just Meddens):Learn how to confront the real challenges of current work-impacting trends. Gain practical knowledge for your organization’s future-fit toolkit.
  • When Agile Meets Culture … And Clashes (Ellen Barree): Open your eyes to the “invisible elements” that often undermine transformations. Learn how to make culture change more tangible and sustainable.
  • Why the Agile “Fixed-Team” Dogma is Wrong (Laïla Noujeh & Laurens Bonnema): Solve poor performance with a shift in perspective on the fixed-team dogma. Discover how to implement dynamic reteaming experiments in your organization.

I will definitely attend AGILE NXT FUTURE FRIDAY 2019 and I look forward to the insights the speakers will offer. Afterwards I will write a blog with the highlights of this conference. Interested too, get your ticket at: https://www.agilenxt.com/

Recensie Agile focus in besturing

9789401803878-480x600Agile focus in besturing – pocket guide voor executives in transformaties is geschreven door Marjolijn Feringa en Jeroen Venneman en biedt een praktische methode om als managementteam de focus te houden op de belangrijkste initiatieven en kwartaal voor kwartaal nieuwe focus aan te brengen zodat je als organisatie wendbaarder wordt.

Door het boek loopt een casus van een fictief bedrijf waarin het managementteam, onder begeleiding van een coach, het FOCUS-bord leert toe te passen. Dit visuele bord staat centraal in dit boek.

Het boek begint met een korte introductie op het Agile Manifesto en de vertaling van dit Manifesto voor directieteams in het Agile Executive Manifesto:

  1. Samenwerken aan teamdoelen boven gaan voor individuele mijlpalen
  2. Prioriteren van onderwerpen boven volgen van de agenda
  3. Wegnemen van belemmeringen boven stimuleren van resultaten
  4. Bijsturen op actuele inzichten boven analyseren van rapportages
  5. Visueel overzicht boven spreadsheet rapportages
  6. Verdeling van voorbereiding boven iedereen bereid alles voor
  7. Experimenteren binnen kaders boven plannen maken
  8. Elke kans om te verbeteren benutten boven tijd plannen voor verbeteren
  9. Stellen van vragen op de werkvloer boven accorderen van voorstellen in de vergaderzaal

Daarnaast wordt het belang van het hebben van een visie toegelicht en wat een verandering naar een meer wendbare organisatie betekent.

Het FOCUS-bord heeft drie doelen namelijk visuele ondersteuning, bevorderen van de samenwerking en het aanbrengen van focus. Het verbindt de strategie met de belangrijkste initiatieven, vertaalt de strategie (thema’s) in doelen op de lange termijn, het lopende jaar en het lopende/komende kwartaal (en uitgesplitst per maand). Er worden KPI’s gebruikt om eenduidig meetbare punten te creëren (status). Doelen worden middels initiatieven gerealiseerd. Initiatieven zijn verzamelingen van mijlpalen om een doel te bereiken. Mijlpalen worden als deliverables beschreven. Ieder initiatief heeft haar eigen facilitator die in de stand-up een update geeft over dit initiatief.

Het is de bedoeling dat wekelijks dit bord wordt bijgewerkt en besproken. Waarbij de voorkeur voor staand vergaderen wordt benadrukt. Voor deze stand-up hebben de auteurs een standaard agenda en grondregels opgesteld (Noot recensent: hoe verhoudt zich dit tot het tweede punt uit het Agile Executive Manifesto (Prioriteren van onderwerpen boven volgen van de agenda?). De agenda bestaat uit de volgende punten: check-in, status impediments, doorlopen initiatieven, hulpvragen/impediments/mededelingen, parkeerplaats-punten, fist of five (mini retro: vuist: kon niet slechter, 5 vingers: kon niet beter).

Iedere drie maanden moet het FOCUS-bord ververst worden, de zogenaamde kwartaalwissel. Hier vinden de volgende gebeurtenissen plaats: review resultaat afgelopen kwartaal en aanpassen/aanscherpen doelen, retrospective, planning komend kwartaal.

Het FOCUS-bord staat niet op zichzelf. Strategie verbindt alle teams en middels het cascaderen van strategische doelen naar onderliggende managementteams bereik je dat iedereen op dezelfde golflengte zit. Een mooie manier hiervoor is dat individuele directieleden op eenzelfde manier met een FOCUS-bord aan de slag gaan voor hun eigen MT.

Om in lijn met ontwikkelteams te blijven en hun werkwijze te begrijpen, wordt aanbevolen dat directie of MTs ook, een maar dan op maat gemaakte, Scrum werkwijze gaan hanteren. Verder beschrijven de auteurs een aantal technieken (FOCUS toolbox) zoals de manifesto workshop, strategy deployment (X-matrix) of Hoshin Kanri, veranderkompas, kanban-bord, focus radar, BCP-methode, feature mapping, de retrospective, delegation poker en de anticipate workshop.

Het boek eindigt met een drietal tips om te starten met agile focus in besturing, een agile leiderschap maturity niveau checklist en een beschrijving van de Rabobank case, de FOCUS way of working.

Conclusie: Vlot leesbaar boek met een praktische aanpak en voorbeelden waarmee je als managementteam direct aan de gang kan gaan om een meer agile focus in de besturing aan te brengen.

Jammer dat de voorbeeld FOCUS-borden zo klein gedrukt zijn (zal wel aan mijn ogen liggen maar ik kon de bovenste regel niet lezen). Daarnaast heb ik persoonlijk moeite met het gebruik van het woord facilitator van het initiatief. Deze facilitator kan volgens de auteurs periodiek wisselen. Ik zou liever geen wisselingen willen zien en dat het de eigenaar/sponsor van een initiatief is die toelicht als er problemen zijn. Daarnaast wordt eigenaar initiatief en facilitator door elkaar gebruikt in de tekst. Verderop in het boek wordt vervolgens het begrip facilitator gebruikt als iemand buiten het team die optreedt als procesbewaker.

Bestellen: Agile focus in besturing

via de auteurs heb ik een voorbeeld van een FOCUS-bord gekregen.


Downloaden van de drie in het boek genoemde voorbeeldborden: FOCUS bord

In de kop vind je de omschrijvingen van de kolommen, respectievelijk: Thema, Over een jaar doelen, Dit kwartaal doelen, Status van doelen, Belangrijke initiatieven mijlpalen afgelopen kwartaal, mijlpalen maand 1, mijlpalen maand 2, mijlpalen maand 3, mijlpalen komende kwartaal en mijlpalen later, Impediments / Acties (To do, Doing, done) en rechtsonder de Parkeerplek.

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