Comparative Agility

Adopting Agile / Scrum in your team and organization can be a challenging task. However, with the help of servant leaders with good understanding of Agile principles and practices, your team can adopt a process that works well for you. Once you've established a process however, things can get monotonous. One of the tools I recommend using to help you break the monotony, and try to move forward with something new is Comparative Agility.

Comparative Agility is a survey with questions about your Agile practices. The survey takes about a half an hour or so, and I found the results to be really useful. I recommend one of the following two approaches - take the survey on your own and share the results in a retrospective; or possibly, take the survey collectively as a team in a retrospective, and talk about the results. 

When I took the survey, I was interested in knowing how my team was doing in our effort to adopt Scrum. I also wanted to know where I could help focus my team's attention in our efforts for continuous improvement.

The results definitely brought some of our shortcomings into focus. I could then engage the team in a conversation about why we should concentrate on areas where the survey says we are lacking; and think about what roadblocks we have along that path. I could also use the data to inform our leadership team to help us on our path to adopting Agile.

I found the survey questions and results really useful. I'd definitely recommend taking the time to do this activity.

Here are some results from my team:

Dimension Analysis:

Characteristics Analysis:

Rate this post!

☆

☆

☆

☆

☆

Triage

Along with the 4 recommended Scrum meetings, I usually include a Triage meeting in my implementation of the Scrum process. I thought I'd share some pointers on triage.

What is triage?

Triage is a quick meeting to go over new / incoming defects. In the meeting, we sort defects and set priorities on them. Triage is a good place to groom the minimum viable product backlog, so all the tasks - stories and defects are prioritized in a single list. 

Participants, Frequency, Duration:

I recommend having the Product Owner and the Scrum Master participate in the triage meeting. The team can be made optional attendees. Specific team members join the call if they have opened / are working on defects that need to be explained in detail. 

Frequency of triage meetings is dependent on defect inflow. I have found that I'm comfortable with triage of about 8-10 issues in a single session.

As with any meeting in Agile, it is important to time-box the triage activity. Triage is not a place to solve the issues, or fight about the defect's exact place in the backlog. Triage is a meeting for building quick consensus and clarity on what the issue is, and what release it really needs to be fixed in.

Scrub of defects before the meeting:

In order for the triage meeting to be productive, I spend some time looking at defects before the meeting. I look for several things in this time:

1. Duplicates - if an issue is a duplicate of something that is already in the backlog, clean it up.
2. Change project - if an issue is incorrectly opened against our project, or if I can quickly tell that it should really be assigned to another team, clean that up as well.
3. Comments - I take a little time to look at code to figure out some technical details about the defect. I write my quick analysis as a comment on the defect. This is intended to give a head-start to the developer who is eventually going to fix it. I also try to add some notes that will help set priority during the meeting.

Priority setting:

Priority calls are owned by Product Owners. However, most product owners I have worked with usually take suggestions from everyone involved. I recommend following the MoSCoW principle for priority:

1. Must have - these are defects that "gate" a release. They must be fixed in order for the minimum viable product to ship.
2. Should have - these are "high" priority defects, which should really be fixed for the minimum viable product release.
3. Could have - these are "medium" or "low" priority defects, which can be included in the release if there is time, or if they are really low hanging fruits.
4. Won't have - these are defects that the product owner decides not to fix. The reason for this is up to the product owner. For example - defects that are deemed corner cases, or defects that are needless nitpicking.

As a Scrum Master, triage meetings help give me some idea about what is in front of the team - defects and stories included. This helps me look at forest from the trees. Doing a scrub of defects for triage also keeps me in the loop on latest code changes that the team is making. This helps me be a better code-reviewer. I have found triage meetings to be immensely helpful.

Rate this post!

☆

☆

☆

☆

☆

Spikes

I think Spikes are a very interesting topic to talk about. I have seen a lot of teams struggling with the concept, and potentially abusing the term. I want to write about Spikes, in order to try to clarify their meaning and give some examples of how spikes can be useful and how they may potentially be abused.

What is a spike?

A spike is a time-boxed technical investigation / research undertaken by a single developer or the team in order to solve a specific problem. Spikes usually don't produce working output.

Spikes usually produce example code that is used to build the working output.

Etymology:

On The Agile Dictionary, there is a comment (3rd from the top when I'm writing this) :

Paul says:

My recollection from the early XP Universe conferences in 2001/2002, is that the term “spike” comes from an analogy to rock climbing. When climbing, we might stop to drive a spike into the rock face. Driving the spike is not actual climbing — it does not move us closer to the top — but rather it enables future climbing.

I don't know how true this is, but I definitely like the analogy here.

Example use of a spike:

I recently built an app, which helps users prepare for DMV test. The app is pulls some data from my data source on the web, parses it and shows it to the user. When I started working on the app, I didn't know how to talk to a web data source from an Android app. I was stuck and needed a technical investigation -- a spike. 

I used this spike to try to pull data from a test website. I didn't necessarily need the official app website for the spike, I could use any test data. My aim was to find an implementation that accepted a URL as input; and spit out the text from that URL. I decided to have a long time box, because my app update was intended for this activity. I couldn't proceed with any real development without this investigation.

When I was done with the spike, I didn't have a solution that I could simply copy-paste into the code for my app. Instead, I had an example which I could work off of.

Example abuse of a spike:

I can think about 2 specific examples where spikes are abused:

1. Spikes for accurate estimation: Spikes allow developers to familiarize themselves with the code. This can lead to more accurate estimation. If all your spikes are driven by a need to have accurate estimates, you need to question whether that is really needed. 

If your team runs into issues where they aren't comfortable putting a number on a user story without first going through and knowing the design, I'd like to point you to my article on Story Estimation. I have mentioned a few things there which might be useful to you.

2. Spikes for requirement clarification: I have seen teams using spikes for clarifying the requirement(s). In this semantic change of 'Spike', a developer needs to put on a Product Owner hat to figure out the details of the "what?" and not the "how?". If your team is engaging in spikes because stories aren't clear, I'd encourage holding your Product Owner responsible for providing a reasonably clear stories, and a decent minimum viable feature set for the release. 

In conclusion, I'd encourage teams to:
1. Stick to the definition of the spike I mention here.
2. Take on Spikes only when they are necessary, not before that. You don't want spend time on a spike for a story that never sees light of the day. 
3. Set a time-box for the spike.

At best, spikes are excellent tools for producing working solutions quickly. At worst, spikes can convert your Agile process into Waterfall.

Rate this post!

☆

☆

☆

☆

☆