The not-so-Scrum Scrum team

When I started with Granify, I was put into a team where there were a few responsibilities:

  • Onboard & support clients
  • Build internal tools
  • Work on smaller tasks in the larger domain

The idea was that through doing these steps, myself and 2 other recent grads, under the direction of a Software developer who had been with the company for a couple of years, would learn enough of the domain to be able to work in any area.

I quickly spotted an issue. There was no process for getting any of these items done with any priority: support was naturally “asap”, tools were “is it ready yet?” and smaller tasks got the “how’s it going?” treatment. There was a chaotic mess of task switching.

Naturally the first step was to decide to do a support rotation. Every week 1 of the 4 of us would be dedicated to support. No task switching. If more hands were needed, another could jump on temporarily. Otherwise during “support downtime”, this person was free to work on smaller tasks of their own choice, explore the domain or do self-improvement and education.

For the other 3, they would be dedicated to tools. In a small team comprised of three developers, where expectations were “Just learn, write code and do what you can”, having no process was a little difficult.

My experience and enthusiasm for agile resulted in it seeming like a great idea to implement Scrum as a process in order to work on our current tool. I knew it was going to be difficult, not be a real or full implementation and likely doomed to fail from external sources, but I wanted to try it. We got through three full 2-week Sprints before the team was disbanded to be integrated into the larger teams.

Here are my key takeaways:

  • Scrum works best when everyone buys in. Even if you have your team fired up and ready to go, listening, learning and embracing it, if you have a manager who does not buy into the idea, it is guaranteed there is going to be friction. This is especially so if they feel you are pushing for their role in leading. (This was not the software developer within the team, but an external management of a larger group and us tacked on).
    This could also be known as: “The Importance of Change Management” lesson.
  • Being a fresh developer, pseudo-scrum leader and all-round new face to the business means you get attention from those curious about what you are doing. Even if they believe the task will fail, good mentors will allow you to fail when there’s something to be learned in a space to do so.
  • Meetups like Agile Edmonton are fantastic learning resources and supportive venting grounds to better yourself, your team and get non-biased input from those with more and less experience than you. (I sometimes attend and facilitate this event every 2nd Tuesday at Startup Edmonton).
  • Humility and listening to others is key. Working with other fresh developers, we were all stumbling through our first steps with the business, working on the process and finding pain points of our setup and trying to make a good impression. Without being able to step back sometimes and say “How am I doing?” to each other, I believe we wouldn’t have been able to produce something we’re at least a little bit proud of today and become better developers working in our current teams.

The tool we made during my brief time as a pseudo-scrum enabler never got much use in the end (the nature of changes to the larger business process meant it no longer had a need). For ourselves, while we were developing it was instrumental in helping us support clients and so I still take it as an experience learned and cherished.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s