Having One Big Target

I've been in sprints where there are lots of little things to be done, as well as sprints where there's just one thing that has to happen. My experience is having one big target is much better than lots of little targets.

The reason, I think, is that one big target lacks the context switching that going from target to target. It allows all people to focus on one problem and gradually work to that.

A big target is not an ill-defined target. The same rules apply as apply in all scrum - it should be coherent enough that it can be worked on. Anything less and a big target has a chance of failure.

A big target should still be broken down to small targets. But the package of targets together provides a context to the work. A package of disparate targets has their own context, with the developers needing to adopt that mindset to begin work. Smaller tasks for a greater whole do not have that problem.

Burnout

I describe the agile process as sustainable development. The idea is that development should be able to be continued indefinitely. This is a big change from the usual development approach of big pushes and lulls.

It's a old habit, and old habits die hard. We know we can push harder at times to get over a line. And as individuals, we suffer for doing that. We run the risk of burnout.

We recently jumped deep into a problem that was complex and time sensitive. It required a big effort to get it over the line. At the end of it we made it, but it came at a cost. The following sprint has been deflated, with tired developers, a lack of enthusiasm and focus, and inevitably more mistakes.

The scrum process is set up to avoid this. That we agree to take in what we can handle, and base what we take in future sprints from past performance. We learn what we can achieve from what we have achieved. So those moments we go above and beyond throws that out.

It's an achievement to deliver 4 weeks of work in 2. But if the cost is tired unmotivated developers, there had better have been a very good reason for doing so.

The Utility of a WIP Limit

One of the advantages of using a Kanban board for tracking scrum is that it identify bottlenecks in the process. The Kanban board has an interesting way to stop this - putting a limit on the amount of tickets that can be in a column at any given time.

Putting a WIP limit prevents too much work piling up. The team ought to be doing what it can to keep the flow going smoothly. It helps eliminate bottlenecks by preventing issues from piling up.

It also serves as a reminder to the team of collective commitment. That we are all in it together, and blockers affect everyone. Tickets stuck in analysis, development, or testing all have the same outcome - that feature doesn't get out. And given business value determines ranking order, the tickets in WIP are more valuable than tickets that are on the backlog.

Whatever Tools for the Job

When I was a child, I was amazed at just how many tools were in my grandfather's workshop. I didn't even know what most of the tools did, let one why there would be so many.

My toolkit is virtual rather than physical. Like the craftsman, knowing which tool is right for the job and how to use it effectively is vital.

One recent task I had to do was to query our database and get some intelligible information from it. To do this, I used a combination of SQL Developer and Excel, taking advantage of features in both to perform the task. A DBA may have been able to solve it purely in SQL (just as I'd easily be able to solve it with a targeted Java function), but the combination of tools worked for me. I used SQL Developer and Excel for what each was good at doing.

Knowing multiple ways to solve a problem gives flexibility when issues arise. Sometimes a spreadsheet or even Notepad are the right tools for the job in the right circumstances.

The Nature of Agile Testing

"The focus of agile development is producing high-quality software in a time frame that maximizes its value to the business. This is the job of the whole team, not just testers or designated quality assurance professionals. Everyone on an agile team gets “test-infected.” Tests, from the unit level on up, drive the coding, help the team learn how the application should work, and let us know when we’re “done” with a task or story. An agile team must possess all the skills needed to produce quality code that delivers the features required by the organization. While this might mean including specialists on the team, such as expert testers, it doesn’t limit particular tasks to particular team members. Any task might be completed by any team member, or a pair of team members. This means that the team takes responsibility for all kinds of testing tasks, such as automating tests and manual exploratory testing. It also means that the whole team thinks constantly about designing code for testability." [Crispin, L. and Gregory, J., Agile Testing, p.15]

Our JIRA Scrum Board Columns

• TODO
  It holds the list of all unassigned tickets for the sprint. The expectation is that for the tickets to get into this column, they've had enough refinement done before the sprint that they can be worked on with minimal further clarification. The tickets are ordered vertically by business rank.


• Development
  For when the ticket is being actively developed. The ticket is assigned to the person doing the work, and will remain in this column until the work is complete. If the work being done is Java, then branches are made off the ticket. Tickets with branches that have a pending pull request get coloured orange, while tickets with merged pull requests are green.


• Testing
  When the development work is ready to test, tickets are moved into Test. It will be up to whoever in the testing team is available to assign themselves the work. If a severe defect is found, then a sub-task is created from the ticket. If the defect is not a problem for the functionality, then a new ticket is created and put on the backlog.


• Product Owner Review
  The product owner gets final say over whether a unit of work is done. This column is the for the final verification by the product owner that the ticket meets the business expectation.


• Done
  The product owner moves the cards to this column when they are satisfied the story is complete. When a sprint ends, any tickets not in this sprint will be moved either to the next available sprint, or into the backlog.

Dude's Law: Value = Why / How

The one of the consequences of agile development is the focus on a minimum viable product. The product owner sets the work by business value, so the user stories with the highest value are always worked on first.

The business need for a user story (or the amount of work done on a user story) does depend on the ability for the development team to deliver that story. A really complex piece of work might be the best thing from the business perspective, but is it more important than multiple smaller tickets? This is where Dude's Law comes in.

Dude's Law: Value = Why / How

If something takes a lot of effort, that's effort that could be expended on something else. So if a user story is going to take a lot of effort, it's value ought to be weighed up against what alternatives could be done instead.

The inverse holds for where the how is minimal. Changes that are trivial to implement can high value even if they are not priorities from a business perspective. But a user story that's difficult to implement and of low business importance holds very little value.

Applying Dude's Law gives a way to quantify what tasks ought to be achieved in a sprint. Like everything, the code should be written such that if the project were to be shut down tomorrow, as much business value as possible should have been added until that point.