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!

Leave a comment

How to make BDD work

This post should hopefully keep your discussions on track and help you use BDD correctly.Starting with my preferred format, introduce your product owner and business resources to this concept:

In order to <achieve something which contributes to the release vision>
As a <role>
I want <feature>

The idea here is to focus on the users goal in relation to your pre-agreed release vision.

Point 1 – Get business resources \ product owner to write the stories

Your product owner is the person that is driving what they want so allow them time and space to brainstorm. Get your business people to write the stories themselves so that they begin to own the requirements. I prefer story maps for this. Keep the number of developers to a minimum and don’t let them interrupt this initial activity. After the stories are in a sensible order you can then start the discussions with development.

Point 2 – Keep solutions out of the way

In order to immediately notify users of going over their credit limit
As a bank Manager
I want to send an email to a customer

The above seems quite simple why not say email? The business people have written this and have inadvertently specified a solution. This will lead to a whole email system being created in stories. What if phone texting was a better solution! Change the final sentence to “I want to inform a customer”. Even worse is if you want your work derailed by technologists who will solution every story they can and slow up the whole process. Every time the team talks about solutions in the early stages I get them to stop and focus on the business goal.

Point 3 – Generate Main Scenarios

Now we can talk about scenarios. Start with the happy path through, where the inputs are all valid. Here I’m using inputs for an application form, I have a name, DOB and address.

I like to use grids with a column for each input for this type of work, they are simple to lay out and avoid us talking about clicking buttons and other UI artefacts.

Start by putting some real inputs in, John Smith; 19/12/2001; The Grange, London Road, London, TW2 7WD. This gets us started. Now we can look at what happens if we input a DOB that makes them over 100 years old, or even American addresses.  By talking through the potential scenarios we make the software more robust.

Point 4 – Now move to solutions

After you’ve understood the required business process and goals you can then look at an optimised solution holistically. You’re ready to discuss what items such as the user interface and feed these into your estimation. A negotiation usually takes place around the cost of various solutions too as the optimal one may be too expensive. Estimation is done as a team.