An Agile Framework and Cultural Change

The world of today, is not the world of yesterday and the world tomorrow is not the world of today. The rapid growth in technology, communication and changes in society has meant that traditional businesses which stood the sands of times have crumbled away and new businesses have taken their place. And even these businesses with eventually crumble as innovation and disruption creates new opportunities and new businesses.

To be successful in the 21^st Century a business needs to be nimble enough to innovate and close enough to its customers to listen. The objective of this post is look at one possible methodology the Agile framework and how it can foster an innovative culture.

A definition of culture :

“the total sum of the values, customs, traditions, and meanings that make a company unique.”

What is Waterfall methodology?

To understand Agile, it is important to understand the Waterfall methodology. Waterfall methodology is also referred to as the linear-sequential life cycle model which focuses on completing a task before moving on to the next phase. Waterfall methodology works well when requirements are well documented, the product definition and technology is stable, and the project is short. Where Waterfall struggles is when requirements are not fully known, product definition or technology regularly changes. This can lead to significantly delays and costs that escalate.

Early in the 2000s, Agile was conceived for software development as an alternative to software development lifecycles methodologies such as Waterfall.

What is Agile?

Agile is an iterative approach to software development using empirical evidence. There are three pillars to empirical evidence:

Transparency: This means presenting the facts as is. All people involved—the customer, the CEO, individual contributors—are transparent in their day-to-day dealings with others. They all trust each other, and they have the courage to keep each other abreast of good news as well as bad news. Everyone strives and collectively collaborates for the common organizational objective, and no one has any hidden agenda.

Inspection: Inspection in this context is not an inspection by an inspector or an auditor but an inspection by everyone…. The inspection can be done for the product, processes, people aspects, practices, and continuous improvements….

Adaptation: Adaptation in this context is about continuous improvement, the ability to adapt based on the results of the inspection. Everyone in the organization must ask this question regularly: Are we better off than yesterday? source

The focus is to deliver functional code at the end of each Sprint. A Sprint typically lasts two weeks. The Sprint begins by agreeing on what work can be accomplished within the Sprint from a backlog of tasks. The objective of the Sprint is to deliver functional code this can be rolled out to users to be tested. By getting the code in front of users, feedback can help shape future Sprints.

Agile software development principles

The Manifesto for Agile Software Development is based on twelve principles

Customer satisfaction by early and continuous delivery of valuable software.
Welcome changing requirements, even in late development.
Deliver working software frequently (weeks rather than months).
Close, daily cooperation between businesspeople and developers.
Projects are built around motivated individuals, who should be trusted.
Face-to-face conversation is the best form of communication (co-location).
Working software is the primary measure of progress.
Sustainable development, able to maintain a constant pace.
Continuous attention to technical excellence and good design.
Simplicity—the art of maximizing the amount of work not done—is essential.
Best architectures, requirements, and designs emerge from self-organizing teams.
Regularly, the team reflects on how to become more effective and adjusts accordingly.

The benefits of Agile within software development

Speed to market – By delivering working code at the end of each Sprint and embracing ideas like MVP allows the product to get into the hands of its potential users in weeks, rather than months.
Higher customer satisfaction – engaging users and taking feedback that is incorporated into the product backlog can produce software or features that users actual want.
Control – Agile teams are self-organising and responsible. They establish their own ways of working together based upon their context, experience and any other organisational constraints. They don’t require a manager and have the trust that they will get the job done. This has been shown to motivate teams to push the boundaries.
Higher quality output– getting daily feedback and testing regularly reduces mistakes and oversights.
Transparency – providing visibility in the product backlog and active Sprint creates accountability, helps eliminate office politics and provides visibility to the organisation.
Velocity – The daily stand-ups, the retrospectives help eliminate impediments which in turn increases the velocity of the team.

Examples of Agile methodology outside software development

We have covered the principles and the benefits of Agile in software development, we can now want to look at how an Agile framework can be utilised in marketing and product development.

Growth Hacking

Sean Ellis coined the term ‘growth hacking’ in a blog post in 2010. A growth hacker is focused one single metric, how to grow a business. Using an Agile framework, in each Sprint the cross functional team develop, prioritise and test ideas for growth. The results from these tests are then used to further develop ideas to test i.e. an iterative approach. Those interested to learn more should read the growth hacking blog at growhackers.com

Design Sprints

Developed by Google Venture the design sprint is a “five-day process for answering critical business questions through design, prototyping, and testing ideas with customers.” source

A Design Sprint is split across five days with time allocated to:

Defining the problem you wish to solve.
Designing possible solutions.
Creating a hypothesis for testing.
Developing a high-fidelity prototype.
Testing with users.

What makes Designs Sprint successful can be summarised in three factors:

Using time-boxed events to streamline defining the problem and developing possible solutions.
Creating an MVP (Minimum Viable Product) from one of the possible solutions.
Testing the MVP with real user to measure success.

To learn more about Design Sprint I would recommend reading Jake Knapp book Sprint: How to solve big problems and test new ideas in just five days. Or read the post on Lego’s implementation Design Sprints at scale

Minimum Viable Product (MVP) vs Minimal Desirable Product (MDP)

A minimal viable product (MVP) is a technique where a new product is created with the least effort possible used to validate a hypothesis. MVPs allows for rapid learning at the lowest possible cost. The concept of MVP was popularized by Eric Ries, the author of the Lean Startup. He explains an MVP as,

“the idea of the minimum viable product is useful because you can say: our vision is to build a product that solves this core problem for customers and we think that for the people who are early adopters for this kind of solution, they will be the most forgiving. And they will fill in their minds the features that aren’t quite there if we give them the core, tent-pole features that point the direction of where we’re trying to go.

So, the minimum viable product is that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.”

A minimal desirable product (MDP) is focused on testing a great user/product experience with the least effort required to test. For example, creating a high-fidelity prototype would be an example of a minimal desirable product used for testing.

Andrew Chen explains the MDP process as

Understand user goals
Create a Minimum Desirable Product
Listen to users and maximize Love
Iterate to a great product experience

North Star Metric

The North Star Metric is a concept that has emerged from companies from Silicon Valley who invested in long term sustainable growth by creating and optimising that ‘a-ha’ moment with their customers. The North Star Metric is a single metric that focuses on the product’s core value. It defines the relationship between the customer problems that the product team is trying to solve (the ‘a-ha’ moment) and then the revenue that the business aims to generate by doing so. It has helped teams move beyond focusing on surface-level growth to long term customer growth as everyone and everything is focused on a single metric.

A North Star Metric may not be the flashiest number, nor is it a vanity metric, such as Facebook likes or Twitter followers. Getting one hundred new Twitter followers doesn’t equal growth. Likewise, focusing all your effort on free trial signup, will not provide insight into whether those people will actually use your product, or whether they’ll stick around when the free trial period has ended. North Star Metric is a leading (not lagging) indicator of a future business outcome that your company cares about.

Why do you need a North Star Metric

The North Star Metric provides three essential benefits:

It provides the company and its staff clarity and alignment on what needs to be optimised and what can be left alone.
It communicates in a simple single metric the progress of the product to the whole company.
It holds the company accountable for an outcome.

An Agile Culture

In this section, I want to look at how concepts of Agile can be used to define the culture of a company. By Agile I mean:

Using data over opinion – a culture that looks at market trends, carries our user research or analyses user data to make decisions over personal opinions can be seen as a culture that has adopted concepts of Agile.
Willing to test to find answers – rather than make decisions based upon on experience or decision by committee, an Agile culture focuses on validating a hypothesis.
Willing to fail – a company who is willing to test must be willing to learn when things go wrong. There is much to be learnt from failure if your is willing to listen.
Adapt to change – what worked yesterday, may not work today and tomorrow could be considered to be detrimental to the organisation. A willingness to change is essential for an Agile culture.
Start small and grow – Before allocating resources to anything, it is about iteratively testing to look for those 5mm gains that can scale.
Self-organising – an Agile culture gives autonomy to staff to make decisions and take risks.
Collaboration – an Agile culture encourages staff to share their learnings and collaborate to help move the business forward.
Flat structure – rather than having multiple levels of hierarchy and slowing down the decision-making process, Agile promotes a flat structure empowering a team to make decisions.
Performance Orientated – An Agile culture see success not as single decision or action but rather building a team who continuously strive for success. It is this relentless pursuit that drives performance.
Transparency – an Agile culture fosters a culture of sharing information and best practises, results are documented and shared throughout the organisation so the learnings can benefit all.
Servant leadership – happens when a leader primary function is to serve, putting the needs of the employees first. When staff feel valued and trusted they are motivated to perform at their best.
Standard ways of working – facilitate integration, including common languages, processes and meeting formats help to improve communication between teams

An example of an Agile Culture – Spotify’s’ Squad, Tribes and Guilds

Spotify the popular music app was launched in 2008, they owe part of their success to Agile methodology. As they scaled the business, they scaled the way they used Agile. They believe to have rules at the start and then later break them to adapt to the team’s need, giving them a firm foundation with the ability to adapt based upon needs.

The method they developed is known as Spotify Tribes. Spotify organisation is structured into Squads, Tribes, Chapter and Guilds.

Squads – Spotify staff are divided into teams consisting of 6-12 people focusing on one feature area. Each squad acts like a start-up, they are autonomous and accountable. They use MVP to release often. They resemble the Scrum team as they have Product Owner and an Agile coach, front and back end developer to deliver.

Tribes – Squads working on a related feature area form a tribe. A tribe may consist of 40 – 50 members with an upper limit of 100.

Chapter – A chapter consists of individuals from various tribes at the horizontal level of the functional organisation.

Guild – an informal group of people from different tribes who have a common interest.

The chapters and guilds allow for cross-training, problem-solving and aligning between teams.

Within the Spotify model Agile, each squad has the autonomy to decide what they would like to build, how to build it and how they will work together. Squads will also communicate with other squads to help develops solutions. As the squad is part of a tribe, there needs to be alignment with the mission, product strategy and the short-term goals.

Developing an Agile Culture

Organisations are different because they exist to fulfil different needs, exist in different verticals and have different histories. Some may be public, some may be private, some may hire less than 5 people, whilst others will have over 100,000 staff.

Developing an Agile culture can be initiated by internal or external factors.

What factors may cause a culture to change?

External factors can include:

Economic
Legal
Changes in society.
Technological changes especially when it is disruptive.
The availability of information.

Internal factors can include:

Change in management.
Internal dissatisfaction including high staff overturn.
Increasing losses or dwindling profits.
Hiring decisions.

Ways to bring about a cultural change

In this section we want to look at two different ways we can bring cultural change:

Use a top-down approach when there is change is instigated from the highest level of management within the organisation.
The bottom-up approach where you start from the grass roots to prove the value of the Agile framework and grow.

Taking a top-down approach

A top-down approach occurs when changes are made from the highest level of management which then impacts every individual throughout the organisation. Changes to culture and the direction of the organisation are complicated and can face resistance at many levels, so a key feature is a buy-in at all levels.

One of the modern-day approaches to get buy-in is to galvanise the direction of the organisation by defining the why of the organisation. The why or the purpose of the organisation helps to create a sense of belonging and meaning which is key to culture change.

The video below is Simon Sinek talking about starting with why.

An inclusive approach to determining the Why of the organisation is to allow staff from across the organisation to participate in workshops to share their uncerstanding. Everyone has a perspective and by sharing each other’s understand can lead to a common understanding of what the organisation stands for. To learn more I would suggest reading Find You Why by Simon Sinek. Once the organisation has a reason for being (it’s why) it needs a way to measure if it is moving in that direction. That’s where the idea of North Star Metric comes in. The North Start is that one metric that matter most to fulfil the why of the business.

At an organisation level, it is about setting OKRs which then feed into the North Star Metrics. Staff and then organised cross-functional teams and give them the freedom to define how to achieve their OKRs. At this level it is about fostering a mindset that will think:

I do not know the answer, but I will iterate until I find it.
I will provide visibility so as I learn the organisation will learn.
I will be authentic in my communication and being.
I will critically learn from the mistakes I make.
I am responsible for all our successes.
I will focus on the things that move us closer to the North Star Metric and not move away.

The fostering can be achieved through:

Having Agile coaches who support the transformation.
Define expectations.
Removing impediments or obstacles which delay or stop progression.
Lead by example. Organisational change comes from when what is spoken matches what is believed in the heart and acted upon.
Reward staff for innovating and working smart and not working long hours and achieve mediocre results.
Over-communicate the organisation purpose, expectations and alignment of people though Agile practices.
Establish trust throughout the organization.
Hire the people who have the right culture fit i.e. they believe in the same values of the organization.
Celebrate success.

Taking a bottom-up approach

This approach is about starting small, proving the value of the Agile framework to the organisation and scaling.

It can be started by identify an area of the business that you want to improve. Define the one key metric that matters the most to that business area. It could be a performance metric, a revenue number or something else. As long it can be measured and it is important to that area of the business.

To create a single cross-functional team who have the expertise to make it happen, doesn’t even need to be their full-time job. What is required is that the members of the team will need to:

Understand what and how an Agile framework works.
Be able to implement Agile framework within an organisation that follows a different approach.
Accept that data is more important than opinion.
Able to motivate and lead and effectively work within a cross-functional team where there is no hierarchy structure.
Be able to learn from failure.

It may take several sprints to achieve success and tools such as GV Design Sprint can be utilised. What is important from every success or failure, something is learnt. Some of the best learning can be derived from what failed. Every test, every result, all learning should be documented and shared within the organisation.

Once you have a string of success. It is needs to be decided how do you best communicate your achievements? Who do you show, and how do you show your results? Some may want a summary, some may want details, some think in numbers and graph, others on the impact on the bottom line.

To scale Agile within the organisation it is about understanding what resources are required to scale and then working with management, business leaders to acquire those resources.

In both the top-down or bottom-up approach the following three factors needs to be taken into consideration:

Focus on the customer and their needs and wants.
Keep communication open between teams. Communicate regularly and early on. With larger teams this is especially important as there are dependencies and opportunity if the teams collaborate and work together.
Keep an eye open for new opportunities or new threats and be agile and adapt.

Conclusion

Agile as a framework is based upon principles but at its core it is about trusting staff to self organise and make decisions on what should be built and tested. An Agile culture takes those principles and applies it to the organisation as a whole, giving the staff the freedom to innovate, to fail and to learn. Through testing, success can be uncovered and amplified iterative testing other possible solutions.

Photo Credits

Micheile Henderson
Pietro Mattia
Alvaro Reyes
Mike Setchell
Ross Findon