Posts Tagged ‘Change Management’

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

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.

References:
[1] David Anderson – Kanban, Successful Evolutionary Change for Your Technology Business http://agilemanagement.net/index.php/site/kanbanbook/
[2] Mike Cottmeyer – Blending Scrum and Kanban to Create an End-to-End Agile Enterprise, http://www.leadingagile.com/2011/01/blending-scrum-and-kanban-to-create-an-end-to-end-agile-enterprise/