To use Scrum, you arguably need to apply it wholly. However, some practices are not unique to Scrum: practices all teams can benefit from.
It might also be an eye-opener for people, making them more inclined to turn fully agile. I recently switched from a project doing Scrum to a team with no clear project methodology or framework: the change in the level of communication and willingness to change and improve was striking. I think these three things alone would go a long way to improve the situation.
So, here is my list of three things I believe all teams can apply successfully.
1. Synchronization Stand-Ups
One Scrum trademark is the daily stand-up. A 15 minute meeting where team members share what they've been working on, what they plan to do next, and if anything stops them from doing their job.
All teams benefit from daily synchronize stand-ups: not only Scrum teams. Daily synchronization meetings help
- Focus on relevant, prioritized work
- Spread knowledge and avoid duplicated work
- Raise and solve problems together
Additionally, holding these meetings daily help nurture face-to-face communication. Standing up is key to stand any chance (no pun intended) of keeping the 15 minute timebox.
2. Regular Retrospectives
In many projects lessons learned sessions are held sporadically or at the bitter end. This is too seldom.
One risk of waiting too long between retrospectives is that the list of potential improvements has grown to an undefeatable beast that is banished to the archives.
Another risk is that project members never have a chance to implement changes, and experience the effects.
3. Abstract Assessments
Estimating in abstract units such as story points effectively separate what from when: two different questions altogether.
It is easier to relatively compare things (A is roughly twice as big as B) than to give accurate absolute estimates (A is 20 hours and B is 35).
When you are asked to give an ETC (Estimated Time of Completion), no matter how futile, you're as bad off estimating relative size. However, as you learn more and go about refining estimates you're better off.
With relative estimates you don't have to start from scratch. For example, if you find out that all tasks take longer than you first expected (a systematic error) your estimates are still valid. You only need to change the ETC.