Who are your Users?

I’ve wanted to write this post for a while, and reading “Metaphors we live by” has given me some language and ideas to express it in. So here goes.

Requirements come from above

In a straw-man Waterfall project, requirements are delivered to senior developers to design. Senior developers deliver the designs to junior developers to implement. Managers instruct teams in how to progress. We have, in our language and hierarchical organisation, a metaphor which maps “up” to the origin of the project, and “down” to the implementing details. We also think in terms of seniority and power, with the originators of the vision having that seniority and power, and the more junior developers and testers being at the bottom of the pile. We even talk about the team members “on the ground”.

Think of every organisational chart with the managers at the top, or the V-model in which the requirements are split into increasing detail towards the bottom.

In life, things naturally flow downwards.

Orders come from above

The other hierarchy with which we’re familiar is the military. We can map our employment and communication hierarchies to those of the military. We even talk about companies fighting for market share, defending their reputation, a hostile trading environment, captains of industry, command-and-control management, etc. It’s hardly surprising that we have, in our subconsciousness, another pattern: that the more junior members of a company should obey orders. (This isn’t necessarily true even in the military, but it fits our perception of it.)

Turning the world upside-down

I once heard of a business analyst who got tired of explaining the requirements to the developers. “I’ve told you three times already!” she snapped. “Everything’s clear. Just do it.” The BA sees the developers as working to fulfil her requirements. They serve her needs, rather than the other way around.

When we write and deliver software to a user on an Agile project, we ask them for their feedback.

  • Is this useful to you?
  • Is this easy to use?
  • Is anything difficult to use?
  • Does it help you to do your job more effectively?
  • Can you think of any ways we could make this more intuitive?
  • What would you like next?

Because we think of communication in terms of orders, we also think of junior staff delivering value to senior staff. We don’t necessarily think in terms of the communication itself being a form of delivery. If we did, we might ask for feedback from the users of our communication.

  • Is this communication useful to you?
  • How easy was our communication to use?
  • Was anything difficult to understand?
  • Did it help you to do your job more effectively?
  • Can you think of any format you’d find more intuitive than this?
  • Any questions?

If the BA above was a piece of software, her users would be filing bug reports, working around her, and using her competitors instead. I imagine instead that she’ll get a poor review and teams will prefer to work with her colleagues. If they only have the one BA to work with, the project will probably fail – the developers won’t be able to use her to get their job done.

Stakeholders aren’t users

I’ve written about this before, and it takes on a new importance in the context of users, and stakeholders, of communication. When we get a management report, we often think, “So what?” We hit the delete key. Instead, we could try to think, “Who is it that cares about us understanding this? Why does he care?” It’s often the case that a user is meant to do something, as part of his job, which is for the benefit of someone else. Similarly, we may be asked to understand or act on something for someone else’s benefit – and it won’t be the person delivering the message either.

The stakeholders of communication on a project are often stakeholders of the project itself – the security expert, the chief architect, the facilities manager, etc.

Project experience

Eric gave me the concept of a “Project experience”. In the same way that we can think of communication as a form of delivery, we can think of the experience that our stakeholders and customers have when they ask us, as a project team, to deliver their code. We can ask usability questions about the team.

  • How easy is it to use the team?
  • Is it easy to see what’s going on and get information about the progress of the team?
  • Is it easy to undo a mistake?
  • Is it easy to input a new idea?

We often hold retrospectives amongst ourselves to work out how to change our processes. I’d also like to see us actively getting feedback from the people who use the project. And next time someone gives you some instructions which are unclear or don’t help you to do your job, perhaps this metaphor will help.

This entry was posted in feedback, stakeholders. Bookmark the permalink.

3 Responses to Who are your Users?

  1. There’s a lot to chew over here. Firstly, I agree that the Waterfall mimicked a top down command structure that was supposedly military style, but didn’t actually reflect the way the military work. It’s long been established that the best armies depend on highly trained and motivated junior officers and NCO’s who have a clear understanding of their objectives, and considerable freedom in how they achieve them. That’s particularly important if the situation is fluid and chaotic. and senior officers have difficulty finding out what’s going on.

    Communication should, in general, be two way. However, that doesn’t necessarily mean that communication should be made just because it’s possible. Reporting that is too frequent becomes a distraction and dulls the initiative of the people at the sharp end. Often problems can be sorted out quickly by different teams speaking to each other immediately. Reporting up the line can waste everyone’s time. Unfortunately, some managers respond to uncertainty and their own insecurity by micro-managing. They don’t have the confidence in their teams just to let them get on with the job.

    An aspect of the top-down, command and control model with which I’m particularly unhappy is the implicit assumption that everyone affected comes within the command pyramid. In the olden days of corporate, in-house applications that was largely true. The users were given applications to work with, and if they hated them then that was tough. If they really hated them then they could find another job.

    That was a dreadful, blinkered and inefficient way to develop applications and to work, but it was more or less effective in a brutal way. However, the model completely fell apart with the arrival of web applications and users who were real external customers, over which the corporation had no power. If they didn’t like the application they were off to a competitor.

    If you persist with the traditional top-down approach you outlined, then the only way the customer fits into this model is as, er, the enemy! No battle plan survives contact with the enemy, and no first-pass design survives contact with the user.

    Ironically, the way the military really works is more suited to dealing with user/customers than the traditional perception. Just after his 21st birthday my father was an artillery observer at the Battle of Arnhem. He was right on the front line, directing artillery fire from miles away onto targets within a few hundred metres of his position. The process was to call in a ranging shot, then home in on the target with rapid feedback and adjustment. Bright, well trained youngsters, with complete command of the technology and given the freedom to get the job done without constantly referring to their commanders. Oh, and incredibly strong team spirit. My father’s best friends for the rest of his life were those he made in the army.

    So the freedom of initiative, and rapid feedback/iteration of Agile fits more neatly with the military than people have tended to assume.

    The rigid top-down structures of Waterfall were never about doing the right job, or even a good job. They were formed to suit the needs of project management, accountants, procurement and the lawyers who wrote contracts. It’s a long time since the military was stupid enough to build their command structures to suit the convenience of staff officers.

    In my experience of IT development it’s been a recurring source of frustration to see good teams being broken up, and new ones having to form from scratch as each project ends and another starts. By far the best work I’ve been involved in has been when the same team has been given the chance to run through a series of repeated projects. It’s great when you’re part of the same team working with users whom you’ve come to know well and you have the chance to learn from the last project and do it better next time.

    Feedback from users about the “project experience” of the team comes naturally when you have that continuity. It’s usually not even considered when each project is treated as a one-off with a brand new team. One of the seldom mentioned benefits of Agile is that you really can’t work with these one-off, disposable teams, who have to learn expensive lessons from scratch each time. Great!

  2. liz says:

    James, thanks for elaborating on the nature of the real military! A little different from “Full Metal Jacket”.

    I love your sentence about the rigid top-down structures of Waterfall being “formed to suit the needs of project management, accountants, procurement and the lawyers who wrote contracts”. So many times I’ve seen consultants responsible for making money through their work, but spending their time jumping through hoops to make themselves easier to measure or manage.

    I also appreciate you for sharing your insight into long-lived project teams. I’ve just joined a brand new team and it’s a long way from bonded yet. Oh, well… pub on Thursday!

  3. Reading this article made me realize what great BA folks we have in our team. We developers use scrum and work together tightly with the business people to investigate and evolve the tasks we get. I believe that we then together at least try to think of the end users. This makes the BA think of the tasks from a different perspective and it makes us understand the task better before we start implementing.

    Thanks for a great post!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s