Agile Dev Stuff

Well, its certainly been a while since I’ve posted here and a lot has happened in that time. I’ve had a baby, took a years maternity leave, came back for a while and then started a new a job.

My new place is just starting down the agile road and I’m finding it a fascinating process to start it all over again. Although I’ve only been there a few months now there’s quite a few little insights that I’ve found interesting as a second-timer.

1. My past experience does not make me an expert

A fairly obvious one, perhaps, but still worth mentioning. There is not just one right way to do Scrum. Over the years I’ve built up in my head an ideal way of how I think Scrum should work but that does not mean that any other way of doing it is wrong. Yes, I’m entitled to have opinions and to share them but the goal should really be to collaboratively decide what works for this team and this company.

2. The road to true Agile development is a long one

I seem to have forgotten just exactly how long it took for my previous company to really get into a groove with Agile. We’d been doing Scrum for about five years when I left and even then there was a lot that could still be improved. It was a slo-o-o-w process as far as tangible benefits were concerned so I should really know better than to expert overnight mastery in my new place.

3. Some things you just have to learn for yourself

I’ve been quite heavily involved with the introduction of Scrum in my new place and there’s been a few times where I’ve found myself quite strongly disagreeing with decisions that have been made. The ones that are most hard to take are the ones that were also made in my previous company and turned out to be a mistake.

So did I say anything? Yes. It’s been hard to reign back at times (and maybe I haven’t *always* managed to 100%) but I’ve aimed to just say my piece and then leave it at that. Anything more than that would be wrong. Who’s to say that just because it didn’t work in my previous team it won’t work here? And even if it doesn’t work then at least it should be a learning process.

4. There’s still plenty more to learn

I’ve learned tons since starting this new job, both on a technical level and an agile one. I’ve tried out pair-programming for the first time (it’s awesome!), discovered BDD (behaviour-driven development) and created unit tests at the database level. It’s been fantastic to try out these new things and see how they can work to make the team better.

I’m excited to be starting down the agile road again from the start as it’s pretty clear already that it’s going to be a different route and ending up in a completely different part of the destination. Not only am I learning about totally new practices but also learning more about the ones I would have said I already knew.

Our standup takes place by the Scrum Wall each day at 9:30am. Every member of our team attends including our Product Owner and every team member talks about what they were working on yesterday, what they’re doing today and any impediments they may have and updates the relevant post-its on the wall. Any new impediments raised are added to our impediment white board for follow-up.

It’s recommended in Scrum that you timebox your standups to 15 minutes, and in our team of 9 standups generally last around 10 minutes. Our team is fairly well established so I rarely have to actually ask “the three questions” (What did you do yesterday? What will you do today? Are there any impediments in your way?). For the most part each team member gives their update in turn without this prompting, although sometimes I do follow up with one of these questions if their update doesn’t address it e.g.

Team Member:I’m finishing off that bug [updates post-it]
Scrum Master:Ok, was that what you were working on yesterday too?

I don’t generally ask each person if they have any impediments even if they don’t specifically say so in their update. A common complaint I’ve heard of “The Three Questions” approach to stand-ups is a general feeling that the questions make the team members feel like they’re being spoken to as if they’re babies or young children. Once a team is the rhythm of answering these questions every day, it seems to me there’s no need to explicitly ask them.

So that’s about it for our morning stand-ups. Team members are able to start the day knowing what everyone else has achieved yesterday and with a plan for what they’ll aim to achieve today. The PO knows exactly how far we are progressing and the Scrum Master has a clear idea of anything that may be impacting on the team’s ability to progress.

I like to start off the day by updating our burndown chart which yesterday’s changes. At this time in the morning our office is usually very quiet, which means I have nice clear view of our Scrum Wall. Once I’ve updated all the hour estimates on our tasks and added in any new ones, I print off an A4 sized chart of our burndown and put it up next to the Scrum Wall. As I’m currently using Banana Scrum, a typical example looks like this:

The entire process usually only takes a few minutes and ensures the entire team has visibility on the sprint’s progress.

You don’t need much in the way of tools and software to do Scrum, but that doesn’t mean there aren’t some great tools out there that can make it a bit easier. Over the next while I’ll be taking a look at some of the different free Scrum software that’s available to see if it can offer any improvements over our current tools.

We currently use a custom list on our Sharepoint intranet for our product backlog. It’s highly customisable, so we can add in or remove any fields we want. It’s very easy to create custom views, so we can easily see only items in the current iteration or a prioritised list of uncommitted items or only items still be estimated. We can also email out links to specific items or views so that we can easily share information. Everyone in the company knows how to get to it and how to use it.

The downside to it is that it can be very slow to work with. Each page load can take a while and it can take quite a few clicks to get to the relevant screen for editing and adding items. It means that setting the priorities on 15 items can take about 10 minutes.

We use Excel to keep track of how many hours remain on each task in an iteration. This works fairly well but it would be nice to have all Scrum-related data in the same tool.

The first evaluation will be done by me and my Scrum Master colleague. We’ll be looking for tools that allow us to have both product and sprint backlog management in one tool and allows Product Owners to easily update and prioritise the product backlog. It’s also fairly important that you can create custom views or filters of the pbl and that you can send out a link to individual user stories or views in an email.

Next time I’ll be looking at Danube ScrumWorks Basic.

From the blogs and articles I’ve read of different companies have implemented Scrum, it seems that the most popular iteration lengths are either 2 or 4 weeks. When we first adopted Scrum over a year ago we decided to go with a 2 week iteration. I wasn’t Scrum Master at this point so I can’t say for sure why we decided on this length, but there does seem to be a lot of support advocating this as the best choice when beginning with Scrum.

• How quick can we react to change?
  Once an iteration has started, there should be no unforeseen changes to the team’s workload. In theory, if new work comes in then either it will be high enough priority to warrant terminating the current sprint and starting again (NOT something you want to happen on a regular basis, since it means wasted effort on the planning and starting of a sprint) or it waits until the planning meeting for the next sprint. Would the business be happiest having to wait 2 or 3 or 4 weeks for the scrum team to start working on a new piece of work?
• How often should we feed back to the customer?
  At the end of every iteration the customer has the opportunity to review the work that has been completed, allowing them to know if changes are needed early on in the project. The longer the iteration length, the fewer opportunities the customer has review the project.
• How well does the team know Scrum?
  If your team is relatively new to Scrum it may be beneficial to start with a shorter iteration length, since this means the team gets a feel for it quicker and has the opportunity to discuss and improve the Scrum process more often in their retrospectives.
• How big are your user stories?
  A larger iteration length means that a team can tackle larger pieces of work in it.

With our two week iterations, we started to find that some of our user stories got chopped up into “dev stories” to try and make them fit into one iteration. The major issue with this approach is that in a lot of cases, the completed stories could not be properly tested or demonstrated as they consisted of only low-level code changes. It also meant that they could not be properly prioritised by our non-technical product owner.

To solve this problem we are trialling a new three week iteration length. We’ve completed two so far which have gone pretty well. The rest of team like the perceived reduction in overhead, since our planning and review meetings are further apart. We haven’t really had an example of a much larger story yet, so I guess we’ll need to wait and see if we have really solved the “dev story” problem.

Recently we’ve been a lot estimating for new features in preparation of our huge quarterly planning sessions. Did I mention it was a lot of estimating? It was a lot of estimating. Some of these estimation sessions ended up lasting a few hours, and after a while the user stories started to blend together. It didn’t help that in some cases this was the first real time the team had seen these stories so they would estimate a story assuming they would have to do certain things in order to complete it and then find out fifteen minutes later that there was another user story specifically covering those things. It seemed relatively clear that we needed a better way to handle these sessions, but it wasn’t immediately obvious what that better way would be.

The answer for us came from Xebia’s blog.

It’s a very simple idea. Write all your user stories out onto strips of paper and then have the team sort them into descending order of size. There’s no talk of story points (or whatever other unit of measurement you normally use for estimation) at this point, just the question “Is this user story bigger or smaller than that user story?” The great thing about this approach is that it really helped generate discussion about the user stories too as the team decided where in list each strip of paper belonged. It was also much easier to keep track of what each user story was compared to viewing them on screen as we normally do.

Once we had our ordered list of user stories it was easy to identify which groups of stories were 8s and which were 5s etc. The team pretty much just drew lines in the list and said “This lot are x, this lot are y”. And that’s it. Done.

Afterwards the team were really positive about this approach. One said he thought it was an improvement over previous meetings and particularly liked the discussions that it generated over the user stories. I think we’ll definitely try this one again when we are faced with a huge list of user stories to try and get through.

I came across this article recently on a test devised by Nokia to figure out if teams are really doing Scrum or if they just think they are.

There are two parts to the test, the first asks questions based around iterative development and the second focuses on making sure the main aspects of Scrum are present.

From the article:

First, are you doing Iterative Development?

• Iterations must be timeboxed to less than 4 weeks
• Software features must be tested and working at the end of each iteration
• The Iteration must start before specification is complete

The experience is that if you ask a lot of “Scrum” teams if they can pass this part of the test, they can’t. If you are at a conference, often not a single team in the room.

The next part of the test checks whether you are doing Scrum (in Nokia’s opinion):

• You know who the product owner is
• There is a product backlog prioritized by business value
• The product backlog has estimates created by the team
• The team generates burndown charts and knows their velocity
• There are no project managers (or anyone else) disrupting the work of the team

So the big question then: Are we doing Scrum?

According to the criteria in this test, yes! Of course that’s solely based on my answers to the questions so maybe a poll of my team would yield different results. It would certainly be an interesting insight to see if we had any differences in answers.

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Taken from http://agilemanifesto.org

This is an excellent book for anyone who will facilitate a Retrospective at some point in their career. It’s very easy to read or drop in and out of as you require and it has a ton of great suggestions for Retrospective activities for teams in all different stages of a project.

One of my favorites is “Mad Glad Sad”, which is where the team sorts the different events that happened into an iteration into what made them mad, sad or glad. These are then grouped by common themes, which makes it really easy for the team to see and discuss exactly what had the most impact during the past sprint. This tends to naturally lead on to discussing what working particularly well, and what can be improved next time.

I’m a Certified Scrum Master working for a Glasgow-based Internet start up company. My company has been using Scrum in its Engineering teams for over year and I’ve been Scrum Master of one team or another for most of this time.

I’m currently Scrum Master of a well-established feature team working on the development of new features for our company’s website.