Release Management as a Competitive Advantage

“Delivery focussed”, “Getting the job done”, “Results driven”, “The proof is in the pudding” – we are all familiar with these phrases and in Information Technology it means getting the solutions into operations through effective Release Management, quickly.

In the increasingly competitive market, where digital is enabling rapid change, time to market is king. Translated into IT terms – you must get your solution into production before the competition does through an effective ability to do frequent releases. Doing frequent releases benefit teams as features can be validated earlier and bugs detected easily. The smaller iteration cycles provide flexibility, making adjustments to unforeseen scope changes easier and reducing the overall risk of change.

IT teams with well governed agile and robust release management practices have a significant competitive advantage. This advantage materialises through self-managed teams consisting of highly skilled technologist who collaborative work according to a team defined release management process, that continuously improves through constructive feedback loops and corrective actions.

The process of implementing such agile practices, can be challenging as building software becomes increasingly more complex due to factors such as technical debt, increasing legacy code, resource movements, globally distributed development teams, and the increasing number of platforms to be supported.

To realise this advantage, an organisation must first optimise its release management process and identify the most appropriate platform and release management tools.

Here are three well known trends that every technology team can use to optimise delivery:

1. Agile delivery practises – with automation at the core 

So you have adopted an agile delivery methodology and your re having daily scrum meetings – but you know that is not enough. Sprint planning as well as review and retrospection are all essential elements for a successful release, but in order to gain substantial and meaningful deliverables within the time constraints of agile iterations, you need to invest in automation.

An automation ability bring measurable benefits to the delivery team as it reduces the pressure on people in minimising human error and increasing overall productivity and delivery quality into your environment that shows in key metrics like team velocity. Another benefit automation introduces is consistent and repeatable process, enabling easily scalable teams while reducing errors and release times. Agile delivery practices (see “Executive Summary of 4 commonly used Agile Methodologies“) all embrace and promote the use of automation across the delivery lifecycle, especially in build, test and deployment automation. Proper automation support delivery teams in reducing overhead of time consuming repetitive tasks in configuration and testing so them can focus on the core of customer centric product/service development with quality build in. Also readHow to Innovate to stay Relevant“; “Agile Software Development – What Business Executives need to know” for further insight in Agile methodologies…

Example:

Code Repository (version Control) –> Automated Integration –> Automated Deployment of changes to Test Environments –> Platform & Environment Changes automated build into Testbed –> Automated Build Acceptance Tests –> Automated Release

When a software developer commits changes to the version control, these changes automatically get integrated with the rest of the modules. Integrated assembles are then automatically deployed to a test environment. If there are changes to the platform or the environment, the environment gets automatically built and deployed on test bed. Next, build acceptance tests are automatically kicked off, which would include capacity tests, performance, and reliability tests. Developers and/or leads are notified only when something fails. Therefore, the focus remains on core development and not just on other overhead activities. Of course, there will be some manual check points that the release management team will have to pass in order to trigger next the phase, but each activity within this deployment pipeline can be more or less automated. As your software passes all quality checkpoints, product version releases are automatically pushed to the release repository from which new versions can be pulled automatically by systems or downloaded by customers.

Technologies:

  • Build Automation:  Ant, Maven, Make
  • Continuous Integration: Jenkins, Cruise Control, Bamboo
  • Test Automation: Silk Test, EggPlant, Test Complete, Coded UI
  • Continuous Deployment: Jenkins, Bamboo, Prism

2. Cloud platforms and Virtualisation as development and test environments

Today, most software products are built to support multiple platforms, be it operating systems, application servers, databases, or Internet browsers. Software development teams need to test their products in all of these environments in-house prior to releasing them to the market.

This presents the challenge of creating all of these environments as well as maintaining them. These challenges increase in complexity as development and test teams become more geographically distributed. In these circumstances, the use of cloud platforms and virtualisation helps, especially as these platforms have recently been widely adopted in all industries.

Automation on cloud and virtualised platforms enables delivery teams to rapidly spin up/down environments optimising infrastructure utilisation aligned with demand while, similar to maintaining code and configuration version history for our products, also maintain the version history of all supported platforms. Automated cloud platforms and virtualisation introduces flexibility that optimises infrastructure utilisation and the delivery footprint as demand changes – bringing savings across the overall delivery life-cycle.

Example:

When a build and release engineer changes configurations for the target platform – the operating system, database, or application server settings – the whole platform can be built and a snapshot of it created and deployed to the relevant target platforms.

Virtualisation:The virtual machine (VM) is automatically provisioned from the snapshot of base operating system VM, appropriate configurations are deployed and the rest of the platform and application components are automatically deployed.

Cloud:Using a solution provider like Rackspace to deliver Infrastructure-as-a-Service (IaaS) and Platform as a Service (PaaS), new configurations can be introduced in a new Rackspace instance is produced, instantiated, and configured as a development and test environment. This is crucial for flexibility and productivity, as it takes minutes instead of weeks to adapt to configuration changes. With automation, the process becomes repeatable, quick, and streamlines communication across different teams within the Tech-hub.

3. Distributed version control systems

Distributed version control systems (DVCS), for example GIT, Perforce or Mercurial, introduces flexibility for teams to collaborate at the code level. The fundamental design principle behind DVCS is that each user keeps a self-contained repository with complete version history on one’s local computer. There is no need for a privileged master repository, although most teams designate one as a best practice. DVCS allow developers to work offline and commit changes locally.

As developers complete their changes for an assigned story or feature set, they push their changes to the central repository as a release candidate. DVCS offers a fundamentally new way to collaborate, as  developers can commit their changes frequently without disrupting the main codebase or trunk. This becomes useful when teams are exploring new ideas or experimenting as well as enabling rapid team scalability with reduced disruption.

DVCS is a powerful enabler for the team that utilise an agile-feature-based branching strategy. This encourages development teams to continue to work on their features (branches) as they get ready, having fully tested their changes locally, to load them into next release cycle. In this scenario, developers are able to work on and merge their feature branches to a local copy of the repository.After standard reviews and quality checks will the changes then be merged into the main repository.

To conclude

Adopting these three major trends in the delivery life-cycle enables a organisation to imbed proper release management as a strategic competitive advantage. Implementing these best practices will obviously require strategic planning and an investment of time in the early phases of your project or team maturity journey – this will reduce the organisational and change management efforts to get to market quicker.

Modular Operating Model for Strategy Agility

One of life’s real pleasures, is riding a motorcycle. The sense of freedom when it is just you, machine and the open road is something only sharing enthusiast would truly understand. Inspired, I recently completed a hobby project building the Lego Set 42063. The building blocks of this Technic model constructs the BMW R1200GS Adventure motorcycle, arguably the best allrounder, adapted to handle all road conditions. The same building blocks can also be used to build a futuristic flying scooter, or shall I call it a speedster in true Star Wars style… While building the model I was marvelled by the ingeniousness of the design and how the different components come together in a final product – fit for purpose today but easily adapted to be fit for future.

Lego-Technic-modular

This made me think about business agility – how can this modular approach be used within business. We know that SOA (Service Oriented Architecture) takes a modular approach in building adaptable software application and in the talk on “Structure Technology for Success – using SOA” I explained a modular approached to design a Service Orientated Organisation (SOO), to directly contribute to the business success.

Recently I’ve also written about how to construct a business Operating Models that delivers. Such an operating model aligns the business operations with the needs of it’s customers, while it provides the agility to continuously adapt to changes in this fast changing technological ecosystem we live in. An Operating Model that delivers, fit for purpose today but easy adaptable to be fit for the future, in other words – a Modular Operating Model.

As the environment for a company changes rapidly, static operating models lack the agility to respond. Successful companies are customer centric and embrace continuous innovation to enhance the ability of the organisation to re-design it’s operations. This requires an Operating Model that incorporates the agility to be responsive to changes in business strategy and customer needs. A modular operating model enables agility in business operations with a design that can respond to change by defining standard building blocks and how to dynamically combine them. Modular blocks (with the specific operational complexity contained) simplifies managing complexity. This reduces the time to produce a new operational outcome, irrespective of this being a new services, product or just an efficiency improvement within an existing value chain.  An example of applying modular thinking to a operational delivery methodology is covered in the blog post: “How to Innovate to stay Relevant”. In combining the core principles and benefits of three different delivery methodologies, Design Thinking, Lean Startup and Agile Scrum as modular building blocks, a delivery methodology are constructed that ensures rapid delivery of innovation into customer centric revenue channels while optimising the chances of success through continuous alignment with customer and market demand.

A modular operating model imbeds operational agility through the ability to use, re-use, plug and play different capabilities, processes and resources (building blocks) tech-TOMto easily produce new business outcomes without having to deal with the complexities which are already defined within the individual building blocks – just like a Lego set using the same set of standardised and pre-defined blocks to build completely different things. The focus is on re-using the blocks and not on the design of the blocks itself. Off course a lot of thinking has gone into the design of the different building blocks, but through re-using the same block designs, the model design time is focussed on a new/different outcome and not on a component of an outcome.

Designing modular capabilities, processes and resources that are used to design operating models have benefits not just in efficiencies and savings through economies of scale, but also in the reduction of time to market. These benefits are easier to accomplish in larger multi-divisional organisation with multiple operating models or organisations with complex operating models bringing together multiple organisations and different locations, where the re-use of modular operating model blocks bring demonstrable efficiencies.

 

WIP…

An Operating Model that Delivers

Every organisation that I have worked with around the world, whether it is in London, Johannesburg, Sydney, Singapore, Dallas, Kuala Lumpir, Las-Vegas, Nairobi or New York, there was always reference to a Target Operating Model (TOM) when business leaders spoke about business strategy and performance. Yes, the TOM – the ever eluding state of euphoria when all business operations work together in harmony to deliver the business vision… Sometime in the never reaching future.

Most business transformation programmes are focussed to deliver a target operating model – transforming the business by introducing a new way of working that better aligns the business offering with it’s customer’s changing expectation. Millions in business change budgets have been invested in TOM design projects and 1000s of people have worked in these TOM projects of which some have delivered against the promise.

With the TOM as the defined deliverable, the targeted operational state and the outcome of the business transformation programme, it is very important that the designed TOM are actually fit for purpose. The TOM also has to lend itself to be easily adjustable in order to contribute to the agility of an organisation. The way the business is operating must be able to adapt to an ever changing technology driven world. The quick evolving digital world is probably the main catalyst for transformation in organisations today – read “The Digital Transformation Necessity” for further insights…

Operating Model (OM)

The Operating Model uses key inputs from the Business Model and Strategy.

The Business Model focuses on the business’ customers, the associated product and service offerings – how the organisation creates value for it’s cliental – and the commercial proposition. Within the business model the business’s revenue streams and how those are contributing to the business value chain to generate profits, are decried. In other words, the Business Model envisages the What within the organisation.

Within the Business Strategy the plan to achieve specific goals are defined, as well as the metrics required to measure how successfully these are achieved. The business goals are achieved through the daily actions as defined within the Operating Model.

Typically an Operating Model takes the What from the Business Model in conjunction with the business strategy, and defines the Why, What, How, Who and With. It is the way in which the business model and strategy is executed by conducting the day to day business operations. Execution is key as no business can be successful by just having a business strategy, the execution of the operating model delivering the business strategy is the operative ingredient of success.

In order to document and describe how an organisation functions, the Operating model usually includes business capabilities and associated processes, the products and/or services being delivered, the roles and responsibilities of people within the business and how these are organised and governed within the business, the metrics defined to manage, monitor and control the performance of the organisation and then the underpinning Technology, Information Systems and Tools the business uses in delivering it’s services and/or products.

Analogy: A good analogy to describe the Operating Model is to compare it to the engine of F1 car. In 2016 the Mercedes Silver Arrow (the fastest car, driven by Lewis Hamilton (arguably the fastest driver), did not win because of engine and reliability problems. Instead the World Championship was won by Nico Rosberg, who had a better performing engine over the whole season. Nico benefited from a better operating model – he had the processes, data, systems and the people (including himself) to win. The mechanical failures that Lewis suffered, mostly not through fault of his own, were a result of failures somewhere within his operating model.

Target Operating Model (TOM)

The Target Operating Model (TOM) is a future state version of the Operating Model. To derive the TOM, the existing Operating Model is compared with the desired future state keeping the key aspects of an operating model in mind: Why, What, How, Where, Who and With. The TOM also cover two additional key aspects: the When & Where defined within the transformation programme to evolve from current to future states.

The difference between the “as is” Operating Model and the “to be” Target Operating Model, indicates the gap that the business must bridge in the execution of its Transformation Model/Strategy – the When and Where. To achieve the Target Operating Model usually require large transformation effort, executed as change & transformation programmes and projects.

ToBe (TOM) – AsIs (OM) = Transformation Model (TM)

Why >> Business Vision & Mission

What >> Business Model (Revenue channels through Products and Services – the Value Chain)

How >> Business Values & Processes & Metrics

Who >> Roles & Responsibilities (RACI)

With >> Tools, Technology and Information

Where & When >> Transformation Model/Strategy

Defining the TOM

A methodology to compile the Target Operating Model (TOM) is summarised by the three steps shown in the diagram below:

TOM Methodology
Inputs to the methodology:

  • Business Model
  • Business Strategy
  • Current Operating Model
  • Formaly documented information, processes, resource models, strategies, statistics, metrics…
  • Information gathered through interviews, meetings, workshops…

Methodology produces TOM Outputs:

  • Business capabilities and associated processes
  • Clearly defined and monetised catalogue of the products and/or services being delivered
  • Organisation structure indicating roles and responsibilities of people within the business and how these are organised and governed
  • Metrics specifically defined to manage, monitor and control the performance of the organisation
  • Underpinning Technology, Information Systems and Tools the business uses in delivering it’s services and/or products

The outputs from this methodology covers each key aspect needed for a TOM that will deliver on the desired business outcomes. Understanding these desired outcomes and the associated goals and milestones to achieve them, is hence a fundamental prerequisite in compiling a TOM.

To Conclude

An achievable Target Operating Model, that delivers, is dependant on the execution of an overall business transformation strategy that aligns the business’ vision, mission and strategy with a future desired state in which the business should function.

Part of the TOM is this Business Transformation Model that outlines the transformation programme plan, which functionally syncs the current with the future operating states. It also outlines the execution phases required to deliver the desired outcomes, in the right place at the right time, while having the agility to continuously adapt to changes.

Only if an organisation has a strategically aligned and agile Target Operating Model in place that can achieve this, is the business in a position to successfully navigate its journey to the benefits and value growth it desires.

renierbotha Ltd has a demonstrable track record of compiling and delivering visionary Target Operating Models.

If you know that your business has to transform to stay relevant – Get in touch!

Originally written by Renier Botha in 2016 when, as Managing Director, he was pivotal in delivering the TOM for Systems Powering Healthcare Ltd.

How to Innovate to stay Relevant

Staying relevant! The biggest challenge we all face – staying relevant within our market. Relevance to your customers is what keeps you in business.

With the world changing as rapidly as it does today, mainly due to the profound influence of technology on our lives, the expectations of the consumer is changing at pace. They have access to an increasing array of choice, not just in how they spend their money but also in how they are communicating and interacting – change fueled by a digital revolution. The last thing that anyone can afford, in this fast paced race, is losing relevance – that will cost us customers or worse…

Is what you are selling today, adaptable to the continuous changing ecosystems? Does your strategy reflect that agility? How can you ensure that your business stays relevant in the digital age? We have all heard about digital transformation as a necessity, but even then, how can you ensure that you are evolving as fast as your customers and stay relevant within your market?

Business, who has a culture of continuous evolvement, aligning their products and services with the digital driven customer, is the business that stays relevant. This is the kind of business that does not require a digital transformation to realign with customer’s demand to secure their future. A customer centric focus and a culture of continuous evolution within the business, throughout the business value chain, is what assure relevance. Looking at these businesses, their ability/agility to get innovation into production, rapidly, is a core success criterion.

Not having a strategy to stay relevant is a very high and real risk to business. Traditionally we deal with risk by asking “Why?”. For continuous improvement/evolution and agility, we should instead be asking “Why not?” and by that, introduce opportunities for pilots, prototypes, experimentation and proof of concepts. Use your people as an incubator for innovation.

Sure, you have a R&D team and you are continuously finding new ways to deliver your value proposition – but getting your innovative ideas into production is cumbersome, just to discover that it is already aged and possibly absolute in a year a two. R&D is expensive and time consuming and there are no guarantees that your effort will result in a working product or desired service. Just because you have the ability to build something, does not mean that you have to build something. Focusing the scares and expensive resources on the right initiatives makes sense, right! This is why many firms are shifting from a project-minded (short term) approach to a longer-term product-minded investment and management approach.

So, how do you remain customer centric, use your staff as incubators of innovation, select the ideas that will improve your market relevance and then rapidly develop those ideas into revenue earners while shifting to a product-minded investment approach?

You could combine Design Thinking with Lean Startup and Agile Delivery…

In 2016, I was attending the Gartner Symposium where Gartner brought these concepts together very well in this illustration:

Gartner - Design-Lean-Agile 2

Instead of selecting and religiously follow one specific delivery methodology, use the best of multiple worlds to get the optimum output through the innovation lifecycle.

Design-Lean-Agile 1

Using Design Thinking (Empathise >> Define >> Ideate >> Prototype) puts the customer at the core of customer centric innovation and product/service development. Starting by empathising with the customers and defining their most pressing issues and problems, before coming up with a variety of ideas to potentially solve the problems. Each idea is considered before developing a prototype. This dramatically reduces the risk of innovation initiatives, by engaging with what people (the customer) really need and want before actually investing further in development.

Lean Startup focuses on getting a product-market fit by moving a Prototype or MVP (minimum viable product) through a cycle of Build >> Measure >> Learn. This ensures a thorough knowledge of the user of the product/service is gained through an active and measureable engagement with the customer. Customer experience and feedback is captured and used to learn and adapt resulting in an improved MVP, better aligned to the target market, after every cycle.

Finally Agile Scrum, continuing the customer centric theme, involves multiple stakeholders, especially users (customers), in every step in maturing the MVP to a product they will be happy to use. This engagement enhances transparency, which in turn grow the trust between the business (Development Team) and the customer (user) who are vested in the product’s/service’s success. Through an iterative approach, new features and changes can be delivered in an accurate and predictable timeline quickly and according to stakeholder’s priorities. This continuous product/service evolvement, with full stakeholder engagement, builds brand loyalty and ensures market relevance.

Looking at a typical innovation lifecycle you could identify three distinct stages: Idea, Prototype/MVP (Minimal Viable Product) and Product. Each of these innovation stages are complimented by some key value, gained from one of the three delivery methodologies:

Design-Lean-Agile 2

All of these methodologies, engage the stakeholders (especially the customer & user) in continuous feedback loops, measuring progress and capturing feedback to adapt and continuously improve, so maximum value creation is achieved.

No one wants to spend a lot of resource and time delivering something that adds little value and create no impact. Using this innovation methodology and associated tools, you will be building better products and service, in the eye of the user – and that’s what matters. You’ll be actively building and unlocking the potential of you’re A-team, to be involved in creating impact and value while cultivating a culture of continuous improvement.

The same methodology works very well for digital transformation programmes.

At the very least, you should be experimenting with these delivery approaches to find the sweat spot methodology for you.

Experiment to stay relevant!

Let’s Talk – renierbotha.com – Are you looking to develop an innovation strategy to be more agile and stay relevant? Do you want to achieve your goals faster? Create better business value? Build strategies to improve growth?

We can help – make contact!

Read similar articles for further insight in our Blog.

Bimodal Organisations

The continuous push towards business improvement combined with the digital revolution, that has changed the way the customer is engaging with business through the use of technology, have introduced the need for an agility in the delivery of IT services. This speed and agility in IT delivery, for the business to keep abreast of a fast evolving and innovative technology landscape and to gain an competitive advantage are not just required in the development and/or introduction of new technology into the business, but in the way “keep the lights on” IT operations are reliably delivered through stable platforms and processes enabling business growth as well.

IT Bimodal

We can agree that once systems and solutions are adopted and integrated into business operations, the business requirement for IT delivery changes with IT stability, reliability, availability and quality as key enablers to business performance optimisation. There are thus two very distinct and equally important ways or modes of delivering IT services that should seamlessly combine into the overall IT Service Operations contributing to business growth.

Gartner minted in 2016 the concept of IT Bimodal – the practise to manage two separate coherent modes of IT delivery.

Mode 1: Focussed on Stability Mode 2: Focussed on Agility
Traditional Exploratory
Sequential Non-linear
Emphasis on: Safety & Accuracy Emphasis on: Agility and Speed

Each of the delivery modes has their own set of benefits and flaws depending on the business context – ultimately the best of both worlds must be adapted as the new way in which technology delivers into business value. Businesses require agility in change without compromising the stability of operations. Change to this new way and associated new Target Operating Model (TOM) is required.

Bimodal Organisation

This transformation is not just applicable to IT but the entire organisation. IT and “the business” are the two parts of the modern digital business. “The Business” needs to adapt and change their work style (operating model) towards digital as well. This transformation by both IT and “the business”, branded by Gartner as Bimodal, is the transformation towards a new business operating model (a new way of working) embracing a common goal of strategic alignment. Full integration of IT and business are the core of a successful digital organisation competing in the digital era.

The introduction of Agile development methodologies and DevOps, led to a transformation in how technology is being delivered into business operations. IT Service Management (ITSM) and the ITIL framework have matured the operational delivery of IT services, as a business (#ITaaBusiness) or within a business while Lean Six Sigma enables business process optimisation to ultimate quality delivery excellence. But these new “agile” ways of working, today mainly applied within IT, is not enough for the full bimodal transformation. Other aspects involving the overall organisation such as business governance and strategy, management structures and organisational architecture, people (Human Capital Management – HCM), skills, competencies, culture, change management, leadership and performance management as well as the formal management of business and technology innovation and integration, form additional service areas that have to be established or transformed.

How do organisations go about defining this new Bimodal TOM? – In come Bimodal Enablement Consulting Services in short BECS.

BECS – Bimodal Enablement Consulting Services

Gartner’s definition: “An emerging market that leverages a composite set of business and technology consulting services and IP assets to achieve faster more reliable and secure, as well as business aligned, solutions in support of strategic business initiatives.”

To establish a Bimodal enabled TOM, organisations need to architect/design the organisation to be customer centric, focussing on the value adding service delivered to the client/customer – a Service Oriented Organisation (SOO) designed using a Service Oriented Architecture (SOA). This set of customer services (external facing) should relay back to a comprehensive and integrated set of supporting and enabling business services (internal facing) that can quickly and effectively enable the business to innovate and rapidly adapt and deliver to changing customer needs and the use of technology within the digital era. This journey of change, that businesses needs to undergo, is exactly what digital transformation is about – not just focused on the technology, processes, quality and customer service, but on the business holistically, starting with the people working within the business and how they add value through the development and use of the right skills and tools, learning an applying it rapidly throughout the business value chain.

A customer centric delivery approach requires the development and adoption of new ways in which work are conducted – new management structures, building and enhancing A-teams (high performing individuals and teams, getting the job done), optimised processes and the right tool sets.

BECS must address the top bimodal drivers or goals, as identified by Gartner research:

  • Deliver greater IT value to the business
  • Shorten the time to deliver solutions
  • Enable digital business strategies
  • Accelerate IT innovation
  • Transform IT talent/culture/operations
  • Increase the interaction between business and IT
  • Embrace leading-edge technologies, tools and/or practices
  • Reduce IT costs (always a favourite)
  • Change the organisation’s culture

Take Action

Are you ready, aligned and actively engaging in the digital world?

Can you accelerate change and enable revenue growth with rock-solid service and business operations?

Are you actively practicing bimodal, continuously adapting to the changing digitally empowered customer demand?

The ultimate test to determine if you are bimodal: Every business process and every enterprise system needs to work without a blip, even as more innovation and disruptors are introduced to make the business more efficient and responsive.

It is time to be a bimodal organisation!

___________Renier Botha specialises in helping organisation to optimise their ability to better integrate technology and change into their main revenue channels – make contact today.

Related post: Success – People First; Performance ImprovementAGILE – What business executives need to know #1; AGILE – What business executives need to know #2; Lean Six Sigma; The Digital Transformation Necessity; Structure Tech for Success

Lean Six Sigma – Organisational Development and Change

Directly related to business performance is the ability to change the business processes for greater efficiency and productivity while terms like specialisation, standardisation comes to mind followed by measurement, data analysis, statistical analysis, root cause analysis and finally process control and quality control.

Remember the saying by Peter Drucker: “What gets measured, gets improved”…

Improvement initiatives bring change.

A brief history of organisational change

Change management has evolved from Organisational Development OD – focused on helping people to manage change and to stay alive post the world war in the 1940S. That lead to Change Management thinking in the 70s and 80s and in parallel project management as another management process, was developed. These processes saw change as linear and hence can it be managed tightly. It starts with a burning platform and a vision to resolve the problem followed by the change journey of solving problems and overcoming obstacles. In the late 80s Appreciative Inquiry emerged changing the focus of change to “best that can be” and driving “what should be” rather than “what is wrong” and driving the “fix it”. The 1990s and 2000s brought more collaborative models and tools to manage change and solve problems and performance coaching got commonly accepted and used.

The drive to improve business performance gave life to various methodologies and frameworks for example:

  • Toyota Production System (TPS), the origins of Lean Thinking, included the prominent problem solving tools through the “five why’s”, continuous improvement, “Just in Time” production and the elimination of waste.
  • Business Process Re-engineering (BPR) which encouraged the outsourcing and off-shoring of work deemed to be non essential or too costly to perform.
  • Balance Scorecard which aims to provide a well-balanced view of the health of an organization through key performance metrics representing the financial, operational, human and environmental aspects of the business performance.
  • Project Management methodologies and frameworks: PMI, Prince2, Agile SCRUM, LEAN, KANBAN
  • Quality Control frameworks, methodologies and standards: ISO9001, Six Sigma
  • Information Technology Service Management (ITSM) frameworks: ITIL

 

Six Sigma

Six Sigma is a quality improvement approach that seeks to improve the quality of process outputs by identifying and removing the causes of defects and minimizing variability in the delivery processes. This is done through a set of quality tools management tools and statistics.

Another definition – the ability of processes to deliver a very high percentage of the output within a defined specification derived from customer specifications. A key KPI is the defect % and the process to reduce that to be within specification of tolerance – where a defect is defined as any process output that does deliver to customer requirements.

Running a process at Six Sigma quality is defined as defect levels below 3.4 defects per 1M cycles of the process!

Six Sigma principles:

  • Continuous efforts to achieve stable and predictable process outputs are vital for business success.
  • Operational business processes can be measured, analysed, improved and controlled.
  • Achieving sustained quality improvement requires commitment from the entire organization, particularly from the top management.

Each Six Sigma project has a five step sequence (DMAIC):

DMAICProblem solving approach:

D – Defining

M – Measuring

A – Analysing

I – Improving

C – Controlling

  1. Defining the problem, and setting a project goal.
  2. Measuring current process performance and collecting relevant data potential root causes.
  3. Analysing the data to investigate and verify cause-and-effect relationships. Determine what the relationships are attempt to ensure that all factors have been considered. The analysis should reveal a root cause of the defect under investigation.
  4. Improving and optimizing the current process by introducing changes that reduce or solve the impact of the identified root cause.
  5. Controlling/Monitoring the newly changed process to ensure no deviation from the expected results occur and that the new process is stable.

 

LEAN Thinking

You are lean when all you resources are used to deliver value to the end customer – nothing else. This value has to flow through the value chain without any interruptions. All activities not directly supporting in the creation and delivery of this value is considered as waste and therefore reviewed for potential elimination.

Another definition: Lean is focused on getting the rights things to the right place at the right time in the right quantity while achieving a perfect workflow that is dictated by the customers demand to deliver the goods just in time.

LEAN – Five Principles:

Lean_principles

  1. Specify value from the customer’s point of view. Start by recognizing that only a small percentage of overall time, effort and resources in a organization actually adds value to the customer.
  2. Identify and map the value chain. This is the te entire set of activities across all part of the organization involved in delivering a product or service to the customer. Where possible eliminate the steps that do not create value
  3. Create flow – your product and service should flow to the customer without any interruptions, detours or waiting – delivering customer value.
  4. Respond to customer demand (also referred to as pull). Understand the demand and optimize the process to deliver to this demand – ensuring you deliver only what the customer wants and when they want it – just in time production.
  5. Pursue perfection – all the steps link together as waste is identified – in layers as one waste rectification can expose another – and eliminated by changing / optimizing the process to ensure all assets add value to the customer.

LEAN Tools:

  • Five S (5S): A process of keeping the workplace ready for use exercising a discipline of 5 workplace practices beginning with S.
    • Sort
    • Set in order
    • Shine
    • Standardise
    • Sustain

5S optimally prepare the workplace to perform optimum tasks in the future including the idea of visual management.

  • Seven Wastes: Waste is any activity that consumes resources but do not not creates value for the customer. The purpose of seven wastes is to identify and eliminate waste in processes hence delivery greater customer value.                                              7 Catagories of Waste: Defects, Overproduction, Unnecessary transportation, Waiting, Inventory, Unnecessary Motion, Over-processing
  • Takt Time: The average rate at which a deliverable item is required to meet the customer demand. It is used to create the balance in the process between supply and demand and to help calculate the resources required to efficiently process a process just in time.
  • SMED
  • Kaizen
  • Value-Stream Mapping

Underlining the success of Lean is a culture of respect of people – at all levels. As Lean is a whole-system management methodology that requires a overall culture change to be successful – starting at the top.

 

Lean Six Sigma

General Electric (GE) adopted Six Sigma in the 1980’s – combining that with the principals adopted by the Toyota Production System (TPS), the origins of Lean Thinking provide the methodology of LEAN SIX SIGMA.

It is a complementary combination between the best of both worlds – Lean Thinking, which is focused on process flow and waste elimination and Six Sigma, which is focused on process variation and defects – driving business operational excellence.

 

Other relevant posts: Executive Overview of Agile #1 and #2

Let’s Talk – Are you looking to achieve your goals faster? Create better business value? Build strategies to improve growth? We can help – make contact!

Executive Summary of 4 commonly used Agile Methodologies

AGILE – What business executives need to know #2: Overview of 4 most commonly used Agile Methodologies

In the first article in this series we focussed on an overview of what Agile software development is and referred to the Agile SCRUM methodology to describe the agile principles.

Let’s recap – Wikipedia describes Agile Software Development as an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross functional teams and their customers / end users.  It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. For an overview see the first blog post…

Several agile delivery methodologies are in use for example: Adaptive Software Development (ASD); Agile Nodelling; Agile Unified Process (AUP); Disciplined Agile Delivery; Dynamic Systems Development Method (DSDM); Extreme Programming (XP); Feature-Driven Development (FDD); Lean Software Development (LEAN); Kanban; Rapid Application Development (RAD); Scrum; Scrumban.

This article covers a brief overview of the four most frequently used Agile Methodologies:

  • Scrum
  • Extreme Programming (XP)
  • Lean
  • Kanban

 

SCRUM

Using Scrum framework the project work is broken down into user stories (basic building blocks of agile projects – these are functional requirements explained in an in business context) which are collated in the backlog (work to be done). Stories, from the backlog, are grouped into sprints (development iteration) based on story functionality dependencies, priorities and resource capacity. The resource capacity is determined by the speed (velocity) at which the team can complete stories, which are categorised into levels of complexity and effort required to complete. Iterations are completed with fully functional deliverables for each story until all the needed stories are completed for functional solutions.

SCRUM

Scrum is based on three pillars:

  • Transparency – providing full visibility on the project progress and a clear understanding of project objectives to the project team but more importantly to the stakeholders responsible for the outcome of the project.
  • Inspection – Frequent and repetitive checks on project progress and milestones as work progresses towards the project goal. The focus of these inspections is to identify problems and differences from the project objectives as well as to identify if the objectives have changed.
  • Adaptation – Responding to the outcome of the inspections to adapt the project to realign in addressing problems and change in objectives.

Through the SCRUM methodology, four opportunities for Inspection and Adaptation are provided:

  • Sprint Retrospective
  • Daily Scrum meeting
  • Sprint review meeting
  • Sprint planning meeting

A Scrum team is made of a Product Owner, a Scrum Master and the Development Team.

Scrum activity can be summarised within the following events:

  • Sprint – a fixed time development iteration
  • Sprint Planning meetings
  • Daily Scrum meetings (Stand-Up meetings)
  • Sprint Review meetings
  • Sprint Retrospectives

 

XP – EXTREME PROGRAMMING

XP

Extreme Programming (XP) provides a set of technically rigorous, team-oriented practices such as Test Driven Development, Continuous Integration, and Pairing that empower teams to deliver high quality software, iteratively.

 

LEAN

LEAN

Lean grew from out of the Toyota manufacturing Production System (TPS). Some key elements of this methodology are:

  • Optimise the whole
  • Eliminate waste
  • Build quality in
  • Learn constantly
  • Deliver fast
  • Engage everybody
  • Keep improving

Lean five principles:

  1. Specify value from the customer’s point of view. Start by recognizing that only a small percentage of overall time, effort and resources in a organization actually adds value to the customer.
  2. Identify and map the value chain. This is the te entire set of activities across all part of the organization involved in delivering a product or service to the customer. Where possible eliminate the steps that do not create value
  3. Create flow – your product and service should flow to the customer without any interruptions, detours or waiting – delivering customer value.
  4. Respond to customer demand (also referred to as pull). Understand the demand and optimize the process to deliver to this demand – ensuring you deliver only what the customer wants and when they want it – just in time production.
  5. Pursue perfection – all the steps link together waste is identified – in layers as one waste rectification can expose another – and eliminated by changing / optimizing the process to ensure all assets add value to the customer.

 

KANBAN

Kanban is focussed the visual presentation and management of work on a kanban board to better balance the understanding of the volume of work with the available resources and the delivery workflow.

KANBAN

Six general work practices are exercised in kanban:

  • Visualisation
  • Limiting work in Progress (WIP)
  • Flow management
  • Making policies explicit
  • Using feedback loops to ensure customer and quality alignment
  • Collaborative & experimental evolution of process and solutions

By limiting WIP you are minimising waste through the elimination of multi tasking and context switching.

There is no prescription of the number of steps to follow but it should align with the natural evolution of the changes being made in resolving a problem or completing a specific peace of work.

It focuses on delivering to customer expectations and needs by promoting team collaboration including the customer.

 

A Pragmatic approach

These techniques together provide a powerful, compelling and effective software development approach that brings the needed flexibility / agility into the software development lifecycle.

Combining and borrowing components from different methodologies to find the optimum delivery method that will deliver to the needs of the organisation is key. Depending on the specific business needs/situation, these components are combined to optimise the design, development and deployment of the software.

Helpful references:

A good overview of different agile methodologies can be found on slideshare at https://www.slideshare.net/SmartBizVN/introduction-to-agile-and-lean-software-development.

 

Let’s Talk – Are you looking to achieve your goals faster? Create better business value? Build strategies to improve growth? We can help – make contact!

 

The 7 Deadly Sins Of Product Development

Guest Blog: Travis Jacobs via LinkedIn

1.   The Pregnant Woman Theory

If one woman can make a baby in 9 months, then 9 women can make a baby in 30 days.  Now you may laugh, but this is the most common problem in developing a new product. Throwing more resources at the problem and praying it goes away does not solve anything.

2.   Stepping Over A Stack Of $100 Bills To Pick Up A Penny

We can’t spend $10 on an off the shelf tool but we can spend $1,000 to develop our own, which doesn’t work and causes more problems than it solves.

Spending countless hours in useless meetings and then having a meeting to discuss why everything is overbudget and behind schedule.

3.   Champagne On A Beer Budget

Expecting everything for free and having It done yesterday. This is a very common occurrence especially when subcontractors are hired.

I want to hire an Engineer with 3 PhD’s, and 30 years of experience for minimum wage

4.   The Scalpel Is Only As Good As The Surgeon Who Uses It, Not All Tools Are Created Equally.

A Scalpel is a commodity, the surgeon who uses it to save your life is not.

Not all tools are created equally, choose the right tool for the right job, not just because that tool Is the cheapest and the “sales guy” said it would “work”.

5.   You Never Run Out Of Things That Go Wrong

There will always be an endless supply of challenges and things that go wrong. Pretending there aren’t any problems doesn’t make them go away.

6.   A Plan Is Just A List Of Stuff That Didn’t Happen & Everything Takes Longer, And Costs More Than You Planned

The battle plan is the first casualty of war, as soon as the first shot is fired the plan goes out the window. Likewise, when the first problem is encountered when developing a new product, the plan and the Gantt Chart go out the window.

7.   Good, Fast, Cheap… Pick Any Two

We never have time to do it right, but we always have time to do it over….. and over….. and over…..

I hear time and time again. Just get it done right now, we’ll fix it later. The problem is that later never comes, and the product is only “fixed” after a very expensive product recall. By then it is too late and significant market share has been lost as well as the reputation of the brand. Trying to save a few bucks in product development can cost millions in product recalls.

AGILE Software Development – What business executives need to know

AGILE Software Development – What business executives need to know

As a business executive how much do you really know about the Agile approach to software development? As the leaders within the company responsible for using technology innovation as an enabler to accelerate the business operations and improve the companies results, do you really understand your role and involvement in the technology development methodology used in your organisation? How can you direct the team if you do not understand the principals of the software development game?

All executives in businesses using an agile approach for software development must understand the basic principals, rules, practices and concepts of “Agile”. With an understanding of the methodology the software development team is following, a better understanding and appreciation of the team and their efforts are reached improving your ability to lead and direct the people involved across the business.

This series of Blog Posts provides an executive summary of the “Agile Software Development Approach” to get your tow in the water.

Agility is expected in modern software development and the customers assume that through appropriate planning, solutions are build with the ability to anticipate changes and to realign over time as requirements and needs are changing.

Agile comes from the Latin word ‘agere’ which means “to do” – it means the ability to progress and change direction quickly and effectively while remaining in full control.

Software development delivering products and solutions, usually come about through the same phases within the business:

  • A need – The business has a particular demand and/or requirement and need a new software product or changes and enhancements to existing software solutions to address this demand and deliver value to the client and/or customers.
  • Funds – Budgets are drawn up and the business secures the availability of funds required to deliver the new project
  • Project Acceptance – The business stakeholders approves the software development project and it is chartered.
  • A Plan – Project Planning and Management is the fist but also a continuous key exercise in any project.
  • Execution – Build it!
  • Acceptance and Go-Live – The business accepts the software as fit for purpose, addressing the need and it is released into production.
  • Support – The provision of operational and technical support to keep the new software working after deployment into production.

In addressing this business need, software technology development teams follow a typical cycle – The Software Development Cycle:

Requirements –> Design & Architecture –> Functional Specifications & Use Cases –> Acceptance Criteria –> Technical Specifications –> Code Engineering –> Testing –> Deploy –> User Acceptance –> Production –> Support –> Requirements for a new cycle

SWDev_Trad_Agile

In traditional software development, individual specialised groups of Business Analyst, Testers, Architects, Designers, Developers and Network Engineers completing each step by working through the full scope of the project before it is handed over to the next step. A lot of effort is spent in each of the steps and more time is spent in handing over documentation and knowledge from one step to the other until the project is done.

In agile software development, the entire project team, consisting of members from specialised groups, is responsible to complete small increments of working software that deliver value to the business. Collaboration, across the whole company and the end user, client or customer during the development of each increment, ensures the need is met. The full Software Development Lifecycle is followed in the development of each increment, which is concluded with a release of working software into production. Change is the only constant in today’s world, so the project planning is done one increment and release at a time starting with high-level functionality. More incremental releases are completed adding more detailed to the functionality until the full project scope has been completed or until the business is satisfied that the need has been addressed.

Agile project management is not meant to replace formal project management methodologies, but to compliment it.

Agile Software Development’s Prime Goal: High value, high quality software, delivered quickly and frequently!

Agile Manifesto

Agile is all about – expecting change through rapid feedback and interaction though-out the project; the ability to adapt and anticipate change events, delivering scalable components that address the stakeholder’s needs; parallel cycles of work delivery with good communication and progress feedback; keeping it simple assuming the lowest cost and simplest solution is the best; demonstrating the progress after each cycle and evaluate improvements to feedback into the next cycle.

Agile Framework

Being agile is all about being flexible and adaptable to continuous change. Agile project management can help to manage change consistently and effectively. It is all about thinking lean and making optimum use of resources as well as looking after the team though continuous interaction, coaching and mentoring to increase the performance.

Inception – Setting the project up for success

During inception all members of the team collaborate and define the outcomes of the project and what success looks like. The team grasps an understanding of the business requirements, meet the stakeholders, and compile a prioritized list of the functionality required broken down as “user stories” – later more on user stories. The high level solution design and underlining technical architecture are compiled followed by an estimating exercise defining the high-level effort required to deliver the project scope.

Iteration 0 – Preparation that enables the team to be productive from Iteration 1

In this iteration preparations of the team’s workspace, tools and infrastructure are completed.

Execution – The execution consists of a series releases that each consists of a series of time-boxed iterations – also called sprints – where the software increments are planned, built (coded and tested), deployed and demonstrated to the stakeholders.

image003

Closing – Was the business need met by this project delivery? Ensure everyone understands how the new changes introduced by the project will work in operations with appropriate handovers from the project team to the operational teams. The team does a retrospective to discuss the ‘Lessons Learned’ – What has worked well? What caused difficulties? What value and benefits were added? How accurate was the estimates? What should be done differently next time? These answers are an important feedback loop to continuous improvement.

Cycling through the iterations, the focus is on continuous improvement of the functionality, productivity and efficiency to optimize the use of funds and reduce waste. Through this constant cycle of adapting and learning, excellence becomes an reality.

Agile Methodologies: The next post give an executive overview of four of the most commonly used Agile Methodologies.

Let’s Talk – Are you looking to achieve your goals faster? Create better business value? Build strategies to improve growth? We can help – make contact!