Increasing speed in product development – is your IP at risk?

Written by Philip Zollinger on . Posted in Continuous Improvement, Lean Product Development Flows

Is your IP important? If yes, then these thoughts may be of interest.

Reducing release cycles is on the agenda of most product development companies. There are many reasons why this is becoming ever more a way to keep ahead – even more so as competition is changing and coming increasingly from newcomers to the market or from market players acting nowadays in completely different domains. But what is the advantage of faster releases? Well, there are many, such as less risk, less waste, lower cost and happier customers because they get earlier what they are really asking for, or they’re able to harvest the benefits from new innovations earlier.

This increasing speed also impacts organisations enhancing and intensifying the cooperation with partners and suppliers. Consequently, keeping up with this speed and putting measures in place to protect the Intellectual Property (IP) is ever more becoming a challenge for the security office. With speed increasing the dynamics increase as well, and static measures become fast a burden and can lead to frustrated development teams not advancing as fast as they could.

While increasing the speed in development it is very likely that processes need to be reassessed, as automating and improving activities is only one part of the picture. When looking at the delivery pipeline holistically and looking at it as a development stream (like in the eyes of Value Mapping in lean thinking), most delivery pipelines are very likely to be 30% doing and 70% waiting. The doing can be optimised through automation but in order to optimise the waiting, processes changes are needed which usually have an impact on the organisation. The desire to do this can be considered to be a major goal for every company as it also helps keeping remediation fast. In a DevOps scenario you should be looking at the paradigm of infrastructure as code, i.e. to automate the complete deployment process as this not only increases speed but also helps with respect to security since any attacks on your running system can be more easily remediated.

From a security standpoint Forrester says that the continuous delivery paradigm is seen more like a continuous friction or nagging. (Forrester: Secure DevOps – Overcoming the risk of modern Service Delivery). According to a study, 75% of attacks are successfully done in days, whereas only 25% of those are detected in days. And I would claim that this is getting even worse. Traditional security measures are not working sufficiently. Forrester again thinks that most organisations are still using technologies of the 90s, mainly based on the fixed perimeter paradigm – outdated and no more applicable, the perimeter is DEAD. Firewalls are no more scalable to the extranet. Identity and access management is important, but is becoming ever more a challenge especially in large co-operations due to complexity and dynamics. Lately I heard from one of our customers that he needed to wait at least a week to be granted access … a situation which could easily kill the existence of small innovative companies. Further, the “kidnapping” of accounts is becoming ever more an issue and even if two factor authentication will help – is it really the solution? All these measures are static and do not really help in surfacing threats.

Finally, security is still working mostly in silos (security, development, production). A more holistic approach is required – in every sense of the word. Security aspects need to be integrated in all aspects. A more real-time analysis on the data and more is required, and the analysis needs to be done on every file, ever user, every interaction. Thus the analysis needs to support large data amounts from various sources. Those who are acting in this field will for sure bring benefit to the challenges which most security responsible are facing.

What are your thoughts on this subject?

Visualize – Collaborate – Automate

Written by Philip Zollinger on . Posted in Continuous Improvement, Lean & Agile Product Development, Lean Product Development Flows

I would like to give some background to our headline „Visualize, Collaborate, Automate“ we introduced following our slogan „challenging complexity – increasing agility“, which of course is still true. However, we wanted to bring more value to our heading as we strongly believe that the three pillars visualisation, collaboration and automation are integral values to the benefits of all our services in improving product development and your quest for continuous improvement.

Since the founding of EVOCEAN almost 10 years back we have been focusing on leveraging product development through experience, techniques and tools. It has been the combination of all three values which created the greatest leverage. Let me iterate today what we understand by these three terms. We will be giving examples in future blogs.

First of all, let’s talk about visualisation. It is essential to know that the term’s meaning depends on the context and has more than one dimension. What we understand by visualisation is – on the one hand – the abstraction in graphics, models, the graphical synthesis in user interfaces, i.e. user experience, and – more generally – a concept helping to visualise complexity. We believe in layers, in different views, each one of them having its benefit for its special purpose. Or to say it in Einstein’s words: “Make it as simple as possible, but not simpler.” As expressed in the term „simplexity“, we are convinced that complexity is inherent and we need ways to manage it (refer also to systems engineering). In future, you will hear more from us in the context of visual management. We believe very strongly that visualisation helps a lot in making decisions earlier, thus helping to validate your tasks earlier. Especially in innovation projects early feedbacks are very important. In another dimension we also feel strongly about models in the context of Model Driven Development or Model Based Systems Engineering. Models are a way to visualize and in further steps to execute, i.e. they are also a basis to generate code, which leads us directly to the automation part.

Automation is always part of an improvement. However, be aware that automation will only improve your activities and make them faster if done manually today, but sometimes you need more profound changes – i.e. adjusting your business model or, in the context of products, its architecture. In all these tasks and with respect to increasing your speed, automation shortens release cycles and reduces time to market to stay ahead of your ever increasing competition.

Collaboration is key for success and is becoming ever more important. If you cannot access your data easily, cannot share, trace, collaborate with others easily, it will be tough – because while speed increases, parallel activities increase and thus teamwork gains weight. Changes need to be transparent and traceable. Having an infrastructure which supports this helps you reducing mundane non-valuable tasks and enables to excel in your product development.

In this sense I ask you to think about how visualisation , collaboration and automation will help you.

Continuous Improvement: Product development as change project

Written by Blaise Rey-Mermet on . Posted in Change Management, Continuous Improvement

I am sharing this material from our continuous improvement site (the original post is here on this blog since I was discussing this topic on other places and started to collect comments. So the blog is a good place for it!

This is a short overview of the steps we apply to start continuous improvement in a software or product development team. Instead of applying complicated, unsuitable procedures, collect information about your organization and start a step-wise improvement project based on actual needs and competencies.

Start with an improvements backlog

You need to prepare your organization for the change. The change receives a direction – with the vision, which entails the goals as well as their value for the customers and the organization. Start by carefully observing and collecting needs and motivations for change. Meet all stakeholders, attend their restrospecive meetings and perform interviews. Prioritize the topics to address, and build a first version of a list of improvements ( the improvement backlog). Do this as an agile project to learn and adapt your improvement backlog as you move forward.

Build on strengths

At the beginning of every improvement project, carefully build a picture of the actual situation. What is already working fine? What can be kept and propagated between projects? Get a balanced view from your team about what they think is most important and the different objectives they want to achieve. If the team stands behind the aimed objectives, it will embrace the change emotionally.


When establishing new work practices, techniques and tools, bear in mind that development teams do not act in predefined patterns: deploy only rough workflows, general goals and guidelines. Allow space for the project teams to tailor the techniques according to their own needs. You must ensure an open communication. Share the improvement backlog with everyone who will be affected and listen to their comments.

Give it a try!

Ask the early adopters from the different units to pilot the initial solutions in their own projects. They are the most capable persons to gain practical experience, adapt the development practices and then optimize the way they work.
Make sure that the improvement is not tailored to a single person or project.

Visualize progresses

Visualize your team’s every-days tasks to make progresses and bottlenecks apparent. Use simple Task Boards or Kanban Boards as a quick way to get an objective view of what works and what not. You can then improve the work practices accordingly.

Eliminate waste

Changing is not only about adding new techniques and tools. It is also about departing from old habits that are not anymore useful.

Anchor the change in everyday life

Ask the participants of the first pilot to deploy the improved practices to other projects and to communicate their personal experience to their peers. They can also help their peers to tailor the practice to new projects.
Let the participants and the structure vary when the number of projects involved is growing. Communicate new successes and advantages of deploying the new practices to the complete organization.


A periodic retrospective is important to learn from your experiences. Use the experience gained during the piloting and introduction of new practices to adapt them. Compare the picture of where you are to the one of where you want to be; the difference between the two is the focus of your next improvement step!

Feel free to comment or share your experience.

Read more:
[1] David Anderson – Kanban, Successful Evolutionary Change for Your Technology Business
[2] Lean Change -Evolving Change Management by Jason Little

Agile Configuration Management – overview

Written by Blaise Rey-Mermet on . Posted in Agile Configuration Management


What is it? Configuration Management (CM) plays a central role to keep a development team synchronized. A classical definition can be found for example in CMMI for development: “The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.“Common configuration Management practices are:

  • Identifying and organizing the configuration items (configuration items: work products that undergoes changes during the product lifecycle and needs to be maintained, e.g. software code, documentation, requirements, and more)
  • Maintaining change requests and systematically controlling the changes to the configuration items
  • Managing the status of configuration items
  • Creating and managing product baselines (baseline: a set of specifications or work products that has been formally reviewed and agreed on, which thereafter serves as the basis for further development)


Relationship between versions of work products and baselines

Relationship between versions of work products and baselines

Lean / Agile Configuration Management (CM) Concepts The goals of applying lean and agile principle to CM are

  • to reduce the development time by avoiding waste and delays in the development process,
  • and to get fast feedback about the integration and quality of the product.

An important point to remember is that a lean configuration management process is also continuously adapted and improved. For the CM process to profit from the lean and agile software development principles, we should keep in mind the following aspects:

  • Add support for parallel multiple development branches, because large programs will be organized in a set small agile teams.
  • Avoid centralized Change Control Boards (CCB) that control all changes – Instead control non-strategic decisions on changes in the distributed organization of Scrums and using the cadence of the Sprints. Reserve centralized decisions for changes that impacts the whole program or organization.
  • Let the agile team assumes the CM role instead of a dedicated Configuration Manager. The daily management of configuration items can be handled by the self-organizing team, while the Configuration Manager at the program level defines enterprise-wide aspects such as a CM strategy and CM tools, and support the teams when needed.
  • Use automated tools – Automated continuous integration helps to reduce the integration and testing delays and allow quick feedback about the product quality.
  • Continuously observe and adapt the CM tools and process. For example, avoid complex branching or baselining mechanism if your team does not need them, or observe where long build times are slowing down the team and improve these procedures.
Roles Configuration Manager
This describes the role of the Configuration Manager at the Project or Agile Team Level. The Configuration Manager will typically:

  • Adapt the CM Plan with assistance from the (agile) team, the IT project manager or Scrum Master. Communicate the CM Plan to the team.
  • Ensure team compliance with CM Handbook and CM Plan.
  • Manage the CM System and the Configuration Libraries
  • Identify the configuration item,
  • Control configuration
Read more  [1] Configuration Management Best Practices: Practical Methods That Work in the Real World  – Bob Aiello, Leslie Sachs – Addison Wesley Pub Co Inc (10. August 2010)
[2] Practical Perforce von Laura Wingerd von O’Reilly Media (25. November 2005). This book describes in particular branching and merging in agile environments.


Continuous improvement in development projects: games for behavioural change

Written by Blaise Rey-Mermet on . Posted in Change Management

Games for behavioural changeThe majority of projects possess the technological competence, resources, and intellectual capacity to succeed, yet many of these projects fail or encounter significant difficulties. The number one cause of these difficulties is the inability of team members to work together effectively to solve critical problems. Therefore for teams to succeed the human aspects of teams must be taken into account.
The idea being that a big component of continuous improvement is about a series of behavioural modifications.  We investigate the important behavioural concepts by doing a review of relevant behavioural experiments and experience.

Our workshop
Everyone involved in teamwork, who is interested in learning about the characteristics of effective teams and techniques for continuous improvement towards high quality and high efficiency development teams is invited to join our workshop at IQNITE SUISSE 2012 THE CONFERENCE FOR SOFTWARE QUALITY AND TESTING, 19 June 2012, IATA Geneva Conference Center
In the workshop we discussed:

  • Characteristics of effectively functioning team
  • Motivation, dysfunctional and functional behaviours of team members
  • Continuous improvement
  • The nature of successful collaborative interactions

Participants  learned:

  • The necessary characteristics of successful teams
  • The basic principles of continuous improvement
  • A set of game based techniques for fostering successful interactions

Kanban Lean techniques applied to change requests management

Written by Blaise Rey-Mermet on . Posted in Agile Configuration Management

When maintaining and developing a large software system, the many change requests and service requests coming from the support (including bugs and incidents) are usually solved as soon as possible by the production team. The requests that comes from the sales and R&D and contain new customer needs (as opposed to let’s say: bugs) must be examined and passed to the development team.

Why Lean Change Request Management?

For our system, dozens of requests are raised every day, so we have a proper change request management in place. As the change management team gets overloaded, we asked ourselves how to apply Kanban and Lean techniques (in particular limiting and measuring the work in progress) to balance speed and quality.

Kanban board for Change Request Management

Kanban board for Change Request Management


How to do it?

We are experimenting with the following set of principles:

  • Maintain a prioritized entry queue: The change requests are first roughly estimated and placed in a request queue until the Change Management Team pulls them. The queue is roughly prioritized by value and urgency. There is no limit to the work in progress (WIP) here, since this is the initial request queue. Emergency requests are directly handled in a dedicated flow.
  • Limit the amount of Requests in progress: The prioritized requests are pulled from the queue by the change request management team according to the team’s capacity or work in progress limit (WIP). Change Requests and User Stories are analyzed. Requests that are sufficiently understood are pulled by the development team. This makes capacity free for new Change Requests.
  • Avoid early commitment on the deadline: We stop to call the changes a “2 days change” or “10 days change” from the start. Estimation is done with the collaboration of development team once a common understanding is reached.
  • We add a different flow for requests with fixed deadlines and for emergency requests.
  • Formulate the business value to make them understandable and valuable. For example:
    Increase / Protect / Promote <something of value>
    Decrease <something reducing the value>
    Don’t forget to estimate the effort, the impact and list the risks.
  • Add examples whenever useful to make them understandable and serve as acceptance test, such as:
    Given <precondition>
    When <action>
    Then <resulting action>

As we will gain more experience, we surely will have to adapt. So far, it sounds logical to apply some lean techniques here, since there is some effort to be done for each single request and we can’t control the amount of requests we get. With some lean and agile techniques, we can process all requests in sufficient detail depending on their priority, find the highest sustainable speed and enjoy our weekends.

Mixing requirements techniques and wrapping them with Kanban.

Written by Blaise Rey-Mermet on . Posted in Agile Requirements Management, Lean & Agile Product Development

cooking session with light - blend
With motivated colleagues, we are helping other development teams in one large IT organization to improve business analysis and project management. As we meet the diverse teams (from business analysis up to the implementation and production teams) we find various methods of development such as the Unified Process or the V-Model. These proceses have been defined as standard by the management and partly established. Despite that most team are struggling under a long list of high priority requirements and changes, some benefits of the deployed process are visible. It is therefore not an option to replace the established processes with a new agile process.

Instead of replacing your development processe, improve it with Kanban.

This matches the situations described by David Anderson [1]. By establishing a Pull System to limit the work-in-progress and balance the demand against the capacity of the team. The first effect will be to visualize inefficiencies; we can then improve the processes accordingly.

There is logically no predefined way to tailor the existing process with Kanban, since it will depend on where your teams needs an improvement, but in general it makes it easier to

  1. keep the process in place for the overall control of the project, and manage the work load with a pull system,
  2. then use a simpler process for the daily work, Scrum if you like, and also control its flow with Kanban.

At the project / product level, keep the established process as appropriated, to control the flow and add Kanban as pull system.

At the team level use Kanban to drive the work.

You will need to adapt the requirements at all levels (user requirements, product requirements). A possible solution is to apply User Stories and Tasks at the team level and group them into large Use Cases at the project level to understand overall product. Read more on blending Kanban and other processes: Mike Cottmeyer [2]

Key points:

  • You may not need to throw away the established processes – improve them with Kanban
  • Instead of replacing Use Cases with User Stories – apply them at different levels
  • Kanban enables improvements with minimal resistance.
  • Big-bang changes do not work – Kanban enables continuous improvements.

Feel free to comment or discuss your experience about tailoring Kanban and other development processes.

[1] David Anderson – Kanban, Successful Evolutionary Change for Your Technology Business
[2] Mike Cottmeyer – Blending Scrum and Kanban to Create an End-to-End Agile Enterprise,

Tracing user stories and code – why is this valuable

Written by Blaise Rey-Mermet on . Posted in Agile Requirements Management, Lean & Agile Product Development

Establishing and maintaining traceability between the requirements and the product is valuable not only for critical system (and most systems are at least critical for your business) but also for any system that you intend to maintain and improve after their initial deployment. Traceability is often seen as expensive and politically sensitive since agile teams tend to consider that the requirements are not a part of the delivered product. So is tracing them waste?

What is it?
By tracing requirements, I mean tracing the requirements up to the delivered product (software, electronic, mechanic). For example acc. to CMMI [see Ref: CMMI]: Requirements traceability: “A discernable association between requirements and related requirements, implementations, and verifications.”

Why tracing requirements?

  • This is necessary if you consider that the requirements are useful to understand and maintain the product – which is not such a strange idea. There is information in the user stories that is not documented in the code: the “why”, the purpose and value of a specific feature. Losing this information makes it very hard to understand the impact of requirements changes on the product.
  • For complex systems, none of the original developer will remember the original purpose of each part of the product. Keeping a trace to the product requirement does this.
  • It is essential to establish and continuously improve organizational knowledge about the product. Team members can understand the original intend of a specific feature without having to keep asking the lead architect for help.

So – how to do it?

  • Simplify: Define a simple strategy (what is traced with what, on a graph). Trace only what is useful– what you are willing to maintain. Then do it systematically.
  • Automate: don’t try this without some kind of (Requirement Management) tool. In regulated product development, standards require that a product is completely specified. The users’ needs must trace to specifications that define the system required to satisfy those needs. Nothing should have been added or omitted. Requirements management tools are necessary to establish and maintain this level of consistency.

A possible traceability strategy for User Stories: The traceability between the product and the requirements can be supported by keeping a record of the earlier stories, tasks and functional tests. Before establishing new traces, look for what you may already trace without calling it so:

Sample requirements traceability between user stories and the product

  • If you systematically apply the agile practice of writing codes specifically to meet test cases, your product is indirectly traceable to the Stories through the acceptance tests.
  • A Sprint Goal satisfies a set of User Stories. At the end of the Sprint, each Sprint goal is demonstrable by a (potentially shippable) set of features. So these features and stories are indirectly traceable through the sprint goals.
  • For functional requirements, I usually systematically group stories in Use Cases and then trace the Use Cases to product specifications and code.

Depending on your product and teams, many other strategies are possible to do this in an efficient and simple way. Feel free to comment.

References: CMMI for Development, Version 1.3

Requirements for products that should not fail

Written by Blaise Rey-Mermet on . Posted in Lean & Agile Product Development

Here are the slides from my seminar “A Specific Requirements Formulation for less Risks and more Dependability” at the Embedded Computing Conference 2010 ECC . It contains some practical examples and things to remember when formulating requirements for products that should not fail.

The cooking recipe is in short to address the risk in the requirements by specifying:
• the value
• the required quality level, measurable
• who will use this
• under which conditions
• with which risks
• and what happened in the past

Get immediate feedback.
The results are requirements that you can trust.

Thanks to all attendees!

Agile Requirements: Expressing Assumptions in User Stories.

Written by Blaise Rey-Mermet on . Posted in Agile Requirements Management, Lean & Agile Product Development

Last Saturday was cold and I was at home browsing through a pile of unwrapped magazines, so I came across an article by Daniel Jackson about dependable software (see reference below). The author explains the importance of software in safety-critical equipment that we come across every day and he considers approaches that offer a greater trust in them. He defines dependable systems as follows:

“A dependable system is one you can depend on—that is, you can place your trust in it. A rational person or organization only does this with evidence that the system’s benefits far outweigh its risks. Without such evidence, a system cannot be depended on…“

In the development of critical products, we use agile practices like Scrum because they make the product more dependable and safe. In this context, the requirements play an important role.

With Scrum, we can use and adapt User Stories to help to clarify this dependability:

  • First, in Scrum, we formulate requirements in the form of User Stories to enforce verbal communication because talking (and listening carefully), writing and drawing is a more efficient and careful way to communicate.
  • Second, User Stories help us to discuss carefully with the stakeholders the purpose they want to accomplish, the value of a requirement, not the implementation details. For example by using a template like “As a … I want to … so I can ”. This is particularly helpful when testing the system: to know in which context to test it. Example of User Story, in this case the control unit of a medical device:

    As a
    patient, I want a view of the operating history for the last 24 hours in the simplest possible way so I can easily read it in low lightning conditions or when I am tired or confused.Commitments to the details can be postponed and made later when the first implementations and prototypes allow a better understanding. At this time, the constrains (or non-functional requirements) related to User Stories can be written down (just) in time for the implementation and make the requirements quantifiable.
  • Third, for dependable systems, the critical properties of this functionality, and the assumptions that could cause problems -if untrue- could be added to the Story in the same way. When discussing or writing Stories, consider expressing the critical properties and the assumptions, and add them to the Story, for example:Assumptions:
    1) Ambient luminance range: 100 to 1000 lux.
    2) Viewing distance: 20cm to 60cm

    3) For alarm signals, specific requirements shall apply.

Knowing the assumptions and intends of the User Story seems important enough to take the time to clarify this with the Product Owners. For the agile development of dependable products, just-enough details may mean clarifying the value, the constraints, assumptions and risks that make the story verifiable, and doing this at the latest possible time, when the first implemented features permits a better understanding of the product. In this way, we can balance the benefits and the risks, and implement User Stories where we are reasonably sure to understand the risks.

References: D.Jackson, A Direct Path to Dependable Software. CACM.ACM.ORG 04/2009 Vol.52 No. 4 –