Applying agile to non-software development settings

“Agile” has been a buzzword in the software industry for quite some time now. These days you will be surprised to hear if an IT project is not utilizing some form of agile methodology. However, in more recent times agile has been showing up in mainstream publications touting success in various non-software project settings. The Wall Street Journal recently posted on how modern families are using agile to improve communication. Here’s a recent TED talk about again, using agile in the family. Finally recent article on Forbes about how agile is the “best kept management secret on the planet”. Clearly, people outside of software are seeing value in the ideas and principles behind agile. Culture and organisational structure  aside, what is agile that is so universally beneficial?

Let’s go back to the basic principles and philosophies behind agile and how they can be the catalyst for improvement:

  1. MVP

Minimum viable product – breaking things to manageable pieces is such a no brainer. By piece-mealing a often challenging and complex work into chunks not only improve workability, but more importantly reduce the fear and uncertainty associated with making the first step. Having something to celebrate also creates a sense of achievement, no matter how small, that boosts morale and teamwork.

  1. Feedback loops

Having key stakeholders continuously engaged is the best insurance for last minute surprises – and nobody likes surprises. Taking stakeholders along the journey also exposes them to not just the achievements but challenges faced so they understand where the time, effort and money were spent on. With a shared goal toward success, feedbacks identify all those negatives such as progress that is off track, group think, inaccurate or unrealistic requirements, poor quality delivery etc.

Agile teams do this in regular meetings called retrospectives. These meetings happen regularly (usually every 2 weeks) and the team is encouraged to talk candidly about their work and how things are going on the team. Positive things are reinforced, negative issues are discussed openly, and ideas for changes are considered and planned.

  1. Transparency

Agile teams are famous for their ‘walls’. Using a physical task board makes your team’s work more visible. Whilst tough to start this at first, creating columns for things to do, work in progress, and completed tasks can do wonders for your team’s communication and collaboration on projects. It is simple but there is something physiologically satisfying about moving a task across the board.

  1. Outcome-driven

Hands up if you intuitively think about your work in terms of output. How many features did we release? How many emails, phone calls, etc. did we make? How many ticks of approvals achieved? Us humans think about our work in terms of output because it is easy to measure (also we were told to set these measures up front, so we can call our goals ‘measurable’), but it’s not what really matters. What matters is the impact or outcome of our work – the value it creates. Maximizing the outcomes is a fundamental principle of agile and I feel it’s the most powerful.

Opposite to value is waste. One of the agile principles is around the idea of simplicity. Is the team empowered to question the value of a piece of work? Be willing to ask if and why something must be done If it is no longer valuable, be willing to see what happens if you stop doing it. Look for things that are wasteful and eliminate them. This will free you and your team up to focus on the things that drive outcomes – the things that add value.

  1. Change is constant

Eisenhower once said “Plans are worthless, once the first shot is fired, but planning is still essential” we live in a world that sees information or circumstances change at a speed never seen before. Assisted by technology, information penetrates fast and the power is squarely in the hands of consumers now. Be very cautious about making detailed long term plans that are costly to change. Getting into the rhythm and embrace changes and be agile about changing directions, requirements, deliverables, in fact, Everything.

6.  Self organsing teams

Spotify uses the principle that the ‘culture is the sum of everyone’s values and behaviours’. Thoroughbred agile lives only in an environment of empowerment and trust. I personally think there is no better way than letting the team self-organise to demonstrate the company’s commitment to empowerment and trust. People with intrinsic motivation are more committed, outcome driven, push to limited and generally happier.  Tell them the problem at hand and don’t tell people how to do things, articulate the problem, create a facilitating environment and let them surprise you with their results.

In all, these above principles and their perceived benefits I believe transcend software development projects. Be it traditional product development, BAU operations management, business improvement, incident management and problem solving, adopting some or all of these principles could change the way it sued to be and potentially deliver massive benefits with little costs.

What is your experience with agile in non IT project?

Incident Management and Agile Thinking

I recently had a very interesting conversation with a respected friend who works in incident management. The company in question is a giant in a traditional sector with mostly established and linear structure and processes. The company realises and is directly facing the impact of digital revolution and is gradually transforming itself to be prepared.

However, due to its long history, size and a diverse set of business areas, this transformation is only gaining traction after 3 or so years. Initiatives such as process redesign and streamlining became norm, cultural changes on unified purpose and shared values were introduced. Parts of IT and Operations even attempted to bring agile methodology into the scene. Not to mention the company also flexes its muscles and took over a handful of tech startups for both vertical and horizontal integration.


To be perfectly honest, I have rudimentary knowledge about incident management and operations management overall (though I completed ITIL greenbelt years ago) but I summarised some key attributes as below:

  • Its extremely time sensitive – when an incident occurs, standby teams kick in to respond, restore and recover, all along keeping the internal and external (if necessary) communication going to ensure impacted stakeholders are ‘in the know’
  • Its extremely unpredictable – incidents may occur from anywhere in the company’s value chain. Sometimes the collateral damage or flow on effect, an incident that occurred outside of the company’s remit may still be considered significant to warrant actions
  • Its extremely demanding – in a complex environment, the process needed to respond to, restore and recover from an incident must be coordinated across different stakeholder teams in different functions and perhaps in different geographical locations. This collaboration and coordination requires years of team building, finetuning processes, clear roles and responsibilities through wargaming and tackling real life events
  • Its extremely long-tailed as a process – from initial incident detection, severity assessment and escalation criteria, to allocated response, containment and communication, to incident closure, root cause analysis and problem fixing. A properly set up incident management is usually the thread connecting an otherwise disjointed set of functions
  • Its extremely data rich – what went wrong says a lot about the integrity and robustness of a process. The nature and volume of incidents is a great source for risk assessment, business cases, cost and benefit analysis and ultimately decision making on what, why and how to fix a problem

As our conversation went along, the agile-inspired part of me took over and joined force with my risk management brain. We started thinking and exploring how potentially agile and agile thinking could help the incident management team to be better at what they do. Here are some of it:

  1. A core principle of agile methodologies is to limit ‘work in progress’. Teams will agree to take on a small subset of work from the pipeline within a timeboxed period. By limiting the teams focus and attention on what is most important you enable them to complete work to the appropriate quality standards. In incident management context, its usually about completing the root cause analysis and introducing permanent fixes so similar incident do not reoccur.
  2. Another similar agile concept is to focus on the most important task at hand. Highly relevant to the incident management that had to reprioritise constantly as new incidents come to hand. The team can gain a lot of focus by understanding the pipeline. Where the incidents come from? How does it arrive in the team. Visualise it by using agile tool like leankit or trello can help identify which items are the most important and challenge the team to focus on and finish those items. By reducing the scope of work could result in a change in behaviour, delivery time and quality.
  3. Another great attribute of agile is empowerment of the team that is usually self-organised and cross functional. It may be an easy concept to adopt as the team is already embracive to the idea of working collaboratively across the teams. They understand that it is usually the key in successfully dealing with an incident
  4. An extension of across team collaboration is the concept of DevOps – continuous and dynamic change management. The company still operates under the traditional change management model where limited release windows are predetermined and production is locked down otherwise. Dedicated management layers of testing and approval points must be passed before a release becomes possible. Historic data confirms that this model is a big pain point – significant spike in incident volume follows a release window. DevOps could perhaps change this paradigm or at least improve the situation but I agree it sits beyond the remit of incident management team and requires a wholesale change in how IT operations (software development, change management, testing, service management) works.
  5. Agile teams work with the principle that plans will change; that the understanding about the work becomes better as we go along and that no amount of planning really prepares us for the road ahead. It is also true for incident management too. By working in iterations and deliver incremental values, an incident team can handle distractions and uncertainties associated with investigations much better. Hypothesis and assumptions made at the beginning are normally wrong and being flexible in delivering small fixes can help the team in solving the problem in piecemeal fashion and bring together business stakeholders along the journey. For the teams this might mean short term focus on a set of metric goals to solve a particular business problem. Just having the routine of sitting with the business and reviewing priorities is a great first step.
  6. Adopting the concept of the “Definition of Done” for common activities. Not an operations manual that no one will ever read but a collection of one-page definitions of what it means to be done with regard to a problem ticket. Make the definition of done visible and easy to use, incident managers will know when they are finished with a piece of work before moving on.
  7. The best architectures, requirements, and designs emerge from self-organizing teams. Teams that are not controlled but enabled. Teams that trust each other enough to have passionate debate and disagreement without destroying the teams culture. The worst experience for an incident manager would be presented with a piece of work that has no scope for flexibility or creativity, and worst of all to be told how long it will take. Imagine an incident team that is self-organising within the constraints of the organisation. They receive requirements that describe the incident (why), the ideal acceptance criteria (what) and they, as a team, determine the solution (how). With that trust, the team know they have spare capacity for more work and they pull work into their queue.
  8. Short time-boxes focus teams on an objective they have to meet – particularly in this highly unpredictable incident environment, the most valued attribute of the incident team may not just lie in the velocity or the volume of work, or the number of fixes they delivered? It may just be that the rest of the organisations really appreciates the predictability introduced by working in set time-boxes, or sprints, so they know incidents and their fixes are being taken care of.

I’d love to hear people who work in IT Operations, service desks, incident and problem management and engineering who can compare the way they work currently against these ideas – all of which are simple and cheap to implement. If you have experiences in overlaying agile to existing service operations, even better – please share.

Ultimately the ideas of focus, alignment, self-organisation and predictable rhythm promotes a culture of learning – about the work the team handles, about how the team performs and how the team interacts with the business. What are your thoughts?

#agile, #agile thinking, #incident management, #service management, #ITIL, #devops, #collaboration, #Rispeak

How does risk management stay relevant in a fast-evolving digital world? (Continued)

Let’s start off with a recap

Last time we discussed how innovative culture represents the most important force behind modern business success, which drives innovation in both technology and the business model that applies such technology.  We dived into the concept of agile and agile thinking being the essential ingredient for building an innovative culture. We compared agile culture and its underlying value beliefs and how they influence the ‘way of work’ for different organisations.

In the context of risk management, the differences in this culture undertone, shared values and the way of work have profound implication to the risks faced by the organisation and how these risks can be best managed. Let’s explore this using project management as a relatively straightforward example.

Maybe I should rename this post to – ‘how to deal with the inevitable agile disruption?

Project and project risk management

How an organisation runs and manages its projects says a lot about itself. All projects are subject to constraints within the boundaries of the ‘way of work’ because they must work in tandem with resources already committed – people, funding, processes, priorities, inter-dependencies and timing.

An established companies usually run projects within a clear structure of teams, roles and responsibilities, reporting lines, handoff points and decision making regime. Embedded within a formalised PMO, traditional project risk management fits into this linear project lifecycle (usually waterfall) and is anchored by clear action points (or management controls) at key milestone stages such as qualitative and quantitative risk assessment, management review and approval points.


Comparatively in a start-up agile environment, project management is turned on its head. Team are mostly cross functional with significant autonomy in deciding what and how to deliver a product or value. Non-value adding activities such as process maps and progress report are considered ‘waste’ because constant progress will render them outdated by the time they are created.

Evolved from project management, the agile thinking has been dubbed as the single most fundamental feature for most of the modern successful tech companies. In advanced agile organisations, agile way of working extends beyond project management and becomes ‘the norm’ and ‘business as usual’ reinforced by people initiatives on trust, learning, innovation, sharing and value. I have seen organisations continuously deliver products or values in squads, tribes and guilds without formal reporting lines or delegation authority.

The key risks addressed by traditional project risk management – time, cost and quality – are significantly mitigated simply by the approach advocated by agile philosophy –  Agile teams can start with a simple user story to build a minimum viable product deployed into production through short and iterative sprints dotted with regular feedback loops. Agile practitioners will know that I had omitted a whole lot of other enablers, pre-requisites and tools of agile practice. For more details, refer to here, here, here, here, and here.

So how risk management can stay relevant and add value for a company that is yet to embrace digital revolution and agile (denial), or a company in transition (embrace), or a full digital/agile organisation (improve)? From my recent experiences, these are some conversation starters:

For agile aspirants, the values may lie in

  • Education of ‘agile way of working’ through a risk lens. A better understanding will lead to better acceptance for change. I was surely confused with jargons like lean, kata, Kanban, test-driven development and feature toggles and why the team believes ‘wall walks’ is better than a ‘status report’?
  • Providing people who came from an established environment with a risk assessment of ‘going agile’. An objective and independent assessment on how key attributes such as cost, time and quality can be managed in an agile environment? Why is it ok for project team to not commit to a deadline until much later into the project?

For those in transition, the values may lie in:

  • A risk assessment on how the transition as a project can impact and deliver value to the company. Informing a decision on the necessary investment in resources, people skills and organisational restructuring to maximise the values of ‘going agile’?
  • Leveraging risk knowledge in current process and practice to identify ‘best value’ opportunity for agile adoption. Being an agile champion and a catalyst for incremental changes. Highlighting the positive risks associated with agile and the risks of inaction.
  • Do what risk managers do best naturally in promoting a collaborative culture that values trust, transparency and challenging status quo.

For those already agile equipped, the values may lie in:

  • Providing management comfort over key risk areas that conventional risk information would otherwise not be available. Particularly for C-suite executives who usually came from a traditional setting. Gone are hefty business cases, periodic status reports and approval gates, replaced with risk insights from stand-ups, wall walks, demos and retrospective reviews.
  • Qualitative risk assessment in this high velocity environment where emphasis is skewed toward stakeholder feedback that is mostly subjective? Visual risk representation such as risk burn-down chart would bridge the communication between project teams and business stakeholders.
  • Contributing to the management of the most important asset – people. Devs, Agile coaches, BAs, Product owners and senior management. How best to recruit, retain, develop and grow people in an evolving environment? How to facilitate, promote and build a culture that is conducive to agile philosophy?
  • Providing risk support to the management of operational risks associated with ever moving structure and elevated autonomy. For instance proliferated user access management, IT change management (DevOps), security and availability risk consideration within the development lifecycle, incident response and problem management.


In true agile fashion, risk managers, irrespective of the industry or the disruptive journey the company is at, must also be digital-ready and agile – trial and error, explore and continuously improvement to stay relevant and add value. What is your experience?

#agile, #project management, #project risk management, #risk management, #culture, #values

How does risk management stay relevant in a fast-evolving digital world?

Any experienced risk management professional would know it best – establishing a risk management framework is no mean feat, particularly if it’s for a ‘one of a kind’ organisation and not guided by a set of prescriptive regulation and standards. Above all the bells and whistles a risk team can build is one crucial attribute – risk management must stay relevant and add value to the achievement of the organisation’s strategic objectives.

Strategic objectives are enabled and influenced by important factors within the organisation itself –processes, projects, resources and culture. Beyond these intrinsic factors, in recent times many companies had to deal with the impacts of the digital revolution as the disruptive forces of ‘Internet’ transcend tech sector and seep into pretty much every industry. Uber for taxi, Netflix for video, Airbnb for hotel, the list goes on.

This fast and inevitable change is forcing risk professionals to renew their emphasis on ‘emerging risks’ and must now broaden their ‘feel on the pulse’ beyond immediate competitors and adjacent industries. This is introducing an additional layer to the above question – ‘How does risk management stay relevant and continue to add value to organisation’s strategic objectives (in a digital world)?’

It is obviously a complex question that doesn’t have a simple answer, so let’s peel back to the basics and explore this topic piecemeal.

Illu #1

Learn from the best

In preparing for the disruption and its impacts, organisations must understand and learn the key factors fuelling the success of many modern successful companies. One thing for sure – simply embracing and adopting new technology only gives temporary reprieve in this fast evolving world. In fact, recent research confirmed that the technology itself only disrupts to certain extent as followers embrace and adapt. It is the innovative business culture that drives constant discovery of new business model and application of technology that is the most disruptive.


Agile and agile thinking

Literature abounds on why individual or companies succeed, you don’t need to go far to be inundated with business coaches and mentors spruiking ‘how to’ guides. Here, here, here. However, many would agree that ‘agile’ thinking is universally one of the most fundamental ingredients for many success stories.

Let’s focus on this topic for now, so what is agile?

Evolved from a form of project management methodology and manufacturing, agile and agile thinking are interpreted in countless ways and applied differently. In its very essence, its reciprocal power advocates value adding behaviours, cut development cycles, facilitate informed decisions and drive continuous improvement. In an advanced agile environment, agile thinking would become so pervasive in all aspects of the organisation, defining its culture, the way of work and risks that propel its growth.

Let’s look deeper using real corporate examples

Typical of a traditional yet progressive company with mostly established processes and linear structure, a great deal of emphasis would be placed over important values such as team work, accountability, efficiency and simplification to support the execution of its strategy. Typically, most manufacturers, banks, telcos, retailer would fit to this category.

On the other hand, a tech start-up based on agile principles of being lean and people oriented would focus on more tangible and actionable values such as collaboration, empowerment, fast throughput and continuous value delivery. Team structure and formalised policies would be minimised with virtually no reporting lines and delegated authority. Examples are Spotify, REA, Pivotallabs and many more.

Illu #3

Ok, you noticed I haven’t really answered my original question. That’s for another day.

#riskmanagement, #agile, #disruption, #culture, #values, #stayrelevant, #rispeak