Leave a comment

Feedback Loops in Agile

Feedback loops are one of those things we all know something about, from the annual review process, to the speedometer on the car we are driving, we are receiving feedback from the world around us that we can act on it. After looking at a typical Scrum based project, I will show how feedback is a critical part of agile by mapping it to the principles. Built into the principles there are feedback loops used to…

  • find out as fast as possible if the project outcome will result in the expected benefits
  • improve the project outcome
  • ensure the software works properly as early as possible
  • ensure minimal effort is expended on re-work throughout the project
  • ensure that the software is built as efficiently as possible
  • ensure that collaboration and learning is as efficient as possible
  • improve the way the team works together

Feedback in a Scrum Based Project

Here’s a simple example of a Scrum based project set up. Within the sprint each story is worked on, then demonstrated in a show and tell at the end of the sprint. Finally there is a monthly product show and tell that gives a few key stakeholders the big picture view. Note: this picture purposefully shows the delivery stages being completed one after another to simplify the example described below:

Story Feedback

Consider the increasing cost of receiving feedback from a product owner or user as we get further through the stages. If these people were to tell you that the process you have designed was completely wrong during the Story Acceptance Criteria and UI Design stage the cost of change would be minimal. If this feedback was received as late as the monthly product show & tell we would obviously see a high cost to fix (or throw away). There is an additional hidden cost of re-learning (one of the seven wastes) when we go back to the problem and re-analyse it, which can make things much worse if the feedback is slow. Building feedback in to this model to be early and often greatly improves the situation and helps us remove the poor practice of completing stages before seeking feedback. Now let’s look at the agile principles and how they have feedback built into them:

Agile Principle: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Projects range from high risk new ventures, typically start-ups, through to those with a definite need such as operating system upgrades. In business we typically release products into the marketplace with some degree of risk. A really dangerous situation occurs when we find ourselves assessing the risk incorrectly, we are so bought into our project or feature idea that we actually think it’s certain to succeed, until it doesn’t. We can get feedback from those people who are not customers to positively re-inforce the likelihood of success leading to more delusion. Ultimately we look to improve on uncertainty with factors like previous experience to lower the risk, however it is better to get real feedback. Agile has this principle of delivering to customers early in it to lower the risk of failure by getting feedback as soon as possible.

As a product owner you should always look to cut scope where there is risk in the market, looking for the real minimal marketable feature set. You can build on your success if it works and minimise loses if it doesn’t.

This feedback loop is used to find out as fast as possible if the project outcome will result in the expected benefits.

Agile Principle: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Within a project people are learning as they go, trying to lay out every requirement up front in great detail is very difficult due to the amount of complexity in most projects. Rather than assuming that we just need to try harder to nail everything down Agile shifts to allowing changing requirements. Further to this there may be feedback from the marketplace as a competitor adjusts their strategy, allowing this flexibility makes us more likely to succeed.

This feedback loop is used to improve the project outcome.

Agile Principle: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

By making sure that our software is fully working on real environments with real components we get feedback about how well the solution will work. Great disasters have been known to occur at the end of projects when a full scale environment is built for the first time and we learn too late that our solution isn’t performant. By delivering the working software frequently we can get feedback that it will work when released.

This feedback loop is used to ensure the software works properly as early as possible.

Agile Principle: Business people and developers must work together daily throughout the project.

In the past infrequent contact with business people would lead to the wrong product being built, then expensive and time consuming re-work occurs based on change control. By bringing the business and developers together we greatly shorten the feedback loops. The creation of the product owner in Scrum is a direct response to this problem.

This feedback loop is used to ensure minimal effort is expended on re-work throughout the project.

Agile Principle: Working software is the primary measure of progress.

Within waterfall projects we often see success in terms of the analysis and design stages being signed off on time, only to see disaster at the testing stage. Defects are found, users aren’t happy and the project spirals out of control. This is down to documentation being a poor substitute for feedback from working software. If you don’t have working software you are receiving poor feedback. This is an inefficient way of working.

Even using agile methods it can be very tempting to build up lots of screens that look like they are working without any real end-to-end scenarios truly being ready, this is adding great risk to a project even though it makes it look like progress is good. Using mock objects and having a lack of real data are typical culprits in this area.

This feedback loop is used to ensure that the software is built as efficiently as possible.

Agile Principle: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Here we see a feedback loop from people talking with each other. It is very difficult to get complex and large amounts of information across to people. In these situations our assumption that we have transferred 100% of our knowledge will be incorrect. From this post you will likely get 10% as you are reading, discussion rises to 50%, so we can see face to face communication is far more effective than documentation. When working through problems together this rises to 75%.

This feedback loop is used to ensure that collaboration and learning is as efficient as possible.

Agile Principle: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

Here we see a feedback loop from within the team, focussed on how they are working. This helps improve efficiency and promotes a feedback culture. This is done at “regular intervals” to highlight the importance of re-assessing efficiency regularly and not just once at the end of a project.

This feedback loop is used to improve the way the team works together.


Protect the Team

“Protect the team” is part of the Scrum Masters role on a project. Please note that this post is not a discussion on the rights and wrongs of project setup. Let’s look at what this should and shouldn’t mean in practice….

  • The background

The Scrum master is there to maximise the productivity of the team by ensuring the Scrum processes are as effective as possible. They are there to help the team reflect on how they are working and improve.

They protect the team to help the team achieve their sprint goals and achieve this by:

  • Keeping the team focussed on their goals.
  • Protecting the team from external interruptions that will damage the sprint goal.
  • Ensuring that the goals are realistic.
  • Protecting the team from itself.

I hope you find little controversy in what I have written here!

  • How it can break down

The primary issue I have seen with Scrum masters is when they protect the team from their own delivery team. At its worst I have heard a Scrum master say, “Do you want me to get rid of him”, directed at someone involved in running the project.  The chickens and pigs sketch was a primary example of this, it suggested that the “chickens” or non-Scrum team members were not committed to delivery. This created a them and us culture, seeing anyone outside of the team as meddling with progress.

I believe one of the failings of Scrum is not to insist on a big picture or system wide view. When the goal of the sprint takes priority above everything else this can damage delivery overall. Here are some simple examples:

  • As a database administrator I need to know how much space the team are likely to need for a test database so I can build it for the next sprint.
  • As a the head of security I need to know how the payments engine interface is secured so I can get it certified to go live.
  • As a service manager I want to talk through how code quality is being addressed so I can be sure it’s maintainable.

Let’s be pragmatic! In this case I believe it is the role of the Scrum master to help understand and express the impact of the interruption. This can be light touch, it is not to patrol for anyone attempting to talk to the team and get rid of them. This closed view of a Scrum team can damage a project and introduce delays. We also need to be careful with solutions like, “I’ll talk to them and get back to you”, as this can create waste in the form of poor information hand-offs, leading to additional delays.

A good way of spotting this behaviour is when team members start to use the word “management” in a derogatory fashion to describe non-Scrum team members. This re-inforces a them and us culture. 

  • The solution

As a Scrum master you may wish to minimise interruptions, that’s fine:

  • Maybe you ask for a meeting to be scheduled for a later part of the day, if it’s a large subject.
  • You could openly accept interruptions just after the stand-up.
  • You can ask for non-team members to think carefully about the urgency of their request before interrupting.

These are simple suggestions and I’m sure you can come up with more that fit your situation. What we must avoid is a them and us culture, as a Scrum master help everyone to feel like a team!

1 Comment

Project Manager versus Scrum Master

This is a controversial topic to say the least, so I thought I’d share how I feel about it. The point I’m going to be making is as follows:

If we want to change things we should stop asking how these roles are supposed to work and start asking how the structures outside of the Scrum team should work.  

I’ve read a lot about the PM role no longer being of value, that it has been replaced by the Scrum Master, Product Owner (PO) and team. In the traditional sense of managing a PRINCE2 waterfall project there are certainly major differences, such as allocating resources to tasks and building Gantt plans. However time has moved on and now we have PM’s running Agile projects, their responsibilities have changed, some would say they have been replaced with a new set.

Why is it so difficult to remove this role? Well let’s use synthetic thinking to answer that, “The explanation for a system always exists outside of the system”. A simple example of this would be a kettle, it has no value in itself, it is used to boil water for something (or someone), i.e. myself making coffee. In other words if I look at any outputs being produced I need to understand the reason for their existence outside of the system. On a project this means that when I see a report being produced by a PM or Scrum team I need to look outside of it to see what it is used for, it has no value on its own, it is used outside of the current system for something.

Organisational Structure

Back to the subject then, why does this matter in relation to a project manager role? The structure above the Scrum teams is often a programme team, they are the reason for the project manager role. The inputs needed from the programme team line up with the outputs from the project manager. When you break this model and stop providing those outputs the programme team can no longer function. Note that I am not passing judgement on the programme structure I am simply looking to explain how the parts relate.

Now consider how a Scrum team would interface with a programme team if there was no project manager:

  • Costs: The PO is now accountable for costs in Scrum
  • Progress: The PO is now accountable for project progress in Scrum
  • Risk: No-one is directly responsible for recording risks in a Scrum team. The programme board either have to accept this or modify Scrum.
  • Quality: The team are now responsible for quality via a definition of done. Rather than the PM reporting on quality some new form of communication must take place.

What we need to understand therefore is that the programme board is a structure that is set up to work with defined inputs and outputs if we want to change these we have to do one of two things:

1) Change the way the programme team functions to work with Scrum without PM’s,

2) or change the way the Scrum team functions to work with the programme team.

The PM is trained to interface with a programme board in a certain way, they are skilled in it and are a central point of contact for their desired inputs, that is why this works so well (for the programme team). Now let’s consider the other factors that need to be considered before removing the PM:


The skills of the various parties now need to be changed, you cannot ignore this aspect. As an example asking a PO to take accountability for cost outputs means they need to be able to manage cost. A PM is trained in this area and is ready from day one. A similar situation usually occurs in Scrum where the PO is a subject matter expert but not an agile requirements specialist and a BA is brought in to facilitate, in this case we recognise the PO may not have the skills to perform the role.


Programme boards that are set up to work with project managers being accountable will find it very hard to find the Scrum team accountable. In reality everyone has a level of accountability but this is not easy to put in place. When treating a PM as being accountable you will drive a particular behaviour as they seek to monitor and control, because if they don’t they will be punished for it. We split our roles and responsibilities like this and rarely would consider punishing an entire team, instead saying some people were good and some bad, but probably weren’t controlled (managed) well enough. In true Scrum accountability comes down to the PO for building the right thing, having met PO’s few would hold themselves accountable in the same way that a PM would. I have never seen a situation where a PM has not been affected by team failing.


So that’s why I believe there is a place for the Project Manager or indeed a Scrum Master who takes on the additional responsibilities and accountabilities of a PM (i.e. Agile PM) in todays world of programmes. If we want to change things we should stop asking how these roles are supposed to work and start asking how the structures outside of the Scrum team should work.  

Leave a comment

Lean Delivery Mechanisms – Programme and Product Management

This post is written to compare and contrast how most companies have been set up. Lean has a new way of thinking and is making very large inroads into the software industry.

You should read this if:

  • If your competitors are releasing products that their customers want faster than you and therefore your business is at risk
  • If you want to stop wasting money on products your customers don’t want
  • If you want to understand staff performance in your company
  • If you want to set your company up to be product and not project focused

Traditional Approach – Delivery Structure

Here we see a standard company set up for delivering projects (simplified):


Traditional Approach – Project Focus


Lean Approach – Product Focus


Traditional Approach – Typical Value Stream


Here is an example of the number of steps, between each of these there is a delay

  • This can be a Scrum based organisation
  • Activities before project delivery taking excessive time
  • Project delivery team put under pressure to deliver quickly
  • Mean time to project failure is around 10 months!
  • Large scale investment wasted

All delays and steps will depend on the actual organisation

Lean Approach –  Ideal Value Stream


In this case we generate ideas as experiments

  • Teams are not created based on large projects and programmes
  • Small features allow the assignment of the next most important thing to do
  • Experimental feature may be a prototype and not a fully built solution

This is an example only, feature size and set up may vary

Lean Approach –  Build Measure Learn


  • Fail at a scale you can afford
  • Treat all change as a learning
  • Speed up feedback loops – fail fast

Traditional Approach – Improvements

Delivery improved at a local level

  • Project manager improves project processes
  • Development Manager improves development processes
  • Operations manager improves operations processes
  • Scrum teams improve at a local level
  • Organisational culture rewards people on component parts

Lean Approach – Improvements

Delivery improved at a system level

  • Holistic view of the system taken by all
  • Strategic improvements aimed at the system
  • Component parts understand their role in the whole
  • Reduce hand-off of information
  • Benefits realisation targeted and rewarded
  • Learning and adaptation targeted and rewarded

Systemic Approach to Failure – Demming

“I should estimate that in my experience most troubles and most possibilities for improvement add up to the proportions something like this:

  • 94% belongs to the system (responsibility of management)
  • 6% special”



Systemic Approach to Success

In this same model we see testers rewarded for their successful defect discovery rates (not that they’re doing a bad job!)



Dev Ops Culture Example


Faster feedback loops:

  • Release faster
  • Identify failure faster
  • Simplifies error correction if less has changed

“But it’s just a flexible framework!”

  • You see frameworks claiming they have solved how to deliver and effectively managed risk
  • Core principles of learning and systemic thinking are missing or a minor part of their definitions
  • This drives poor behaviour and can cripple a company
  • Agile and Lean work from principles
    • Working software over documentation – Agile example
    • Identify waste – Lean example
  • Good practice should be applied rather than enforcing “best” practice for complex problem domains
Leave a comment

User Persona’s – Some Hints and Tips

User personas are there to help us design products for groups of people. They represent the users or customers of your product. This helps you think about how they would relate to what you’re building. How often have you seen personas created, stuck on a wall and then ignored?

Here are some tips to help make them successful:

– Use a real picture that sums up how they feel, ideally relating to your product. Here we have a mum who’s struggling with too much to do. This could be very helpful if we were targeting a diary product at this group of people. Don’t use a known actor as we’re trying not to introduce preconceived ideas of who they are.


– They need to be descriptive enough to believe that person is real without so much detail they get confusing. Think of each person as an actor in a film. If you have enough detail you’ll be able to imagine them in a scene. For example, “Hey Carol, take a look at this new cup holder for your car, it’s carbon fibre and super light”. “Looks good but I rarely drink anything in the car as I only drive to work which takes 10 minutes, and why would I need it in lightweight carbon fibre?!”.


– Create enough personas to capture your main users, look at around 6 as a guideline. You usually don’t design a product for everyone so think carefully about who you’re targeting.

– Get the Scrum team involved in their creation, help them to buy in to the idea. Avoid them becoming silly caricatures.

– As a BA / Agile Coach you should be talking about them regularly until they become part of the team dynamic. Asking how would Carol use this feature, will help assess it’s suitability. You can add them into stories like this:

As Carol a customer I want to store my contact information so that I can quickly retrieve peoples details when they contact me.

– Find the real users. Personas are great as a starting point but you need to review and improve them. If you assume every student is poor because they drink too much you may design the wrong product. Validate your assumptions with research. The whole point of the persona is to make the right product, if you have the wrong customer profile you probably won’t.

– Chose a primary persona (or stakeholder if you can identify a single person) to build for. Who is the person you’re most concerned about? Your product will be very different if your primary stakeholder is a client who wants a really cheap supportable solution, compared to a customer who wants all the bells and whistles. That doesn’t mean you take things to extremes but it will help guide your solution.


Self Managing Teams – Systems Thinking

This is a similar post to my last one on systems thinking, but from a slightly different viewpoint, this time we’ll look at the Scrum team and focus on retrospectives.

A Scrum team can get very good at what they do and given the retrospective’s can improve their working processes. This post may seem simple at the start but please keep reading. Here’s a common scenario where the Scrum Master informs the team that they are empowered to make changes….

A developer starts to influence the group, “I really don’t like the way we test at the moment, it’s slow and we’re not seeing many benefits, there are much better tools we can use”. The Scrum Master facilitating, “OK, let’s look at how we can improve this, come up with some solutions and try them out during the next sprint”. Sounds fine doesn’t it? The team change the testing tool and a month from that point they have a really great new testing strategy.

After 2 months the following occurs. The team about to pick up the software has two different testing tools to support and they’re not very happy. The other teams are struggling to understand which test strategy to implement when some of the newer code needs to change. The metrics the teams were using are now mismatched and hard to understand. No-one can easily tell if areas of code are covered by tests without manually looking.

The reason why the problem occurred is because the Scrum Team are within a larger system. They did not really appreciate this and built a consensus amongst themselves that what they were doing was exercising empowerment and continuous improvement. When you are working in a team it is important to understand how the outputs you produce fit within the larger picture. Who is using those outputs? what is their intended purpose. If you want to change them how do you keep the system functioning?

At this point you should expand the decision making process to beyond the Scrum team and identify the stakeholders and the outputs. If you can convince someone they no longer need something or can get something in a different or better way you’ll achieve far more. This will also help stop the team getting frustrated.

Leave a comment

Joining a New Project – Applying Systems Thinking

Thanks to Wikipedia for this definition: “Systems thinking is the process of understanding how things, regarded as systems, influence one another within a whole”

Let’s take a simple example to illustrate a common problem when people arrive on a project. As a team we currently make large cups of black coffee for our customers who are very happy with them.

1.John fills the water, 2. Mike grinds the beans, 3. Phil puts the cup in place and finally 4. Sally presses the go button and serves the customer with the finished coffee. Sounds very simple doesn’t it. Our customer is getting what they want.

Now let’s say John is replaced by George who is asked to fill the water. George has experience of making expressos, he’s really good at that. Now he wants to change the system, as that’s what he did in the last coffee shop and everyone loved his precise work, he was really really good at getting just the right amount of water for expresso’s, he even made sure it was at the right temperature. So George now comes in and does the same job resulting in the customer getting an Expresso sized coffee, they are not happy.

In this example George has very good intentions, he’s using a lot of skill, what he doesn’t see is his impact on the system. If he didn’t talk to the customer he may never know. What we can do when we join projects is not realise that we’re part of a larger system. There are customers for our product, they may expect certain outputs. Our support team may need that handover document to operate the service, our project manager may need the release report to highlight risks. All of these are probably of no value to us but they do matter in the context of the whole system.

So what should you do? Understand the existing set up, try to see beyond the boundaries of your job and understand the impact before you change things. You may know a better way to do something but consider the system before you change it.


Get every new post delivered to your Inbox.