Tag Archives: Agile

Blending Old and New for a bright Agile future

Future And Past On Green Road Sign

Information technology is always evolving. Everyday old paradigms are challenged and, eventually, replaced by new ones. This is what makes the IT industry so interesting and so attracting to IT professionals. This also explains the abundance of job opportunities in the industry and a never ending demand for new practices and ways of working.

The pace of change requires experienced professionals to be open-minded to what is new and patient with the younger professionals, who bring in new enthusiasm and energy, but also a share of mistakes and shortfalls that have been repeated exhaustively in the past, but are brand new for them!

Very few question today the business value of Agile when developing new IT solutions and services. However, Agile is focused on doing things in a time-boxed manner and we know that some ideas require time to mature. So, there is always an element of risk in the Agile approach, that must be identified, understood and accepted by all involved parties.

The beauty of Agile is that the solution is not necessarily expected to have been thoroughly thought through by the time it “goes live”. However, this has consequences that should be understood.

One possible scenario is that the data produced by the solution can contain defects that are difficult to correct afterwards. This represents a type of technical debt that needs to be managed by the business as well as the teams that develop and support the solution.

There are cases where data correction can be done via smart algorithms. However, in others cases, a manual work-around (i.e. re-work) might be necessary. Even worst if help is required from end-users to address the shortfall.

In this example Agile can be seen to conflict with Lean. Lean is keen to do things right the first time and looks down on re-work as one of the worst forms of waste.

Is there a solution for that?

As usual, there is no silver bullet, but Design Thinking – a method for practical and creative solution of problems whose notions can be traced back to as early as the 1970s – resonates quite well with the Agile generation, and brings in hope by helping product owners to orchestrate the support of a multi-disciplinary team to help them defining and designing what needs to be developed, i.e. “the right thing to do”.

Agile ways of working are a must and there is no way back. Practice and observation have proven that Agile is the right way to do things. However, Design Thinking and Lean values need to co-exist along with Agile, as Agile alone might not be enough to identify the right things to do.

As for us, experienced IT professionals, we must keep our eyes wide open to new practices in our day-to-day jobs, even if those practices are not that much “new”. As for the younger generation, there is a wealth of experience out there, that can be wisely and energetically leveraged. The blend of tradition and revolution, old and new, seems to be the most appropriate combination to face the challenges of information technology in the next few years.


Agile Transformation: The Minimum Viable Operation (MVO)


As more and more organisations adopt Agile practices like Scrum to deliver complex projects, old traps and organisational challenges seem to get new clothes and terminology to doom these initiatives.

Enterprise IT, and IT professionals in general, have a reputation of being too product-centric.

Whilst Scrum is one of the best known manifestations of Agile principles and values, deserving the credit for fostering a collaborative and dynamic backdrop for IT and non-IT professionals to work together, it has a natural tendency to become product-centric.

The Minimum Viable Product (MVP) – a core concept in an Agile project – remains product-centric, regardless whether you replace the P of Product with the Ps of Processes, People and Partners.

The problem is amplified when the “product” is not aimed at external consumers, like the apps that you run in your smartphone, but at internal and external corporate stakeholders that will need to change their ways of working to use the new “product”.

Organisations rely on a complex interactions and workflows in order to operate. Large organisations go further and rely on defined processes to orchestrate these interactions. These processes are usually interdependent and managed by different areas.

Initiate a complex IT project in this scenario and give each process owner the hat of a Scrum “Product Owner” and the result is very likely to be the same as 30 years ago: each one will develop their own product, taking into considerations the needs and requirements of their own process silos, ignoring the inter-dependencies and the impacts on other areas.

Add a multi-supplier environment, where parts of the operation have been outsourced to external companies, ignore contracts and the enterprise is fully equipped go down its route to delays, additional costs or even complete failure.

The good news is that there is a way to avoid the trap and use the best of Agile and Scrum in a transformation program.

Think about the Minimum Viable Operation (MVO) that would allow the organisation to test new ideas, tools, ways of working, people, suppliers and partnerships. Think about the internal and external dependencies and try to identify that minimum set of Ps that would allow the organisation to go-live with the concept.

An example in the IT Service Management (ITSM) area, traditionally process-centric, may illustrate the concept.

IT Service Management Background

IT Service Management is based on a set of interdependent processes. Change Management, Configuration Management and Service Portfolio Management are three of the processes described in ITIL, the most well know framework of IT Service Management processes.

Whilst Service Portfolio Management look at how IT Services and resources enable the business from a strategy perspective, Change and Configuration look on a more granular and technical level, accounting for and protecting the specific components required to deliver those IT Services.

Configuration Management maintains a database, known as Configuration Management Database (CMDB), with information about those components and how they are related to the IT Services.

Change Management deals with many different types of change. These changes are categorised so that the most effective workflow can be selected. Regardless of their type, all changes are recorded and assessed with regards to the exact components that need to be changed, and potential impacts to other components and services that rely on those components.

The integration and inter-dependencies between Change, Configuration and Service Portfolio Management becomes clear during change approval. At this point of the Change Management process, it is not possible to make an informed decision unless there is information regarding the components being changed (as informed by Configuration Management) and the impacted services (from Service Portfolio Management).

This shows how Change Management is dependent on CMDB and Service Portfolio information.


Suppose a large organisation wants to transform its IT Service Management practices to boost agility in Enterprise IT and decides to start with Change Management as there is an internal perception that the process is bureaucratic and is hindering agility. Suppose the transformation program includes adopting a new IT Service Management tool and re-designing other processes, apart from Change Management itself.

The organisation decides to adopt an Agile Transformation approach, based on a roadmap. The roadmap establishes three releases, with the first one delivering the Minimum Viable Operation (MVO) for the new Change Management.

The MVO for Change Management (mvCHG) should be defined in terms of:

  • the Minimum Viable Process (mvProc): a self-contained sub-set of Change Management activities;
  • the Minimum Viable Product (the traditional MVP): the minimum set of functionalities required from the tool to support those activities;
  • the Minimum Viable CMDB (mvCMDB) and the Minimum Viable Service Portfolio (mvSP): representing the minimum set of data and information required for the process to work;
  • the Minimum Viable Resources (mvR): as the minimum set of internal and supplier resources and services to perform the required activities, according with the new roles and responsibilities.

After some consideration, the organisation decides to define mvCHG around the Standard changes, as these are low risk, low impact, repeatable changes.

Because Change Management is dependent on the data from the CMDB and the Service Portfolio, the mvSP is defined as only those services for which there are standard changes, and the mvCMDB is defined as containing only the Configuration Items (CIs) associated with the Standard changes.

The mvR identifies the teams and suppliers involved in delivering Standard changes, which also helps to determine if contractual changes are required to support the MVO.

The MVP identifies the minimum features required to support the operation of Standard changes, like  to be able to select a Standard changes from a catalogue.

For the second release, the organisation decides to expand the operation to all patching changes, which requires the CMDB to be populated with all CIs that require patching.

For the third and last release, the organisation decides to operate all other types of change, including Normal and Emergency changes.


Enterprises don’t want do adopt Agile development, they want to become agile themselves. This is achieved by adopting Agile values and principles in all business functions, not only IT. Agile values and principles, supported by agile practices, lead to agile decisions and actions.

The Current Operation can be transformed into an Agile Operation though an Agile Transformation.

An Agile Transformation gives an organisation the opportunity to experience Agile values and principles during the transformation journey itself, preparing them to become agile.

Scrum is traditionally used to develop “products” such as software and process documentation. However, Scrum can also be used to deliver transformation.

It is possible to avoid the natural tendency of Agile Development to become product-centric and the natural tendency of IT Service Management to become process-centric.

The MVO allows an organisation to experience new practices, tools, partnerships and ideas as a complete and integrated system, whilst considering all aspects of the operation – not only the Product – and laying solid foundations for future expansions of scope and business value.