Tag Archives: review

Review AGILE NXT – New Insights for Agile Performance Management

Schermafbeelding 2019-06-18 om 13.27.07This is XEBIA’s second edition of AGILE NXT (see AGILE NXT for the first edition). This time you get approximately twenty articles to bring you up to speed with new insights for agile performance management.

  • Measuring the Value of Business Agility (by Daria Nozhkina) shows that business agility generally adds value in three ways: it impacts the top line or the costs (or both); drives profitability; and contributes soft value which ensures that the profitability achieved is sustainable over the long term.
  • Data Science and Coaching: The Yin/Yang of Better Interventions (by Pieter Rijken) gives insights in team behavioral change by looking at goodness for fit for the delivery rate (items per iteration) data.
  • The Efficiency Addiction: Just Say No (by Roel trienekens). If you focus on efficiency … you get better at being increasingly less effective. Efficiency is about doing the same for less, effectiveness is about achieving more with the same input.
  • Four Steps to Effective Performance Meetings (by Daniel Burm) discusses four fundamental principles to keep in mind for people leading performance meetings: it’s not about you, close the loop, achievable next steps, and ask open questions.
  • The Quantifiable Added Value of Scrum is an interview with Jeff Sutherland about result-oriented organizations operating on clear and simple performance indicators (by Serge Beaumont).
  • Diamond Agile: Measuring What’s Meaningful (by Frank Verbruggen). Diamond Agile is a way of looking at organizational health from 5 different perspectives. Associated with each perspective are metrics. These metrics have been selected from hundreds of metrics as the best fit. 
  • The Power of Play in a Safe (But Not Too Safe) Environment (by Jasper Lamers) shows that a safe environment in which people can experiment, learn and fail without ruining the company, boost creativity.
  • Measuring Success, Measuring Value: Performance Management in a Scrum World (by Gunther Verheyen) highlights that team engagement is the most ignored aspect of value, yet one where huge gain can be made to increase the ability to deliver value.
  • The Gentle Way of Change (by Chris Lukassen) talks about six levers or sources of influence from the path to Judo black belt that could make you a better leader in business: personal motivation, personal ability, social motivation, social ability, structural motivation, and structural ability.
  • Changing Behavior—Measure First, Change Next (by Just Meddens) emphasizes what it does take to actually change behavior in the long term, and why it is so important in business. To change behavior the ABC change model can be of help (Antecedent: what triggers the behavior? Behavior: what’s being displayed? Consequence: what happens after the behavior is displayed? Is it being reinforced?).
  • It Takes Two to Do the Agile Tango: Invite Security to the Dancefloor (by Dave van Stein). Security and development need to dance together, so it’s best if they both learn the steps together, right from the beginning of your agile transition. Otherwise, once the development teams gain velocity, security and incident management becomes an impediment, and there is likely to be a few stumbles on the dancefloor.
  • Micro-Interventions from a Position of Leadership (by Rik de Groot). Management is responsible for 33% of transition failures. Micro-interventions that can help to achieve a positive outcome are provide purpose, speak out and build trust, lead by example, think big, act small, and shared leadership.
  • Doing: Diagnosis and Intervention Guide (by Paul Immerzeel and Maarten Uppelschoten) gives insights in the Doing model. Why people do things, how intervention triggers the behavior that creates the desired outcome and with it, organizational change. Forces that influence doing are understanding, willing, able and being enabled.
  • The Secret Key to Performance: Inner Agility (by Mirjam Diependaal). When in transition, organizations often forget that the essential factor in change is people. And people are often afraid to change. That’s why organizations should explicitly focus on helping people develop inner agility, because, without it, lasting change won’t occur.
  • Reducing Waste in the Race for Innovation (by Wilco Nap) outlines strategies designed to prevent product waste, time waste, and talent waste.
  • EventStorming: Increasing Performance Through Continuous Discovery, Learning, and Sharing (by Kenny Baas-Schwegler) explains EventStorming. It’s a workshop-based method for facilitating collaboration between the different IT disciplines and silos to empower knowledge-sharing.
  • Metrics: WiFi, Hamburgers, and the Successful Improvement Rate (by Jarl Meijer) emphasizes that there are two metrics that matter most in measuring the success of an agile transformation: the “level of agility” and the” successful improvement rate”.
  • How DevOps Helps You Accelerate Your Execution Power and Why it Matters (by Hans-Jürgen Jacobs and Pavel Goultiaev). DevOps allows a company to respond faster and rapidly test assumptions in any response to opportunities or threats. By creating more customer value, a company can achieve superior performance.

Curious to read the magazine? Download or request a printed copy at: AGILE NXT

 

Review Flawless consulting

flawless consulting 9780470620748-480x600Peter Block is the author of Flawless consulting – A guide to getting your expertise used. Starting point are the following three consulting goals. Establish a collaborative relationship. Solve problems so they stay solved and ensure attention is given to both the technical/ business problem and the relationships. To achieve this, you have to follow four phases and you must make sure you complete the requirements for each phase before you move into the next phase.

The four phases and their requirements are:

  • Negotiate the client and your own wants, cope with mixed motivation, surface concerns about exposure and loss of control, and understand triangular and rectangular contracts.
  • Discovery and inquiry. Layers of inquiry, political climate, resistance to sharing information, and the interview as a joint learning event.
  • Feedback and decision to act. Funneling data, presenting personal and organizational data, managing the meeting for action, focusing on the here and now, and don’t take it personally.
  • Engagement and implementation. Bet on engagement over mandate and persuasion, design more participation than presentation, encourage difficult public exchanges, put real choice on the table, change the conversation to change the culture, and pay attention to place.

Result By definition, being a consultant – and not a manager – means you have direct control and responsibility only for your own time and your own support resources. The line manager is paid to take responsibility for what the line organization implements or doesn’t implement!

Accountability If I – know my area of expertise (a given), behave authentically with the client, tend to and complete the business of each consulting phase, and act to build capacity for the client to solve the next problem on their own, I can legitimately say I have consulted flawlessly.

QRC (Flawless consulting, 190628) v1.0To download: QRC (Flawless consulting, 190628) v1.0

The book explains what to do during the different phases, what kind of meetings can be or must be held (including checklists). You get practical guidance on how to ask better questions, gives suggestions for dealing with difficult clients, and contains expanded guidelines on more engaging forms of implementation. It describes the important differences between internal and external consultants. What kind of resistance can you face, what does it mean and how to deal with resistance? Several examples are given including two outside the consultancy world. One taken from the health care and one from educational reform efforts.

In the book you can find several handy checklists:

  • Assessing the balance of responsibility: Rate who is taking responsibility in a project you are engaged in.
  • Analyzing one of Your contracts: Practice writing up elements of your contract.
  • Planning a contracting meeting: Answer these questions when you are planning a contracting meeting.
  • Reviewing the contracting meeting: Questions to answer after the meeting.
  • Planning a discovery meeting: Planning guidelines to aid in data collection and prepare for resistance.
  • Reviewing the discovery meeting: Questions to answer after the meeting.
  • Planning a meeting for action: Guidelines to help you prepare for the meeting.
  • Reviewing the meeting for action: Questions to answer after the meeting.
  • Preparing for implementation: Reminders on working the elements of engagement into the implementation phase.
  • Reviewing an implementation event: Questions to answer after the Implementation phase.

To download these checklists, visit www.flawlessconsulting.com where you can find much more resources too.

Conclusion. A must read for consultants. If you just start or if you are already a very experienced consultant, this book gives a lot a very useful insights, practices, checklists, examples, and a way of thinking and working to build the right relationship with your client and to avoid disappointments on the client’s or your own side.

To order (Managementboek): Flawless Consulting

To order (Bol.com): Flawless consulting

Review User Story Mapping

User story mappingJeff Patton wrote the book User Story Mapping. Story mapping it’s a tool to enable your team to hold better conversations about the project throughout the development process. Your team will learn to come away with a shared understanding of what you’re attempting to build and why.

The book offers 18 chapters:

  1. The big picture. This chapter will help to get a basic understanding of a story map and what it means to tell stories.
  2. Plan to build less. Now you have a basis understanding of a map some more details are added. What’s the backbone of the map, what type of users are playing a role, which big activities are the performing, how can those activities be divided into smaller steps, how can we split a single step into more details.
  3. Plan to learn faster. Are we going to deliver everything in one big release, or can we have multiple releases? How are we going to set up the individual releases? How can we learn from the users using the release (validated learning, build – measure – learn)?
  4. Plan to finish on time. Don’t release each slice. Divide your release in an opening game (see it work), mid game (make it better) and an end game (make it releasable). Include risk stories to make risk visible.
  5. You already know how. Based on the previous chapters you now have a pretty good understanding of a story map. In this chapter you can prove you really understand it by creating a story map of all the things you have done this morning when you woke up until you’ve gotten ready for work. Will be fun, definitely when you do this with some more people and start to discuss differences. QRC (story mapping, 190606) v1.0To download: QRC (story mapping, 190606) v1.0
  6. The real story about stories. The founding father of the idea of stories was Kent Beck (eXtreme Programming). His idea was to stop working so hard on writing the perfect document, and to get to tell stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used. Ron Jeffries describe the story process as 3 C’s: Card, Conversation and Conformation.
  7. Telling better stories. Stay away from template zombies. Start talking about the who, what, why, what goes wrong, what happens outside the software, questions and assumptions, better solutions, how and how long.
  8. It’s not all on the card. You could scribble everything you like on a card. E.g. short title, description, story number, estimate, size or budget, value, metrics, dependencies, status, dates. You could even flip the chart to the back and write additional notes or bulleted acceptance criteria.
  9. The card is just the beginning. The 3 C’s are just the beginning. Two more C’s complete it: Construction and Consequences (evaluate with team first, then with business stakeholders and in tests with customers and users).
  10. Bake stories like cake. Ask lots of who, what, and why questions. Ask about the context (where, when, how many). Talk long enough to build shared understanding. If the story describes a solution that’s too expensive, consider a different solution that helps you reach the goal. If the story describes a solution that’s affordable but big, break it into smaller parts that allow you to evaluate and see progress sooner.
  11. Rock breaking. A right-sized story from a user’s perspective is one that fulfills a need. A right-sized story from a development team’s perspective is one that takes just a few days to build and test. A right-sized story from a business perspective is one that helps a business achieve a business outcome. Conversations are one of the best tools for breaking down big stories.
  12. Rock breakers. A small, cross-functional team led by a product owner orchestrates product discovery work. The ideal size for a product discovery team is two to four people – dinner-conversation-sized so the members can quickly build shared understanding. The solution we want is valuable, feasible and usable (the three concerns; triad).
  13. Start with opportunities. Have conversations about opportunities and decide whether to move forward with them or trash them. If you agree to take on everything you are not helping anyone. Aggressively trash opportunities that don’t offer much hope of creating the outcomes you hope for.
  14. Using discovery to build shared understanding. Discovery work isn’t about building shippable software, it’s about learning. What problems are we really solving? What solutions could be valuable? What does a usable solution look like? What’s feasible to build given the time and tools that we have? Use four essential steps to discovery: frame the idea, understand customers and users, envision your solution and minimize and plan.
  15. Using discovery for validated learning. During discovery and validated learning, you may be telling stories constantly, breaking ideas and work down into small buildable pieces and agreeing on exactly what to build. You’ll be doing it so fast that it won’t be clear you’re using stories. But you are.
  16. Refine, define, and build. Play the Good-Better-Best game for splitting stories (What’s good enough to get things working, what would make it better, what’s the best version we can imagine?).
  17. Stories are actually like asteroids. Break stories down progressively, and just in time. To avoid a backlog filled with lots of tiny stories, take a bundle of stories that go together, and write all their titles on a single card as a bulleted list. Summarize those tittles with a single title on your new card and you’ve got one big story. In this way you can clean-up your backlog.
  18. Learn from everything you build. There are many opportunities to learn: review as a team, review with others in your organization, learn from users, learn from release to users, and use a map to evaluate release readiness.

Conclusion: A must read for product owners and agile team members. It’s the most complete book on story mapping I have read, and it will answer all (or most of) your questions regarding user story mapping.The book will definitely help you to use story mapping to deliver results that satisfy your customers.

To order (Managementboek): User Story Mapping

 To order (Bol.com): User Story Mapping

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

 

 

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

 

 

 

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