Posts Tagged agile
This is not a manifesto: Valuing Throughput over Utilisation
Posted by AntonyMarcano in Agile, Lean, Project Management, Software Development, Software Testing on February 11, 2012
In a previous article, This is not a manifesto, I expressed the values I hold as a software development team member. Today, I’m going to talk about the first of these values.
Before I do, I’d like to say what I mean by “software development team”. I mean a cross-discipline team with the combined skills to deliver a software product – product owner, user experience, business analysts, programmers, testers, dev-ops, etc.
A common problem
Many teams I encounter will, at least in the beginning, have team-members who specialise in a single role. Each team-member will rarely, if ever, step outside their job description [1]. This can cause a problem.
Many teams find themselves in a situation where some team members have little to do on the current stories. At this point, the team has some choices, they can focus the under-utilised people on:
- Future user-stories, working on tasks most relevant to their job title
- Another team, working on tasks most relevant to their job title (e.g. ‘matrix management’)
- Current stories, taking on tasks that will take the story to completion sooner, even if it’s more relevant to someone else’s job title
- Things that will make the more utilised people get through their work faster, today and in the future.
More often than not, I find teams taking option 1. I think that people choose this option because it feels like it should increase the throughput of the team – i.e. the amount of new features they can add to the product. In fact, it has the opposite effect.
Little’s law
Let’s consider a team that is working in time-boxes or ‘sprints’ (à la Scrum) and measures it’s throughput with ‘velocity’ (story-points per-sprint). Points are accrued as each user-story is completed – i.e. coded, tested and product-owner validated.
In this particular team, it is able to complete an average of 10 points per sprint. Let’s say this is due to a bottleneck in the process. This bottleneck might limit the amount of testing that can be completed during the sprint. This is illustrated in fig.1 where each ball is a story point.
Little’s law [2] tells us that the amount of time it takes to complete an item of work (cycle-time) is:
Work in Progress (WIP)
Throughput
Which we can read as:
story points in progress
velocity
In this simplified example, WIP is 10 points and throughput is 10 points per sprint. The average cycle time of a story is therefore 10/10 = 1 sprint. Notice, however, there’s all that spare capacity.
Let’s say this spare capacity is developers. So, the team starts taking on more user-stories from the backlog – increasing the number of story points in progress to 20 points (fig.2).
Because the bottleneck remains, velocity remains the same – 10 points per sprint. The amount of flexibility that the team has, however, is now reduced because the average time required to get a story to completion has increased from 1 sprint to 20/10 = 2 sprints [3].
Often this will take the form of testers working a sprint behind the developers. Worse still, over 10 sprints, the team still only completes 100 story points (as they would have before) but is left with a lot of unfinished work. This ‘inventory’ of unfinished work carries overheads which can, ultimately, reduce the velocity of the team.
The impact of filling capacity in this way has yet another effect.
Latency effect
As the developers get through more stories, a queue of stories that are “ready for testing” will build up. Testers working through these will, at least, have questions for the developer(s) or even find some defects. The developer, having moved on from that story, is now deep into the code and context of another story. When the tester has questions, or finds defects, relating to a story that the developer had worked on, say a week ago, then the developer has to reload their understanding of this old code and context in order to answer any questions or fix any defects. This context-switching carries significant overheads [4].
The end result is that the effort required to complete a story increases due to the repeated context switching, therefore reducing velocity.
So, not only does filling the capacity with more work fail to increase throughput, it adds costly context-switching overheads – ultimately slowing everything down.
This phenomenon is not unique to teams using fixed-length time-boxes, such as sprints. Strictly following Kanban avoids this problem, but what I’ve seen is some teams creating a ‘ready for testing’ queue – so that developers can start work on the next story. This has the same latency effect and turns a process designed for continuous flow into a batch and queue process. But, I digress.
What to do with the spare capacity?
The simple answer is to look at the whole approach and determine what is slowing things down. In the example above, I’d be wondering what’s slowing the testing down. Many of the things that hinder testing can be addressed by changing how we do things ‘upstream’.
Are lots of defects being found, causing the testers to spend more time investigating and reproducing them? Can we get the testers involved earlier? Can any predictable tests be defined up front so that developers can make sure the code passes them before it even gets to the testers (e.g. Behaviour Driven Development)?
Are the testers manually regression testing every sprint? Could the developers help by automating more of that? Are the testers having to perform repetitive tasks to get to the part of the user-journey they’re actually testing? Can that be automated by the developers?
Is there anything else that is impacting them? Test data set-up and maintenance, product owner availability to answer questions? Anything else?
Addressing any of these issues is likely to speed up the testing process and increase throughput of the entire team as a result. One solution is to put these types of tasks onto the product backlog. This is fine but if we assign point values to them it can give a skewed view of velocity. Or rather, velocity is no longer a measure of throughput. You won’t be able to see if these types of tasks are actually improving things unless you are also measuring what proportion of the points are delivering new product capabilities.
The only good reason I can think of for story-pointing these throughput-enhancing tasks is if your focus is utilisation – i.e. maximising the number of story-points in progress. Personally, I care more about measuring and improving throughput. By doing so, we get the right utilisation for free and a faster, more capable team.
Up next: Valuing Effectiveness over Efficiency.
Footnotes:
[1] “Lessons Learned in Close Quarters Battle” Illustrates how stepping outside our job descriptions can move the team through each story more quickly by using special-forces room-clearing as an analogy.
[2] Little’s law (PDF) – the section “Evolution of Little’s Law in Operations Management” that references Hopp and Spearman’s observation about throughput (TH), work-in-progress (WIP) and cycle-time (CT) – i.e. TH=CT/WIP. And therefore we can say CT = WIP/TH.
[3] Little’s law also illustrates that if we reduce the work in progress to one quarter, then the cycle time for each story reduces to one quarter of a sprint. We’ll still get through 10 points per sprint, but stories will be completed more as a continuous stream throughout the sprint rather than all at the end.
[4] “The Multi-Tasking Myth” by Jeff Atwood, talks about multi-tasking across projects and pulls together several resources to illustrate the impact of multitasking at various levels. This applies when multi-tasking across stories.
Acknowledgements:
I’d like to say a special thank you to my fellow RiverGliders – Andy Palmer and James Martin – for the feedback that helped me refine this article.
Scenario-Oriented vs. Rules-Oriented Acceptance Criteria
Posted by AntonyMarcano in Agile, BDD/ATDD, Business Analysis, Software Development, Software Testing, Uncategorized on October 2, 2011
Acceptance Criteria, Scenarios, Acceptance Tests are, in my experience, often a source of confusion.
Such confusion results in questions like the one asked of Rachel Davies recently, i.e. “When to write story tests” (sometimes also known as “Acceptance Tests” or in BDD parlance “Scenarios”).
In her answer, Rachel highlighted that:
“…acceptance criteria and example scenarios are a bit like the chicken and the egg – it’s not always clear which comes first so iterate!”
In that article, Rachel distinguishes between acceptance criteria and example scenarios by reference to Liz Keogh’s blog post on the subject of “Acceptance Criteria vs. Scenarios”:
“where she explains that acceptance criteria are general rules covering system behaviour from which executable examples (Scenarios) can be derived“
Seeing the acceptance criteria as rules and the scenarios as something else, is one way of looking at it. There’s another way too…
Instead of Acceptance Criteria that are rules and Acceptance Tests that are scenarios… I often find it useful to arrive at Acceptance Criteria that are scenarios, of which the Acceptance Tests are just a more detailed expression.
I.e. Scenario-Oriented Acceptance Criteria.
Expressing the Intent of the Story
Many teams I encounter, especially newer ones, place higher importance on the things we label “acceptance criteria” than on the things we label “acceptance tests” or “scenarios”.
By this I mean that, such a team might ultimately determine whether the intent of the story was fulfilled by evaluating the product against these rules-oriented criteria. Worse still, I’ve observed some teams also have:
- Overheads of checking that these rule-based criteria are fulfilled as well as the scenario-oriented acceptance tests
- Teams working in silos where BAs take sole responsibility of criteria and testers take sole responsibility for scenarios
- A desire to have traceability from the acceptance tests back to the acceptance criteria
- Rules expressed as rules in two places – the criteria and the code
- Criteria treated as the specification, rather than using specification by example
If we take the approach of not distinguishing between acceptance criteria and acceptance tests (i.e. see the acceptance tests as the acceptance criteria) then we can encourage teams away from these kinds of problems.
I’m not saying it solves the problem – it’s just easier, in my experience, to move the team towards collaboratively arriving at a shared understanding of the intent of the story this way.
To do this, we need to iteratively evolve our acceptance criteria from rules-oriented to scenario-oriented criteria.
Acceptance Criteria: from rules-oriented to scenario-oriented:
Let’s say we had this user story:
As a snapshot photographer
I want some photo albums to be private
So that I have a backup of my personal photos online
And let’s say the product owner first expresses the Acceptance Criteria as rules:
- Must have a way to set the privacy of photo albums
- Private albums must be visible to me
- Private albums must not be visible to others
We might discuss those to identify scenarios (as vertical slices through the above criteria):
- Create new private album
- Make public album private
- Make private album public
Here, many teams would retain both acceptance criteria and scenarios. That’s ok but I’d only do that if we collectively understood that the information from these two will come together in the acceptance tests… And that whatever we agree in those acceptance tests supersede the previously discussed criteria.
This understanding tends to occur in highly collaborative teams. In newer teams, where disciplines (Business Analysts, Testers, Developers) are working more independently this tends to be harder to achieve.
In those situations (and often even in highly collaborative teams) I’d continue the discussion to iterate over the rules-oriented criteria to arrive at scenario-oriented criteria, carrying over any information captured in the rules, discarding the original rules-based criteria as we go. This might leave me with the following scenarios:
- Create new private album (visible to me, not to others)
- Make public album private (visible to me, not to others)
- Make private album public (visible to me, & others)
Which, with a subtle change to the wording, become the acceptance criteria. I.e. the story is complete when we:
- Can create new private album (visible to me, not to others)
- Can make public album private (visible to me, not to others)
- Can make private album public (visible to me, & others)
Once the story is ‘in-play’ (e.g. during a time-box/iteration/sprint) I’d elaborate these one at a time, implementing just enough to get each one passing as I go. By doing this we might arrive at:
Scenario: Can Create new private album When I create a new private album called "Weekend in Brighton" Then I should be able to see the album And others should not be able to see it Scenario: Can Make public album private Given there is a public album called "Friday Night" When I make that album private Then I should be able to see the album And others should not be able to see it Scenario: Can Make private album public Given there is a private album called "Friday Night" When I make that album public Then I should be able to see the album And others should be able to see it
By being an elaboration of the scenario-oriented acceptance criteria there’s no implied need to also check the implementation against the original ‘rules-oriented’ criteria.
Agreeing that this is how we’ll work, it encourages more collaborative working – at least between the Business Analysts and Testers.
These new scenario-based criteria become the only means of determining whether the intent of the story has been fulfilled, avoiding much of the confusion that can occur when we have rules-oriented acceptance criteria as well as separate acceptance test scenarios.
In short, more often than not, I find these things much easier when the criteria and the scenarios are essentially one and the same.
Why not give it a try?
Old Favourite – More Sharks and Delaying Critical Mass
Posted by AntonyMarcano in Agile, Business, Business Analysis, Old Favourites, Project Management, Software Development, Software Testing on June 7, 2011
This article originally featured on my old blog on 19th January 2010.
In a previous post I talked about Critical Mass of software. I showed how an ever-increasing cost of change resulted in it becoming more economical to completely rewrite the system than to enhance and maintain the original.
I explained how this could be avoided by using practices that sustain a consistent and flat cost of change. I also mentioned that you could defer reaching critical mass. Some teams find it difficult to get the time to do this because “the business” always has “more important” or “higher-value” things on their backlog.
What are the implications of reaching critical mass? Well, depending on what the software does and whether the rewritten version still has to do all of those things, it could cost millions… or more.
Presented with the situation that the product could reach critical mass within a year – costing millions to replace – do you think “the business” would start to think it is worth investing in reducing the cost of change? Obviously, I would advise teams to avoid this situation in the first place:
The reality for many teams I’ve encountered is that they don’t feel empowered to push back on the business’ demands for that next feature in half the time it takes to do it properly. If we could present back the impact of that choice as shortening the time to Critical Mass and bringing about costs to replace the software far in excess of the value gained by delivering that feature a month early then perhaps the business would be better informed.
A big visible chart on the wall, showing the estimated point at which Critical Mass was reached could play a big role in getting the business more interested in sustainable change, or at least inspire a conversation on the subject.
Convincing “the business” to invest in some remedial refactoring or allowing three times as long for each feature to facilitate enough remedial refactoring for each new feature and refactoring-as-we-go for the new feature might be easier if we could represent this idea visually:
The problem with this idea is how do we credibly determine when Critical Mass is going to be reached? Many experienced practitioners could probably reasonably accurately estimate when that was going to happen purely on gut feel but this would be torn to pieces by many product managers. I’ve not solved this problem yet because doing this would require a mathematical model, determined by empirical data.
Perhaps someone will take inspiration from the ideas in these blog posts and find a solution. Perhaps someone has already done this or maybe this is an idea for a future PhD I might undertake? Maybe someone else will take inspiration from this article and undertake that work before I do. If so, they’re welcome to (with due attribution where applicable of course 
I think it is possible, however, to come up with a simple model based on the average complexity per unit of value (assuming that the team is using value and complexity). Trending this and keeping an estimate of a complete re-write up to date might allow the simple charts above to be maintained along side release-level burn-down charts.
These ideas are still in their infancy for me. Has this problem been solved already? If not, I encourage others to explore my hypothesis and help take it from just an interesting idea to something more useful.
Old Favourite – Sharks, Debts, Critical Mass and other reasons to Sustain Quality
Posted by AntonyMarcano in Agile, BDD/ATDD, Business, Business Analysis, Old Favourites, Project Management, Software Development, Software Testing on June 7, 2011
This article originally featured on my old blog on 18th January 2010.
A while back I tweeted about critical mass of software:
Critical Mass of Code – past which the changeability of the code is infeasible, requiring that it be completely rewritten.
An elaboration of this might be:
Critical Mass of Software: the state of a software system when the cost of changing it (enhancement or correcting defects) is less economical than re-writing it.
This graph illustrates a hypothetical project where the cost of change increases over time (the shape of which reminds me of a thresher shark):
Note:The cost of a rewrite gradually grows at first to account for the delay between starting the re-write and achieving the same amount of functionality in the original version of the software at the same point in time. The gap between the cost-of-change and the cost-of-rewrite begins to decrease as the time it takes to implement each feature of comparable benefit in the original version grows.
It was just one of those thoughts that popped into my head. I soon discovered that critical mass of software is not a new idea.
One opportunity that I feel organisations miss out on is that this can be used as a financial justification for repaying technical debt, thus preventing or delaying the point at which software reaches its Critical Mass, or avoiding it altogether.
Maintaining quality combined with practices that keep the effort involved in completing each feature from growing over time can defer critical mass indefinitely:
Note: The cost of a rewrite is slightly less at first assuming that we are doing a little extra work to ensure that we get the infrastructure we need up and running to support sustainable change (e.g. continuous integration etc.)
This flat cost of change curve is one of the motivations of many agile practices and software craftsmanship techniques, such as continuous integration, test-driven-development, behaviour driven development and the continuous refactoring inherent in the latter two. A flat cost-of-change trend is good for the business, as they have more predictable expenditure.
The behaviour I’ve noticed with some teams is to knowingly accrue technical debt to shorten time to a near-future delivery in order to capitalise on an opportunity and then pay it back soon after:
This certainly defers reaching critical mass but it doesn’t prevent it.
Unfortunately, I see more teams taking on technical debt and not repaying it (for various reasons, often blamed on “the business” putting pressure on delivery dates).
If we had a way of estimating the point at which we’d reach critical mass, we’d be able to compare the benefit of repaying technical debt now in order to avoid or delay the cost of a rewrite… or even better, demonstrate the value of achieving a flatter cost of change.
I’m not sure that we have the data or the means of predicting it, but perhaps these illustrations of a hypothetical scenario will help you explain why sustaining constant quality, automating repeatable tests (or checking as some prefer to call it) wherever technically possible and, on those occasions when we do need to make a conscious choice to compromise quality to capitalise on an opportunity, that the debt is repaid soon after.
One company I know reached this point a couple of years ago and embarked on a department wide transformation to grow their skills in agile methods so that they not only re-wrote the software but could also avoid ever reaching critical mass again. A bold move, but one that paid off within a year. Even for them, they’ll need to avoid complacency as time goes on and not forget the lessons of the past. Let’s hope they do.
Old Favourite – Developer Race-Tech: Continuous Testing
Posted by AntonyMarcano in BDD/ATDD, Old Favourites, Software Development on June 6, 2011
The original version of this article appeared on my old blog on 28th April 2010. This version has had some edits…
Gearboxes in competitive motor racing are designed to shift as fast as possible. A competitive race-car has computer controlled, hydraulically activated gear shifts that change gears up or down faster than you can blink (literally)! In Formula One, each shift is so fast that the gearbox systems have been dubbed “seamless shift” gearboxes and can shift gear in around 2-4 100ths (0.02 – 0.04) of a second. Compare that to the circa 1-2 second gear-shift a competent driver takes to manually de-clutch, change gear and re-clutch on a road car. Even automatic gearboxes on road cars can’t keep pace with the rapid gear changes that a race car delivers.
Competitive Edge
The race car is only saving fractions of a second with each accelerated up-shift, but the race-driver changes gear so often per lap and there are so many laps in a race that these fractions of a second can add up to a vital and significant lead over their competitors.[1]
Set aside the lap-time improvements for a moment from spending at least half a second more on the power per up-shift than with a manual box… The modern F1 driver has much more to do in the cockpit too than the comparative tedium of changing gear [2].
Developer race-tech
Now, in motor racing, such gearboxes are taken for granted. No serious Formula One racing team would put their car on the track without one.
In a world where a lot of software development is for companies competing in the economical equivalent of a race, it seems that development teams aren’t taking full advantage of their own metaphorical millisecond gear-shifts.
There are tools that are a developer’s equivalent of a racing gearbox. The simplest example is background compilation. Other examples are refactoring tools that make widespread changes with a simple key-stroke. What once took minutes or hours with global find & replace or even scripting, we can complete in seconds. IDEs that automatically complete class-names and method names are another example. These are tools that many of us take for granted, like the racing driver and automated gear-shift.
Falling behind
But there are other places where we are still not taking full advantage of the technology. I am still encountering surprisingly few people using continuous testing tools, where tests are run automatically in the background every time a file is saved, and not just the test I’m working on, all my tests. There are a few tools available for this, including Infinitest and ZenTest.
Despite the availability of such tools, I still see many developers using keyboard shortcuts to execute tests. Or, worse, reaching for the mouse, right-clicking, navigating another menu level down and running the tests with a left-click, or worse still, forgetting to run them altogether. I want rapid feedback with minimum friction to obtaining it. Much like background compilation, unit tests should just run, and run often, alerting us when a problem occurs. The easier they are to run, the more likely we are to run them… How much easier could it be than it happening automagically each time we save a file?
Need for Speed
Try it for a while and, like me, even keyboard-shortcut executed tests start to feel like you’re stuck in traffic rather than being in a competitive race to the finish… Or, maybe it’s just me and my need for speed…
The video is of me on the Silverstone Southern Circuit (part of the F1 GP circuit) taking my UK National Class B Racing License Test in a Nissan R35 GTR – approx 480+bhp, 0-62mph (0-100kmh) in 3.5secs, using it’s double-clutch, paddle-operated gear-shift providing gear changes in about 0.2 of a second. I passed… despite being very cautious on the brakes… and was noticeably quicker than the other person doing their test… which you see towards the end as I pass them 
[1] At the Monaco GP, an F1 driver will change gear around 50-60 times in one lap. Over 78 laps, this adds up to as many as 4680 gear changes over the whole race (up and down-shifts).
[2] The comparative tedium of de-clutching, shifting and re-engaging the clutch is something that a race-driver should not need to worry about as they approach 200mph while adjusting the brake-balance lever, switching to a new fuel-air mixture setting, pressing the KERS boost button and/or deactivating the Drag Reduction System.
A bit of UCD for BDD & ATDD: Goals -> Tasks -> Actions
Posted by AntonyMarcano in Agile, BDD/ATDD, Business Analysis, Software Development, Software Testing on March 6, 2011
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.
Old Favourite: Taking Repetition To Task
Posted by AntonyMarcano in BDD/ATDD, Business Analysis, Old Favourites, Project Management, Software Development, Software Testing on December 13, 2010
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.
My Tack on Effective Change
Posted by AntonyMarcano in Agile, Business, People, Project Management on November 11, 2010
One of the key characteristics of how we coach our clients’ teams is that we help them start from where they are and introduce small, frequent changes that help them progressively achieve their goals.
Each incremental change is driven by a problem the teams recognise they are facing. We then help to find a small change they are happy to introduce as an experiment. This change must be a solution or a step towards a solution to the identified problem. Sometimes this experiment will be limited to a single iteration. Sometimes it’s limited to a single user-story in a given iteration.
Based on the outcome of the experiment, the team decides what to do next. They may continue the experiment, introduce the change beyond the limitations of the experiment or even abandon that change and try something else.
This has two distinguishing factors.
1. Solving Problems: We focus on solving problems not introducing solutions
2. Continuous Improvement: Delivery continues, becoming increasingly productive
1. Solving Problems: For example, we’ve often been contacted to ‘introduce TDD’ or ‘transition a team to Scrum’. Usually, we find that behind these solutions are problems that our client instinctively understands are there but articulates them as these kinds of solutions. Sometimes they want to reduce the amount of re-work, or get early visibility of achievable scope within a time-constraint. Other-times it’s a solution for solution sake.
By solving the problems the people in the organisation recognise as holding them back, they are bought into each change. Sometimes our job is to help them recognise the problems. Retrospectives are a great way of achieving that.
2. Continuous improvement: When helping an organisation to solve the problems they face they expect large and significant change. Instead we help them make a continuous series of small, team-driven changes. This allows them to continue to deliver with the net effect of gradual and continuous improvements in productivity.
We generally find ourselves taking this approach because for most of our clients, big-bang change is not practical simply due to the impact on productivity. We can understand this using the Satir Change Model (explained very well by Steven Smith).
In this simplified and slightly adapted representation, you can see that with a large change there is a period of net-negative productivity. Once the improvement starts to take hold, performance increases take productivity back into the black.
On rare occasions when an organisation’s software reaches critical mass (it’s more expensive to change than to replace) big-bang changes might be necessary. We’ve worked with a client that had exactly that problem. They took the brave step of ceasing delivery while they redefined how they did things and coached their teams in how to do it. This worked out positively for them. After about 6 months of intensive coaching and 3 months of implementation they delivered a revenue generating system to replace something that had been previously worked on for 18 months and had remained incomplete.
Most organisations would find it difficult to take that step and need to continue to deliver whilst transitioning from how they work today to how they want to work in the future. It is for this reason that we find ourselves employing small incremental changes, eliminating the things that add friction to their process – one problem at a time. Doing this with small experiments helps the organisation limit the risk and achieve continuous delivery and continuous improvement.
A way of understanding how this works is with the same Satir Change Model. If we take the curve shown above illustrating big-bang change, shrink it so that each change represents a much smaller alteration to working practices and then repeat, what we end up with is a much healthier looking series of changes.
Yes, each change can slow productivity temporarily but the impact is dramatically reduced and quickly offset by the improvements gained.
The area under the graph is productivity. If the changes are small enough there is never any period of net-negative output.
Another reason this works well is that it reduces the amount of cultural resistance that you have to deal with. Instead of a lot of resistance from many people for complex reasons, you tend to have only a few people resisting the change. Because the change is driven by a need to solve a recognised problem you have more people in favour of the change. Because change is frequent, people get used to change. In fact, they become experts at it and no longer resist the mere idea of change.
Commercially, it also gives you much more flexibility and allows you to adapt your vision continuously as you learn more.
Julian Davies, a developer at one of our clients, likened this to sailing. To travel from point a to point b in sailing you do so in a series of direction changes, called tacking. This is necessary when point b is against the wind.
You could, theoretically, do this in two long legs with one direction change. However, this leaves you vulnerable to changes in wind-direction potentially taking you significantly, perhaps even catastrophically, off course. Tacking is generally done with a series of small diagonal legs where each leg allows you to adapt to the changing wind. These frequent opportunities to read the context, i.e. the wind and currents, means that we will only ever be slightly off course with plenty of opportunity to recover.
Julian likened it to agile development in general but I think it applies equally to what I’m talking about here today.
With big-bang changes, what happens when we’re in the deepest trough of the curve and an opportunity arises? It is much more difficult to change course. With small changes we can put the latest experiment on hold to capitalise on that opportunity. When the wind changes on our projects, say when someone leaves or half the team is ill with a winter flu bug, we can quickly respond to those changes.
Acknowledgements: Thanks to Andy Palmer for reviewing this article and providing the snappy title.
Being a youDevise Developer – Week 1
Posted by AntonyMarcano in Uncategorized on July 18, 2010
In my previous post, I gave the background to me spending the next month or two as a developer on a youDevise product.
I’ve just completed my first ‘official’ week working with them. It was one of, if not, the smoothest of inductions I’ve ever experienced. I arrived and was shown a desk to work at. There was a welcome letter in front of a dual screen developer machine with Ubuntu installed. The letter told me everything I needed to get logged in, access e-mail and wiki links telling me where to find the rest of the information I needed to configure the machine. For the project I was about to work on.
Their CEO sent out an introduction e-mail telling everyone about me and others who started that day on the development team and in other non-technical departments. I also experienced a warm welcome from the team and was assigned a youDevise mentor to help me settle in.
My first few days involved several presentations – mostly demonstrative – introducing me to youDevise products and their business model. Yet I still got to work on code almost immediately.
I was very lucky to get to pair with their summer intern, Marius Cobzarenco, on a part of an all-new reporting capability for one of their products. I am so impressed with Marius. He left Cambridge University only three weeks ago and I have to say he is one of the most competent graduates that I’ve ever met! He has a level of technical competence that rivals many much more experienced developers and he has a passion and aptitude for learning that is rare. He became competent in Behaviour Driven Development after working with me for only an hour or two and fell in love with the approach. I was so impressed with him that I decided to sponsor his attendance at a TDD workshop this weekend with Jason Gorman.
Marius is a reflection of the high standards youDevise sets for itself. Whenever I’m there, I never feel like the smartest person in the room.
Speaking of smart people, other youDevisers I’ve also had the opportunity to work with include Joe Schmetzer and Stephen Siard.
Joe is a great guy – extraordinarily capable yet incredibly humble. Joe really knows his stuff! I’m looking forward to sharing with him, but mostly, learning from him. Stephen – who I have secretly, in my mind, nicknamed ‘the professor’ simply because his intellect is especially humbling for me – is another who I have been very lucky to work with. He has a way with algorithms that is tantamount to wizardry – but he is far too scientific to be called “the wizard”
These guys stand alongside other similarly impressive and diverse individuals that I’ll mention in future posts – each with their unique talents.
Next week, we start a new iteration. I’ll be seeing what it’s like working with some of their legacy code. Based on what I’ve seen so far, at least I know they recognise where they have legacy and that they are passionate about writing tests and cleaning the code up as they go.
About
Antony Marcano is a consultant in software craftsmanship, effective software processes, software quality and software testing. He has over fifteen years experience with... (read more)
@AntonyMarcano on Twitter- AntonyMarcano: RT @jmrtn: A note about how the @RiverGlide approach to bootstrapping differs from @flowapp: http://t.co/Ap7FkwkC May 15, 2012
- AntonyMarcano: The Floppy Disk means Save, and 14 other old people Icons that don't make sense anymore - Scott Hanselman http://t.co/mtuzFM0r May 14, 2012
- AntonyMarcano: Over the moon! At my sons 3rd kart race meet ever, in his first season of kart racing ever. He wins, beating others who've raced for years! May 10, 2012
- AntonyMarcano: @vsbmeza no, that's the only place. I'm sure @skillsmatter would appreciate specific feedback on their video settings :-) May 10, 2012
