Wednesday, 7 March 2018

For this It's Tech Up North blog, I don my author's hat and meditate upon matters mostly methodological.

Heading up the technical side of Tech Up North Ltd, I have many hats ― Agilist, Engineer, Technologist, Analyst, Co-Founder, Shareholder, Director and so on. In my Apache days, we considered hats a lot and ― like many ideas from those times ― this one stuck with me.

The hat as a perspective, as a viewpoint, a way of thinking. Separating concerns. Opinions but loosely held. A hat to be be put on and taken off again, enhancing rather than defining.

It's Tech Up North is a Tech Up North blog but has my personal voice, expressing my personal opinions. Here I wear my author's hat.

Monday, 16 January 2012

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 Extreme Hour. 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.

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 paper prototyping. 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, pair programming was: with the driver operating the pens and scissors, and the navigator owning the story card.

Sunday, 1 January 2012

Pull scheduling allows developers to grab work from a backlog. 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.”

Software features vary in value (to the business). To align the flow (of features) to maximum business value, empower a product owner with decisiveness to prioritize the backlog. Healthy software has business value, so factor in gradual repayment of technical debt. 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.”

For co-located teams, the physicality of a Kanban board is great, acting as an information radiator. 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, JIRApriority 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.

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 majorissue with paperbusiness 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.

The outermost layer exercises assembled applications. Fidelity to customer configuration is essential, and often means filling heavyweight stores with data. Set up and tear down costs are almost always high for enterprise applications.

Reasonable coverage using slow running integration and application layer tests costs. Avoid disrupting development flow: separate integration and application suites, and run them outside this flow. Consider triggering continuous integration after each commit. To avoid maintenance issues, integration test selectively, invest in good fixtures and use the language of the customer.