As we will have realized by now, DevOps is not a goal. It is merely a means (even better, a mindset) to achieve high-performance teams and organizations. DevOps enables cross-functional (x-silo) collaboration in and between your teams to support a continuously improving digital value chain. As a matter of fact, I rather speak of Value Flow than DevOps. But in the end, it doesn’t really matter how you call it. As long as you achieve your goal. So if it’s high-performance teams we want to achieve, which path leads us there?

I would say the path to high-performance has two axes: Value and Flow. If both value and flow are executed and adopted effectively, you will achieve high-performance. If there’s no flow in the team, but value is high, the organization will lack innovative power and feel bureaucratic. A team delivering low value, but high flow, focus on the wrong work, leading to burnout. A team without both flow and value is bound to become extinct.



So how can a team, or team-of-teams, deliver high value outcomes? In my opinion, just like the realization of value is a team effort, the same should apply to value definition. Specifically in complex environments, designed to deliver high-performing products and services, value is multidimensional. Surely, the business (the customer, the user) have a crucial voice in determining the required value. But we also need to utilize the knowledge and innovative strength which resides in the team and in its environment (e.g. suppliers, architecture, security). Most of the experiments and technology innovations do not come from the business. IT has an ever more relevant role in keeping the business competitive. The same goes for the prioritization of value. If we want to eliminate the burden and potential lead time damage of technical debt, IT will need to help the customer/business establish the right priorities and highlight the real value of work like refactoring or experimenting with new technology opportunities.

(If you want to learn more on how to define and measure value, please have a look at this series of blog posts from Julya van Berkel:


And what about flow? What does a team need to do to achieve a state of high flow? My experience reflects a lot from the practical application of the major principles from Don Reinertsen’s essential work ‘The Principles of Product Development Flow’. Think about the reduction of batch size, which is critical to achieving an end-to-flow in complex delivery networks. Although not all teams have an optimal batch size of 1, reducing the team’s batch size (also while deploying and releasing) has led to considerable improvements in lead times and MTTR (Mean Time To Recover).

Visualizing and limiting WIP (Work in Progress) is yet another fundamental instrument, which has given many of my teams an extreme boost in optimizing their flow. I found out that consistently visualizing the work and identifying/exploiting bottlenecks helps any team in achieving flow.

Finally, flow is achieved through eliminating as much queues as possible. In any organization queues are everywhere, eg. Product Backlogs, service desk call queues, personal to-do- lists, etcetera. The more you apply DevOps principles (such as fast feedback and multidisciplinary teams), the more you will be able to consolidate and reduce queues in the entire end-to-end system.

So, if your CIO turns to you and asks for your view on ‘how to move towards DevOps’, make sure to emphasize the need for an optimal balance between value and flow. More information on DevOps, flow and high-performance value networks, inlcuding several examples, please have a look at this recent report on DevOps and Digital Disruption.


Posted in: architecture, Business Intelligence, DevOps, Digital, Digital strategy, Innovation, IT strategy, project management, Quality Assurance, Requirements, Research, Security, Software Development, Technology Outlook, Test Driven Development, Transformation, User Experience, User Interface      
Comments: 0
Tags: , , , , , , , , , , ,


Agile is hot. Scrum is booming (and it has been for quite some time already!)

As it originates from software development, we mostly see agile methods – Scrum in particular – implemented within development teams. However, in order to actually realise the agile promise, IT operations (including support) will have to take its position in the ‘agile lifecycle’.

Agile Interruptus

We see Agile practices enrich ever more IT and business functions, such as architecture, testing and business process improvement. Nevertheless, too often IT operations are not included in this agile expansion. Agile teams usually consist of software developers, a Scrum Master (facilitator), a Product Owner (business representative), and some occasional testers. Input from operations’ perspective is rarely assured in these teams. As a direct consequence, IT falls short in fulfilling the entire delivery chain, which transforms agile into ‘agile interruptus’: three-weekly, weekly, or even daily sprints are moved to production with undesired delays, missing out on valuable user and operational feedback. Discussions on documentation, acceptance criteria for operations and support, maintainability and rigid release processes lead to waste in terms of time, misunderstanding and user dissatisfaction. That is why it is no surprise that operations (hence IT) is considered as a hindering factor, instead of a service-oriented enabler of business growth and changes.

As a matter of fact, operations has become so used to waterfall deliveries, that it tends to implement its own improvements in the same way. This causes assessments and improvement projects to be too lengthy, and their effects to become visible too late. In addition, operations traditionally hold on to rules, procedures and frameworks too tightly, leaving too little room for creativity and entrepreneurship; by applying agile principles and techniques – such as multidisciplinary teams, visual management (eg. Kanban) and Scrum (eg sprints) – in operations, it can finally get rid of its bureaucratic image.


Derived from and in line with the Agile Manifesto, four basic principles can be drawn up specifically for Agile Operations. As in the original manifesto, the rule applies here: ‘right’ is still important, yet ‘left’ is more important. For instance, compliance with the SLA is still important, but a satisfied customer is more important. The basic principles are:

•Customer satisfaction         over       SLA compliance

•Attitude & collaboration     over       certification

•Focus on results                 over       focus on activities

•Adaptivity                            over       procedures

Good Practices

Now, how do these principles come to life in actual practices? Here are some examples I have seen working at several organizations:

Appointing and mandating an Operations Owner – Agile teams have Product Owners as business representatives, the Operations Owner is part of the Agile team, and will optimize the input and interests of operations during the sprints. Topics include software maintainability, error traceability, knowledge assurance, etc.

•(Non-standard) incidents and changes are visualized on the Kanban board, structuring the Agile team’s workflows – The Operations Owner assures the input and fulfilment with the required priority, in concurrence with the Product Owner.

Requirements from operations and support perspective are included in the Definition of Done – During the subsequent sprints the team can refer to this, but foremost this provides the team with a sound understanding of the organizational interests after go-live.

The implementation of CSI (Continual Service Improvement) is enriched with agile principles and techniques – Service and process improvements take place incrementally, are visualized using Kanban, and most importantly, show a high degree of empowerment during identification and realization.

Above that, several best practices are available with regard to release and test automation, estimating and control in Agile environments, flexible resource management, etc. Of course, as much as with the renowned frameworks, it is not a matter of rigidly implementing all available Agile techniques. Instead, organization and competence development should be combined with any useful technique (cherry picking), in order to facilitate the organization in moving towards the reliable delivery of Agile IT services.


Keen to hear more about Dave’s thoughts on Agile, and his views on other topics? He will be presenting on behalf of Sogeti at the ‘Application of ALM for Today’s Business Requirements’ conference, which is taking place in London on 27th February.

Find out more about this event here.


Posted in: Agile, Events, sogeti employees, Test Methodologies      
Comments: 0
Tags: , , , , , , , , , , , , , , , , , , , , , , , ,