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. For example, find a picture of 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.

1 Comment

Be Careful with Metrics


There are a lot of pitfalls with metrics, they can seem like a magic bullet to control the output of a team. Measurement is certainly useful but how you use it is critical to ensuring your projects succeed.

Let’s take an example. I tell my teams that I’m measuring their success on defects raised. For the testers their success is the more defects they find the better, for the developers the less defects found the better. I have now introduced an extrinsic reward associated with a metric. It is highly likely that the developers don’t want defects in their system and the testers were perfectly happy when they didn’t find any but that’s about to change….

Now comes the unintended consequences. Testers start to raise defects for almost anything such as a text box not quite large enough (in their opinion) etc. This annoys the developers who could just fix the defect really quickly and don’t need it raised, slowing the team down. The developers figure that they’ll not get the software in front of the testers quickly, instead they’ll sit on it for days trying things out, increasing the cycle time. Then the developers then figure that writing less software is the best way for less defects to be found and slow down. The testers and developers and now effectively at war and will fight about whether something is a change or a defect.

This as we can see can be disastrous. So how do we fix this issue. Firstly let’s trust the team to do the best they can. Secondly let’s use the metrics to help them improve and don’t reward them externally. For example we can give the team the metrics and ask them to work out where they can improve. This gives them the information they need without attaching a reward to it, people usually want to do a good job. If you have someone monitoring metrics in this way consider moving them into the team so that they are part of the delivery. They are now as accountable for quality as the rest of the team and inform them that they are there to help.

Did you already mess this up? Here’s a way of understanding that, let’s evaluate our current metrics by asking our teams:

– What was the metric originally meant to be for?

– What is it being used for now?

Leave a comment

Shared Responsibility in a Scrum Team

Just a short post today…

IT by it’s nature is full of specialists, testers, developers, dev ops, BA’s, the list goes on. Now although it makes a great deal of sense to have these roles they can be a curse for a Scrum team. When you join a team as a Scrum Master it’s important to ask the team what would happen if each person in turn was on holiday or out? For some people it’ll mean major impact. Even if people aren’t out you’re likely to see bottlenecks, not enough testers, not enough stories ready from the BA etc.

You can now challenge the team to solve the potential problems before they occur:

  • What would you do if the BA was out or working at a slow pace?
  • How are we going to avoid this problem?
  • Then challenge your BA to work out how to minimise the impact of themselves being out?

Think this through in advance, focus on the areas where you or your team believe there’ll be a problem. Take some time out to cross train people. The more you do this consciously the less impact you’ll see.

Leave a comment

Combining UML Activity Diagrams with Release Goals

I’ve recently been looking at combining story mapping, release goals and UML activity diagrams.

Here is an activity diagram:

Activity Diagram

The point of a release goal is to specify what value is and therefore help guide what should be built. A story map can be built to achieve the goal showing dependencies between stories and therefore basic business flow. UML can not only back this relationship up but also model out and validate a more complex business model. You can map the stories onto the UML activity diagram and use swim lanes to show the various roles.

This provides another way of looking for functional gaps and helps show a cohesive end to end process. Finally the additional benefit to this is to check the external business processes. These may not be stories in the story map and will therefore allow a big picture view of what the external organisation is doing.

Finally we can review the architectural dependencies needed to complete a slice of functionality, so that the BA who is often focused on the business process understands what has to be built before a process will truly work.

Remember you don’t need every story written, you could have placeholder Epics that are rough sized and cover larger parts of the business process so that you don’t move to big design up front.

This moves us way beyond a flat backlog!