Random bits of advice from the scrum masters in Futurice.
Do retrospectives
Get competent team members
Continuous integration from day one.
Use Flowdock or similar tool for digital communication not Skype
An endless backlog is waste
There is no value in tracking all bugs. It is ok to forget a bug which was not important enough to fix right away.
Pull request are a good way to manage peer reviews
We like peer reviews
Definition of done. Have one.
If you are faced with a distributed team rotate people so that everybody personally knows and regularly works with all team members/PO/SM face-to-face.
Shorten sprint length if the scope doesn’t seem to be stable.
If the sprints are unstable, but you have a very stable flow you can consider switching to Kanban.
To reduce a story in size ask what is the value of the story is and how can we deliver 80% of that value (in a shippable way of course).
- To reduce more, get inspiration from e.g. a printed Splitting Story Flowchart.
Don’t release on Friday.
Create a table which shows who is present and who isn’t for the coming week
The daily standup shall not exceed 15 minutes, unless you decide its ok of course :) (Don’t decide too often, and only for learning purposes so that future Dailies are less than 15 minutes)
To keep a daily short, don't discuss in depth, save that for after the daily.
An alternative for daily standup (what did/will I do) is what did I learn, what do I need to learn today and how you can help me
A second alternative is 1) What do others need to know about the things I did yesterday, 2) What can I get from, or how can I collaborate with others to get things done effectively today, 3) What is blocking my effective work?
The Scrum Master should have time to observe (eg not busy with 100s of tasks)
A good PO is very important. Take some time in the beginning of the project to identify the constraints the PO has in terms of availability to the team, authority to make scope and budget decisions, domain knowledge, access to stakeholders.
Weekly smiles (sharing your mood) within the project team are good
On site is the best place to do a project
Index cards are great for planning sessions, any digital tool sucks.
Agile is a mindset not a rigid method.
You can break any rule if and only if you understand why the rule was there in the first place.
The team should own the tools it uses.
Any tool that forces a process on the team limits the capability of the team to optimize creating awesomeness
Minimize the time and effort needed to make a release
Specification by example → automate them
Pair-work
Treat ALL specs as speculation
Estimations are not commitments, they are estimations (i.e. just guesses, predictions)
face-to-face constructive feedback is good (5 minutes between all team members twice a year)
See also about Futurice's agile services here.
Peter TennekesAgile Coach
