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?

Advertisements

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.

2-1

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.

2-2

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