2013 Scrum - Team's achievements after adopting Scrum

Really happy with the results of our team since adopting Scrum. This is the summary for 2013:

The team has already changed and many new development plans for 2014. Hopefully it will only get better and better!

Sprint Planning Meeting

The sprint planning meeting is a 4 hour meeting, for a two week sprint. We prioritise the Product Backlog before we go into a sprint planning meeting. During this meeting we choose the prioritised user stories, estimate them and select the ones we commit to work on during the sprint.

As lists make life easier, for me, this is how I have organised the sprint planning.

[ Before ]

1. Ask everyone to take their holiday plans to the sprint planning. 
2. Checkout Systems holiday’s too!
3. Cards, markers, pens. 
4. Clarify any user stories during the PB grooming meeting.
5. Confirm with PO via email, top X user stories. 

[ During ]

1. Writing board.
2. Sprint Goal (what will be our goal during this sprint? Then, in theory, we shouldn't work on anything that doesn't support this goal.)
3. Holidays need to be taken into account.
4. Steps:
1. Write out user stories (everyone participates)
2. Estimate user stories
3. Prioritise user stories
4. Choose which ones we can get done
5. Commit
6. Developers write out tasks for user stories

[ After ]

1. Book Meeting rooms.
2. Add meetings to calendar.
3. Meetings:
1. Product Backlog Grooming
2. Sprint Review
3. Sprint Retrospective
4. Sprint Planning
5. User communication
6. Daily Stand-up
7. PO/Stakeholder shape-up meeting. 
4. Create Change Requests for Sprint and add deployment dates.
5. Printouts:
1. Calendar
2. Goal
6. Scrum board set up.

Agile - How to determine the appropriate length of a Sprint

The more the environment changes, the more the requirements change, the shorter the length of a sprint. This would help minimize risks and allow those changes to take place without messing up the frozen Sprint Backlog.

In my team we have recently adopted Agile.

Our first 2 sprints were getting used to the new team and the Agile process, so we don't count those. These along with our first official sprint were three weeks long.

The last sprint and this current one are two weeks long. We were told by our Agile coach to try different time frames during our first sprints to see the ideal one for the team.

Here are my findings:

1. We always have an extra "emergency" release at the beginning of the sprint. People always want things ASAP and this is not always (never, in my experience) with the sprint timeframes and we end up having a release at the beginning of the sprint.

2. In our case, with our ITIL process and Platform complications. Release Notes, UAT, test UAT (have users test and sign-off), Release Notes, Live release (testing one node at a time - clustered architecture) and notify users can take up at least 24 hours. All this takes up development time from the sprint.

I find two weeks is too short for such a changing environment and the time spent preparing deployments.

I find three weeks gives us a bit more breathing space.

Maybe the solution is to keep two weeks sprints. This way the business gets changes a lot quicker BUT we need to find a way to freeze our sprint backlog and avoid "emergency" releases mid sprint.

Going Agile : From Waterfall to Agile

A developer's piece of code was posted in the wall of shame. It was a horrible piece of code and should have been refactored to one line of code. No one has ever conducted a code review or spoken to the developer to show what was done wrong.

I asked if anyone had ever told the developer what was wrong with the piece of code (I prefer people telling me where have I done wrong) but no one had and the answer was we have never done code review.

The senior developer said that everyone is responsible for his code. and this is where I disagree.

I know we have just started to adopt Agile methodologies and we are far away from it yet but a couple of people on the team including the senior developer and manager have experience with Agile projects.... so this came in mind: 

• Collective code ownership. Take as much pride in the team's code as in your own code.
• Always leave the code a little better than you found it.
• Fix problems no matter where you find them.

Everyone on the project shares the responsibility for the quality of the code. Developers are expected to be able to refactor code and fix the problems they find. Everyone should see the team's code as their own. If a developer needs help or is not doing his job properly, this might be a good time to use code review and pair programming to spot the problem and educate the person. After all, it's not about processes and methods.. it's about people.

Or not?