A list of principles I think will benefit any kind of team — even if waterfall is your thing.
Lately there’s a lot of hype around Scrum and everyone wants to be agile but even though I really enjoy working following the Scrum framework, when someone asks me if his company or team should adopt it, my answer is always: it depends.
While studying for the scrum.org PSM I exam, I noted down some key takeaways that I think would benefit any kind of team, regardless of the embraced PM process and now I would like to share them.
This post is not meant to define a “Scrum light version” or this kind of things. Scrum is a framework and either you are fully using it or you are doing something else.
Here’re a collection of some basic Scrum concepts that in my opinion are applicable to any kind of team – no matter of the chosen project management methodology.
A well-motivated team is not only high-productive but also provides valuable insights to improve the product and to help the management in the decision-making process.
Maintaining the motivation high across the whole project life is probably one of the hardest challenges of a project manager.
What motivates teams?
- Autonomy – people don’t want to feel observed and/or controlled.
If all the decisions are bottlenecked by a single entity, the team members will just wait around for a permission-to-do-something instead of moving the project forward.
- Empowerment – no one likes to take order.
Team members like to be involved in the decision-making process and since they are the experts in their specific area they hate when someone tells them how to do their job.
- Feeling involved
People want to work on a project they care about and to do actual useful work instead of wasting time working on tasks that are not really needed.
One of the Scrum basic principle is self-organization: team members choose their own tasks and figure out how to best accomplish them.
In this scenario there aren’t bottlenecks and nobody gives order or control people, the team members feel empowered and as a result they will also feel more involved in the project.
2. Value-based prioritization
Human are bad at multitasking and doing multiple things at once will not only reduce the quality of your work but, as a Stanford study shows, may even damage your brain. That’s why a team member should never work on more than one thing at a time.
When everything is urgent, nothing really is.
If someone (management, stakeholders, customer, etc.) needs something urgently as project manager you should always clarify the priority of the task and if it is really critical you need to make sure all the involved authorities understand that in order to start working on the new task, the team must postpone his currently activity whose completion will be delayed.
3. Definition of done
Take this scenario: the PM explain the goal to the team and everyone is ready to work on something for the days to come. From time to time the PM asks the team if everything is fine and it looks like the task is going to be complete in a week. After a week the PM inspect the outcome of the task and noticed something is missing.
In order to prevent this kind of issues, it is critical to define, for each task a clear definition of done (DoD).
A DoD is a checklist of activities that must be performed to consider a task completely done (e.g.: write documentation, add unit tests, perform regression tests, etc.).
A clear definition of done not only ensures that there aren’t misunderstanding like the one described before but also help the team to estimate the time and/or resources required for the completion of a task.
Since the list is not fixed but entries could be added over time, it is also a powerful tool to improve the quality of the product.
4. Time-boxed meetings
A time-boxed meeting is an event that has a fixed duration that must not be exceeded.
Define a short-enough time-box for an event will make sure everyone is focused on the meeting subject and that team members can better schedule their activities without worrying about never-ending meetings.
5. Invest some time to stop and adjust your sails
Sometimes we’re just too busy working to raise our heads and inspect how we work and what we could improve. That’s why Scrum defines fixed events of inspection and adaptation.
The inspection is not done by an inspector or an auditor but by the team members.
It is possible to inspect:
eg: something the team would like to change and/or improve.
eg: a feature has been released when it wasn’t ready yet.
eg: two team members don’t get along very well.
Based on the result of the inspection the team should adapt deciding some action points like adding some new entries to the definition of done, improving the internal communication and so on.
That’s all folks!
What about you? What Scrum concepts do you think will benefit any kind of team?