Sunday, 5 February 2012

Another Charity Day: Maven Training In Manchester

Manchester in Winter, 2012

In January, I took the train to , to visit my friends at .

Manchester in Winter, 2012

HedTek loves but regularly works with and .
So, this — the second of my — would be a Maven master class.

Manchester in Winter, 2012

The session was hands on: after a short discussion around slides focusing on concepts and philosophy, we dived into some real code.

Manchester In Winter 2012

For the morning, I brought along a mystery code base.

Maven's declarative nature means that it's possible to learn a lot about a novel code base from its project build. We started by applying comprehension tips and techniques.

Manchester in Winter, 2012
Manchester in Winter 2012

We completed the morning by moving on to wiring a new into the project. are surprisingly easy to create, and illustrate well how Maven works behind the scenes.

Manchester in Winter, 2012

In the afternoon, we used Maven to create a new project from scratch: picking on . We finished by reviewing some of the builds HedTek already deals with.


Monday, 16 January 2012

An Extreme Hour At Agile Yorkshire

The qualities that the audience brings — enthusiasm, energy and engagement; experience, knowledge and ideas — are the keys to a successful participatory session. So, thanks to all the Yorkshire Agilists who braved the January gloom for our . And a special shout from me to Grant Crofton, who paired-up with me as co-host.

An Extreme Hour is a process miniature illustrating facets of XP. Famously XP leavens a tiny process with practices and philosophy, tools and techniques. XP teams often add optional extras into the mix, for example iterations, which occasionally obscure XP's essential simplicity.

One hour flows by fast: it makes sense to select themes and arrange the focus on them. This time, we stripped down the process to essentials and set out to challenge and through in the between and developers. Our rules-for-today required that each story be written on one card using the classic "As a, I want" template.

Team building happened first and fast: focusing relations within, and limiting ties between, teams. Next, customers were separated and grouped, presented privately with an open, undirected product challenge, then left to brainstorm. This set up customers as domain experts — limiting independent developer knowledge.

The twist thrown into the mix this time was . Teams were challenged to create dynamic interfaces from paper, card and stickies using scissors and pens. This went really well — though testing wasn't feasible, was: with the driver operating the pens and scissors, and the navigator owning the story card.

I left happy.

Materials are available to remix and reuse under the CC-by-3.0.

Monday, 9 January 2012

Some Extreme Programming


Software development fails to deliver, and fails to deliver value. This failure has huge economic and human impact. We need to find a new way to develop software.

Kent Beck, Extreme Programming Explained

Extreme Programming (XP) is a , , influential not only as a highly successful process (for smaller projects) but for the innovative practices (tools and techniques) described and the philosophy espoused.

XP values

For small projects, Agile, extreme programming and high-level programming languages are key practices because coding is the dominant activity for small applications.

Capers Jones, Software Engineering Best Practices

XP believes in

  • rapid feedback,
  • assuming simplicity,
  • incremental change,
  • embracing change and
  • quality work.

The exact limits of XP aren't clear yet. But there are some absolute showstoppers that prevent XP from working — big teams, distrustful customers, technology that doesn't support graceful change.

Kent Beck, Extreme Programming Explained

XP practices

We can drive ourselves crazy with expectation. But by preparing for every eventuality we can think of, we leave ourselves vulnerable to the eventualities we can't imagine.

Kent Beck, Extreme Programming Explained

XP separates traditional project management into

XP is a lightweight, efficient, low risk, flexible, predictable, scientific, and fun way to develop software.

Kent Beck, Extreme Programming Explained



Sunday, 1 January 2012

About Business Value And Issue Trackers

Pull scheduling allows developers to grab work from a . This way of team working is efficient — flowing around impediments — and effective — developers understand software — but is not necessarily well aligned with the business.

Maintaining A Backlog

I hear many people complain that it is hard to define business value. So they won't do it. Or they won't try any harder to do it.

Joseph H. Little, Defining Business Value

Software features vary in value (to the business). To align the flow (of features) to maximum business value, empower a with decisiveness to prioritize the backlog. Healthy software has business value, so factor in gradual repayment of . Over time feature valuations drift, either in response to an evolving business environment or as domain knowledge is won. So, review valuations regularly.

Tracking The Backlog

An information radiator displays information in a place where passersby can see it. With information radiators, the passersby do not need to ask questions; the information simply hits them as they pass.

Alistair Cockburn, Agile Software Development

For co-located teams, the physicality of a board is great, acting as an . Where distribution favours a software solution, use a big screen to radiate backlog and activity feeds to those co-located.

A good issue tracker is a flexible tool, and convenient for backlog tracking. When used so, invest in careful configuring: though similar in structure, an Agile backlog is not a list of defects, differing in several subtle — but significant — semantics.

As the team learns to create higher quality software, the number of defects should fall over time. As the team delivers business value, demand — and the backlog — should increase. Successful teams should expect these queues to move in opposite directions over time: defects shrinking but the backlog growing.

Issue Priority Is Not Business Value

Most issues trackers include a priority quality. For example, priority is selected from BLOCKER, major, minor, trivial and so on. These traditional names carry with them baggage from conventional bug and release management.

This issue priority may differ radically from business value. Behaviour considered unacceptable when wearing a test- and release-hat might reasonably be given a high issue priority, but only the view under a business hat shows the business value delivered by work on this issue.

Avoid conflating these concepts: add a new business value field. Whimsical names (for example gold >> silver >> iron >> paper >> blue skies) are memorable, and help avoid misunderstandings and misuse.

An Example

5 minutes might sound like a long time to wait for a screen to load. From the testing perspective, this might be a seen as a major issue.

However, this does not necessary mean that improved start-up time would bring major business benefit. A business might expect an employee to open the screen in the morning, and then go to make their coffee. The screen would remain open all day, closing again only at night. For this business, value lies in responsiveness and stability but not start-up time. Lengthy start-up would then be a major issue with paper business value.

In this case, reasonable valuations reached wearing tester and business hats would result in seemingly opposing assessments — until understanding that each measures a different quality. Fitting both qualities into a single field encourages wasteful conflict where there should be harmony.

Search This Blog