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 evocean.com/improvement) 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.

Explore

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.

Retrospect

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 http://agilemanagement.net/index.php/site/kanbanbook/
[2] Lean Change -Evolving Change Management by Jason Little https://leanpub.com/leanchange

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 http://www.iqnite-conferences.com/suisse/programme/programme.aspx
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