Should we be doing planning poker?

I got a message from an old colleague today with a link to a wiki page on Poker Planning and a question: “Why didn’t we do this?”

My initial reaction was that we did, we did it for years but after consideration I realised he was right – by the time he’d started working with us we had stopped using poker planning to estimate – or at least we only used it when we really needed it. So why stop? Did we lose our discipline?

The Scrum approach

Poker planning is a great way of using the wisdom of crowds to estimate stories. Points rather than days are normally used to keep the estimation abstract and these points are then tracked to calculate a team’s velocity to allow for capacity planning. In our early days of agile experimentation we followed the Scrum dogma quite rigidly – the team would gather together and examine features and help break them down to stories and then use planning poker to come up with an estimate, then the Product Owner would come along and select the stories he wanted the team to work on. More than once he commented on how he felt he was given the ‘illusion of choice’ whereby due to story size, team capacity and soft dependencies his options to select and order the backlog were severely limited.

This approach lead to us having a ‘well-groomed’ backlog but many of the groomed and estimated stories would languish in the backlog for a long period of time as small tokens of time wasted; growing stale and decreasing the signal to noise ratio. Furthermore, production bugs sat in their own backlog, prioritised separately and largely ignored by a product owner focused on building ‘the new’ and a team attempting to maintain its velocity.

A Product Owner’s role is to generate the maximum ROI through picking the stories which return the most business value for the amount of effort expended, however, the reality is often far more subtle than this; while each feature or story is technically an independent release of business value, more often than not each feature and story is part of a much bigger picture and really needs to be played in a specific order that the team understands. Backlog grooming, planning poker and sprint-stacking can become a transactional (rather than collaborative) affair leading to a poorly maintained and planned product.

Continuous deployment and a high-performing team

By the time the aforementioned colleague had joined the team we had restructured our approach. The Product Owner was embedded in the team, story and feature selection had become collaborative; there was no formal backlog grooming and commitments were agreed by small teams based upon the entire team having an in-depth understanding of both the business benefits of each feature and the estimated effort.
The roadmap was understood by the whole team and any up and coming work had either been spiked already or been analysed by the engineers and collaborated on (with UX and BA’s as necessary).

Furthermore, specialisation was respected and ownership of components encouraged: while we all love full-stack engineers, in a small team the reality is you may only have one real JS expert, one back-end expert and one HTML/CSS expert. Working on a maximum of one week iterations and with your definition of done as “released to production”, the abstraction of poker-planning-driven velocity becomes irrelevant – it’s easier for the team to work out what they can achieve in that sprint that week, estimating by days if necessary. With the onus on quality and user experience, fixing production bugs is treated as a priority and will often need to be prioritised at short notice which will impact deliverables so focusing on hard, velocity-based commitments can encourage a compromise on product quality.

So why did we stop Poker Planning?

When a product is well-established and development is lean and iterative, the team should be in control of its own destiny, understanding the vision and goals of the business and driving towards those goals with a roadmap for guidance if necessary. With the product owner embedded as part of the team and in constant collaboration with his team members the need for poker and velocity based capacity planning becomes irrelevant and the one important question becomes: “What can you (or even better, ‘we’) commit to delivering to production this week”.

With good stakeholders (or good stakeholder management) the sponsors will ask “what goals or improvements have we achieved” rather than “how many features did we complete”. With code being released to production on a weekly (or daily) basis the transparency that this approach delivers encourages trust between stakeholders, product owners and the delivery team, and negates the need for the transactional approach of poker planning, sprint stacking and velocity tracking.

Advertisements

SOA: An enabler for Continuous Delivery and innovation

Building on my experience at Westfield Labs, this presentation was delivered to Sydney CTO Summit and explores how implementing a Service Oriented Architecture allowed Westfield Labs to embrace a Lean, Agile approach to Product delivery.

The presentation covers how an SOA assisted with:

  • Management of backlog, particularly bugs
  • Managing build times
  • Cross-functional teams
  • Faster iterations
  • The ‘QA Paradox’ of better quality through reducing testers

We are the business

An ex-manager of mine once pointed out that we need to stop talking about “the business.” Doing so gives leverage to those claiming to represent “the business” and limits the influence of the engineering team. His was more a political observation than a call to change our mind state, but ever since then I have noticed how commonplace it is for colleagues to make vague assurances that “the business requested it,” or “the business want it like that.”

When someone uses the term “the business” they invoke shadowy high priests with absolute knowledge — but they could be referring to a clueless HIPPO, an opinionated sales or marketing exec or equally to any end user of a piece of software. The engineer should have every right to question those requirements and to request exactly whom “the business” refers to in this scenario.

At Westfield Labs we are very fortunate to work in a ‘digital’ department which combines product, design, end-users and engineering resources as equal collaborators. Most recently we have moved to truly cross-functional teams where the only direction given to us by sponsors and stakeholders is high-level: e.g. bring us more customers and more conversions through focusing on streams x and y. Sure, the product team provide the ultimate direction from a product perspective but only after close consultation and collaboration with all other relevant parties.

In this scenario it is not hard for an engineer to think of oneself as part of the business and I positively encourage my team to stop using the term ‘the business’ to refer to others as it implies that we are not an equal partner. To take it further, I actively encourage my engineers to question and understand business requirements and to shout out if they don’t make sense.

Talking recently to an engineer from a UK online retailer, he noted that his company “think of themselves as a marketing company, not a software company” and see the engineering department as a necessary expense to realising their feature requests. In a business that is so dependent on the quality of the implementation and the iterative improvements upon that implementation, it is naive to think that engineers are not equal partners.

Obviously it’s not so easy when you are working in an agency (and let’s face it, sometimes you are working from a spec and clearly not ‘equal partners’) but any enterprise that wishes to succeed in the digital age will ultimately depend on the quality of its implementation – and the feedback from those that are doing the implementing. Otherwise it will be made irrelevant by a competitor that does.

So, I entreat software developers everywhere: let’s stop talking about “the business” and start talking about: customers, stakeholders, sponsors, sales team, marketers, product team, whatever. Make it clear that we consider ourselves part of ‘the business’.

New look

I just changed the theme. Not because I didn’t like the old Chunk theme but because it didn’t credit the author on the home page and I thought that was important now that hissohathair is contributing as well. It appears that editing templates on wordpress.com is not an option so welcome truly minimal, hopefully we will have a long and fruitful relationship.

While browsing the 300+ themes available on WordPress I was reminded of the elegance with which WordPress separates content from presentation and the experiences I have had moving from a CMS toward a set of APIs that serve ‘structured data’.

At westfield.com.au we threw out our Teamsite CMS a few years ago and moved away from the idea of a meta-data driven ‘universal CMS’ toward an API that serves structured data to our Presentation Layer(s). As any OO programmer will appreciate, this allows us to store the behaviour and business rules with the data – as opposed to treating data as an anonymous blob – and we’ve never looked back. We avoided the problem of an ever-growing database schema and ‘Business Layer’ by implementing an SOA but more about that another time.

We’ve been able to provide content parity across all devices by fully embracing responsive web design and we can do this because (like the WordPress themes) there is a complete separation of data from the presentation layer. As we start to move toward providing richer editorial-style content we are really starting to reap the benefits of this approach; we store data in it’s small component parts and then tag and curate this data. This allows us to create simple editorial pages such as the recently launched Curations but as we start to discover more about our users and their tastes through the power of big data we can start to tailor our content to their individual tastes and look to serve our content algorithmically rather than through creating pages as one would have in traditional publishing.

From my perspective, well constrained CMS’s like WordPress that solve a clearly defined and well understood requirement will continue to flourish but if you’re looking to fulfil a unique requirement you’re going to have to write a lot of bespoke code so why not embrace it and give yourself that freedom and control. Leave the off-the-shelf CMS for the brochure-ware sites and the big publishing companies that have the money and patience to customise them.

 

The philosophy of Continuous Deployment

Over the past few years my team have been on a journey toward Continuous Deployment – this has involved changing our architecture, our attitude towards testing, and our tolerance toward slow build times but most fundamentally we have noticed it required a change in philosophy and our attitude toward quality, responsibility and ownership.

In our previous model our mantra was “you release what you test” and with the right phase gates and environments in place it allowed new releases to flow through the hands of QA and into the responsibility of Production Operations. Despite having a huge body of automated tests, our attempts to refine this process to become faster always foundered:

  1. we could patch additions into the release branch but this delayed the release while QA assured themselves we were ‘ready’

  2. any late patches or bug fixes to the release branch had to be merged back into the Master branch and were sometimes forgotten causing regressions on the next release

  3. the longer the delay to the branch release the more the product team tried to shoehorn more stuff into the release branch instead of Master and the vicious cycle continued

  4. meanwhile QA were always absorbed getting the branch release out and work on Master was delayed or quality suffered

A recent pivot allowed us to become far more aggressive toward enforcing a strict “no junk in the trunk (master)” policy and we found that when a team embraces Continuous Deployment, they start to embrace a philosophy of personal responsibility and develop the following behaviours:

  • ownership of services or code bases

  • collaboration with the operations team (devops)

  • making sure their code is well-tested and production ready

  • releasing code in small releasable chunks

  • thinking about backwards compatibility

  • collaborating and communicating with your team and the business users that your code changes will affect

  • accepting that you cannot live in isolation on your long-running branch without paying the price in conflicts

  • realising that the QA team are not your bug finding monkeys

  • checking your production logs for errors

  • writing the correct level of automated tests to limit regressions without negatively impacting productivity

  • monitoring your systems vital statistics (in all environments)

  • deciding when to back-out and when to fix-forward (and having a plan for this)

  • having a nuanced understanding of risk, quality assurance, testing and release strategies and that some features and bugs can be released immediately while others need in-depth testing

  • understanding that you no longer need a “definition of done” because your work isn’t done until it’s successfully released into a stable production environment.

All this comes under the umbrella of personal responsibility and that comes from the knowledge that when a developer chooses to release a piece of code, that code will go to production and they will accept responsibility for it. Along with that responsibility is the pride and reward in knowing that one’s code is released – it’s live, in the wild, and changing users lives (hopefully for the better).

Recently we experimented with adding a traditional formal sign-off to our release process from business owners outside the product team and the results have been interesting. We were faced with either applying a moratorium to Master while sign-off was approved or creating a release branch and letting Master flow. Either way we were faced with similar issues:

  1. Developers are no longer able to release their own code so Master starts to differ significantly from what is in production.

  2. A “one size fits all” approach is used for release sign-off – whether it’s fixing a typo or refactoring your payment system you still need sign-off as developers are no longer trusted to weigh the risk themselves.

  3. The QA team and release manager become responsible for the release, not the individual that wrote the code. The theme of personal responsibility is broken: the developer has moved onto a new task.

  4. The release manager starts to manage what goes into the release: features and fixes are forced to languish on branches until the release manager is ready to merge them.

  5. As the amount of code ready to deploy grows, release managers get nervous and need more time to test on the release branch.

  6. More and more time is spent managing ‘the release’ than writing and delivering features

  7. As stakeholders realise that releases take longer, they start to hold up the release for “one last fix” rather than wait another week. A full regression is then required by a nervous release manager and the vicious cycle continues.

  8. When you push out your release it has batches of changes in it. If production is affected, it is far more difficult to work out which change caused the problem.

The end result: your release cycle is slower, your team is less productive and less engaged, your QA team is over-loaded and your releases are potentially more buggy and harder to fix.

Continuous Deployment is not just about releasing code fast – it’s about having a team that takes pride in their work and feels responsibility for the quality, stability and effectiveness of the live product.

Our focus now is on improving visibility, accountability and automation so we can better provide rich, descriptive release notifications to stakeholders and regain the capacity to release from within the team rather than have to ask permission from an approval body from outside the team.

How Agile would have saved project ORCA

Working in the Web Development industry it’s easy to get the impression that everyone involved in software knows about Agile and is at least paying it lip service even if their processes are not really Agile in practice. Clearly this is not the case. The Unmitigated Disaster Known As Project ORCA describes how Mitt Romney’s team attempted to win the race to get voters out to the polls using new technology but fell at every hurdle. It presents us with a textbook copy of everything that can go wrong in software delivery with (depending on how significant its impact) potentially election losing consequences for Mitt Romney and the GOP.

The following are some of the glaring errors made that would have been avoided using Agile/Lean techniques:

  • Putting a mission critical piece of software to its first real use on a day when failure was not an option.
  • Giving themselves no opportunity for feedback or pressure testing and gaining no validated learnings as to whether what they had built would even work – conceptually, functionally or practically
  • Using a top-down approach that ignored the huge amount of skills, knowledge and experience that could have come from the greater team (those on the ground that would have to use the product)
  • Convincing themselves they had a product so great that it was better to keep it under wraps and maintain the element of surprise than it was to allow the product to be pressure-tested by the people that were going to use it

Agile software development recognises that you will not get it right in version one, that a delivery team needs to include its end users, that software improves iteratively and that not only your software but your business model itself must be able to pivot and adapt to the realities on the ground and the feedback you receive.

This is what Jason Fried of 37signals did when he gave his company a month to work on projects of their own choosing.

Sounds radical at first thought but if you have dedicated passionate people it makes a lot of sense. It’s the staff involved in the day to day running and building of your business that are most likely to know what your business needs. Fried has given them an opportunity to demonstrate what’s needed and the solutions to those needs.

How can you afford to do this? How can you afford not to? Argues Fried: “We would never have had such a burst of creative energy had we stuck to business as usual.”

Jason Fried – Why I gave my company a month off