My presentations

Videos

Slides

Audio

podcast_badge_big

Advertisements

The common ground of #Estimates and #NoEstimates

One of the criticisms of the #NoEstimates (NE) stance is the view that even contemplating not estimating is a non-starter – because estimates are “for those paying our salaries”, not those doing the work. That the business folk in our organisations need to know what will happen and when in order to run their company successfully.

OK, even if NE advocates could successfully argue against that assertion, perhaps it is time we started to acknowledge the “impediments” of the debate? The back and forth arguments that prevent us from moving forward to a more constructive place.

Perhaps it is time to find the common ground, and build on that.

A simple truth is that business wants (needs) both speed and predictability. I think we can all (mostly) agree on that 🙂

Some NE critics argue that we should learn better estimation skills such that our predictability improves. Yep, sure. Difficult to argue that learning to do something better is a bad thing.

Given that we have to do a lot of estimating as software practitioners, learning and using more effective estimation techniques seems a good idea.

However, in return for NE advocates acknowledging that we need to provide estimates for those asking, and get better at doing so, I think it’s time for the critics to acknowledge that arguing better estimation as the answer to all the dysfunctions surrounding software estimation is another impediment to the debate moving forward.

I see common ground in that we are all trying to create better predictability for our teams, customers and internal stakeholders. If we put aside “better estimation” as a way of doing that, how else might we do it?

Better predictability can be achieved in many other ways:

  • Stability and autonomy of teams
  • Limited WIP of initiatives (1 per team at any given time)
  • Frequency of delivery of “done” software
  • Cadence of collaboration – planning, building and reviewing together
  • High visibility and transparency of work and progress
  • Shared understanding of variability, its effects on long range planning and how/when to try to minimise it or leverage it to our advantage

to name but a few.

To take the NE debate forward, we need to find ways to provide “those paying our salaries” with the predictability they need, while at the same time moving away from the dysfunctional behaviours associated with holding teams accountable to estimates in highly unpredictable environments.

What is an unpredictable software development environment? One in which 1 or more of the things listed above are not being addressed. It might not be a stretch to suggest that’s pretty much every software shop on the planet.

There is common ground between critics and advocates in this debate. Let’s move on from “no estimates for anyone!” and “just learn better estimation techniques” – these arguments will perpetuate butting heads.

Instead, let’s explore – together – how we might create more predictable environments for our software teams, such that estimation becomes easier (and, in some cases, redundant).

“We are uncovering better ways of developing software by doing it and helping others do it.”


~ Agile Manifesto

Context is no longer King

One of my frustrations as a software practitioner is our seemingly programmed human bias toward keeping the status quo.

I guess it wouldn’t be so bad if the status quo (pictured above) was actually something approaching effective, inspiring or at least motivating. But unfortunately the reality for many (most) people making their living in the crazy (in a bad way) world of software development remains one of boredom, dysfunction, wasting time on unimportant things, going along with stupid decisions (or lack of them), stress, hatred of Mondays, being put in our place by our “superiors”, et cetera, et cetera.

“23,858 tweets and counting. Worthwhile or a colossal waste of time?”

I tweeted this yesterday. Often I wonder why I stay in an industry that suffers from the afflictions listed above. My work mood swings from utter dejection to tremendous elation. Like the software we create, the variability in my mental state is subject to wild fluctuations.

Here’s the thing. The reason I do this; the reason I stay in the industry, tweet opinions, tips and debate; the reason I write these blog posts; the reason I give a significant portion of my time freely, mostly at my own cost, to talk at meetup groups, conferences and company brown-bag lunches; is…

Because I want to play a small part in creating a better world of work for those involved in software development.

Particularly developers, who I believe have been treated for years like some kind of underclass in organisations of all sizes and industries. Crammed like sardines into some dark, dingy corner of the building, given to-the-letter specifications of some crappy software system that will keep them busy for a few months and then will never be used by a soul. Forced to commit to an estimate of how long this will all take (minus whatever needs to be trimmed off because the estimate doesn’t fit into the already agreed timelines). Constantly being micro-managed and asked “why is this taking so long?” and “why is this so hard?”.

Yes, I’m angry about this. And I want things to change. So I’m trying to do that in my own little way.

I want us to start treating smart, motivated people with the respect they deserve – right from the moment we hire them. Why on earth companies put engineers through 3 or 4 rounds of interviews and then fail to actually trust them once they get the job is beyond me. Managers continue to spoon feed solutions to their subordinates because they “can’t be trusted” to solve business problems quickly and efficiently enough.

This is why I am challenging the status quo in our industry. Sometimes what I write or say is found provocative by some. One dimensional. Context-less. “It depends on the context”, people say. “There’s no one right way. No advice is universal.”

I get disappointed (sometimes annoyed) when people who have never met me and know nothing about my professional reputation and abilities confuse what I tweet as “professional advice”, and then start questioning my integrity and ability as a consultant. It is hypocritical and way off the mark.

The reason why people write blog posts with provocative titles, and tweet with controversial hashtags, is because it is interesting. It invites conversation and debate. It stirs things up a bit. God knows (and so should the rest of us) that this industry is in dire need of some stirring up.

I was questioned by a couple of people about a tweet I wrote recently:

“In fact my tip is NEVER do a MoSCoW prioritisation. The implied fixing of scope makes change very difficult. Order things instead.”

A tweet, I might add, that was retweeted dozens of times, so obviously resonated with many.

I was told that my opinion was “unjustified”. That I shouldn’t make “categorical statements”. That “never is a long time”. That some poor soul may take my advice (assuming a tweet constitutes professional advice?!) and destroy a project because I am uninformed about their “context”.

I am constantly told the same kind of things about the #NoEstimates debate. That I can’t tell people not to estimate because I don’t know their context. Their boss might need estimates. Sometimes we need them, sometimes we don’t. Et cetera, et cetera.

With all due respect to these people, they are completely missing the point. For a start, I think it’s ridiculous to suggest that people would read a tweet from little old me and that would somehow create a chain of events that would destroy a project. Even if I were someone with anywhere near the influence and expertise of the great Ron Jeffries or Kent Beck, I don’t think I would yield that kind of power over people.

I do not use Twitter to dish out free professional advice. It is a forum for opinion, conversation and debate. Well written tweets resonate with people in some way, such that they retweet them, favourite them or, preferably, start conversations about them.

Perhaps reading a tweet like the one above will encourage someone to think a bit more about a practice that they have always done without question. To look into alternative ways of organising and prioritising work. To completely reject what I’m saying. Good tweets create a reaction, and whether this reaction is an angry disagreement or a nodding of the head, it has done its job.

Twitter is not to be taken too seriously, but the conversations it can create are serious and, I believe, are helping us as an industry to increasingly question long established practices. This can help us improve the way we work. The way we think. It is vitally important for us to have our world view challenged on a regular basis. This is how we learn and evolve.

I don’t just want to read tweets saying that “it depends on context”. Stuff that confirms my world view. Stuff that I agree with all the time. If every piece of advice or opinion “depends on context” then we might as well just give up trying to improve things.

“Depending on your context, you might want to consider alternatives to MoSCoW prioritisation. However, if it works for you then fine, just keep on doing it.”

Politically correct, perhaps, but it’s not exactly going to give me a reaction. I’ll probably not even notice that tweet on my timeline. “Be happy”. Ooh, can’t say that, it depends on context.

Moving away from social media for a second and into the real world of professional coaching and consulting – As Agile coaches I believe we can do much, much more for our clients. If someone tells me that I’m being unprofessional for suggesting better alternatives than MoSCoW then we are on different planes, I’m afraid. I know that there are certain principles and practices that have proved effective for me time and time again.

I’m not alone on this. I believe some statements are universally applicable, regardless of context. Questioning the way we do things doesn’t depend on context. Respecting each other and striving to work more collaboratively doesn’t depend on context. Adopting good engineering practices will help you to deliver incrementally and iteratively at a constant pace over time – this is universally applicable also.

Of course context is important – to me that’s so obvious that I can’t believe people keep saying it. We know that. It goes without saying.

But it’s not the point. The point is that many, many companies are still struggling to grasp the principles and practices that we in the Agile and Lean community know can increase effectiveness. Our clients deserve better advice from us than “well, if that’s working for you then keep on doing it”. We all know that something “working” is a perception and may actually be destroying the morale of the employees, or even putting the business as a whole at risk.

It is not “professional” for us to keep playing the context card. We need to be bold in our decisions and advice giving. Take risks. Challenge the status quo. Encourage innovation, not just of products but of process also. Be a true change agent, not just blend into the environment.

If you like what I tweet and blog, that’s wonderful so please do keep following! If you don’t like it, please unfollow. Twitter is wonderful because it is the ultimate pull system. If we don’t like what we see we can block and unfollow. We can filter out content that doesn’t interest us. It’s brilliant. And I shall continue to use it to challenge, provoke and generate conversation and debate. I cannot begin to measure how much I have learned and evolved my thinking thanks to conversations on, or starting on, Twitter. I’m pretty sure others will say the same.

And I will continue to help clients, in their context, get better whilst trying to create happy and humane workplaces. I want to live in a world where people enjoy going to work. It’s time away from our family and friends, and we spend most of our time there, so for God’s sake if we’re not enjoying it then what are we doing?

I don’t get it right all the time. Probably not even most of the time. But I do this because I care. I will continue to risk getting lambasted by people and losing the respect of gurus and experts. Like the rest of us, I don’t know it all – far from it. But I do not learn by being uncontroversial and not pushing the boundaries of what I believe or how I think things should work.

Thanks for listening 🙂

Note: I will write a follow-up post about  MoSCoW prioritisation itself. Aside from the fact that it perpetuates the myth of “requirements” (if something is not a “must-have” then how can it be a requirement?), I’m not including my further ideas on the topic here because it’s not really what this post is about.

Many have already written about the damage it can do and some better alternatives to set you on the road to delivering a successful project (read building a successful product). For starters, Joakim Holm wrote a great post about it the other day. And there’s lots more to investigate using our friend Google!

False Gods, Silver Bullets and the Myth of Innovation

I am privileged to publish this guest post from the brilliant and lovely Michael Rembach (@mrembach).

In October I stumbled across a blog article about product development using Scrum and the hindering effect that Scrum can have on the innovation process especially if the organisation is fully ‘agile immersed’.  The blog was written by Brian de Haaf (@bdehaaff) who is the co-founder of Aha! – A product management software company.  While the article was well written and brought up many salient points about innovation, I disagree with the overall premise that Scrum may have innovation-limiting behaviours  You can read the original article here zite.to/17HnE4S .

The first thing I’d like to point out is that I agree with the points about innovation in the article.  Innovation practices, such as having a shared vision, engendering trust in your organisation and having a strategic direction are all vital ingredients for success and even more so in technology companies.  The thing about innovation is that it’s a cultural thing and no framework/methodology/philosophy in the world is going to make your company innovative without the desire (or need) to. Having a myopic view of your product because you’re ‘Agile’ misses the point of the delivery focus and discounts the innovation-enabling practices that Agile encourages.

Scrum, and other Agile methodologies, are essentially delivery focussed which is why there is a requirement for product owners to focus strongly on the Sprint cycle and the short-term delivery timeline that it brings.  However, this does not and should not excuse the product owner for not checking that what is being delivered is aligned to the strategic goals for the product or in fact, the organisation.  The two aren’t mutually exclusive and a product owner is responsible for communicating that vision to the project team so that they are aware of the purpose of the product.  Constantly checking in with the vision by all the team should ensure that what is being built doesn’t deviate from the intention of the product’s purpose.  The product owner is simply not performing her role properly if she suffers from the myopic concern with delivery-cycles without also ensuring that the product is meeting its intended strategic objectives.

Rather than inhibiting innovation, I posit that Agile has a number of practices that encourage innovative behaviour:

    1. MVP – the primary reason for creating a minimum viable product is to determine that what you’re trying to produce is viable, but it also serves a couple of other important purposes.  The first is prototyping; where you have the opportunity to experiment with your solution, try something small and novel and see if it works and the second; it gives you the opportunity to solicit feedback from your clients, the product ecosystem and anywhere else.  This is a primary source of knowledge for decision-making.
    2. Fast-failure – Agile methodologies allow you to fail quickly and learn some valuable lessons before it costs you too much.  Innovation is all about finding out new ways to do things and failing fast and safely is one of the best ways to forge new paths.
    3. Continuous learning through retrospectives – a learning organisation is an innovative organisation and retrospectives provide an excellent opportunity to improve not only what we are producing (again, you can look at the strategic alignment at the end of every sprint or release cycle), but also how we work together.
    4. Embracing change – if making changes to your product is painful then your ability to be innovative will be too.  Agile methodologies accept that change is inevitable from the get go and therefore provide less resistance to innovating during the development of a product.

Innovation is difficult at the best of times.  As Clayton Christensen illustrates in his famous Innovator’s dilemma, history is filled with the burnt out shell of successful companies that died as a result of not being able to change.  To succeed, innovation needs to be part of the organisations culture.  The premise that progressive change-embracing frameworks like Scrum inhibit innovation does not recognise these aforementioned practices.  Agile won’t make you innovative, but it sure can help encourage it.

#NoEstimates puzzle experiment in Melbourne

Craig Brown and I ran a variant of Chris Chapman’s now famous jigsaw puzzle experiment at a meetup of the Melbourne Agile and Scrum User Group on Wednesday evening.

Everyone had fun and was intensely engaged throughout. There were loads of interesting dynamics emerging from the teams, perhaps surprising given the contrived nature of the experiment.

Set up

  • We set up three same-sized (10-12 people) teams, each with:
    • an identical jigsaw puzzle (way too big to be completed)
    • a Product Owner (to provide the vision and direction) and
    • a Scrum Master (to help the team achieve the PO’s vision)
  • We opted for 3 * 15-minute iterations, with 3 minutes for a Retro in between
  • Each team was told to use a different method – one was a Scrum team, one was a “mob team” and one was a “no rules” team. Here’s what that meant:

Scrum team

  • Must have Planning (including estimation), Review and Retro in each iteration
    • We provided Planning Poker cards for the estimation but the team was free to choose whatever estimation method they liked
  • Must only work on “stories” agreed in Planning – new stories can’t be introduced mid-iteration
  • Stories are only “done” when PO accepts them (in Review or before)

“Mob” team

  • No formal ceremonies required
  • Team all works on one story at a time until “done” (single-piece flow approach)
  • No estimation
  • Retro encouraged but not “enforced”

“No Rules” team

  • Can work like the Scrum team, the Mob team, any combination of the two, or any other way they like

Outcome

  • 600_301537052600_301537062Scrum team delivered most stories (3; the other teams delivered 2 each)
  • Whole group was asked to vote on which they thought was the best outcome
    • “No rules” team won (emphatically)
    • Scrum team lost

Interesting Observations

Here are some empirical observations of the evening’s events and outcomes, along with my interpretation of what they indicate in an Agile/#NoEstimates context (==> in bold italics underneath the observation).

Scrum team

  • Delivered most in terms of stories but least in terms of value, both for their Product Owner and as voted for by the wider group
    ==> Output <> Value
    ==> Comparing teams in a useful way would require consistent measures of both effort and value velocity across teams
  • Spent far too large a proportion of time (particularly the first iteration) in planning, and needed to be alerted to this fact
    ==> Consistent timeboxing is important to ensure there is time to do all that is required, and for less variability of outcomes
  • A member of the team openly admitted that he inflated an estimate because he did not agree with the value of the story that the PO wanted to do next
    ==> Estimates are often gamed, and for various reasons

“No rules” team

  • Implicitly chose not to estimate, but instead to maximise the time they had for building
  • Eventually delighted their Product Owner (and wider group), but during the game the PO felt like:
    • The approach to delivery was too ad-hoc, even chaotic, especially at the beginning
      ==> Teams must collaborate in order to be co-ordinated, improve and deliver the right outcomes
    • Stories were too large (epic) so delivery all happened near the end rather than incrementally
      ==> Smaller stories have lower variability and can help with early and frequent delivery, creating better predictability for PO/customer and lessening the need for estimates
      ==> Larger, higher variability stories rely on estimates of time, or at least relative size, to provide the illusion of predictability
  • Started with no process at all but this was deemed unproductive (with such a big team), so they split into smaller teams with focused goals
    ==> Smaller teams are more effective because it is easier to collaborate, change direction, gain consensus, etc.

General

  • Scrum and Mob team both delivered purely incrementally (concentrating on edges) rather than iteratively (identifying a recognisable area of interest and building upon it), although stories were clearly too big
    ==> An iterative approach is crucial for risk management, predictability and delivering the right thing (value), i.e. without such an approach you have no choice but to estimate
  • Product Owners all felt like they weren’t being listened to – this had particularly bad consequences for the Scrum and Mob teams, perhaps due to their purely incremental approach
    ==> Important for all team voices to be heard, especially given the PO is driving what should be built in order to deliver on the vision

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.