Development process is a game with its own stakes, rituals and actors.
Based on Standish research only 16.2% of such games are finishing with everyone happy: scope delivered fully and on time.
To understand why the percentage is so low we need to understand who are the actors and where they could do well or bad in the game.

In Scrum-like software projects there could be such actors.

Project/product owner - a person who is directly interested in a success of a product, he should maximize the value of the product.

  • management backlog
  • product vision
  • prioritization

Good patterns:

  • establishing good communication channels with both stakeholders and developers sides
  • ready to negotiate scope and priorities
  • being precise, clear and consistent

Bad patterns:

  • often missing or being non-available
  • not trusting Dev team
  • not speaking with customers
  • not giving clear acceptance criteria

Project manager - a person who should coordinate all parties involved in a project, works closer to project/product owner

  • coordination of all parties
  • building communication channels
  • managing risks and deadlines
  • building a clear plan for a project

Bad patterns:

  • meetings are broken: bad agenda/timing/meeting minutes/too much of meetings
  • doing self-promotion
  • not keeping promises
  • poor listening
  • poor delegation
  • lack of knowledge of team's posibilities

Scrum master - is a manager, helps team to do "How" part and not "What" part
are well described at Scrum resources
Good patterns:

  • keeping everyone focused on goals set
  • staying neutral and unbiased
  • keeping everyone from team engaged

Bad patterns:

  • replacing project manager or product owner: conflict of interests
  • not understanding of what focus is
  • skipping helping organizations with Agile transformation
  • being just a secretary, not actively involved
  • not being recognised by a company

Business analyst - a person who writes and creates requirements/documentation
Responsibilities: depends on a project, mostly they are helping project/product owners to make their thoughts materialised in documentation.
Good patterns:

  • constantly learning
  • being pro-active in discussing requirements
  • understand well development process
  • keeping things structural

Bad patterns:

  • document everything in deep details, not doing design
  • being passive in discussions, not curious
  • working by templates, not being fluent
  • putting processes over customer's experiences

A non-zero sum game

Everyone should act as a team player.
Any personal ambitious could cause lost of trust or broken communications.
There should not be rock-star developers or managers.
Ideally, everyone should share the knowledge and expertise he has with team members.
The processes should be clear and transparent. could help managers to understand their developers better.
Contact me and I will tell you how you could improve your management process for your development team.
You may send us an email or contact via Linkedin.