TDD haiku
I didn't make the haiku session at XPDAY5, but I thought I'd try it on test-driven development:
Red. Green. Refactor.
Write test to fail. Code to pass.
Tidy up after.
The rhyme wasn't intentional but ever since I was in school any attempt at poetry always produced limericks.
Tags:
agile,
tdd,
xpday5
Links to this post
This session was presented by
Steve Freeman and
Mike Hill. Using
FIT is a great way to produce automated acceptance tests, but the underlying message of the session was: The act of designing and writing the
FIT documents can be an effective means of communicating with the customer. This can help us understand the details of a user story and identify suitable acceptance criteria, which tell us when we're done. The role playing between Steve [the techie] and Mike [the busy customer] was a 'giggle' and demonstrated how well this communication mechanism can work.
Two exercises were conducted. The audience was split into 9 groups and each handed a description of business requirements. Each group was tasked with identifying, and then writing some
FIT test documents on paper. A member of each group would then show the test documents to another group to see if they could understand what the original requirement was. After a period of time, the person presenting the test document would explain the requirement to the group. Then the fun part. The presenter had to turn their back to the group while they criticised the test document. Steve enthusiastically encouraged people not to hold back. This situation emulated the conversation that developers often have amongst themselves when the customer has gone away.
Here's a test document that we literally stuck together, uh-hem, i mean produced iteratively:
fit
Originally uploaded by sjb140470.I came out of this session enthused to use
FIT tests in the same way that Steve and Mike had been using them. On a current project, we've been using the
Fit Library but to produce acceptance tests used at the iteration review meeting. Our difficulty in using the
Fit Library effectively has been the investment time required to produce the tests. I asked Steve what percentage of their iteration was dedicated to producing
FIT tests. He replied "One third". I guess we need more practice and the room to do it.
It would be useful to get a copy of the presentation slides.
See also:
Read how James Shore uses FIT. His post concludes a series of articles he has written on FIT.
Resources:
FitLibraryFIT ConsolidationFitNesseSeleniumRecommended reading:
Tags:
agile,
user stories,
fitnesse,
xpday5
Links to this post
This session was presented by
Pascal Van Cauwenberge and
Rob Westgeest and introduced the
Theory of Constraints.
The theoryAcknowledging cause and effect, the premise of the theory is that "the throughput of any system is determined by one constraint or bottleneck", and that the throughput can be optimised by following 5 focusing steps:
1. Find the constraint2. Exploit the constraintThe system's output equals the output of the constraint, therefore try to maximise the output of the constraint by removing non-productive work from the constraint, or buffering the input to the constraint and have the constraint pull work in. The constraint exists and is therefore already paid for, so always try exploiting first because it doesn't have additional costs.
3. Subordinate to the constraint
Resources which are not bottlenecks will have spare capacity so try subordinating them to the constraint to help boost its output by taking over some of the constraint's work, or improving the constraint's input, or carefully treating the contraint's output to limit any waste. The other resources with capacity are already paid for, so when no further exploits are available focus on subordination because it doesn't have additional costs.
4. Elevate the constraintTime to spend some money on improving the constraint's output by investing in training, coaching, better tools or perhaps more people. Only do this when exploitations and subordinations are exhausted.
5. RepeatRemoving one constraint simply promotes the next constraint, so around we go again.
The sessionThe first half of the session saw the group simulate a development process constructing paper hats and boats. Unbeknown to the group the distribution of tasks placed the constraint at the developers. Following a 5-minute production run 24 sheets of paper entered the process but only 3 boat-hat pairs were delivered to the customer. 5 boat-hat pairs were rejected by QA or the customer, and the rest lay incomplete somewhere on the production line. The observers identified the constraint noting that the developers were overloaded and decided that the construction of hats (which were easier to make) should be subordinated up-stream to the designers.
A second 5-minute production run delivered 4 boat-hat pairs to the customer with only 1 boat rejected by the customer. I can't remember how many incomplete boat-hat pairs were in the system but it was better than the first run. Following the simulation, 2 additional focusing steps were revealed:
0. Find the goalUnderstand the goal of the system and make it explicit at the start.
6. Change the systemEventually, options for improving the throughput of a system will run out. At this point, if the system is not achieving an acceptable throughput it's time to ask whether the whole system is wrong and should to be replaced with a different system.
The second half of the session saw us split into smaller groups. One person became a customer and described a real-life problem they had experienced to the others, now
Theory of Constraints consultants charged with finding and resolving the constraint. Our customer,
Willem Van Den Ende, described a troubled CMS project where the customer was dissatisfied with the usability of the functionality delivered so far. The team comprised permanent developers working flat out on new business value, a part-time graphics designer writing brittle and smelly template code, and a part-time usability consultant who seemed to pop-in occasionally to make cursory comments about the usability of the UI. The graphics designer and usability consultant were seldom in the office at the same time, and neither attended the iteration planning meetings.
We identified the goal 'to deliver usable functionality to the customer' and decided that both the graphics designer and the usability consultant were constraints. Following some discussion another focusing step was revealed:
1.5. Choose the constraintThe theory claims that a system is unlikely to have more than 3 constraints. However, when faced with more than 1 identified constraint, you need to select the one to deal with first.
So we decided to deal with the usability consultant constraint. Since the usability consultant's time was already paid for, we set up a strategy to tackle usability proactively rather than reactively.
An exploitation involved the usabilty consultant attending the planning meetings, pairing with the graphics designer up front to create UI mockups, and then pairing with developers to make them aware of usability factors as they code.
A subordination cleared the developers of implementing new functionality and instead refocused them on resolving current usability issues.
An elevation involved paying for the usability consultant to conduct formal usability tests with real users in an observation laboratory. The developers could attend these sessions as observers to witness, first-hand, the problems and frustrations experienced by the customers. The usability consultant could then follow-up with a usability training course for the team.
Tags:
agile,
theory of constraints,
xpday5
Links to this post
This session was presented by
Steve Freeman and
Nat Pryce. It's purpose was to allow all project stakeholders to explore what needs to be done before agile development can commence. The session synopsis posed a number of thought provoking questions:
- What must be considered before the first development iteration?
- What place does analysis have in an agile process?
- How much design do we need to do up front?
- How do we set up the tools and working environment to support the project?
- How do we ensure that lines of power and responsibility are aligned for success?
- How do we build a cooperative relationship with users based upon continual learning?
The session kicked off with a
cafe-style brainstorming session where groups of people sitting around tables shared their experiences, and identified things that were in place at the start of a project and things that were missing. These were written on colour coded index cards to reflect 'good' and 'bad'. The group then scattered the cards on the floor and, working collectively, started to group them logically.
Grouping the cards
Originally uploaded by sjb140470. The logical groups that emerged were:
- Build and test
- Infrastructure and workspace
- Managing expectations
- Project governance
- Roles and responsibilites
- team building
Each group of index cards was then collected by Nat and returned to a table.
Collecting the grouped cards
Originally uploaded by sjb140470. The people sitting at each table were responsible for distilling the information and creating a poster that presented a list of items, for the given topic, that should be in place before iteration zero. People then circulated around the tables to discuss each poster.
Paul Beckford tells Tim Lister how big his 'Dead Fish' was
Originally uploaded by sjb140470. Here are the posters:
Tags:
agile,
iterative development,
iteration zero,
xpday5
Links to this post
The sessionThis session was presented by
Rachel Davies and
Romilly Cocking. The newsgroup can be found at
Agile Thinking Tools at Yahoo. It introduced mind maps as a thinking tool and communication medium. Following an introduction to mind mapping techniques, Rachel made a good suggestion which was to first brainstorm key words, write them on index cards and arrange the index cards to get a feel for the best layout. Then start mapping.
The first exercise required each person to create a mind map on a topic of their choosing. I chose to map snowboarding:
snowboarding
Originally uploaded by sjb140470.This is a first-pass mind map which should be re-organised. Specifically, I would move the 'Apres' branch to be a sub-branch of the 'Holiday' branch rather than have it come directly from the central image. I would also re-draw the 'Freeriding' image so that it looks more like a tree-lined, snowy mountain pass and less like a desert oasis. I had many more associations I wanted to make but the exercise was timeboxed.
The second exercise required people to map a different topic as a team. De Bono's
Six Thinking Hats theory was employed, where colours are used to convey specific combination of qualities and characteristics:
White - Neutral and objective
Red - Powerful emotions
Black - Gloomy and negative
Yellow - Sunny and positive
Green - Fertile and creative
Blue - Logical and in control
One technique is to group branches with the same colour together so that only six branches, one for each colour, emerge from the map's central image. Another technique branches as normal but applies a colour to each branch according to the defining qualities of the associated key word. We employed the second technique to map organising Christmas because we wanted to retain context in each branch and sub-branch.
xmas
Originally uploaded by sjb140470.The session concluded by using mind mapping to conduct a retrospective for the session. The resultant mind map employed the first technique for employing colour described above.
agilethinkingtoolsretrospective
Originally uploaded by sjb140470. How I use mind mapsMind maps help to generate ideas, promote learning and facilitate communication. When I use mind maps to clarify my own thinking on a particular subject, I often find that the act of mapping is more valuable than the resulting map. This is similar to my use of UML, where I find more value in the modeling than in the model produced.
Mind mapping as a team can be a productive exercise that promotes interaction and teamwork. Recently we started
mind mapping scrum's sprint goal. This has helped the team retain a visual representation of our objectives in big-picture terms.
In my experience, using mind maps to communicate ideas, concepts or information between disparate groups can sometimes be tricky. Simple mind maps or mind maps that concentrate on a small or everyday topic like those created by Kent beck in XPv2 can be understood without explanation. A more complex mind map or a mind map that focuses on a specialised subject can require a domain of discourse to exist between the author and the audience for the information to be transferable without explanation. A UML model can communicate details of a design without the author's presence but UML employs a standard nomenclature and notation that is understood by people conversant with UML. A mind map, however, employs keywords and imagery representing free associations made in the author's mind. An audience may not easily connect with the imagery and associations for a number of reasons, e.g. unidentifiable images, unintentionally obscure associations, tortuous associations, etc.
Mind maps can communicate information effectively when the author conducts a walk-through, e.g. when using a mind map to drive a presentation. Recently I used a simple mind map to
introduce scrum to a group of project managers.
Tags:
agile,
mindmap,
xpday5
Links to this post
I think the most memorable phrases that come out of
XPDAY05 will be those used by Tim Lister in his keynote speech.
First,
Dead Fish of Failure describes the festering 'smell' those projects have which are setup to fail from the beginning.
Second, imagine your project is a cruise liner or cargo freighter. When it set sail it contained lots of cargo or user stories. As the cruise progresses the act of descoping user stories from a sprint or iteration is like throwing
cargo overboard. I wonder how many projects have reached their destination with empty holds?
Tags:
agile,
xpday5
Links to this post
Encourage collaboration by using just a story name on the card
I read Brian Marick's blog post
Story card style and liked Rachel Davies' comment about limiting the text on a story card to a story name. We have been writing notes on the story cards and they've become messy. There's always room to improve communication and it sounds like this will be a simple but effective way to "encourage conversation to continue during the iteration". So I'm going to try it.
Links to this post
Repaying technical debt
Circumstances often place developers in a situation where they face the decision: Do I write a cheap and nasty solution in order to move forward now? Or do I take more time to solve the problem properly and risk delivering less business value by the end of the sprint? In this situation, an agile developer should
do the right thing.
Technical debt was a metaphor first coined by Ward Cunningham. Electing to implement a quick solution with dirty code can sometimes be the right thing to do. What's important is to realise that it incurs technical debt which, like financial debt, requires repayment by returning at a later date to refactor the dirty code. Recognising the implications of technical debt helps us to understand its effects and enables us to control our level of debt to ensure that it remains affordable.
It's a responsible practice to repay technical debt frequently, and we are obligated to manage the repayment as we would with financial debt. However, the repayment plan can be flexible. Extending the financial debt metaphor, I like to use a special case - flexible mortgages - to describe the various methods I employ for repaying technical debt over a project's lifetime. Flexible mortgages generally allow you to take the following actions:
Regular monthly repayments: In agreement with the product owner, a fixed part of each sprint can be reserved for repaying technical debt. In the interests of
open and honest communication and
keeping things visible I maintain an explicit technical debt backlog as part of the product backlog. During sprint planning, the scrum team negotiates the inclusion of technical debt items with the product owner. Consequently, a typical sprint becomes a concoction comprising a selection of high business-value user stories, a selection of the more risky technical debt items, and some slack containing a handful of low business-value user stories. I dedicate approximately 20% of the sprint's velocity to slack, leaving 80% to be divided between delivering business value and repaying technical debt.
Lump-sum repayments: If it's acceptable to the product owner, an entire sprint can be dedicated to repaying the technical debt incurred by previous sprints. This approach may be considered part of a recurring stabilisation strategy (if you consider stabilisation to be more than preparing a product for release), which occurs periodically throughout the project.
Borrow money back: Sometimes, in order to repay some technical debt in one place you inadvertently (or advertently) create a smaller piece of technical debt in another place. Perhaps, there's not enough time left in the sprint to completely repay a piece of technical debt, e.g. a refactoring was more complex than anticipated and consequently a tactical solution had to be left in place that will require more refactoring later on.
Take payment holidays: Some dirty solutions may not require immediate refactoring if, given certain circumstances, they are considered to be of acceptable risk. Therefore, some sprints may not repay technical debt and instead focus entirely on delivering business value. However, it should be agreed with the product owner that deferred technical debt must be repaid sooner rather than later.
Underpayments: If the technical debt is small or it has acceptable risk, the scrum team can spend less time in the sprint repaying technical debt and more time focusing on delivering business value.
Further reading:
Technical Debt by Martin Fowler
Don't Live with Broken Windows, A Conversation with Andy Hunt and Dave Thomas, Part I by Bill Venners
Climbing Out of Technical Debt by Johanna Rothman
What Testers Can Do About Technical Debt by Johanna Rothman
Tags:
agile,
technical debt
Links to this post
Scrum Mind Map
scrummindmap
Originally uploaded by sjb140470.Today, I created a simple mind map for Scrum (well, strictly speaking it's a visual map since I did not always use single words to describe the items on the map). Anyway, I plan to use this mindmap for a presentation I'm delivering called Scrum In A Nutshell, which provides an overview of Scrum.
I have updated the mind map following some feedback from Mike Cohn. Thanks Mike.
Tags:
agile,
scrum,
mindmap
Links to this post
How not to do it: Test-Driven Development, Microsoft-style
In their
Guidelines for Test-Driven Development, Microsoft says "If your software-development project uses test-driven development, you can benefit from features of Visual Studio 2005, and in particular, features of Visual Studio 2005 Team System. These features include the unit test type of Team Edition for Testers, and especially the ability to generate unit tests automatically; automatic refactoring capabilities that are introduced in Visual Studio 2005, and the Class Designer tool. The unit test support of Team Edition for Testers is particularly suited to TDD because these Team System testing tools can generate tests from a minimum of production code."
Read the guidelines and then erase them from your memory.
TDD is all about
RED GREEN REFACTOR - write some unit test code that fails, then write the simplest code to make the unit test pass, then refactor the code to remove code smells and check that all unit tests still pass.
With experience a developer can complete an iteration of the test-code-refactor cycle in minutes to give the impression of concurrent coding and testing, a bit like a CPU switching rapidly between processes to give the appearance of concurrent execution. Taking the metaphor a step further, as a preemptive scheduler triggers a context switch between processes, a green bar, indicating that all unit tests have passed, initiates a new iteration of the cycle. The conscious act of writing tests first to capture the desired behaviour of a class, coupled with
merciless refactoring, enables the design to evolve in
baby steps. This is defeated when you generate the unit tests from skeletal code; you're back to DUF.
If you do not adhere to the test-code-refactor cycle you lose inherent benefits of TDD. Unit tests that are run at the same stage of the cycle, in every iteration, and pass with a green bar give a developer the confidence to proceed and make changes. When a red bar occurs, a developer fixes the problem before proceeding, confirming the fix with a re-run of the unit tests. Locating the problem is easily accomplished because only a small number of lines of code are added per iteration of the cycle.
Here's some good reading material on TDD, JUnit and refactoring.
Test-Driven Development:Test Driven Development by Kent Beck
Test Driven Development: A Practical Guide by Dave Astels
Agile Java: Crafting Code with Test-Driven Development by Jeff Langr
JUnit:Test Infected: Programmers Love Writing TestsJUnit Cookbook by Kent Beck, Erich Gamma
JUnit in Action by Vincent Massol
JUnit Recipes: Practical Methods for Programmer Testing by J B. Rainsberger
Refactoring:Refactoring: Improving the Design of Existing Code by Martin Fowler
Refactoring Workbook by William C. Wake
Refactoring to Patterns by Joshua Kerievsky
To keep up with the latest news and developments in the field of TDD visit:
PLEASE NOTE: In a previous edition of this post I incorrectly attributed
Guidelines for Test-Driven Development to Scott Dockendorf.
Scott has rightly pointed out to me that he
is not the author of any part of this MSDN document, nor is he responsible for its content.
Tags:
agile,
tdd
Links to this post
The courage to be creative
Travelling home on the Tube last night, I grabbed one of the morning newspapers left on the seats. It was The Times Career supplement. Bored, I scanned the paper anyway and found an article titled "New Ideas Pay Dividends", which declared "employees freed to think imaginatively are more likely to produce better work". Intrigued, I read on.
"Creativity was once regarded as subversive and imagination was seen as a seed of insurrection. Companies wanted compliant workers, not ones who had ideas. Today, some companies still regard creativity with a touch of suspicion, even though
create means nothing more than to bring into existence." Dr Marilyn Freyer of the Creativity Centre says "creativity is about producing the best you can". Creativity is a motivator so how can it be maximised? "Try pushing the boundaries" she says, "People assume that they can't do things". Without the freedom to be creative, many of the less independent people "will not do their best and the organisation will not grow".
Creativity requires imagination, expertise, flexible and lateral thinking, and motivation. Scrum's self-organizing team gives individual members an empowered status with the freedom to be creative, the authority to decide the right thing to do and how to do it, and the facilities to learn and adapt to attain improvement. In return, each team member must have the courage to participate proactively in the scrum team, and to be openly expressive and creative. If they don't they will not be doing their best and the team will not advance. To convert creativity into productivity, each team member must also be diligent, persistent and committed. "Imagination without implementation is like a car without wheels".
Further reading on self-organizing teams:
1. Mishkin Berteig on
Agile Work Uses Lean Thinking - Team Self-Organization.
2. Ken Schwaber on
Self Organization [pdf]
3. Diana Larson on
Team Agility: Exploring Self-Organizing Software Development Teams [pdf]
4. Esther Derby on
Self OrganizationTags:
agile,
scrum
Links to this post
The Guardian has written about
Simple steps to making better software. The only thing to take from this article is that "there is no magic bullet to making software work".
Links to this post
10 things about scrum
1. Software projects are non-linear and too complex to predictably plan in detail, up front. Scrum uses the empirical techniques of frequent inspection and adaptation to steer the project towards its objectives.
2. Scrum is about applying common sense. Identify the right thing to do, the right way to do it, and then do it.
3. Scrum insists on total visibility. There's no hiding problems, issues, or obstacles. See them, understand them, deal with them.
4. Scrum is driven by results and not by effort. Progress is measured by the goals met and not by how many hours it took to meet them.
5. An inventory of work is maintained as a list prioritised by business value [product backlog].
6. The product owner represents the project stakeholders and is responsible for proactively managing and frequently prioritising the product backlog so that it steers the development effort.
7. A scrum team is self-organising and cross-functional. There is no command and control. The scrum team has the authority to do whatever is needed to meet its commitments. Everyone is equally responsible for determining the most suitable way to proceed.
8. A scrum team delivers business value every 30 days [sprint]. The product owner selects the items to be developed in the next sprint [sprint backlog] from the product backlog so that the highest business value is delivered first and return-on-investment is maximised.
9. A scrum team meets every day for no longer than 15 minutes, at the same time and in the same place [daily scrum meeting]. Each team member answers 3 questions:
- What have I done since yesterday?
- What am i going to do today?
- What obstacles are preventing me from doing my work?
10. The scrum master is a facilitator and has no authority. The scrum master's responsibilities include ensuring that everyone follows the scrum rules and practices, bringing the scrum team and product owner together so that the product owner directly drives development, and facilitating creativity and empowerment in the scrum team.
Here's a diagram of the scrum cycle created by Mike Cohn at
Mountain Goat Software.
scrum
Originally uploaded by sjb140470. Recommended reading:
Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle
Agile Project Management with SCRUM by Ken Schwaber
Tags:
agile,
scrum
Links to this post
Hustle and bustle
Hustle - verb to move energetically and in a particular direction. Bustle - noun excited activity and commotion I read
James Shore's blog-posts about
sense of urgency and
hustle, for a second time recently. He hits on an important point which is often not fully appreciated by teams new to agile methods. While it's essential that a team produces "high-quality, tested code that meets their own estimates", it's equally essential that the team "takes the customer's goals seriously" and hustles, demonstrating they care as much about delivering the iteration's scope as the customer.
Hustle is not only about keeping the customer happy by looking busy. Hustle creates bustle - a buzz or that air of excitement generated by the purposeful activity, which radiates positive energy that is absorbed and re-radiated by the team members. In return bustle helps to drive hustle by provoking further communication, improving focus, and potentially increasing productivity.
Ron Jeffries wonders whether hustle is sustainable in his post,
The engergy to hustle. Certainly, in a human environment, hustle and bustle cannot regenerate each other perpetually. The development team is the primary energy source for hustle and needs to recharge at regular intervals. As Ron Jeffries suggests, this can be accomplished by achieving success at the end of each iteration and by resting frequently as part of an
energized work strategy.
Tags:
agile,
extreme programming,
energised work
Links to this post
Conchango have a nice little site called scrum-master. It has video presentations where Ken Schwaber talks about Scrum, how it affects an organisation and the benefits it brings. Great fun!
See:
Hear Ken Schwaber talk about ScrumTags:
agile,
scrum
Links to this post
