Pair programming: supporting agile practice

In my blog post a few weeks ago, I said that future posts would include some of the supporting practices (outwith the Scrum framework) that we can use from our agile toolbox.

When I first discovered agile and then introduced it to my team in 2008, pair programming was one of the first practices we adopted.

What is pair programming?

As the name suggests, pair programming involves two developers sitting side by side working together on the same code. Two developers means two brains working on the same problem. One developer ‘drives’ while the other ‘navigates’.

As Shore and Warden say in The Art of Agile Development (O’Reilly, 2008), “together, the driver and navigator create higher-quality work more quickly than either could produce on their own.”

Continue reading Pair programming: supporting agile practice

Agile is a toolbox

While it’s true to say we use the Scrum framework here at Vision, that’s not the whole picture. As Bertrand Meyer says in Agile! The Good, The Hype and the Ugly (Springer, 2014), “every agile team in the field makes up its own cocktail of agile practices, rejecting the ones that do not fit” (p.vii).

In terms of project lifecycle and team management practices, we are fully embracing Scrum. But Scrum has little or no opinion about engineering and delivery practices, which we complement largely with XP methodologies. The Scrum model assumes the development team will work with a product backlog but has no guidance on how that will be created—tools from AgilePM, DSDM or even PRINCE2 might be considered to supplement Scrum. (I’ve not been with Vision for long enough to fully understand how this is done here but that will come.)

Since I was introduced to it, I’ve always considered myself a proponent of agility rather than being partisan to any particular flavour or methodology: XP, Lean, Scrum, DSDM, Crystal, etc.

My agile journey

I was first introduced to agile through XP (extreme programming) having picked up a book at the 2008 Scotland on Rails conference in Edinburgh. (Memorably, that was the same day my then-wife learned we were expecting twins!) The keynote speaker spoke eloquently and persuasively about how agile approaches to software development had brought huge benefits to his team. I was hooked. I raced home, read the book from cover to cover and began to implement the ideas in my own team.

Then the university I was working for embraced Lean and I was introduced to its five principles, eight wastes, kaizen, kanban and a host of other useful concepts. I saw first-hand how empowering teams to own and change their processes reduced waste and improved productivity, effectiveness and team morale.

Latterly, it was decided that our team should embrace DSDM Atern. From a project management perspective, DSDM/AgilePM is the most complete. I have a terrific fondness for both its structure and flexibility.

Agile toolbox

Beneath the umbrella term ‘agile’ we have a toolbox of practices. Some have been codified into highly defined systems like AgilePM, DSDM and Scrum, others like XP and Lean feel more like loosely-related methodologies grouped into adaptable frameworks.

Within each there is the freedom to mine other disciplines for best practices: business analysis techniques, MSP, P3O, traditional project management tools, etc.

Just as you wouldn’t chastise a plumber for using a joiner’s hammer, it makes no sense to prevent an agile team from using a technique from another discipline if it does the job.

None of the frameworks cover everything. It makes perfect sense to supplement them with tools from elsewhere. DSDM makes that explicit: “for most organisations, DSDM is all that is needed,” the handbook proclaims, “although some gain value from integrating DSDM with project management methods such as PRINCE2 and PMI, or detailed development techniques, such as extreme programming (XP).”

This is one of the most helpful diagrams I’ve found that demonstrates the relationship between agile methodologies and how they complement one another:

Diagram showing agile method coverage

Diagram credit: Agile Project Management in Easy Steps by John Carroll (2012)

Over the next few weeks, I expect my blog posts to focus on aspects of both Scrum and XP in particular, exploring in more depth some of the tools we have access to in our agile toolbox.


Originally published on my work internal blog.

Steadily delivering quality

This week it was revealed that car hire company Hertz has sued Accenture for US$32 million for failing to deliver either a functional website or mobile app during a 16-month digital transformation project.

While there is a lot that could (and will) be said about this. It’s quite remarkable that even now digital and software development projects are still being carried out using traditional ‘waterfall’ project management approaches with all the design and planning done up-front rather than using an agile, just-in-time approach.

Fixed or variable?

In every project there are four key elements:

  • Features (requirements)
  • Time
  • Resources (cost)
  • Quality

Whether these elements are regarded as fixed or variable is what distinguishes one project management methodology from another.

Traditional

In so-called ‘traditional’ or ‘waterfall’ projects features are fixed.

Triangle diagram showing fixed features

Requirements are gathered, plans are drawn up and the project does not finish until the last feature has been delivered.

If the project goes off-track, more money and resources are thrown at the project and the deadline slips further and further away.

As projects get later, often quality also suffers, as this cartoon demonstrates:

Drawing of a horse showing one end in high quality and the other as though drawn in a hurry by a child

This is what happened to the Hertz/Accenture project. Started in August 2016, a new website and mobile app were meant to be launched in December 2017. The project was abandoned in May 2018. Nothing was usable; nothing was launched.

Agile

In contrast, an agile approach to project management fixes time, resources (cost) and quality. It is the features that are variable.

Agile diagram showing variable features

A minimum viable product (MVP) will be delivered quickly, tested with real users and iterated on to bring more features to market incrementally.

Time is fixed using fixed-length sprints. Resources are fixed using established teams who stay together for months. Quality is fixed by establishing good testing disciplines, agreeing on common practices, and establishing a solid definition of done.

There is an old military adage that even the best plan goes awry after the first contact with the enemy. So it is with projects: there ought to be an expectation that features will evolve and change as you learn more about the product during development, user testing and once those new features have been delivered to end users.

As our own agile journey continues, we would benefit from bearing in mind the eight principles of the AgilePM framework:

  1. Focus on business need
  2. Deliver on time
  3. Collaborate
  4. Never compromise quality
  5. Build incrementally from firm foundations
  6. Develop iteratively
  7. Communicate continuously and clearly
  8. Demonstrate control

What next?

The Vision Tasks team has recently delivered v1.4 to SIT and ELS. This is a major milestone for the project and a huge confidence boost for the team. (Well done, Tasks team!) This is a fabulous foundation on which to build, incrementally.

Over the next few months, I’d like to see one of the focuses for the team to be working towards being able to deliver releasable features at the end of each sprint (even if they don’t immediately get put into production).

There is some work to be done first to get us to that point but that’s the goal: steadily delivering quality.


Originally published on my work internal blog.

Shu ha ri—three stages towards agile maturity

“Scrum has its roots in Japanese thought and practice”, Jeff Sutherland, the co-creator of Scrum, tells us in his book Scrum: the art of doing twice the work in half the time (Random House, 2014), p.38.

One of the ideas that Scrum has drawn on is the Japanese martial art concept of shu ha ri (or shuhari) which outlines three stages of learning towards mastery.

Over the last few years, I have found this a really useful model to bear in mind when working with teams as they embrace and grow towards agility.

Continue reading Shu ha ri—three stages towards agile maturity

The primary purpose of a development team is…

Before you read further, take a moment and answer the following question for yourself: what is the primary purpose of a development team?

Don’t worry, I’ll wait…

Okay, what was your answer? Is it to create working software? (Well, yes.) Is it to complete everything on the sprint backlog (Hmmm… kinda.) Is it Henry, the mild-mannered janitor? (Could b… No!)

Above all, the primary job of an agile development team is to build quality into the product.

That focus on quality is important because it informs us and shapes us in everything we do as a team, from planning through to delivery.

When I introduced agile to one team with whom I worked, it took me a long time to help them get beyond their misconception that agile meant quickly hack things together and shove it out the door. Release early and release often—yes; dirty hacks—no! Done well, agile should be more disciplined than other traditional methodologies and focus on quality.

The first principle of the agile manifesto reads, “our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” The agile manifesto values “working software over comprehensive documentation”. Valuable software is working; working software relies on quality.

The fourth principle of DSDM/AgilePM is “never compromise quality”.

What small step could you take now to improve the quality of your work?