Posts Tagged ‘Lean’

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?

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.