This is not a prescription for the right way or wrong way of building software on product teams. In fact there is no such thing as a right or wrong way of working. Different practices work in different ways with different people on different teams. Instead this is a breakdown of the practices in building software that have always worked well for me, and have thus been informed by the many repeated problems, failures and breakdowns in communication as well as the learnings, triumphs and successes that I’ve seen or experienced in the time that I’ve been working as an engineer on product teams of different shapes and sizes.

This is a breakdown of the practices in building software that have always worked well for me…

Question Every Process

What is of upmost importance always, is that you’re constantly questioning whether the way that you’re working is helping you reach your goals as a team. If it isn’t then being able to change it quickly and easily is critical to being successful. Be sure that you’re always open to new ways of working which might augment what you’re already doing, making you more effective and productive, or even replacing it.

Know that individual push back from change is inevitable. You need to know how to manage push back and any other feedback in a way that is useful and that works for everyone. This is never easy, but rejecting feedback completely only ever leads to bigger problems and worse products.

Hire Talented People

It’s important that during the hiring process, instead of just measuring people’s technical expertise (whether that’s their ability to design visually beautiful things, or to traverse a binary search tree), that you also make sure you’re hiring people who are open minded, collaborative, motivated, natural learners and have strong communicative skills.

These skills are the distance from a good team to a great team and yet the modern day interview process does absolutely nothing to identify it or measure it. Surprisingly, there are people who do exist that hate change, and can’t work well with others, but they easily slip through the cracks because they can sort an Array on a whiteboard while blindfolded. You shouldn’t want them.

People who are open minded, collaborative, motivated, that communicate well and are natural learners will accomplish far more with a team of like minded people than one lone programmer who sits in a corner and quietly writes complex algorithms faster than the entire team combined.

Track work in Stories

Forget about all the labels for this, and simplify it down to what it actually is, which is Task Management. Identifying work to be done, breaking it down into size-able pieces that signify varying things for different people on a product team:

For Product Managers

  • To size the amount of work to be done, and provide estimates
  • To measure the velocity of the team (or simply, the speed at which work is being done)
  • To prioritize certain tasks, features, bug fixes or chores over others
  • To enable strategizing based on analytical trends in team workflow

For Designers

  • To provide Assets, Resources, Prototypes and Designs for Engineers to use during implementation

For Engineers

  • To identify the tasks associated with Commits, Pull Requests, or code changes
  • To identify chores or Dev tasks to come back to such as Refactoring or paying down Technical Debt

For All Team Members

  • To communicate what they’re currently working on, will be working on and have worked on
  • To identify dependencies or blockers on tasks and get them unblocked
  • To frame general communication around specific tasks, issues or features with each other
  • To facilitate bridging the divide between Product, Design and Engineering work flows
  • To record history of product changes, communication and domain specific information over time

I may have missed a lot of things but you get the idea. Tasks are important, they’re the underlying foundation of communication that can make or break effective teams. I’ve worked on teams that track work verbally, or over text-based chat and it has always created more problems than it has solved.

How do I prevent the pile of work in-front of me from consuming me and burning me out?

How does everyone know what I’m working on? How do I know when I come into work each day what is expected of me? How does the business know when a specific feature will be delivered? How do I prevent the pile of work in-front of me from consuming me and burning me out?

Move Tasks through Swim Lanes

Clearly defined swim lanes for each stage of the Task lifecycle works wonders. Any team member at any time without asking anyone anything is able to view a task board that displays the status of all open tasks flowing from ‘Backlog’ to ‘In Progress’ to ‘QA’ to ‘Done’. It reduces confusion, clarifies communication, provides context and promotes visibility.

Swim Lanes shouldn’t be created in isolation by a Product Manager and thrust upon the entire team to work within, ever. Company wide swim lane configurations (such as in JIRA) are always a bad idea. Different systems work for different teams, and while the fundamentals might all be similar each team has its own unique nuances that work best for them. Let people own their own flow.

Swim Lanes shouldn’t be created in isolation by a Product Manager and thrust upon the entire team to work within, ever.

Fundamentally all task boards should include swim lanes for ‘To Do’ (Tasks that need to be done), ‘In Progress’ (Tasks that are being worked on), ‘Test’ (Tasks that are ready to be tested), and ‘Done’ (Tasks that are ready for release).

Give Design a chance to provide Feedback

Once a task has been implemented by engineering, if it involves design in any way, designers needs to have the opportunity to review its implementation before it ships to anyone external from the core team. Designers providing feedback before QA means UI bugs are caught early, and enable engineers to fix them quickly and easily instead of diving back into code written days or weeks ago. Every time this feedback loop gets skipped and tasks go directly from Engineering to external stakeholders risks critical design issues slipping through that could have been caught sooner simply with a glance from a designer.

Design needs to have the opportunity to review the implementation before it ships to anyone external from the core team.

QA Internally before Delivering Externally

Bug fixes or new features should never be seen by anyone outside of the core team (designers and engineers) until they’ve been tested internally and validated internally, reaching the end of the swim lanes. This small separation from the core team and the business stakeholders is critical to delivering bug fixes and features faster and more effectively.

Stop measuring Stories based on Time

It’s human nature to reason about and measure tasks based on the amount of time it takes to complete. It feels natural and it’s easier to understand than other arbitrary concepts like t-shirt sizes (Small, Medium or Large). Despite how tempting this may seem, and how much sense it makes to designers and engineers, time-based story points don’t mean what you think they mean.

Story Points have two key (yet distinct) purposes:

1. Estimates for Stakeholders
Story points enable Product Managers to provide estimates to stakeholders about how long a specific feature, or release will take. Based on this they can provide a Statement of Work (SOW) with a somewhat concrete cost estimate. These estimates don’t necessarily need to be pin-point accurate, but usually time-based estimates provide a more concrete way of measuring time and materials. Without an estimate it becomes difficult to justify charging money for work, and the only alternative is an upfront fixed cost (that doesn’t scale to large undertakings at all).

2. Estimates for Core Team
Story points also enable designers and engineers to communicate with each other about the level of effort and complexity required for different tasks. Based on this they can make decisions about which tasks to tackle first, the order of the tasks to work on and dependencies between tasks. Story Points allow designers and engineers to identify ways of breaking down larger and more complex tasks into smaller more manageable pieces of work.

Story Points serve different purposes for different members of product teams. While time-based estimates work well for stakeholder estimates, holding designers and engineers to such specific units of time inevitably ends up becoming ‘deadlines’ for tasks which don’t make any sense in an environment where constant change is such a looming, influential factor on everything and everyone.

Holding designers and engineers to such specific units of time inevitably ends up becoming ‘deadlines’ for tasks which don’t make any sense in an environment where constant change is such a looming, influential factor on everything and everyone.

Symptoms of this issue tend to reveal themselves when you start to hear people asking “When will this be done?” Or “How long do you think this will take to be done?” Or “How long left do you have on this?”. This means that your team has not reached a good cadence or rhythm of working. It does NOT mean that designers and engineers are not working hard enough, but that work is not being done at a constant pace.

Speed vs Pace

There is a very subtle, and often misunderstood difference between ‘Speed’ and ‘Pace’ in Software Development. Moving fast, almost always means taking shortcuts, sacrificing quality for quantity and will inevitably lead to burn out. Moving at a consistent pace means providing accurate Story Point estimates, breaking down stories into manageable pieces and delivering these small pieces at a consistent and predictable speed that circumvents the negative effects of last minute change.

Where modern software companies such as Airbnb, Facebook and Google have managed to thrive is by hiring enough designers and engineers so that individuals can take as long as they need to in order to deliver high quality and well-tested features, without any concerns for speed or hard deadlines. There are so many teams working on so many things that even though one person who is working on one specific thing might be slow, Facebook as an organization is constantly pumping out new features daily that are all high quality.

Separate Stakeholder Estimates from Core Team Estimates

Don’t use Story Points from the Core Team to estimate time and materials for a Statement of Work. Designers and engineers don’t know about the unpredictable issues they might encounter during their day to day work on a task until they’ve started. That’s exactly why they’re called estimates. Time-based estimates for a Statement of Work should come from an experienced individual outside of the Core Team who can provide rational, concrete time-based estimates based on their previous experiences. If at all possible, keep the specific estimates as far from the eyes of Product Managers as possible, to prevent the estimates from leaking into and undermining the estimates provided by the Core Team.

Estimate using what works best for your team

Small, Medium, Large. Fibonacci Sequence. Red, Green, Blue. There are many different ways of conceptualizing the ‘complexity’ of a task that are not based on amount of time required to complete.

Complexity. Not Time.

When Story Pointing, team members should be asking “How hard is this task?” And categorizing this metric in whatever way works best for them. Not everyone thinks in the same way, so not all ways of measuring complexity will work for everyone. You must find what works best for your team.

Product Managers who inadvertently force a specific way of estimating onto a team usually end up fielding push back or dealing with confusion. Don’t punish someone for not agreeing with your estimates strategy.

Break Complex Stories Down

Arguably the most important reason why Story Points exist is to enable complex stories to be separated into smaller, less complex stories. It is also one of the biggest contributing factors to:

  • Achieving a consistent pace
  • Encouraging visibility
  • Reducing the size of Pull Requests
  • Making Code Review more effective
  • Catching bugs earlier
  • Constantly delivering value
  • Improving architecture
  • Reducing the amount of time tasks are ‘In Progress’
  • Preventing merge conflicts
  • Speeding up Stand-ups

Smaller tasks are in progress for less time, meaning git branches don’t need to live as long, preventing engineers from overlapping with each other and preventing merge conflicts. Tasks are delivered faster, designers give feedback sooner, and catch issues earlier. Even though tasks are smaller, the same amount of work will ultimately be delivered in the same amount of time.

Continuous Integration is a must have

By defining a build, test and deploy process programmatically and automating it — team workflow becomes much more predictable and manageable. Product Managers and QA testers know exactly where and when to expect a Release build. They can perform their testing without any engineering intervention, leaving engineers to focus on more important tasks. Engineers can feel a certain level of comfort that their unit tests are validating that their ongoing work is not breaking existing functionality.

On every team that I have worked where there has been no CI process, or a bad CI process — the same underlying issues occur.

Daily Builds

Don’t take daily builds for granted. Automate your CI to trigger an external release to stakeholders at the same time, each and every work day. Product Managers and stakeholders being able to know exactly when features will be delivered on a consistent basis means that value is being delivered at a predictable and steady pace. No one needs to tell stakeholders when features are being delivered, they will receive each update and have full visibility.

Keep Stand-ups Short

Spend a short amount of time each and every day discussing what people are working on in some form. It’s too easy to get into in-depth discussions about issues that are irrelevant. Set a timer, and be harsh. Give every individual 30 seconds to speak and then move on. Easy. Just do it. Move on.

Some teams choose not to discuss what was done yesterday, other teams find significant value in doing so. Recently, I’ve heard of teams who find daily stand-ups to be more effective at the end of each work day, allowing team members to provide more insightful information about the current day’s work and work for the next day. Other teams choose to perform daily standup over chat using chat bots that request specific information from individuals and generate brief overviews that teams can read. Whatever works for your team do it, but do it consistently every day.

Whatever works for your team do it, but do it consistently every day.

Be intentional about Sprint Goals

Sprints are less of a requirement for members of the Core Team if they’re working at a consistent pace. They are important however for Product Managers, to encapsulate short periods of time so that they can track changes in velocity per sprint over time, or number of tasks delivered. It’s important that you’re not just working within sprints for the sake of working in sprints, but if you do, trend towards keeping them short.

Strategizing around Team Workflow is irrelevant to the Core Team

Product Managers like to spend time analyzing trends and patterns in the ways that product teams work. Tracking metrics such as velocity, number of Story Points delivered per sprint, and so forth. There’s nothing wrong with doing this, but it is entirely irrelevant to the Core Team itself and should be done strictly to inform the Product Manager and their planning. Don’t facilitate unnecessary meetings intended to discuss statistics that don’t matter to the product or the people building it.

Make retrospectives a hard requirement

What’s important is that you’re constantly questioning whether the way that you’re working is helping you reach your goals as a team. You can’t do this if you’re not constantly looking back at what you’ve done and understanding what worked and what didn’t. Hold retrospectives regularly, keep them short and productive or team members will hate attending them and won’t provide adequate feedback.

Team Members need to want to participate in order for retrospectives to be effective. To want to participate team members need to feel that the feedback and suggestions they provide are being heard, and actions are taken as quickly as possible based on their participation. If retrospectives are just another checkbox, and nothing comes out of them, they will lose all value.

All team members and contributors who touch a project in some way need to be in a retrospective. No one is above retrospectives. Even if a team member is no longer involved in a project or is leaving the team, they should be involved in the retrospective so that their insights can be used to improve the team’s way of working.

Don’t use Retrospectives as a crutch for not questioning your workflow. Retrospectives are one way of being aware of problems with a way of working, but they are not the only way. Always be open to change and seek better ways to work together as a team.

Great MVPs Don’t Have Any Code

It isn’t etched into a holy tablet somewhere that Minimum Viable Products (MVPs) need to be made by writing code. You can achieve the intended outcome of an MVP, validating that an idea or hypothesis is true, by building something physical or by performing calculations in a Google Spreadsheet, or Google Form.

Ideally your MVP is the minimum amount of effort that you need to exert in order to confirm (or disprove) your hypothesis. If your hypothesis is correct, you now know that you’re about to build the right product.

A Symptom of a bad MVP is a product that is heavily code intensive, involves a lot of engineering overhead and usually involves hacks or shortcuts taken ‘because it’s just an MVP’ which end up becoming key to the final product. Meaning accruing tech debt before the product has started. If you can validate your hypothesis without code, you’ll be more likely to start from a solid foundation and be setting yourself up for success in the long term.

Involve Engineering in the Design Process

Designs and interfaces should not be created in isolation. Not all designers know how to write code, not all designers understand network requests, asynchronous patterns, code reusability, UIViewController Navigation hierarchies or other engineering specific knowledge. This is exactly why engineers should always be involved in the design process. A design should not be considered ‘ready to be implemented’ until an engineer has validated that design from an technical perspective.

Agile is not a thing you can hold, or touch or see.

Working in an Agile way is not about conforming to a strict set of standards. It is not about fulfilling an ancient prophecy inscribed in some ancient manifesto. It’s not something you pay money to be certified in, where you can spread the good word across the lands and prophesize to its greatness.

It’s breaking complex tasks down into manageable pieces and encouraging product teams to work comfortably in an environment where change is an inevitable force.

Agility is about achieving a way of working in which you are constantly re-evaluating the ways in which you are working. It’s breaking complex tasks down into manageable pieces and encouraging product teams to work comfortably in an environment where change is an inevitable force. It means different things to different people, and you will find that what works for you in one team will almost definitely not work for someone else in another team.

Agile is not a thing you can hold, or touch or see. You are not Agile.