Scrum: A Year in Review

It was early October of last year that we took the first steps towards adopting Scrum and undertaking the challenge of becoming more agile.  I figure this is a good time to review the year, the progress we’ve made, and the challenges we still have to overcome.

Original intentions

My original intentions with Scrum were to adopt a methodology that forced issues to the surface and gave us some flexibility in dealing with them.  Specifically, I felt: (1) my staff weren’t working together as well as they could, (2) we had serious quality issues with our applications, and (3) projects lacked visibility with the business.  I think that these were largely symptoms of underlying issues, and I hoped Scrum would allow us to bring those issues to the surface and deal with them.  So …

How did it work out?

Are my staff working better together?

Definitely.  There is a greater appreciation for each others’ roles.  We’ve largely eliminated the perspective that work can be thrown ‘over the wall’ (i.e. requirements over to development over to QA) with no interest in how others do their job.  There is a greater focus on the team and accomplishing something together.  And no one works in isolation with no understanding of what the person next to him or her is doing.

But we’re not quite there yet.  From my perspective we’ve come maybe 50% of how far I’d like use to go.  I’d like to see more critical thinking and discussion, and still more of a focus on the team.  I’d also like to see more thought going into and a stronger commitment to the sprint goals.  But there is no doubt in my mind that the Scrum framework can facilitate improvements in team work, and with my staff I think it will continue to do so.

Has quality improved?

We get some positive marks here, as well. Code coverage and documentation is probably five or ten times what it is in our legacy, pre-Scrum systems.  Regression bugs (i.e. those that crop up outside the execution of a story) are rare — maybe one or two a month.  As we are about to put the first piece of the system into production, I have great confidence that it should be essentially bug free.

But we still need our test coverage to be higher, and we need the quality of our tests to improve.  The team is still weak on Test Driven Development (TDD).  While we are making improvements, our focus on quality must continue to grow.  Again … we’ve come maybe 50% of how far we should go.

Has visibility increased?

In this area we’ve made incredible progress.  The quantification of user stories (we estimate using t-shirt sizes but I convert them to numbers) and the use of Version1 to manage our backlog have provided the project team and leadership with an unprecedented view in the project, our progress, and where we have to go.  In addition, Scrum has given us the tools to work more closely with the business, with stakeholders (not just the product owner) joining us for planning meetings and stand-ups.  I think their perspective on the work we do has changed … and just maybe become a little more sympathetic to the challenges of software development.

My Lessons Learned

Changing peoples’ perspectives is hard

You can never underestimate how hard it is for people to change their perspectives.  This has been one of my biggest challenges — getting my staff to see their jobs and our systems (products) from a different perspective.  My perspective on their roles has certainly changed: it’s clear to me know how important it is to have staff who aren’t just coders, who can see the big picture, who have good judgment, and who take it upon themselves to learn continuously (and not just about the latest technology).

I have definitely seen a change in all of my staff, but I have to admit I’d like to see more.

Training is critical to make a change like this

This is an obvious one, but I’ve learned it nonetheless.  Unfortunately we undertook a change towards Scrum just as the financial crisis hit, and as a result I had very little resources to train my staff.  Specifically I would have got them training in Scrum, and at least a class on test-driven development.  I also would have liked to have money to send them to conferences (specifically the annual Agile Vancouver event).  If I were to undertake this again at a different company, a lack of sufficient training funds would be a non-starter.

Get your systems in place first

By systems I mean proper development and test environments, build servers, et cetera.   It’s been a year and we’re still building out some of the infrastructure we need to be really agile (like a proper user acceptance testing environment).  I’ve read discussions of the value of a ‘sprint zero’, which is used to set up all the infrastructure.  For us, we could have taken use a sprint zero through two or three to get it all set up.  It has impeded us at various levels since day one.  (Although, admittedly, we didn’t know everything we wanted or needed when we started, and some of his has been dictated by how the project has developed.)

Managing expectations is critical

Typically I’m pretty good at this, but there’s always room for improvement.  I was the one who sold Scrum internally, and in so doing established certain expectations with my bosses concerning what we could accomplish.  While I’m sure they see the value, I should have spent more time educating them on what we were doing and what they could expect from it.  I should have managed expectations better — but I was walking the fine line of selling the change enough that they’d buy in, but not so much that they’d think this would be a cure-all.

What’s next?

I have a few goals for the next six-to-twelve months.  As the team matures and our processes continue to stabilize, this will open up opportunities for additional improvements in how we work.

A greater focus on quality

From day one I’ve told the team that quality is non-negotiable.  That said, if everyone isn’t on the same page as to what quality means, it becomes negotiable anyway (we did define it, but there’s always room for interpretation).  We have recently improved the metrics we use and will take more proactive action with these metrics in hand to increase system quality.  This will involve some more learning within the team, and definitely some greater discipline.

Lean development

I recently read “Implementing Lean Software Development” by  Mary and Tom Poppendieck and it was awesome.  I had looked into lean concepts before, but it didn’t really seem to fit where we were as a development group (in other words I don’t think we weren’t ready for these ideas).  With a year of Scrum under our belts, now is the time to start maturing and getting a better understanding of some of the valuable ideas and practices lean offers.

Scrumban

This is related to lean development, but it involves more process changes to how we approach our work.  I see the value of continuous flow, but I don’t think the team or the company is ready to go there.  In six months, maybe … .  I definitely see this as a natural progression from where we are today.

Stepping Away

From day one I’ve acted as the ScrumMaster.  As the department director I’ve known this goes against best practices — managers shouldn’t be ScrumMasters.  Given our company culture, as well as resources we had at hand, I chose to take on this job anyway.  I think I have been reasonable successful, although I have plenty of examples of where my position has caused problems.  I will be stepping away somewhat, letting another team member take on many of the responsibilities.  I still plan to be involved from more of a coaching perspective — I probably still have the greatest technical knowledge of Scrum — but I won’t be as involved on a day-to-day basis.

And that’s all …

The past year my perspective on software development, team work, and project management has changed dramatically.  Scrum is good.