2) Make sure someone on your team has experience practicing agile. Ideally the product owner or the Scrum Master. Look for a coach if you need some help.
3) Good reason to go agile – “requirements change” and there’s “too much time wasted on junk”. Also see my post on why stories work where requirements documents fail.
4) Need help on story writing? Stories are not exactly use cases or tasks. They must answer “As a -who- I would like to -what- so that -result achieve-“. Also see writing good user stories,
5) Daily SCRUM “Commitment and accountability, say what you do, do what you say, whole world is invited” – I would add “transparency”.
6) Contrast the sprint retrospective with the classic ‘postmortem meeting’. Think about it. Your technologists meet after each sprint and talk about process improvement.
7) Let the team estimate in ‘ideal person days’ or ‘story points’. It doesn’t matter what’s used when you start, but it is important to get the team started on some metrics.
8) Don’t expect to have things perfect when you start; a perfect product owners, scrum master, or even a backlog. Every organization I know practicing agile has to fit the roles and practice to the business, organizational, and technological dynamics.
9) Work board and stickies are important because these tools help the team prioritize and communicate efficiently. But balance these with technological tools even if they are simple spreadsheets. The tools help with transparency, metrics, and developing a history.
10) SCRUM is sometimes reduced and oversimplified to project management of a fixed cost, fixed time line, variable scope project. Don’t make this mistake. You’re leaving out the key social dynamics of the process that make for agile success stories.
Leave a Reply