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
- establishing good communication channels with both stakeholders and developers sides
- ready to negotiate scope and priorities
- being precise, clear and consistent
- 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
- 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
- keeping everyone focused on goals set
- staying neutral and unbiased
- keeping everyone from team engaged
- 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.
- constantly learning
- being pro-active in discussing requirements
- understand well development process
- keeping things structural
- 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.
Efficiefy.io 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.