Given the feedback on the original article, I thought it worthwhile to post an update which includes some new ideas and approaches gained from our own team and from those who have commented and emailed me as a result of that original post.
So, before I jump into the questions, here are some variations that we have successfully trialled and adopted in our own team very recently.
They follow some really good, constructive sprint retrospectives in which we identified that we were a bit too inwardly focussed. Retrospectives really are a golden opportunity to identify and try new things if you are prepared to recognise them.
Have your daily stand-ups on customer turf
Literally. You need to ask permission obviously, but I doubt they’ll refuse. This act symbolises your committment to the project, the associated business processes and all the non-IT aspects of what you’re doing. You will have access to people who wouldn’t ordinarily come along to your daily meetings and you might well have a few of them dropping by just to see what its all about. You’ll find out things you couldn’t have known and which could save your hours or days. Plus, its fun, you get to talk to the real people and build real relationships with them. Scary huh?
Email your stakeholders with a summary of each retrospective
We do a ‘What Went Well’, ‘What Didn’t Go Well’ and a ‘What We Will Do Differently Next Time’ whiteboard summary after each sprint. A snappy bulleted version goes to our executives and interested stakeholders. Sometimes it is ugly reading but we preface it with a statement about how we do this in the interests of identifying process improvements and striving to deliver to their goals as effectively as possible. No one can argue with that and we have only had positive feedback on this approach so far.
Rotate the Scrum Master Role
Obviously this hinges on having sufficient people in your team who can and will take on the role but it is just that, a role. It has nothing to do with management or seniority. There might be a few raised eyebrows outside your immediate team, but generally they will be from people not used to letting go of the reins so a little education and communication here will go a long way. With a team like ours where we just can’t afford the luxury of a full-time dedicated Scrum Master, this works really well. It also helps in the shared understanding of what we are expecting of each other and this in turn can only benefit the team.
To follow up on the comment posts…
Could we use this approach (Scrum) as a consultant?
Absolutely! I can’t think of anything more compelling than a consultant who gives me an option to call a halt, change the scope or rejig the priorities at the drop of a hat. If I were still consulting I would definitely be offering this in the shopping list of options. It takes a little education again and I suspect the burndown chart will need a little introduction if it is to replace the Gantt chart but that is well worth investing some time in. Abdel points out that without a plan this might be a harder sell, but you can still have a plan, indeed you might invest a half sprint or mini-sprint in developing the initial backlog to give your customer some comfort in the approach.
Is there cross-skilling or do people tend to stick to their traditional roles?
Again, due to the size of our team we all pretty do whatever we can and the breadth of our abilities widens each day. We are generalists, we do a lot and we realise we probably don’t do what we do at the precison level of a specialist but we have a lot of combined IT experience in our team and work in an environment where learning is actively encouraged and supported. That also makes life more interesting, keeps our skills up to date and ever-growing and, to be frank, makes us more employable.
