The journey 

I work in a software organisation that uses Scrum to lead our development teams. Outside the development team, the business unit is structured in functional silos e.g. marketing, design etc. With the success, we had with using Scrum we believed by adopting Agile principles in other areas of the business we could change the way we work for the better.  

At the time of writing this post, I have been running an Agile squad for a few months, and these are some of the learnings I have had. 

The most important things I learnt 

If I were asked what are the top two most important things I have learnt, they would be:  

• The team – Focus on building a team so they can work in harmony   
• Test, measure & adapt – don’t assume it will be successful. Find a quick and easy to test your ideas. 

The other important thing I learnt the mission of the squad has should be: 

• Easy to understand 
• Easy to measure 
• Something possible but impossible to complete 

The principles we started with 

• Change takes time so start small  
• The squad members have responsibilities outside the squad, so do not overburden the team
• Being a member of the squad is entirely voluntary so build an amazing team to attract and retain members 

Where we started 

To build the squad, we needed people to cover every major business function (UX, user research, design, development and marketing) and some particular requirements for our business model. This way the team could act independently and deliver.  

We also had soft skills that we felt were essential for the team (happy to learn through iteration, able to accept change and able to work effectively in a team). 

It was important to get the business leader’s buy-in as members of the squad would come from their team. Once we knew what we wanted, we spoke to the team leaders and explained what we were looking for. They then spoke to their teams looking trying to match the experience of their teams, the availability of individual members and their desire to work in an Agile squad.  

The interviewing process 

Once we had a list of possible candidates it was time to speak to them. It was important to understand: 

• What are their expectations? 
• What skills do they bring to the team? 
• Are they a good match for the team e.g. do they welcome change, can they work under an Agile framework and are they interested in the projects we will work on? 
• How much time can they devote to the project? 

What I learnt from this experience: 

• Being excited does not necessarily translate to commitment to the squad. Some of the more reserved people have a deep passion for their work. 
• Agile is buzz word so it is important to clarify what it is meant by it 
• Clarify the level of participation they are comfortable with. Do they want to lead? Are they are interested in trying things outside their core skill set? Do they have any major upcoming projects coming up?

Kick-off meeting  

Once we have the team it is important to have a kick-off meeting. The objective was twofold: 

• Let everyone get to know each other 
• Outline how the squad will work  

What our kick-off meeting contained: 

• Objectives – Explain the mission of the squad and how it plays into the vision of the business. 
• Some sort of icebreaker activity – to create a space where people can open up  
• Metrics – how will we measure success and failure 
• Failing fast – ideas of MVPs 
• First steps – what are the first round of projects we will work on 

What I learnt from the experience 

• Build trust first 
• Outlining initial projects helped the team adjust to working in a squad 
• There are many smart people in the room, listen attentively

Having squad meetings 

What I learnt from having squad meetings:

• Regular squad meetups are instrumental in improving communication and collaboration 
• Ask for feedback
• Not everyone will participate in a meeting. They may prefer to share, comment or feedback after the meeting.
• Having meetings optional except the kick-off meeting respects the squad member’s time. If certain members of the squad need to attend a meeting, then it needs to be explained why we would like them to attend.  
• Publish meeting notes after the meetings to act as a reminder of the outcome of the meeting and for those who did not attend. 

Sharing is power – communication and virtual whiteboards 

People learn differently, they understand things differently, some are auditory, some are visual, and some are tactile learners. By sharing information openly, we achieved: 

• Sharing early and often helps save time in the long run.  
• If it is documented, it is easy to reference in the future. Especially when onboarding new members. 
• Sharing information creates a culture for others to share as well.  
• Helps remove follow-the-leader mindset and puts a value on the contributions of all members of the squad 

The ego and the need to be right 

Moving from a top-down approach where the highest paid opinion counts more moving to an Agile framework can be a jarring experience. The leader becomes a servant leader rather than the centre of the team. A meeting or a project can easily be derailed when a difference of opinion arises. And the only way to resolve this is through discussion and testing.  

The take-home message from this experience it can be a very humbling experience. Success in Agile is about swallowing your pride and accepting that evidence/testing is more important than your opinion.  

A shared brief 

In a business where teams are organised by function, it is typical for the business owner to produce a brief for a project. This brief will then be used by other teams to deliver on that project. In the Agile squad model, the cross-functional team meet to discuss so everyone can voice their concerns or how to optimise before it goes into production.  

What I learnt from this experience 

• Encourage critiquing of ideas as everyone has a perspective
• Meetings can easily get sidetracked. It is important to manage the discussion to be on point.  
• Use virtual whiteboards to brainstorm and track conclusions 
• Some team members will need to be encouraged to speak 
• Ask the question how do we test? 
• End the meeting with action items 
• Produce a summary write-up after the meeting and share it with the team 

Prioritisation and Impact 

One of the first exercises we ran was to rank a list of projects by impact and ease of implementation. For impact, we look at estimating revenue generated and ease of implementation we used t-shirt size to measure the level of complexity.  These were then sorted by now, next and future which gave us the pipeline.  

What I learnt from this exercise: 

• Estimating revenue is difficult, but expert help was a lifesaver 
• Using t-shirt sizes simplified the comparison between projects 
• Using now, next and future not only gave us a pipeline of activities but helped unify the team under a roadmap 

First project – the first win 

I believe it is important to take baby steps as the team comes together. Our first project was simple to implement and likely to be successful. This gave us an early win and time to come together as a team.  

MVP (minimum viable product) 

An MVP is a concept from Lean Start-up. A proof of concept is built and tested with the results of the test determining what action the squad takes. 

What I learnt from this experience 

• MVPs do save time and effort in the long run but in the short run, they can add more work for the squad. 
• A successful MVP is not a complete product. There is usually duct tape holding it together. 

Running a retrospective 

The developers run a retrospective at the end of every two-week Sprint. In our Agile squad, we don’t have Sprints, but we still use retrospectives. The purpose of the retrospective is to take stock of what has been achieved, the good, and the bad. This gives us the ability to improve. 

Everyone answers three questions  

• What should we continue to do? 
• What should we start doing? 
• What should we stop doing? 

Once everyone has spoken, we then get a vote on the top 3 areas of improvement.  

What we learnt from this experience 

• Look for themes in the feedback 
• The value of the retrospective is to act 
• Post retrospective report back on improvements made

Dealing with priorities and overload 

As the squad member had other priorities and other projects it is easy to pile on the work without understanding the impact it has. In my experience, it is better to set a target deadline that is an unrealistic fanciful deadline that looks great on a Gantt chart. More importantly, regular check-ins can help to maintain, build or slow down the momentum.  

If a key person cannot deliver: 

• Do they need help to prioritise? 
• Can we assign the work to someone else? 
• Should we focus the team on the next top priorities while we wait for them to become available? 

Definition of done 

To end I wanted to mention the importance of the definition of done. In Scrum, the definition of done is an artefact. The Scrum guide states: 

The Definition of Done creates transparency by providing everyone with a shared understanding of what work was completed as part of the Increment. If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration. 

In our squad, as we come from different specialties what we see as done can be very different from each other. This is something we are working on.

Images taken from Pixabay

Principle 8 from the Agile Manifesto

Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace indefinitely.

What is Burnout?

According to Psychology Today burnout is defined as:

Burnout is a state of emotional, mental, and often physical exhaustion brought on by prolonged or repeated stress. Though it’s most often caused by problems at work, it can also appear in other areas of life.

According to a recent Gallup study of nearly 7,500 full-time employees found that 23% of employees reported feeling burned out at work very often or always. An additional 44% reported feeling burned out sometimes.

Burnout is attributed to long hours, little downtime, and continual peer, customer, and superior surveillance. Source

Signs of Burnout

• Chronic fatigue
• Insomnia
• Physical symptoms like headaches and stomach aches
• Anger
• Detachment from co-workers and customers
• Extreme dissatisfaction with your work

Causes of Burnout

• Negative work culture
• Lack of work-life balance
• Lack of control over the direction of your career

Why does burnout exist within an organisation?

Reasons include

• Lack of prioritisation so everything is done at once
• Lack of a coherent strategy and direction
• Not distinguishing between what is urgent and what is important
• Poor management 
• Putting short term profit above people
• Treating staff as a factor of production rather than a human being

What are the implications of burnout to an organisation?

Work-related stress costs British businesses over £26 billion a year in absences, sick leave and disability benefits. 

We can look at the impact of burnouts at three levels:

• Individual cases
• Team level
• Organisational level

Individual-level 

Work-related burnout can be devastating to the individual. It can take time to recover and it can leave long term mental and physical damage. For some, it may even mean changing careers or being away from work for long periods. 

Team level 

If a team or department exists within a high-stress environment then the following issues may be seen:

• Drop-in productivity 
• High staff absenteeism 
• Demoralised teams 
• Increased staff turnover
• More mistakes are made

Organisational level 

Burnout leads to low staff morale, turnover of staff, lower product quality and ultimately impacts the bottom line. This also can negatively impact the company culture, increase the workload for all staff and could lead to legal cases as well as negative press.

Time, product features and quality

Before we look at sustained development it is important, we consider the idea of delivery.

In every project there are three factors:

• The deadline to deliver the project
• The product features that the project will deliver
• The quality of the features that are built

If the deadline is fixed and it is not possible to deliver all the features in time then we may be faced with two possible scenarios:

• Apply pressure on the team to deliver regardless of the impact it has on the team
• Compromise quality which impacts the user and builds tech debt for the technical team

Commonly the team would be expected to work longer hours to deliver. Working longer hours and trying to squeeze everything in can impact impact quality. Compromises are made to meet the deadlines, QA may not have sufficient time to full test and any feedback may not get actioned by the development team. 

From an Agile perspective quality (the definition of done) is not compromised rather we limit the number of features that can be delivered in the timeframe given. The product roadmap then maps out the order of the features that will be developed. 

What is Sustained Development?

Sustained development is one of the principles from the Agile Manifesto. According to the Agile methodology, the pace of development is set by the development team and not by managers or external parties. The team understand their capacity so they can scale up and scale down according to their circumstance. Therefore the pace of development can be continued indefinitely because it adjusts to the particular needs at the time. 

Pace of development

One of the aspects of sustained development is the ability to say no. The team has a capacity and anything above and beyond that capacity may not be done straight away. This introduces the idea of opportunity cost. Opportunity cost is the loss of other alternatives when one alternative is chosen. If you work on one story then the cost is the lost opportunity to work on another story.

One of the features of Scrum is the team is self-organising. The development team will decide what it will work on per Sprint. The product manager can set the priorities in the product backlog and explain their rationale but ultimately the developers decide what will enter the Sprint backlog. The Sprint backlog determines the pace of the development which is agreed upon by the development team. 

If the developers are on annual leave or ill, they can adjust the number of stories they commit to in that Sprint. If the dev team are trying to implement a story in new technology in the Sprint planning session can award the story a higher Fibonacci story point because of the uncertainty of a new language. This helps to protect the well-being of the team. The opposite is also true, as the team become experienced they are able to complete my stories per Sprint. 

If during the Sprint an urgent and important story is presented to the development team, the product manager and the development team will negotiate what needs to be removed from the Sprint to focus on the urgent story. This also helps to protect the well-being of the team and ensures that only the stories with the most value are developed first. 

The final example in this section is the idea of velocity and story points. Stories points are not compared between teams and it is something that is consumed within the team. What one team may classify as 5 points another may see it is as a 13-point story. It is the team that defines the amount required to deliver a story and it is not imposed upon them by an external party. They may seek external expert advice but it is the team who ultimately decide. This helps to reduce unnecessary expectation to deliver because each team is different. 

Why are development teams motivated to deliver?

While the cat’s away the mice will play. (proverb) 

If a manager is not supervising a team, it could be argued that the team will ultimately become demotivated and lose focus and not deliver. 

Within an Agile culture, we look for leaders rather than have people supervisor what other’s do. The product manager job is to motivate the team through the product vision. A team that believes in the product vision is more likely to consistently deliver than a team that is faced with a long list of to-do without any context. The product vision creates a shared value that people aspire to.

What is the benefit of sustained development?

To illustrate the benefits of sustained development we can look at three audiences within the organisation.:

Company-level

At a company level one of the key benefits to sustained development is a more stable workforce. Having a culture where crunch time is expected may in the short to middle term increase the output by staff as they are working longer hours. In the long run, such a culture leads to burnout with higher staff turnover and staff sickness. In such scenarios, it becomes rather then fully focus on growth the organisation there is a continuous demand to backfill positions. 

One of the best ways to recruit new staff is how current and staff who have left the organisation feel about the organisation. A simple search on Glassdoor on a company’s name can easily attract or repel potential employees. 

A company ability to be agile and pivot quickly in an ever-changing environment is vital. Sustained development is a part of Agile methodology which lends itself perfectly to support MVPs, lean and methodology like Evidence-Based Management. 

Team

A team that is based upon sustained development understands that there is an opportunity cost for any work that is carried out. There needs to be a ruthless focus on the most important because there is limit of what can enter a Sprint.  

Under high-pressure environments, the focus for the team is the here and now. With sustained development time can be allocated to work on future projects because not everything is about completing the backlog. Having time to focus on future projects gives autonomy to the individual to directly influence the direction of the business, and gives variety. 

As a  final example is the idea of removing impediments. An impediment is something that will slow down or stop a developer delivering a story. It could be technical or non-technical, it could be an internal or external factor to the team. Impediments can causes stress to the team members and one of the objectives of the daily stand ups is to highlight impediments. The Scrum master will identify, track and help remove impediments. It is common that the impediment may be removed by the team, but sometimes it is beyond the team. The Scrum master will then work with other teams or external parties to remove the impediments. 

Individual

In this section, we will look at two examples. Sustained development on the wellbeing of the individual and how it can help to create a growth mindset. 

• Managing wellbeing – a team or an organisation that adopts sustained development as part of an Agile framework looks to give autonomy to the employee, a feedback loop as well as a more balanced workload. These features help to reduce the possibility of burnout. 
• Growing as an individual – in a safe environment where the workload is manageable and everything is not required yesterday gives space to the individual to experiment, learn and take on more responsibilities.

Practical ways to avoid burnout using sustained development 

This section will look at practical ways to avoid burnout. 

• Avoid making commitments that do not come from the development team. This avoids putting unnecessary strain on the team. 
• When Sprint planning allocates 10-20% for non-committed time to unknown impromptu meetings etc.
• Have meetings in blocks rather than spread out through the day. Developers as well as those who create content require uninterrupted focused time. Having meetings spread out may not give the necessary to get into the flow.
• Make sure there are clear targets for each sprint. 
• End a sprint on a Friday morning. Have the sprint review and retrospective in the morning and have sprint planning on the following Monday. This leaves Friday afternoon for the team to work on something else. 
• On the Sprint planning meeting ensure the developers are given time to walk through each story so reasonable know what can be completed. The team should be comfortable saying no.
• Schedule and ensure time is set aside for the team to improve their technical skills. 
• After every three Sprints have a week where developers can work on side projects that provide business value. 
• Ensure the feedback from the retrospective is acted upon to improve the lives of the team. 
• If not every Sprint, every other Sprint or after a few Sprints the Sprint backlog should contain stories for technical debt and quality of life (QOL)
• The focus must be placed on impediments that stop or slow down delivery. 
• Keep the Sprints fun. It helps to bring people together and helps destress potential stressful situations. 

Health Check Model

One way to check the well-being of the development team is to do what is called a health check of the team. An example of a health check can be found on the Spotify engineering blog.

Image used from Pixabay

“In God we trust. All other must bring data” W Edwards Deming

 

In our previous posts we have consisted Agile as a way to find solutions to complex business problems or Agile as a company culture. The purpose of this post is to look at Evidence-Based Management, an Agile framework that looks to unify an organisation under a single strategic goal and applies Agile processes to work towards achieving that one strategic goal. It was developed and sustained by Ken Schwaber and Scrum.org.

Evidence-Based Management and Empiricism

Evidence-Based Management is based upon empiricism and looks to optimise an organisation using an incremental and iterative methodology. Empiricism is a theory that states that all knowledge comes from sensory experience rather than innate ideas or traditions. It was developed in the 17^th and 18^th Century and expounded by John Locke, George Berkeley and David Hume. Within Evidence-Based Management (EBM) there is no such thing as a guaranteed success , rather everything needs to be tested to prove its value.

What is meant by iterative is doing something again and again with the intention to improve it. Whilst incremental is making minor improvements to an existing product or service. Incremental and iterative go hand in hand as one looks to make minor improvements and the other looks to build on each improvement with another round of Improvements. Empiricism ensures that the improvements are tested to ensure that they actual improve the product or service.

Goals within Evidence-Based Management

EDM similar to North Star Metrics focuses an organisation and its staff under one overarching strategic goal.   Under that single strategic goal there are multiple intermediate and immediate goals to help to pave the way towards fulfilling the strategic goal.

The three different types of goals within EDM are:

• Strategic goal: this is something that the organisation seeks to achieve that is both aspirational and far in the future. As it is far in the future there are uncertainties, an organisation will create intermediate goals to help navigate the uncertainties.
• Intermediate goals: these are goals when completed help that the organisation move towards their strategic goal.
• Immediate Tactical goals: are near term goals for a team or a group of teams which works towards an immediate goal.

 Before embarking on the journey, it is important for an organisation to know its Starting State i.e. where the organisation is relative to the strategic goal when it starts its journey. During the journey it should be aware of its Current State where the organisation is relative to the strategic goal at the present time. It is important to remember that for a goal to be achievable it must be both measurable.

 Progression towards to the Strategic goal

As the strategic goal is far away and the path to achieve it is uncertain, an organisation will run experiments and use the results to determine their next steps. Setbacks are part of the journey and so it may change direction (intermediate and immediate goals) as long as we keep the strategic goal as our destination point.

It is also important to state without have a strategic goal guiding the direction of an organisation it is easy for the organisation to get lost and focus on non-essential areas or vanity goals.

Real-life examples

Using two examples, one in the private sector and another in the charity sector we can illustrate how a strategic goal can guide an organisation’s strategic direction.

Charity sector example

A charity defines its strategic goal to eliminate death by preventable diseases in Kenya, East Africa. That is both a difficult goal to achieve and it is inspirational.

Its intermediate goals could be to:

• Provide safe drinking water in the cities and villages.
• Run educational programs to promote good health.
• Set up and run medical clinics throughout Kenya.

Its tactical goals would take the intermediate goals and break them down into tasks that can be done by the team(s).

As an example, if our intermediate goal is to promote good health through education one of our tactical goals for a team could be:

• Book a venue for an event.
• Develop marketing material to promote the event.
• Find someone to present the event.

Once we run an event, we take the learnings from running the event and look to ways to optimise the future events. Our yardstick for optimisation could be, does the change help to eliminate preventable diseases through education?

By having different teams working on and fulfilling different tactical goals the organisation moves towards fulfilling its intermediate goal of promoting good health. Promoting good health moves the organisation towards its strategic goal of eliminate death from preventable diseases.

Private sector example

Using the private sector let us take the example of a mobile application that helps students organise their college’s lives. It generates revenue and has a product roadmap with several exciting features planned. The organisation decides it is will adopt an EDM framework and defines its strategic goal as:

To ensure all students regardless of background or disability to get the support they need to complete their education.

Let us consider what is the impact on the product road map by adopting this specific strategic goal.

A new proposed feature within the roadmap matches with the intermediate goal and the long strategic goal of the organisation.

• There is an existing tactical goal can be fulfilled or partial fulfilled by building this feature. The product manager must decide the priority of this feature relative to other items in the backlog.
• There is no existing tactical goal to match the new proposed feature. The product manager must decide if they should recommend that a new tactical goal be created now or is better to complete the current tactical goals before looking at the possibility of creating new ones.

If the new proposed feature does match any intermediate goals of the organisation it should remain in the product backlog until it can.

The other aspect to consider as it builds it looks to get feedback often and early to ensure what is developed is inline with the user needs.

Measurement within EMB

In the previous section we showed how Evidence-Based Management can be used to determine the goals of the organisation and how through an agile framework of testing we can work towards to fulfilling those goals.

In this section we are going to look at how EMB recommends measuring the value of the organisation and how the organisation can therefore optimise for value.

Organisations may measure value by looking at:

• Activities: these are things that individuals do. For example, an individual may design an image, write code, attend meetings or perform tasks.
• Outputs: these are things that the organisation produces. It could be reports, products, new product features or even scientific discoveries.
• Outcomes: Outcomes are of two types: positive and negative. Positive outcomes happen when our customers or users benefit from using our product or service. For example, establishing a platform for C2C (consumer to consumer) trade like eBay or Etsy allows consumers to trade. A user of these platform benefit being able to generate an income stream. By focusing on the user needs, the positive outcome for the user is also a positive outcome for the company. Negative outcomes are undesirable and can happen when a user is no longer able to achieve something they were previous able to. Sometimes an organisation may retire a product or service which can cause a negative outcome.

EBM is focused on outcomes rather than outputs or activities. It believes that true value is realized by serving the user and not by producing more product or doing more activities. By focusing on the user, we build a product that our users want more then they just need. That in turn improves customer retention and customer referrals.

How is value measured within Evidence-Based Management?

 

Value can be measured in multiple different ways, some looks at EBITA, others look at ROI whilst others may care about NPS. EBM defines value in four different areas, these are called Key-Value Areas (KVAs). They are:

• Current Value (CV)
• Unrealized Value (UV)
• Ability to Innovate (A2I)
• Time to Market (T2M)

 Current Value (CV)

The current value is a measure of what the organisation can deliver to its customers and stakeholders today.  Current value is not limited to revenue generated or size of the paid database but also considers the levels of happiness of the customers, the staff and the investors/stakeholders.

Questions they can be used to assess it values could include:

• How happy are our employees? Would they recommend working there?
• How happy are our users/customers with our product or service? Is their happiness on the incline or decline?
• How happy are our investors and stakeholders? Is their happiness on the incline or decline?

By measuring employee happiness, we can optimise for it because an incline or decline in the level of happiness has ramifications all across the organisation. An engaged and happy employee is going to contribute more to the company success then an employee who is unhappy and disengaged with the company.

Levels of user happiness for the product or service acts as an indicator of what needs to be improved in the product to retain customers. Looking at how often a feature is used, and for how long, is a way to understand what a customer value in the product.  It is also important to compare user level of happiness to the past to determine if it is on the incline or decline.

ROI is important for investors but so is the direction and the vision of the organisation. If they are concerns, then they must be addressed. Continuously engaging stakeholders to determine what concerns them and then working to deal with the concerns is essential for the success of an organisation. By measuring for it, we can optimise for it.

It is important that an organisation continuously reassess its position.

Unrealized Value (UV)

Current value measures the value of the organisation today, unrealized value is the potential future value of the organisation. These values represent the difference between what is possible today and what is possible in the future. This difference is the unrealized value.

A start-up may have high unrealized value and a low realized value as it is recently started its journey to greatness. Investing at this stage can help unlock the Unrealized Value and increase the Current Value of the organisation.

An organisation within a mature market that is either a monopoly or an oligopoly may have a high realized value but a low unrealized value as the opportunity to grow is limited.

The type of questions that an organisation can use to assess and reassess its unrealized value could include:

• Is it possible for the organisation to generate additional value in this market or another market?
• What is the opportunity cost of pursuing these opportunities?
• What level of investment would be required to realize the unrealized value?

Time-to-Market (T2M)

An organisation may build an amazing product or service but not until it is available on the market can it deliver value to the customer. Time to market is a measure of how quick an organisation can deliver new products, new services or develop new capabilities. What is important for an organisation is to improve or sustain its time to market.

By maintaining a schedule of regular releases with maybe a smaller number of features per release can improve T2M as well as the Current Value of the organisation relative to having larger releases with more features but release less often.

Having the ability to deliver a product on time but then spending several months fixing the problems that the release created limits the ability for the organisation to launch new products.

Questions that the organisation can ask to assess their T2M can include:

• How fast can an organisation test a hypothesis with users?
• How fast can the learnings from the test be understood and adopted by the organisation?
• How fast can the learnings from the test be implemented?

It is important to optimise the time to market to ensure what is learnt can be implemented in the time frame where it can add value. Being late to market may mean a new feature is no longer consider as adding value but rather becomes what is expected but still important, to no longer required as users has moved to another solution that is more preferable.

 Ability to Innovate (A2I)

Innovation is the ability to improve a product or service for its users. The ability to innovate is a measure of ease at which an organisation can innovate.

The type of questions that an organisation can use to assess and reassess its unrealized value include:

• What are obstacles that stop an organisation from innovating?
• What can be done to remove these obstacles?
• What are the factors which can impacts users from benefiting these innovations?
• What can be done to ensure users benefit from these innovations?

It is important for organisation that follows a hypothesis, experiment & measure, inspect and adapt model to improve the organisation value. Competitors may be a good example of what is possible, but the real competition is about constantly growing by asking what could you do better.

The interaction between the four values

Realized value is the unrealized value in the past that was achieved and acts as an indicator of how the organisation can innovate and the blockages and stumbling blocks it circumnavigated during its journey.

Unrealized value carries risk as there is no guarantee of unlocking it. By breaking down the unrealized value into tactical and immediate goals as we achieve each goal, we can unlock unrealized value. By adopting a short iterative approach, we can ensure if something does not yield the results we are looking for or is no longer valid, we simply try something else or pivot in a totally different direction. This helps us to achieve our goals and saves time and resources by not pursuing activities that do not yield the optimal results.

Our ability to innovate is how we can unlock unrealized value.  Innovation is seen by some by a single eureka moment. Innovation under an Agile is a process by where we test multiple different hypothesis and look to what works best, and once that is found something we continue to optimise it further through further iterations. The speed of innovation is depending upon our time to market. Optimising time to market, increase the number hypothesis we can test, which helps realize the unrealized value that is available.

To learn more EBM I would recommend reading the guide, which can be found here.

Image by Pexels from Pixabay

 May 7th 2020 marked the first Inside Xbox event to show off gameplay running on the Xbox One X Series, Microsoft’s latest gaming console. There was much hype surrounding this event, unfortunately, many felt disappointed by what was shown. Aaron Greenberg the General Manager of Games Marketing had to say about this:

Had we not said anything & just shown May Inside Xbox show like we did last month, I suspect reactions might have been different. Clearly we set some wrong expectations & that’s on us. We appreciate all the feedback & can assure you we will take it all in & learn as a team. 🙏🏻💚

— Aaron Greenberg 🙅🏼‍♂️❎ (@aarongreenberg) May 8, 2020

Is failure bad?

We live in a world where success is celebrated and failure is seen by some as a disaster. Not scoring that point, not passing that exam, or getting that deal can hurt but it can also stop someone from trying again.

 “I have not failed. I’ve just found 1,000 ways that won’t work.” Thomas Edison.

Thomas Edison is regarded as America’s most recognised and prolific inventor. In his pursuit in developing an efficient incandescent lamp, he tried over 1,000 different ways with each one failing, only to finally succeed. Sometimes in life, the greatest opportunity to learn comes from failing, getting up and trying again.

In Agile, failure is just a result of a test, there is no social stigma or negativity around it. By failing and you have learnt something you may not have learnt otherwise.

“What good is an idea if it remains an idea? Try. Experiment. Iterate. Try again. Change the world.” Simon Sinek Together is Better

Failure in an Agile Environment

The purpose of this post is to show how we can leverage user research coupled with a testing mindset to help to exceed user expectation and create a buzz around the Xbox One Series X and its games.

Agile can be defined in two different ways:

1. The ability to react to an ever-changing environment. When technology introduces new opportunities, markets collapse, or new markets open up, having the ability to react quickly amd take advantage of the opportunity is being agile.
2. To take what you don’t know (the known unknown) and use a systematic approach to test different hypothesis to make it become  a known known.

In this post we will look at the second approach, that is to develop a set of hypotheses, build a minimum viable product (MVP) to test and use the results for either iterative or deliver to the end users. 

The importance of user research

It is sometimes very easy to forget the maxim,

“you are not your customer”

To help eliminate such biases, user research helps to understand user behaviour, their needs, their motivations through testing, observation and interviewing.

What is user research within Agile?

If Agile is the process by which we can develop and test new ideas, user research is the way we can help generate ideas to test from the users.

What are we looking to test?

Jerret West, CVP of Gaming Marketing at Xbox said, “starting with the May 7th episode of Inside Xbox, we will be showcasing what happens next in the world of Xbox, every month, which is why we’re calling it ‘Xbox 20/20.’”

By having an event every month until release provides the perfect opportunity to test and iterate.

To illustrate the idea of using user feedback and iterating we will look at two different examples:

1. Ray Tracing – a hardware feature for the Xbox Series X.
2. Halo Infinite – the launch of a new game.

 

Hardware – Ray Tracing on Xbox Series X

The Xbox Series X is the first Microsoft console to feature Ray Tracing which has traditionally been reserved for high-end PCs.

What questions do users have and where does the information exist?

Gathering information online

In this example, we are looking for users who are discussing ray tracing. This may include content on Quora.com, Twitter, Microsoft Answers and the comment section in YouTube videos. What is important is to identify what questions are people asking? What makes people excited about Ray Tracing? And how are people justifying the purchase of a new graphic card or a next-generation console to experience Ray Tracing?

Asking questions – slicing and dicing data 

We have all seen Twitter polls, voting in Instagram Stories, emails with questionnaire etc. there are many ways to get answers to questions. We may want to ask questions to specific audiences which can be done by using different social accounts, time of day of posting or paid postings where we have even more control on who participates. 

What if we took this a stage forward? Microsoft has significant amount of user data on which games are played, which apps are used and which consoles have been purchased by user. We could create different audience segments:

• Users who have purchased Xbox S and Xbox X.
• Users who buy multiple games per month.
• Users who play less than 4 hours of gamer per month.
• Users by gamerscore. 

It can then be possible to target user in console (having surveys on the dashboard) or over email. Questions can be asked can include if they know what Ray Tracing is? How important are graphics relative to other feathers a new console has to offer? Or if they have any specific questions on Ray Tracing? 

In terms of the audience we can take two approaches:

1. Select the audience which is most likely to purchase the Xbox Series X and target those.
2. Look for the audience that share similar properties which is largest in in size relative to other audiences. By optimising a campaign for this audience  will also have the greatest impact on the whole audience.

Developing a hypothesis and MVP

Now that you have data, it is about developing hypothesis from the data and finding, ‘quick and dirty’ ways to test. What is important to remember:

1. A hypothesis is just an idea, not every idea will work. Don’t become attached to an idea until you have data to prove its validity. 
2. Your hypothesis may not be the best. 
3. It is all about getting feedback and iterating.
4. The solution may not fit all (e.g. ways people learn or consume media.) 
5. The endpoint is a decision based upon on data you currently have on how to present Ray Tracing for the Series X launch period. Things change over time.  

Let us for a moment walk through an example to see how this could work.  We may for example have a segment of the audience who does not know what Ray Tracing is but regard improved graphics as the most important factor when buying a new generation console. 

We could test showing videos of Ray Tracing on and off versus screenshots of games with and without Ray Tracing, to see which one better communicates how Ray Tracing can make graphics look better. Or is there a place to show both video and images? Taking that a stage further by iterating, what if we had an engineer talk how Ray Tracing works before or after showing the video/images? Rather then using an engineer what if we used a studio head talked about the power of Ray Tracing in building games? The objective here is to test multiple different scenarios with users to find the one that is most optimal. This format can then be used at  the reveal event. 

 

Launching a New Game – Halo Infinite

Halo is a system seller and the second biggest IP after Minecraft. We know that Halo Infinite will be shown at the Xbox 20/20 event in July and the game is due to be released this year.

Let’s set ourselves a different question, post the reveal event how quickly can we adapt to user feedback and produce marketing material? Usually, in any marketing campaign, we define all the marketing materials required in advance and have them ready for the event. What if we took a different stance, and decided we needed to be flexible and respond to user feedback during the actual reveal?

The following is a an example how we can build a team that has the capability to respond rapidly to user feedback.

Predict 

We are going look at two sources to try to predict how fans will react to the reveal. Internal users and historical reactions to new video game reveals.

Internal users

Bring together employees from Microsoft/Xbox who are experienced in storytelling but have not worked on the Halo reveal in a ‘room’ together to show the Halo reveal to. The objective is to highlight potential problems with the reveal.

I would recommend using the format called ‘Braintrust’ pioneered by Pixar, where everyone’s’ opinion is equal, no one is to be blamed for failure and people are encouraged to use Radical Candor to identify the root causes of problems. To learn more about Braintrust I would suggest reading this article on fastcompany.com or reading the book Culture Code by Daniel Coyle

Having this critical feedback can be used to identify which problems need to be resolved before the reveal and which are a potential problem that we need to help mitigate during the reveal event. 

Historical reactions

There have been many First Person Shooters in the past, there include previous releases of Halo including the more recent release of Halo Master Chief Collection on the PC. There have had reveals, trailers, gameplay videos with lots of user feedback. Take all that user feedback and identify common questions, common disappointments, recommendation I.e. ‘I wish we could see more of….’

Building a multi-disciplined team

The idea is to put together a team with different skills so they can act independently from all the  other teams. The team should consist of people who have the necessary skill and experience to produce any marketing material  they require. The team may include graphic designers, video designers, content writers, engineers, video editors etc. The team should be independent and able to self organise in a way that works for them. In software development we would  call this team a Scrum team. In our example we can say we have an Agile team. 

Their first objective is to understand what the Halo Infinite reveal contains, take the feedback from the internal users and the data from the historical reactions and understand possible pitfalls.

Building a content library

Once you have all these possible scenarios, the scenarios need to be ranked according to the chance of it happening on the day of the reveal and the effort required to produce something. Let’s look at a possible example of this playing out.

Let’s say the July event is 90 minutes long. Halo Infinite is shown in the first 5 minutes and there is space reserved for the last 5 minutes for a follow up to the Halo Infinite reveal. Within minutes of the reveal the feedback online is negative indicating an area of disappointment, for example, the lack of multiplayer gameplay. The team has 80 minutes event to rectify it and present something at the end of the show.

It may seem scary at first producing a something in a very limited time-space but with all things, it is all about practice and having retrospectives to see how you can improve. Questions that could come up in the retrospective could include:

• What additional content needs to be added to the content library, that we can repurpose? 
• Which Halo staff need to available to interview on the day if needed?
• What skills does the team need to learn?
• How does the team perform under pressure?
• What can we do to ease the pressue?
• What are the impediments that need to be removed?
• What backs up can we put in place?

Each time you run a scenario the team become quicker because they know what works.  Through the retrospective they have highlighted the bottlenecks and subsquent dealt with them. And on the day of the reveal and they become aware of what is needed, they function like a well oiled machine, relaying on each other’s capability to deal with what ever hit’s them. 

Conclusion

The post looked at two different ways we can apply a framework of taking user feedback, testing and optimising as we learn. What is key to note, there is no absolute right solution, it taking the data you have, making educated guesses and testing with real users. When you build a business that Agile in both senses it will learn from it mistakes and takes it successes and look to amplify them.

Image Credit

Thanks to Zohre Nemati for sharing their work on Unsplash.

Photo by David Travis on Unsplash

 

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

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

The benefits of Agile within software development 

1. 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.
2. Higher customer satisfaction – engaging users and taking feedback that is incorporated into the product backlog can produce software or features that users actual want.
3. 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.
4. Higher quality output– getting daily feedback and testing regularly reduces mistakes and oversights.
5. Transparency – providing visibility in the product backlog and active Sprint creates accountability, helps eliminate office politics and provides visibility to the organisation.
6. 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:

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

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

1. Using time-boxed events to streamline defining the problem and developing possible solutions.
2. Creating an MVP (Minimum Viable Product) from one of the possible solutions.
3. 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:

1. It provides the company and its staff clarity and alignment on what needs to be optimised and what can be left alone.
2. It communicates in a simple single metric the progress of the product to the whole company.
3. 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:

1. 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.
2. 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.
3. 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.
4. 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.
5. Start small and grow – Before allocating resources to anything, it is about iteratively testing to look for those 5mm gains that can scale.
6. Self-organising – an Agile culture gives autonomy to staff to make decisions and take risks.
7. Collaboration – an Agile culture encourages staff to share their learnings and collaborate to help move the business forward.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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:

1. Economic
2. Legal
3. Changes in society.
4. Technological changes especially when it is disruptive.
5. The availability of information.

Internal factors can include:

1. Change in management.
2. Internal dissatisfaction including high staff overturn.
3. Increasing losses or dwindling profits.
4. 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:

1. Use a top-down approach when there is change is instigated from the highest level of management within the organisation.
2. 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:

1.  Focus on the customer and their needs and wants.
2.  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.
3. 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