Stand Up and Shut Up

As with many simple and now commonplace “Agile practices”, debates still rage on about the Daily Standup (Scrum) meeting, a meeting which has somehow become a ritualistic signal that a team is “Agile” but is often an equally conspicuous signal of the exact opposite.

I’ve been in many organisations where God forbid anyone asks whether we should get rid of the meeting, or even change it, despite the fact that no one is getting any value out of it every single goddamn day*.

*Except some managers. A daily status update meeting? Terrific! The Daily Standup is an opportunity to micro-manage people every single day without having to approach their desks!

I digress. The point is, people still question the value of the Daily Standup and, if it is indeed valuable, how we might make it more effective.

I share the view of the Scrum Guide on this – at least in what the spirit of an effective Daily Standup meeting is, if not necessarily the prescribed format.

An effective Daily Standup meeting, for me, is one in which the team inspects and adapts both product and process.

That is to say it is an alignment meeting. A daily planning meeting. An opportunity to change our path if there is a better one. We do not have to (and should not) wait for the Sprint Review (product) and Retrospective (process) for this. Continuous improvement is about daily inspection and adaptation.

Here are some of the more effective questions that can be used in a Daily Standup meeting:

  • How will we work together today to move toward our goal?
  • What should we focus on today?
  • What should we not do that we originally thought we would do?
  • How will we remove this impediment right now?
  • Given we are a little behind, how might we simplify this product increment?

It is about purposeful intent for the day. It is certainly not intended as a status meeting. If managers and others outside of the core team are not getting the information they require from conversations or the team wall then it will surely pay dividends to improve visibility and transparency in the way people interact while doing their work rather than have a daily status update meeting.

In fact, I would go as far as saying that the ritual of an unchanging Daily Standup meeting is usually a smell of poor collaboration in and between teams on the actual work to be done. Some companies mistake this meeting as a way of actually getting people to collaborate. It’s almost as if they think that the benefits of collaboration, as Agile promotes, can be gleaned simply by having this meeting.

standup-construction1Unfortunately it is not that simple. Standing (or sitting) people together does not make them collaborate.

Collaboration is an organic thing and only comes if the “way the work works” is designed to encourage it.

I sometimes see or hear the argument that, “because we’re Agile we should make the meeting fit with the way we currently work“, and that doing this will intrinsically make it more valuable. So, the argument continues, it’s OK if it becomes a status update meeting because that’s what the environment demands.

The issue with this approach is that the environment in which you currently operate is likely one of managers wanting status updates. One of traditional ways of doing things.

But in order to be effective with an Agile approach we have to do things differently. To think differently.

Agile does not mean “make compromises”. It is about mindful changes in the way we work to move toward improved effectiveness. If something feels a bit different and uncomfortable then it may well be a sign you are on the right track.

As coaches, we ought to let the team decide how they can get most value from a Daily Standup meeting. Then, rather than focusing all our attention on how to improve the meeting, we should instead be helping the managers create an environment in which actual collaboration (working together effectively toward common goals) is encouraged and starts to feel natural.

Where excellence, rather than dogma, can prevail.

P.S. Standing up is not mandatory! If the meeting is timeboxed to 15 minutes then it will be quick regardless of whether you’re sitting down, standing up or doing the cha-cha.

Revisiting the Three Amigos

Next week I am speaking at a SIGiST (Specialist Group in Software Testing) event in Melbourne. Having to prepare my presentation has encouraged (OK, forced) me over the past couple of weeks to re-immerse myself in the world of quality, testing and BDD (Behaviour Driven Development).

Despite everything we’ve learned about the value of conversations when deciding what to build into our software — about the value of automating as much of our testing as possible in order to shorten the feedback loops between things breaking and us knowing about them breaking, and to instill confidence among the stakeholders and the team that we can rapidly add new features without breaking existing ones; about the value of taking a test driven approach to building our software, based on real user behaviour rather than code behaviour, to enforce good design practices and ensure the software does what it is supposed to do — I still constantly see and hear of teams struggling with their approach to quality.

Some are struggling to find time to improve due to a combination of legacy systems with brittle or no automated test coverage and looming deadlines for new products or features. Some are struggling to create a short enough feedback loop for testing software increments as they are built so that problems can be addressed before code is deployed, or before developers have moved on to the next or even the next feature.

There is no denying that it is crucial to get the technical practices right from the start. Enough has been written about this. BDD at all layers, continuous integration and automated acceptance and regression tests.

However, when you find yourself in a situation where you are adopting a legacy system or process – i.e. you or your predecessors haven’t got your technical practices right from the start – then your only viable option will usually be to improve things gradually. Have developers learn how to and implement automated acceptance tests. Chuck out and replace flaky record-and-play UI tests with robust unit, integration and browser tests using best-of-breed tools. Embed testers in the development team. Gradually start to do all the things that ideally would have been done from the start.

It seems like a desperate situation, but all is not lost. Far from it. I feel that a common mistake teams and businesses make is to place too much focus too early on the necessary technical improvements.

In my experience, the most important thing to improve is the conversations between the business people, customers and the development team.

One effective technique for doing this is The Three Amigos approach, where the customer / Product Owner / BA has a chat with a developer and tester from the team to agree on the acceptance criteria for a new feature or story before it is undertaken. From this conversation the team can decide exactly what tests are needed, and where they should be implemented, in order to prove that the completed functionality will do what is supposed to do.

A mature Agile team would now write the necessary tests in their tool of choice (e.g. JBehave for Java), the developers would write just enough code for the tests to pass, then refactor. When all the acceptance tests pass, the story is considered “done” from a functional perspective.

But what if the tester and/or developers have little or no experience with an automated testing approach? I have worked with teams in this situation and it cannot be fixed right away (or even at all if there is no willingness from the business to invest in training and slack time to address the problem).

Let’s say the tester is traditional in his approach, and would typically create test cases which he will use to manually test the code when it comes to him from the developer. What tends to happen here is that the developer writes the code for the story, then hands it off to the tester, who then hands it back because the code doesn’t do what the tester expects it to do. This to-ing and fro-ing can happen once, twice, three times. It’s time consuming and frustrating for everyone, and makes it very difficult to complete product increments in a timely fashion.

Transform-through-conversations-photoHowever, if the tester and the developer have a conversation before the developer starts coding (with the PO/BA in the Three Amigos meeting, or just-in-time in a story kick-off), the tester can take the developer through his test cases (derived from the acceptance criteria) so that the developer understands everything that the tester expects to work when he is handed the code.

Over time in these conversations the developer will start making suggestions, so the test cases become more collaborative and thus effective. He will also want to make sure the story does not bounce back to him from the tester when he’s coded it, so he may do some more manual testing of the functionality or even write some (more) unit tests before handing the story to the tester. His confidence in his code is likely to have improved, and the bounce-backs become the exception rather than the rule.

The key to building in quality is first and foremost in the conversations because they create improvements in the way we work together, whatever situation we are in technically. The good technical practices will emerge from the better conversations. Agile is largely about focusing on technical excellence but, as the first line in the Manifesto tells us, more important is the interactions between the people doing the work. Continuous improvement allows us to start where we are and take one step at a time.

These up front and ongoing conversations, such as the Three Amigos, can have a massive impact on your effectiveness both individually and as a team, and on the quality and maintainability of your product, increasing your agility to adapt and innovate . Adding such conversations to your process is a great sign of continuous improvement and embracing the first and most important line of the Agile Manifesto.

Scrum Basics Part 2 – Monitoring Progress Toward a Goal

"Various projective practices upon trending have been used to forecast progress, like burndowns, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making."

-- Scrum Guide

Agile/Scrum teams are often asked to estimate how long a release might take. Or an entire project. Sometimes this is done under the guise of relative size estimates like T-shirt sizes – or, perhaps more commonly, story points – coupled with an estimated (or guessed) velocity. This is sometimes done even with new teams that have no velocity history.

Scrum, as defined in the Scrum Guide, places a large emphasis on the use of empiricism. Aside from the quote above, the following nuggets can also be found:

"Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Scrum employs an iterative, incremental approach to optimize predictability and control risk."
"[The Scrum Master helps the Product Owner with] Understanding product planning in an empirical environment"

My interpretation of Scrum is that, while the Development Team are expected to estimate each PBI (Product Backlog Item), they are not asked nor expected to determine delivery dates, or how much work will be completed by a delivery date.

At Sprint Review:

"The Product Owner discusses the Product Backlog as it stands. He or she projects likely completion dates based on progress to date (if needed)"

So, the Product Owner uses the estimates on the PBIs combined with the empirical knowledge gained from what has actually been done to determine completion dates of a set of PBIs (e.g. a release). At no point does the Product Owner ask the team what will get done (beyond the current Sprint).

This use of empiricism is often neglected by Scrum teams. Teams are asked to project release dates, sometimes several months out, without any velocity history. This is not making projections based on what has actually happened. It is not empirical, and does not work in a complex, ever changing environment.

"A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. As long as a product exists, its Product Backlog also exists."

If you are using estimates, it is important that you use probabilistic estimates based on real, empirical data. Scrum suggests this. Practitioners suggest this also. Don’t ask the team to forecast any further out than the current Sprint. As the Product Owner, use real data to make forecasts and decisions. Asking the team to make longer term projections is not respecting the data showing what is actually getting done.

Monitor progress, don’t try and predict it.