Eleven Things You Can Do To Annoy Your Development Team

While one of the goals of Agile is to get the development team closer to those who use the product, the behaviors and decisions of those ‘calling the shots’ can still be confounding to the people writing the code. This middle layer of executives, marketers, product managers and designers is there to grapple with the wide assortment of moving parts that go into running a product-driven company, satisfying investors, and, hey, while we’re at it, making sure the product is something users actually want to use.

In the process of managing this mayhem, it is not unusual for decisions to be made that are, shall we say, a bit mysterious to those who weren’t in the room when the call was made but none-the-less have to deal with it’s consequences. If the pull-and-tug of these competing priorities isn’t enough there are plain and simple process events that only add to the complexity for software development. As a product manager here are some things you should avoid if you want to make life easier for your dev team.

  1. Friday night deployments – Look, you know if something can go wrong, it will. So why risk getting on the bad side of your team before the weekend? Schedule deployments so there is time to make fixes without killing someone’s dinner reservations.
  2. Business/product jargon – Learning the language of the customer, business sector or product can be time consuming and confusing. Have you ever worked on a project where there were five terms that meant essentially the same thing? Create a glossary of commonly used terms and make sure everyone knows where to find it. If possible, standardize on single terms instead of multiple and use them in the context of team communication.
  3. Unbalanced workload (too many or too few developers working on one feature) – This is probably happening if your process is inconsistent or just started, or you’ve cherry-picked the steps you’ve chosen to implement, leaving holes in the planning process. Maybe your Sprint planning sessions are a little light in terms of level of detail. Make sure everyone feels comfortable raising questions and working out unresolved issues around stories so they are properly scoped and estimated.
  4. Too much process – While the purists among us would say, “Oh, you’re not really doing Scrum unless you’re … (fill in the blank). The point of Agile is to build a consistent software development practice that is responsive to the needs of both the customer and the humans creating it. Work with your team to find the right balance between too much and not enough process. As your team’s capabilities grow, continuously review and refine your process based on feedback from all constituents. If this turns out to be pure Scrum or XP or Kanban, great. If not, don’t worry about it. The results are what matter most.
  5. Keep things under wraps too long – Another balancing act is knowing when and when not to bring the development team into the planning process. Or more to the point: how early. Some engineering managers I’ve known want product management to avoid interrupting their engineers so as to maximize throughput on the current Sprint. However, most engineers I’ve known want the opportunity to weigh in on the work that’s coming. Often times, they can offer valuable suggestions that will make the product better. Work with your engineering manager to find the right balance.
  6. Ambiguous requirements – One of the challenges of any software development methodology is determining the right amount of detail to work out ahead of time for each feature. It can get especially confusing if you’re new to Agile as it’s easy to take the ‘working software over comprehensive documentation’ clause too far. The problem with comprehensive documentation is that it’s almost always out of date by the time the feature is delivered. The problem with not enough documentation is that it leaves too much up to interpretation on the part of the developer. Between the user story, the wireframe and/or mock (if applicable), and the test cases, the developer should have enough information to engage productively in the collaboration process and get at the intent of the feature.

Ok, so we went for eleven things and only got to six. Next time, we’ll do a better job of scoping the blog sprint! Truth is, we only picked eleven because it was one more than ten! Just goes to show: more isn’t always better!