|I don't expect everyone, or even a majority, of readers to agree. These are things I wish every Business Analyst (BA), Product Manager (PM), Scrum Master (SM), and Product Owner (PO) could know and take to heart.
1 - Developers are not assembling widgets on an assembly line. Adding more developers, especially after the start of a project, does not speed things up. In fact, it usually slows things down and delays delivery.
2 - Developers, and especially software engineers/architects, are professionals, not blue collar workers. Treat them like professionals, and expect them to act like professionals.
3 - Team leads for a project should be a senior software engineer with people skills, not a BA, PM, SM, or PO. And certainly not QA.
4 - Look at each project like a bus. Lots of different skills are going in the same direction, to the same destination, but there is only ONE bus driver - the Team Lead.
5 - Limit yourself to describing, in specificity, what you want (requirements), not how to do it. Leave the technology choices to the developers and engineers.
6 - Make time for thorough and detailed planning up front (epics, features, user stories, tasks, etc.), with most of those documents fleshed out by the Team Lead and whomever he or she chooses. Then be agile enough to revise as needed during the project.
7 - If coding has started, and the user stories are still ambiguous, then stop wasting developer resources ($$$) and finish the planning.
8 - Keep meetings to a minimum. Ideally, on Monday or Friday, meet with the leads and developers to look at what was done the past week, what is still being worked on, and what is needed to be worked the coming week. Then leave the developers alone and let them go "heads down" coding. That delivers a better result faster.
9 - A well-managed development team converses peer-to-peer when necessary, without need for a meeting. If a problem arises that developers within a team cannot solve, they will contact the team lead, and if the scrum master's help is needed to get outside resources, it can be handled then.
10 - Deep-six the daily scrum "stand ups". They are not needed, and only slow down work.
11 - If you cannot get rid of the daily "stand ups", at least understand what they are. The phrase "stand up" does not refer to actually standing up, like a bunch of little school children. It means to stand up your work before the team for examination and discussion.
12 - Don't go to developers directly without coordinating with the team lead first. Developers on a team need to be coding, not spending time so you can get some data bits for a report. In most cases, the team lead will get what you need.
13 - When a developer is interrupted for meetings or questions not directly dealing with getting code done, it takes anywhere from 15 minutes to 2 hours for the developer to get all the moving parts back in their mind so they can pick up where they left off. Software development is a complex work that takes a lot of intellectual horsepower.
14 - When deciding "we need a meeting" that interrupts developers, calculate the total cost in labor, and ask yourself if the cost is worth what you get out of it. Consider a team of 8 developers and one team lead, at an average labor cost (salary, benefits, etc.) of $100/hr. Your 1 hour meeting just cost $900 and delayed the project by at least 2 hours.
15 - An experienced team lead with business experience and able to describe the technical in non-technical terms can easily reduce the cost of a development team by replacing most, if not all, of what a BA, PM, SM, and PO does. And get it done better and sooner due to lack of overhead. If is far easier for a senior software engineer to learn the business side than for a BA, PM, SM, or PO to learn the software development side.
16 - Agile, Scrum, Kanban, agile frameworks, etc. are not recipes to be followed. They contain principles to be considered and used in the SDLC if and how they provide value. Just read the original Agile Manifesto and see how far today's agile has strayed from it.
17 - Look for generalists, not specialists, on the development team. Hiring specialists (those who work in the specific toolsets being used today) works for now, but not as technology changes. Hiring generalists (those who know software engineering but can adapt and learn whatever toolsets are in use today) gives you people who can efficiently adapt as technology changes.
18 - If you want to learn one new thing, learn what value engineering is.
These opinions are solely my own, and not necessarily those of any current or past employer.