Interview with a developer turned Agile
Following last week’s interview with a newly-minted Scrum Master this week I have had a conversation with developer Mateusz Udowski. We talked about how SilverStripe’s adoption of Agile and Scrum have affected him and why he thinks SilverStripe is now more intelligent as a whole than it was before.
Mateusz, what was the most interesting thing that happened during the change? What was the most surprising?
I was expecting we would have problems with completing less exciting tasks such as testing, but that didn’t happen. Shifting the responsibility from individuals to the group gave space for everyone to work efficiently.
Also, we needed some structure and after we started working as a team we began to collaborate and everything seemed to fall into place. I think the main reason for our success was that the team members regarded each other as peers.
What's different now?
The biggest change is that there is no penalty for helping each other out anymore. The budget is relevant on the team level, but not on individual level, which means we can share problems and solutions.
One can clearly see what to work on now, and what needs to be worked on next. Tasks and impediments are clearly visible and are not being swept under the carpet.
Reducing the size of the team from 40 (whole company interacting semi-randomly) to 7 (Scrum team) makes it easier to work together, mainly because we get the chance to learn about and respect each others’ strengths, weaknesses and habits.
What is your day like now versus before?
Less stressful. It's possible to get more work done because we can focus on tasks and clearly see at any moment where we are in the sprint and in the project.
Folk wisdom has it that when you force a person's brain to focus on many things in parallel, their IQ falls considerably, and that's how it feels now - less chaotic, more intelligent.
What are you more more confident about now?
It's easier now to apply creative solutions and "refactor fearlessly". We have shifted from delivering at all costs to delivering high quality products up to capacity. Peer reviews, test coverages and testing by many people all contribute here.
It is possible to enhance how the team works both technically and from a process perspective. We can now build on top of what we have achieved in previous iterations because there is a "we" - a stable team.
What did you have to learn? What was the hardest to learn?
Not to tell people what to do and how to do it. It never worked well anyway. The other important ability is to be able to discern when is the time to say "no" to factors that would break the Scrum process.
How do you think you benefitted from working with a coach?
I've seen many of these Agile elements previously in different combinations and contexts, but never all put together.
A good coach will give you the confidence to apply all these principles now, immediately, and to achieve good result. Otherwise we would probably be stuck in the step-by-step approach which would stop halfway through and ultimately fail.
Pointing out the future possibilities is also helpful, showing that it's not the end of the road.
What's been in it for you?
There is more room for error and to try things out, hence more is possible. Short feedback loops and peer reviews provide a platform for learning and a cushion for failure.
Would you recommend Scrum and Agile to others?
Yep, without hesitation.
Conversations like these remind me why I love being an Agile coach. Whether the context or flavour is Agile, Lean, Systems Thinking, Scrum or Kanban (all very good things) - what it really boils down to is to make people’s working lives more enjoyable and purposeful and to create an environment where people are trusted to make decisions and have the freedom to succeed.
Mental note to self: Re-read this interview when I get frustrated with process, command and control and factory thinking.
Interview with a newly-minted Scrum Master
Six months ago SilverStripe, an open-source Content Management System provider and Wellington web agency approached me to help them improve the way in which they deliver client and open source projects, increase employee happiness and, in general, just do the best possible job. To achieve this, we decided to move away from the existing Agile-like (fixed scope/fixed price) approach and introduce Scrum with its focus on client-driven iterations, early feedback and continuous improvement.
Silverstripe have asked me to interview some of their staff about the transition to Agile. The original posts can be found on Silverstripe's blog (Sam Minnée, Aleksandra Brewer), below are selected highlights from the interviews.
It has been interesting for me as a coach to learn how people experienced the changes including the biggest surprises, differences, and how they found the changes working out for them.
Today’s conversation is with Scrum Master Aleksandra Brewer. Alex works with one of the Agile teams at Silverstripe and has likened working with me to a visit to the dentist.
Alex, what was the most surprising thing that happened during the transition?
Some of the surprising (although maybe obvious) things were that (1) it's possible for more than one person to work on the same user story, (2) work goes faster when people collaborate, (3) sprint planning that results in greater understanding of stories and tasks necessary to complete them really speeds up the work during the sprint - everyone knows what needs to be done and can pick up a simple task and complete it.
What's different now?
I love being able to see the day to day progress of the team - it's so visible on the board, plus the work seems to be going faster, with several people going through small tasks all the time. With the acceptance criteria being defined and discussed before the start of a sprint, and with the Product Owner being available to answer any additional questions and provide feedback throughout the sprint, there is virtually no possibility for any team member to go off on a tangent.
What are you more confident about now?
Talking to clients is easier now, as they are much more involved and ultimately responsible for making decisions about priorities. We (the team) make recommendations, share our knowledge and inform the client about pros, cons and consequences of the different options, but in the end it's up to them to make a final decision.
All along the course of a project clients know exactly where we're at, what's being built, etc., which they love. The transparency of Scrum, although scary at the beginning, is really beneficial for both the team and clients.
What did you have to learn? What was the hardest to learn?
The hardest thing to learn was to give up the control over what the individual team members were doing from day to day.
How do you think you benefitted from working with a coach?
Working with you has been a bit like going to the dentist - painful at times, but all along I knew it was good for me, and I'm in better shape now than I was before. It's been good to have you keep us on track, and point out things that now seem obvious, and yet were not at first.
Would you recommend Scrum and Agile to others?
Definitely. I couldn't imagine going back to the old ways, negotiating "resourcing" among Project Managers, developers being on several different projects at the same time, and not knowing when a project would end because of the uncertainty of developer availability.
Conversations like these help me put my work into perspective: They show me where I can improve as a coach and help me be a bit less perfectionist and appreciate that, even though we are not perfect, we have come a long way and I have helped make some people's working days a bit more fun and satisfying.
Next week I will talk to Mateusz Udowski., a developer at Silverstripe.
When the Coach Needs to Go
— Nanny McPhee (via Lyssa Adkins)
I am an Agile coach and the goal of my job is to put myself out of a job.
My mission is to teach people Agile and to make sure they understand and correctly apply Agile values, principles, frameworks and techniques. This is quite a big deal as Agile often forces us to change the way we work on a daily basis; how we organise our work, how we collaborate, which tasks we perform and how we communicate with each other and the rest of the organisation.
Adopting Agile is quite an intense process, especially because it involves so much behavioural change. To make matters worse, learning does not progress in a linear fashion, it is more of a “two-steps-forward-one-step-back” process and it takes time. It is frustrating, painful and rewarding and as a coach it is my job to guide people through this experience.
It is also my job to know when they are ready to take off the supporting wheels and to work on their own. It is my responsibility to recognise the point in time when they are safe to fly and let (sometimes force) them to do so. If I’m still coaching the same people after two years or things unravel when I go on a 4-week holiday I have made people dependent and have failed as a coach.
So when am I done? When have I succeeded? Hard to say when you’re dealing with a process that has continuous improvement and therefore no end point at its core but I know for sure that I have succeeded when things not only work without me but keep improving after I have left.
I’m proudly leaving my current client. I won’t forget to tag off.
10 Ways to Fail with Agile
Last week I presented at WebDU in Sydney. The conference was excellently organised by Geoff and the Daemon guys and I met lots of interesting people. And I love Sydney! In short I had a blast.
Apart from a workshop on user stories I presented on 10 ways to fail with Agile. Judging by the Twitter stream my presentation about the most common mistakes and pitfalls during Agile adoption and how to avoid them has been well received (okay, they also tweeted I looked like Starbuck in Battlestar Galactica Season 1 ;-)
As promised here is a version of my slides which more than just pretty pictures ...