Agile, BDD/ATDD, Software Development, Software Testing

Cucumber – with step-free access

May 29, 2011 AntonyMarcano Leave a comment

A while back I wrote about writing feature specs (acceptance tests) at the right level of abstraction. I explained how we want to pitch our scenarios at the “task” level…

Goal: What we’re trying to achieve which has one or more…
Tasks: The high-level work-item that we complete to fulfil the goal, each having one or more…
Actions: The specific steps or interactions we execute to complete the task.

I showed how many scenarios (acceptance tests) are pitched at too low a level. They’re often at the action level, detailing every field filled in and every button clicked. This is too low-level.

Instead, we want to express the business process… the tasks involved in fulfilling a goal. The actions should be expressed in the code (or step-definitions), not the plain-text scenarios. Pitching the scenarios at the action level makes scenarios much harder to maintain – especially when the user-interface changes. But, perhaps more importantly, they don’t express what’s of interest to the business.

There are other challenges faced by teams using cucumber:

Over-wordsmithing scenarios

Limited regular-expression expertise

Unmaintainably large step-definition files

Fragmented step-definition files

Coverage vs. Speed tradeoffs of running scenarios through or below the GUI (respectively)

We’ve taken many of the lessons we’ve learned using BDD tools to address these problems and begun to distill the various heuristics and design ideas (patterns) that emerged into a single open-source extension to cucumber – cukesalad.

Many of the heuristics and design ideas expressed in the project can be used on your existing projects without using cukesalad:

Treat each step-definition as a class of task. Like other classes, have one file per step-definition and organise them so they’re easy to find. Name each file using the text used in the scenario.

Abstract the API that drives your application behind something representing the role or type of role involved in the story
Write scenarios like a narrative for someone in the role relevant to the user-story
Write the actions within the task (or step-definition) as if they’re instructions on how to complete that task
And more…

Cukesalad is the ongoing expression of us mercilessly refactoring a ‘typical’ Cucumber project. At the moment, it is more of an illustration of the concepts and ideas… but some are already using it on their day-to-day projects. Check it out… try it out… and let us know what you think.

Go to http://cukesalad.info – for more info, or checkout the talk I gave at CukeUp, hosted at SkillsMatter.

And if you’re wondering why it’s called cukesalad… It’s cucumber, washed and ready to eat.

Agile

Software Teams can Jump

May 18, 2011 AntonyMarcano 14 Comments

For many years I’ve been coaching software teams in various things such as Example Driven Methods (xDD), including BDD and TDD; pair-programming; programming; testing; retrospectives; Scrum, kanban and various other ways of getting the most out of a development team. One thing that I notice is that while the teams are being coached, they do amazing things. They are more happy, more productive, fast to improve as if there are no limits to what they can achieve.

Then, at some point they decide that it’s time to go it alone. I always say to my clients to keep at least one day in their budget for me to go away and come back some time later. Usually within a month or two to see how things are going. Inevitably when I return, the team is doing reasonably well, but not as well as if I’d stayed involved, even if I was just popping in once every couple of weeks.

Some say that this is what the Scrum master is there for, however, I’ve noticed that this is something that the Scrum master doesn’t get to do much of as they are are often dealing with external pressures “to get things done”…

On many teams, once I move on, there is a coaching void. Despite my pleas and efforts to encourage them to at least establish a coach from someone in-house, the team is often left to just get on with it.

This isn’t a new idea. For example, Extreme Programming highlights “the coach” as a key role in the team.

In sports, teams have coaches. Have you ever heard of a professional sports team without a coach? Can you imagine a professional sports team hiring a coach for a while and then saying – “we think we’re ready to compete on our own now so thanks for your help but you’re not needed anymore”. No, I don’t think so. This is unheard of in competitive sports, yet all too common in competitive business.

Even my 12 year old son’s basketball team, the Islington Panthers, has a coach. He trains them 2-3 times per week and he (or an acting coach from the seniors) attends all of their games. In some training sessions he gets a member of the under 21s team to coach the under 13s training session – so there is always a coach even if they’re just borrowed from another of the club’s teams. Without him, do you think any of the club’s teams would make the national play-offs as they regularly do? Very unlikely.

So, competitive sports teams always have a coach. Temporary coaching in a professional sports team is almost unheard of… Sure, they could get by but would they be taken seriously? Would they be competitive? Would they save money by not having a coach or would this be an obvious false economy? What are their chances of generating sponsorship revenue if they are not winning games? What are their chances of winning games without a coach?

The same applies in software teams. For example, I worked with a client recently and helped a team of 6 people double their output in one day. They’d have to hire another 7-10 people in order to achieve that but instead, one good coach was enough.

So, if you have a professional software team without a coach, consider, are you really helping your business save money by going it alone? Or, like the professional sports team, is having a professional development team without a coach another example of a false economy.

Agile, BDD/ATDD, Business Analysis, Old Favourites, Software Development

Old Favourite: Feature Injection User Stories on a Business Value Theme

March 24, 2011 AntonyMarcano Leave a comment

This originally appeared on my old blog in May 2010

Feature Injection, an approach to Agile Business Analysis created by Chris Matts, is a much misunderstood thing –. It is a way of combining several techniques to understand just enough of a business problem to start expressing solutions to it. It provides specific techniques to incrementally and iteratively comprehend each of the following:

The business value sought (the why)
The problem domain (what specifically needs solving to deliver that value)
The resulting roles, incentives and product capabilities (the solution)

Basically, it helps us to evolve everyone’s understanding of the business-need as we (by other means) also evolve the implementation of the product.

Now, before you say, “it’s nothing new”, Chris Matts will be the first to agree. He’s taken his experience of various techniques, combined several of them that often work, evolved it into an approach to agile business analysis and given it a name.

I wish I could explain all of this now, but we’ll have to save that for another day. This post is intended to try to explain the relationship between Feature Injection and User Stories.

I’ve seen several examples of user stories taking some inspiration from Feature Injection, however, I’m not sure any of them do Feature Injection enough justice.

A common story

One of the problems with how User Stories are often applied is that people focus on the role, the capability and then try to work out what the benefit is. This is quite natural, explained nicely by Udi Dahan:

Users ultimately dictate solutions to us, as a delta from the previous set of solutions we’ve delivered them. That’s just human psychology
– writer’s block when looking at a blank page, as compared to the ease with which we provide ‘constructive criticism’ on somebody else’s work

This is something that other aspects of Feature Injection actually help you to solve… but again, today I’m just focusing on user stories…

The tendency of people to dictate solutions, rather than the problem that needs solving, has lead some to emphasise that we should put the benefit of the story first. For example, let’s say a fictional printer manufacturer consistently entices 3% of everyone they e-mail, reminding them to check their ink-levels, to purchase print consumables. In this situation, some might illustrate taking a story like this…

As the PrintCo marketing manager I want customers to register their e-mail addresses So that we increase the sales of our print consumables

And changing it to this:

In order to increase the number of sales of our print consumables As a marketing manager I want customers to register their e-mail addresses

The intent behind this shuffling around is to get people to think about the problem in order of business value first, then the stakeholder then what the stakeholder thinks will deliver the value.

But, the story is talking about a stakeholder… In my experience, this doesn’t get the best value from the user story approach.

Stakeholder ‘stories’ or User Stories?

I’ve found that user stories are most useful when communicating to the team if they encourage a conversation around who the user is, what capability the user needs and why it’s important to the user (could that be why they are called “user stories”?). This helps us to understand what user experience they need and what capability will make that possible.

This template, brought to us by Rachel Davies and Tim McKinnon’s 2001 XP Day session “Tuning XP”, helps us with that:

As <some role> I want <some capability> So that <some benefit>

If we discuss this solely from the business stakeholder’s point of view, the team doesn’t get as much understanding from what is needed by the user or why the user will need this capability. If the capability summarises what the product will enable or do for user it’s a lot easier to see what needs to be changed in the product. The benefit should be the answer to “what’s in it for the user?” or “why would they want the product to do that?” (exploring the persona of the user is helpful in finding this out).

So, taking the earlier PrintCo example, an alternative way of writing the user story would be like this:

As a PrintCo Customer I want to be prompted to share my e-mail address with PrintCo So that I can avoid those times when I need to print something but the ink is empty

Ah… but now we’re back where we started – where’s the business value? How do we get people to think about the business value first and then identify the roles and capabilities?

Let’s start again

Ideally, we want the benefit of driving the features from the business value and the increased understanding of what we’re implementing by understanding the user in our conversations around a user story.

To get to the right place, we need to start again with our example. Imagine that, instead of the above, we’d taken a different approach.

Recall that the business value or goal was:

Increase PrintCo printer cartridge sales by increasing our customer mailing list

Then, we could consider what behaviour we want to encourage and for whom. For example, we want the Customer to share their e-mail address with us online.

So, what will encourage that behaviour… What’s in it for our users? Into our business value statement, we “inject” the beginnings of a capability (or feature) that will help us deliver the value:

In order that PrintCo printer cartridge sales go up by growing the mailing list: As a PrintCo Customer I want <something> So that an e-mail reminder helps me to avoid those times when I need to print something but the ink is empty

Now we’re ready to talk about the special <something> that we don’t currently have that will give the user the benefit they want:

In order that PrintCo printer cartridge sales go up by growing the mailing list: As a PrintCo Customer I want to be prompted for my e-mail address So that an e-mail reminder can help me avoid those times when I need to print something but the ink is empty

We also want the Customer Services Rep to be encouraged to ask customers for their e-mail address when dealing with customers over the phone. So, we inject some more features:

In order that PrintCo printer cartridge sales go up by growing the mailing list:
  As a PrintCo Customer
  I want to be prompted for my e-mail address
  So that an e-mail reminder can help me avoid those times when
    I need to print something but the ink is empty

  As a PrintCo Customer Services Rep
  I need <something>
  So that I increase the points I get for e-mail captures, improving my
    position on the high-scores display

  As a PrintCo Customer Services Rep
  I need <something>
  So that I can see that the points I earn for e-mail captures affect my
    position on the high-scores display

And now we want to know what that special something is going to be for our Customer Services Rep:

In order that PrintCo printer cartridge sales go up by growing the mailing list:
  As a PrintCo Customer
  I want to be prompted for my e-mail address
  So that an e-mail reminder can help me avoid those times when I need
    to print something but the ink is empty

  As a PrintCo Customer Services Rep
  I need to be prompted to ask for the customer’s e-mail address
  So that I increase the points I get for e-mail captures, improving my
    position on the high-scores display

  As a PrintCo Customer Services Rep
  I need e-mail captures shown as one of the columns on the high-scores display
  So that I can see that the points I earn for e-mail captures affect my
    position on the high-scores display

And, if it is important that you capture the key stakeholder:

In order that the Marketing Manager grows PrintCo printer cartridge sales by growing the mailing list…

Or, you don’t need to even use ‘In order to’… you can word it any way you like

Goal: the Marketing Manager wants to grow PrintCo printer cartridge sales by growing the mailing list…

The most important thing here is not the wording. It’ that we find a way of keeping the business value in the conversation and when we’re talking about the capabilities, we focus on the user. What I’ve described is just one way of achieving that.

It’s like a “theme” for the stories

Themes have been suggested by many as a way of grouping user stories. In this case, the ‘In order to…’ can be thought of as a theme for the stories – i.e. the theme is described in terms of business value. Stories, described in terms of the user capability and incentive/context, are injected into the “theme” as we identify roles and capabilities that deliver the business value.

Notice, that I thought about the “As a…” and “So that…” aspects of the user story first and then summarised the capability, yet the order in which I expressed them remained as normal. As Rachel Davies once highlighted to me, just because we think of these things in one order, that may not be the best order for a discussion with the people who will implement it.

Another way of putting this is that the “As a… I want… So that…” is optimised for the conversation that helps the product owner(s) communicate what is required to the rest of the team, not for the order in which we generally discover the information.

In Summary

As you can see, Feature Injection doesn’t encourage you to simply move the “So that” to the beginning and reword it with “In order to”. I can see why people do that. One possible reason is because the stakeholder intent has been mashed into a user story, but that loses the purpose of a user story. I can also see why that happens, because there wasn’t an obvious place to think or talk about stakeholder intent. Business-value focused themes give us that.

I hope this helps clarify a little about Feature Injection and how it relates to user stories… but remember, this is only the tip of the Feature Injection iceberg. Actually it’s just one of the outcomes of Feature Injection. Watch this space for more.

Agile, BDD/ATDD, Software Development, Software Testing

Putting Cucumber where it’s not supposed to go will hurt!

March 7, 2011 AntonyMarcano Leave a comment

Today, I came across this post by Ryan Bigg where he talks of the pains he’s experienced with Cucumber.

Fortunately for Ryan, the outcome was a positive one, he ended up finding what appears to be a nice looking API for automating test-execution.

The experience he had with Cucumber, however, is a common one. Often teams start using Cucumber in an effort to reduce the need for programming skills when writing automated tests.

This isn’t the problem that Cucumber and other BDD tools are trying to solve and this is why so many teams who misuse it in this way experience difficulty and frustration.

BDD tools like Cucumber are designed to help teams and their customers arrive at a shared understanding of the problem they wish to solve (in terms of the user’s goals and tasks). It’s not really intended to describe the solution (i.e. step-by-step interactions with the GUI).

If your Cucumber scenarios have words such as “click” or “type” or mention field names and the like, it’s probable that you’re either:
a) Using Cucumber to automate test-execution (not what it was intended for) or
b) Trying to do BDD but writing the scenarios at too low a level of detail.

If you’re doing the latter (b)… then you may find the post I wrote over the weekend useful.

If what you’re doing is (a) then the post I wrote over the weekend might help you go down a path where automating your tests will make the transition to BDD that much easier.

If you really, really only want to automate test-execution then you might find that you’re putting Cucumber where it’s not supposed to go… and just so you know – that’s probably going to hurt 🙂

Agile, BDD/ATDD, Business Analysis, Software Development, Software Testing

A bit of UCD for BDD & ATDD: Goals -> Tasks -> Actions

March 6, 2011 AntonyMarcano 2 Comments

There’s something wrong with many behaviour specs (or acceptance tests). It’s been this way for some time. I’ve written about this once or twice before, referencing this post by Kevin Lawrence from 2007.

So, first things first, I want to take this opportunity to update the terminology I use…

Goals -> Tasks -> Actions
A useful technique used in User-Centred Design (UCD) and Human Computer Interface (HCI) design is Task Analysis. There are three layers of detail often talked about in Task Analysis:

Goal: What we’re trying to achieve which has one or more…
Tasks: The high-level work-item that we complete to fulfil the goal, each having one or more…
Actions: The specific steps or interactions we execute to complete the task.

Previously, the terms used by Kevin, myself (and several others) were Goal->Activities->Tasks. From now on, I’m going to use the UCD/HCI/Task Analysis terms Goal->Task->Action. It’s exactly the same model – just with different labels at the three layers of detail.

What’s wrong with your average behaviour spec?
Let’s look at a common example… The calculator. For convenience, I’m going to borrow this one from the cucumber website[1].

Scenario: Add two numbers Given I have entered 10 into the calculator And I have entered 5 into the calculator When I press add Then the result should be 15 on the screen
[1]note: I’m using this example for convenience and simplicity. The value of the example on the cucumber website is to demonstrate how easy cucumber is to use and not necessarily as an exemplar feature spec

What would you say the scenario’s name and steps are representing? Goals and Tasks or Tasks and Actions?

I’d argue that adding two numbers is a task and the steps shown above are actions.

Instead, I try to write the spec (or test) with a scenario-specific goal and the steps as tasks.

Scenario: sum of two numbers When I add 10 and 5 Then I should see the answer 15

I.e.:
Scenario: <A scenario specific goal> Given <Something that needs to have happened or be true> When <Some task I must do> Then <Some way I know I've achieved my goal>

Another Typical Example
Let’s apply this to another typical example that might be closer to what some people are used to seeing:

Scenario: Search for the cucumber homepage Given I am at http://google.com When I enter "cucumber" into the search field and click "Search" Then the top result should say "Cucumber - Making BDD fun"

Again this is talking in terms of actions. As soon as I’m talking in terms of click, enter, type or other user-action, I know I’m going into too much detail. Instead, I write this:

Scenario: Find the Cucumber home page When I search for "Cucumber" Then the top result should say "Cucumber - Making BDD fun"

Why does it matter?
In the calculator example, the outcome the business is interested in for the first scenario is that we get the correct sum of two numbers. The steps in the scenario should help us arrive at a shared understanding of what ‘correct’ means. How we solve the problem of getting the numbers into the calculator and choosing the operator is a separate issue. That’s detail we can defer. It may be better to explore the specifics of the workflow using, sketches, conversation, wire-frames or by seeing and using our new calculator.

So, expressing our scenarios in terms of goals and tasks helps the delivery team and the business arrive at a shared understanding of the problem we’re trying to solve in that scenario.

Expressing the scenario in terms of the clicks, presses and even fields we’re typing into is focusing on a solution, not the problem we’re trying to solve.

But there’s another benefit to doing it this way…

A Practical Concern – Maintainability
The first calculator example follows reverse-polish notation for the sequence of actions:

enter the first number
enter the second number
press add

If we put that detail in the scenarios, that workflow will be repeated everywhere – for addition, subtraction, division, multiplication… and anywhere any calculation is described.

What happens if the workflow for this calculator (such as the UI or API) changes from a reverse-polish notation to a more conventional workflow for a calculator? Like this:

enter the first number
press add
enter the second number
press equals

The correct answer hasn’t changed – i.e. the ‘business rule’ is the same – it’s just the sequence of actions has changed.

Now we have to go through all the feature files and update all the scenarios. In the case of our calculator that may only be a few files covering add, subtract, divide, multiply. For something larger and more complex this could be a lot of work.

Instead, putting this in the code of the step-definition means that this:
When ^I (add|subtract|divide|multiply) (.*) (?:and|from|by)? (.*) do |operator, first_number, second_number| @calc = @calc ||= Calculator.new @calc.enter first_number @calc.enter second_number @calc.send operator.to_sym end

Would have to change to this:
When ^I (add|subtract|divide|multiply) (.*) (?:and|from|by)? (.*) do |operator, first_number, second_number| @calc = @calc ||= Calculator.new @calc.enter first_number @calc.send operator.to_sym #moved up from the bottom @calc.enter second_number @calc.calculate #new action for the conventional calculator workflow end

Nothing else would need to change – other than the product of course. By writing the steps as tasks, all of our feature files would still accurately illustrate the business rule even though the workflow of the interface (gui or api) has changed.

Taking your scenario-steps to task
So, taking this approach helps us to reduce our maintenance overheads. Putting the Actions inside the step definition makes our tests less brittle. When the workflow changes we only need to update our specs in one place – the step-definitions.

Of, perhaps, greater importance – by capturing the user’s scenario-specific goal as the scenario name and the tasks as the steps, the team are working towards a shared understanding of the part of the problem we’re trying to solve not a solution we might be prematurely settling upon. When rolled up with the broader context (expressed in the user-story and its other scenarios) it gives us a focus on solving the wider problem rather than biasing the solution.

Sometimes, at first, it’s hard to see how to express the scenario and is easier when people start by talking of clicks, presses and what they’re entering. And that’s ok. Maybe that’s where the team needs to start the conversation. Just because that’s where you start, ask “why are we doing those actions” a few times, and it doesn’t have to be where you end up.

Business, People

Financial Rewards & Poorer Performance

February 17, 2011 AntonyMarcano Leave a comment

I like the message in this post by Johanna Rothman on Hiring Technical People. Johanna voices her disagreement with something said to her at a conference:

“I don’t think people have the same passion about their jobs. They just want more money.”

Johanna goes on to say:

I, of course, disagreed. The reasons people want money is that organizations have broken the implicit social contract to be fair with their employees […] That means there is strictly a financial contract between the employee and the organization.

There is, however, even more to this topic that I’d like to share.

The Business Incentive

There is a business incentive to paying more per employee that gets hidden by typical “per-unit” cost-budgetting.

Chapter 2 of Dan Pink’s book “Drive” references research (funded by the United States Federal Reserve Bank) that showed that monetary incentives for cognitive tasks will actually have the opposite of the desired effect – perhaps because cognitive capacity is wasted on thinking about what happens if the criteria for the financial incentive are met/not met.

So, financial incentives actually result in poorer performance for cognitive tasks.

Instead, Dan recommends paying enough that money just isn’t something that the employee ever thinks about. This frees up cognitive capacity to focus on the work at hand – thus increasing performance.

As a result, the total output of fewer employees who are paid more can be greater than having more employees who are paid less. This assumes that all the people in these two situations are of comparable levels of talent.

Add to this the fact that a company that does this will not only attract and retain the best talent, the performance gains through increasing the organisation’s “talent-density” can be even greater!

Even if your total salaries budget was the same in both cases and you just had fewer employees, each paid more but delivering the same as the scenario with the larger number of employees – there are still savings to be made on accommodation costs, management overheads etc.

Understanding Drive & Motivation

In Part Two of Drive, Dan Pink explains the three elements of motivation:

Autonomy
Mastery
Purpose

Many of Johanna’s suggestions mostly fall into the “Mastery” category – conferences, book-allowance, etc. Some of her suggestions imply autonomy – such as more flexibility in working hours and holiday/vacation.

A great example of this is Netflix. They started with old-fashioned holiday limits, but eventually…

…some employees recognised that this arrangement was at odds with how they really did their jobs. After all, they were responding to emails on weekends, they were solving problems online at home at night. […]

Since Netflix wasn’t tracking how many hours people were logging each work day, these employees wondered, why should it track how many holidays people were taking each work year?

From the Telegraph Newspaper

Netflix no longer tracks holiday time taken by their employees. Despite this, Netflix offices aren’t deserted with everyone on a permanent holiday and its people have made Netflix so successful that they (arguably) played a role in driving a much larger, more well established provider of blockbuster movie rentals to bankruptcy.

Dan delivers some compelling arguments that motivation and getting the best performance from people comes from giving people autonomy, the opportunity to master what they do and a clear purpose (beyond just making a profit for their employer).

Choosing the right incentives

We can take Dan’s “Three Elements” to inspire ideas about what incentives will motivate our people. Or, we can take these ideas completely to heart.

Rather than telling our employees that they have a book allowance and a conference/workshop budget and so on, we could simply give individuals (or teams) a “Mastery” budget and give them autonomy in how they spend it. Or, we could just pay it directly to the employees (like many companies do with a car allowance) and trust that they’ll spend it wisely.

Realistically, there may be taxation benefits to not giving the money directly to the employees. It may also offer more flexibility, say if a team, wanted to combine some of their budget for coaching or bringing a trainer in-house rather than individually going on the same public course.

The biggest fear some will have is that employees will abuse this freedom. If this happens, we can consider the misspent cash as an investment in discovering the people in our company who we might not want in our company anymore.

Some may argue that this is too much of a risk, but you know what they say… the greater the risk, the greater the rewards.

Many of the things I mention in this post can be heard in Dan Pink’s 10 minute talk on “Drive”…

Business, Old Favourites, Project Management, Software Development

Old Favourite: Adaptive Budgets? “Pull” the other one!

December 13, 2010 AntonyMarcano Leave a comment

This was originally posted on my old blog on 10th April 2010

Recently, I wrote about my views on using and estimating with task-cards. I highlighted that tracking progress with burn-up/down charts showing effort completed/remaining is not a true measure of progress, especially if we subscribe to the idea that we measure progress with working-software.

I also highlighted how tasks “horizontally slice” a “vertically sliced” story.

This inspired an article on infoq by Mark Levison. Since its publication, there have been several comments.

There are some specific points I’ll be answering on infoq, but some general points are more easily answered here…

True measures of progress
One of the key points I was trying to make in my first post (linked to above) is that if “working software” is our measure of progress then tracking task completion is not consistent with that.

One of the problems task-hours are trying to solve is to provide a visible indication of progress. It’s also something that many people find easier to understand. The idea of relative-points estimation seems to baffle many people when they first encounter it.

In my original post (linked above) I referenced an approach, blogged about by Jason Gorman, outlining a solution to providing a visible indication of progress that is compatible with the idea of measuring progress with working software. It also works more seamlessly with the solution of measuring throughput trends of the team (e.g. with story points) so that the team can estimate how much can be done in the next iteration.

Value Points & Task Points
Value points were mentioned in the infoq comments. Value points are solving a different problem and don’t help the team estimate what can be done. The value of a story isn’t an indication of its complexity. Value, combined with complexity points, can help determine priorities. Arlo Belshey explains some interesting views on this.

Prioritisation is, in my view, one of the few reasons to place some sort of estimate on value & complexity. Unfortunately, it seems to be often used to establish a contract with the team for when something will be done and apply pressure when the estimates turn out to be inaccurate.

Non-estimating pull systems
My preference is to use such estimates only for prioritisation… after that, things just take as long as they take. There is some benefit in tracking accuracy trends so that we can learn from them, however, spending too much time on these things simply slows down the process of getting things done. Interestingly, I have not yet seen the business be quite so passionate about evaluating whether their value estimates were accurate when the product makes it to the real world. Funny that.

Instead, I prefer to leave estimation behind once we’ve prioritised things and pull stories or customer valued work items through the system without using previous estimates to predict their completion date. With the way that most budgets are determined and allocated, this idea isn’t compatible with the way much of the business world works. For pull systems that eliminate estimation as a means of predicting the future to work (such as Kanban), we need a more adaptive approach to budgetary spend. Business needs to find a way to adapt budget allocation more frequently, perhaps as frequently as monthly, perhaps more frequently still. The business now needs to look at how it can respond to change rather than focus on following a budget-plan.

Business-world: now it’s your turn
Budget holders now need to be more agile. We, those who evolve the implementation of the ideas of the business, have responded to their demands to be able to respond to rapidly changing markets and provide that competitive edge. For the more mature implementation teams, the hindrance now is no longer how we make the products, but the business culture of inflexible and predictive budget allocation.

BDD/ATDD, Business Analysis, Old Favourites, Project Management, Software Development, Software Testing

Old Favourite: Taking Repetition To Task

December 13, 2010 AntonyMarcano 1 Comment

This originally appeared on my old blog on 16th March 2010…

Others have talked about the virtues of stories as vertical slices of a problem (end-to-end capabilities) rather than horizontal slices (system layers or components). So, if we slice the problem with user stories, how do we slice the user-stories themselves?

If, as I sometimes say, acceptance tests (a.k.a. examples/scenarios/acceptance-criteria) are the knife with which we slice a story into even thinner vertical slices, then I would say my observation of ‘tasks’ is that they are used as the knife used to cut a story into horizontal slices. This feels wrong…

Sometimes I also wonder, hasn’t anyone else noticed that the idea of counting the effort of completed tasks on burn-down/up charts is counter to the value that we measure progress only with working software? Surely it makes more sense to measure progress with passing tests (or “checks” – whichever you prefer).

These are two of the reasons I’ve never felt very comfortable with tasks, because:

they’re often applied in such a way that the story is sliced horizontally
they encourage measuring progress in a less meaningful way than working software

Tasks are, however, very useful for teams at first. Just like anything else we learn how to do, learning how to do it on paper can often help us then discard the paper and do the workings in our heads. However, what I’ve noticed is that most teams I’ve worked with continue to write and estimate tasks long after the practice is useful or relevant to them.

For example, there comes a time for many teams where tasks become repetitive. “Add x to the Model”, “Change View”… and so on. Is this adding value to the process or are you just doing it because the process says you should do it?

Simply finding that your tasks are repetitive doesn’t mean the team is ready to stop using them. There is another important ingredient, meaningful acceptance criteria (scenarios / acceptance-tests / examples).

I often see stories with acceptance criteria such as:

Must have a link to save the profile
Must have a drop down to select business sector
Business sector must be mandatory
…

Although these are “acceptance criteria” they aren’t what we mean by acceptance criteria in the context of user stories. Firstly, they are talking about how the user interacts rather than what they need to achieve (I’ve talked about this before). Secondly, they aren’t examples. What we want are the variations that alter the behaviour or response of the product:

Should create a new profile
Profile cannot be saved with blank “business sector”

As our product fulfils each of these criteria, we are making progress. Jason Gorman illustrates one way of approaching this.

So, if you are using tasks, consider an alternative approach. First, look at your acceptance criteria, make sure they are more like examples and less like instructions. Once that’s achieved, consider slicing each criterion (or scenario) horizontally with the tasks rather than the story. Pretty soon, you’ll find that you don’t need tasks anymore and you can simply measure progress in terms of the new capabilities you add to your product.

Business, People

Your Company Values What?

December 12, 2010 AntonyMarcano 1 Comment

I’ve recently given some time to think about company values on behalf of a client. In my research, I have looked through the stated corporate/business/company values of several organisations, I’m not convinced that many of them are really values.

I’ll take Zappos company values (as they were at the time of writing this) as a perfect example of what I’ve been seeing:

Deliver WOW Through Service

Embrace and Drive Change

Create Fun and A Little Weirdness

Be Adventurous, Creative, and Open-Minded

Pursue Growth and Learning

Build Open and Honest Relationships With Communication

Build a Positive Team and Family Spirit

Do More With Less

Be Passionate and Determined

Be Humble

I love the spirit of these statements and Zappos have a culture that seems to reflect them. These statements, however, are not really ‘values’. Instead, these statements are more like ‘behaviours’.

Behaviours are the things we do. Values are the things we care about.

What are the things we care about?

The things we care about are the things that cause an emotional response – such as when we get angry or frustrated at something someone does, shame at something we do or feel joy and pride when we or someone else does something.

For example, if we care about delighting our customers, we may feel frustration when we see a colleague act with apathy towards a customer complaint or we may feel pride when we or a colleague does something wonderful that our customer didn’t expect.

We may see these responses towards in our clients too. For example, if we value Compassion and Empathy and our customer intentionally delays payment because it helps with their cash-flow we may get frustrated – or if they pay well before the final due-date we may feel positively towards them. But the issue of ‘choosing the right clients’ is perhaps beyond the scope of this article.

When we see our people reacting in these ways, we know that we have an organisational culture based on shared values. We know that we care about the same things.

Why do we want ‘company values’?

For some companies, it’s more about branding – a display of the type of company they think future customers or future employees would want to buy the products of or to work with. It is something that appears on the face of the company but isn’t necessarily reflected in the actual behaviours of the people, as we can see from this article about Enron’s company values. The journalist makes the point that all company values are much the same and really are little reflection of the reality:

I know one writer who, while struggling to draft one of these corporate credos, threw up her hands in despair and observed: ”Why not just come right out and say it? ‘We will strive to make as much money as we can without going to prison.’ ”

She was joking, of course.

What I want from stating our company values is to understand what kind of company we want to be and to guide – even drive – what we do, who we hire and who we fire. I want to see that people in our organisation (and even our clients) have shared, or at least compatible, values. I want to see a negative emotional reaction to situations that go against these values and a positive emotional reaction to situations that are aligned with these values. I want to see the people I work with instinctively do ‘the right thing’ based on our shared (or compatible) values without having to be told what ‘the right thing’ is. I accept that ‘the right thing’ for one person and another may be different – and this is where shared or compatible values are the key to a consistent experience of what we do – for the people inside and outside the company.

The things we care about drive us to act, instinctively, based on the situation at hand. If our people share these values, we’ll act reasonably consistently with each other – delivering a consistent service to our customers.

A Code of Conduct?

When we list our values as the things we do there is a danger that these statements become, to all intents and purposes, a code of conduct. Why does this matter?

A code of conduct, in some ways the ‘laws’ of a company, tells people what to do and what not to do. If we need to tell our people what to do and what not to do (i.e. what is ‘the right thing’ and what is ‘the wrong thing’ to do), I believe, we are compensating for having hired the wrong people.

“Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws.” – Plato

Codes of conduct are a way of constraining freedom. In a society where we have no choice as to who is a member of it, this may be necessary. In an organisation where we do have a choice over who is a member of it, the only reason we would have to reduce freedom is if we compromise on the ‘quality’ of the people we hire.

From slide 38 of this presentation from Netflix, they explain how many companies curtail freedoms as they grow and why they aim to increase freedoms. Hiring the right people is key to the success of this approach.

Culture

View more presentations from Reed Hastings

Many companies try to grow more quickly than they can find the right people to do so effectively. They hire the least-worst from the available candidates in order to grow quickly rather than hiring the best. Netflix have chosen to grow no faster than they can find the most talented people who share in their values.

The people in such an organisation can simply be trusted to do the right thing, in any situation, even if that situation isn’t one we’ve thought of previously. A code-of-conduct and its loopholes is then redundant.

RiverGlide Values

We spent a lot of time thinking about our company values when we first created RiverGlide. We (Andy Palmer, James Martin and I) discussed, explored and refined our understanding of what we cared about and reflected that in our stated values. We learned more as time passed. We added to them (quite recently) because we realised there were many more things that we cared about. How we state our values continuously evolves as we deepen our understanding of what matters to us and what we think differentiates us. These values are not the values we aspire to or the values we want to impose on others. They are the values that reflect what we actually care about. They are the values we see in the people we want working with us.

We originally found ourselves wording our values like this:

Now, I think we’ll be experimenting with this subtle change:

For example:

Trust and Transparency – We feel great when we know you trust us through our extreme levels of transparency.
Integrity and Courage – We would be unhappy if we told you what you wanted to hear if that was not the same as what you need to know.
Innovation and Personal Growth – We get a buzz from learning new things, developing skills, trying whacky ideas and cultivating outside-the-box thinking.
Compassion and Empathy – We love what we do when you love what we do. We are as passionate about your people and products as we are about our own.
Joy and Creativity – We are inspired by fun and creativity – whether it’s in what we do or what we help you do.

Behind these values is a single purpose to our company – we make things easy – hence our tag-line “flow without friction“.

Your Company Values What?

So, what does your company appear to actually value? What values does the culture of your organisation reflect through how it rewards, recognises and respects the things that people do? How do you feel when people act in a way that is aligned or against these values? How does all of this match up to what your company says are its core values?

Why does any of this matter? It matters to me because I am happier when the people I work with are happy – clients, contractors, employees and colleagues alike. It matters to me because I want to trust that the people around me will ‘do the right thing’ and that we’ll all generally agree that what they did was the right thing (even if sometimes we have to have a discussion to understand why). It matters to the people in the company because we know we’ll share in a vision of what kind of company we should be and be motivated to make it a success together – from the most skilled & experienced craftsmen to the smartest and passionate intern.

For us this was relatively easy because we figured out the essence of our core values early in the life of our company and it has formed the foundation of all our working relationships. For you, a legacy culture may not be so easy to redefine. But, if you have a vision of the culture you want to inspire in your organisation or team… If you understand what matters (or should matter) to you and your people and what will bring your company, and the people within it, success… I think you’ll have a great starting point to begin the harder task of spreading those values throughout the culture of the people in your company and teams.

Agile, Project Management, Software Development, Software Testing

Old Favourite: QA / Testing – what’s the difference?

November 19, 2010 AntonyMarcano 2 Comments

Software is ~~about the only industry~~ one of the few industries that lumps testing and QA under one banner. It’s one of those things where common misuse of a term results in the community changing it’s meaning… this happens in mainstream language all the time.

Testing something is actually more analogous to quality control or, QC , [although it isn’t quality control].

QA is more concerned with the process – collecting information about the performance of the process in order to determine if we are ‘assuring’ (or more realistically increasing the probability of) quality. Statistical information about problems found in the product (during quality control) is just one of many pieces of info useful to someone concerned with QA (which really should be the whole project team)

In short:

QC helps us answer the question ‘does our product work?’

QA helps us answer the question ‘does our process work?’

Unfortunately, in the software industry, all too many teams don’t realise their process doesn’t work until the testers find all the ways in which the product doesn’t work… maybe that’s why software testing has come to be known as QA.

This article originally appeared on my old blog in July 2008. I had already elaborated on this topic in the article “What’s in a word” in Better Software Magazine in March 2008.

antonymarcano.com