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!

☆

☆

☆

☆

☆

Agile Product Ownership in a nutshell

Heard about this absolutely fantastic video that I thought I must share! Thanks to the wonderful people at This Agile Life for sharing it!

Rate this post!

☆

☆

☆

☆

☆

Sanity check: Are you really doing Scrum?

Although each team implements Agile in their own special way, it helps to take a step back and think about whether you are really following Agile principles. Here are some things to think about.

Are you really following Scrum if -

• You don't know what a minimum viable product is
• You don't do demos
• You don't do retrospectives
• Your don't follow Scrum roles
• You don't have a backlog
• Your team is constantly overwhelmed with end of sprint deadlines
• You follow 2 week iterations, but don't even attempt to produce working software at the end of each iteration
• Folks on the team are stuck and don't bring it up or ask for help
• Your team thinks 'stand-ups' are a complete waste of time and regularly skips them
• You have separate 'development scrum team' and 'verification scrum team'

If you answered yes to the questions above, you may not be benefiting much from your Agile experiments. I encourage talking about your approach someone who has experience implementing Scrum. Possibly, my post on getting started on your Agile journey may help you find reasonable a start to some of the problems.

Rate this post!

☆

☆

☆

☆

☆

As you begin your Agile journey...

Doing 2 week sprints doesn't make your team Agile. Here are a few thing you might want to consider having in place as you set out on your Agile journey:

Create / Work from a backlog

The first step to solving a problem is to identify what the problem is. Creating a backlog is a great way of thinking through the first iteration of a solution. If you already have a backlog and aren't really using it, I recommend taking some time to groom it so it becomes a valuable resource.

You don't need to wait until you have hundreds of items prioritized correctly in the backlog. I recommend having just enough stories to get started, or just enough for the first minimum viable product. 

When grooming the backlog, consider rewriting some possibly poorly written user stories. We slice a birthday cake vertically, not horizontally. Similar to that, I recommend have your stories span all the layers of your application. I do not recommend having 'create the UI' (that does nothing) as your first solution. Instead, try to find ways to build a shippable and usable product.

Get your roles correct

Although development leads, test leads, project managers, team leads, system architects, development managers may seem like good fits for various Scrum roles, it may not always be the right thing to do. 

I have seen teams where a single person worked as the Scrum Master and the Product Owner. I have seen a team where a relatively non-technical Project Manager was asked to be the Product Owner - creating and grooming the backlog of highly technical work items. 

I recommend taking a little bit of time to think about the roles and get them right.

Start your team on a path of self organization
Self organizing teams stick together through tough times and hold each other accountable for quality. There are some things you can do to nudge your team on a path of self-organization. 

a. Allow failures
If / when the team fails to meet their commitments for a sprint or fails to deliver good product quality, you can use that opportunity to drive conversations so that the team starts holding itself accountable. 

b. Get the team to commit

Drive the commitments by team-input rather than coercion or deadlines. You are more likely to get frequent successes when sprint and release commitments are driven freely by the team.

c. Data driven retrospectives
I recommend collecting good data and having the team reflect on that data in retrospectives. This helps identify problems about why the team didn't meet their commitments. 

Start thinking about improvement opportunities

When teams start Scrum / Agile, the first few sprints are usually bumpy. I recommend that Scrum Masters to maintain a list of items that are good candidates for improvements. Some of them may be:
a. Quality of User stories, Backlog Grooming process

b. Team practices - e.g. code reviews, pair programming

c. Team processes - e.g. "JIRA workflow", quality of retrospectives

d. Delivery cycles - e.g. thinking about how to establish a release cadence

I find that Scrum seems relatively easy in theory, but can be hard for teams to implement. Taking the right steps initially can help create a culture that support Scrum / Agile and can set you up for success.

Rate this post!

☆

☆

☆

☆

☆

User story examples

From my Scrum Master experience, I find that everything starts with user stories. If your user stories are bad, everything can go downhill, no matter how good your process or team is. 

I wanted to write about characteristics of user stories, but I thought it would make more sense to take some examples and discuss them. Here are a few example user stories

1.  As a user, I want to create a new account, so I access the system for my day job

• This story adheres to a commonly used template - defining who is the actor, what is needed from the story and some business justification. 
• I like the 3Cs defined in XP - Card, Conversation, Confirmation. 
• Card - The story is short and can be written on a card. It is not a legal document covering all the possible edge cases in the world. 
• Conversation - The story does allow for some conversation - the team can ask questions or express their opinions. For example - the team can have questions about what is all data that is needed from the user in order to create a new account, or what is the expected UX etc. The conversation about the story becomes part of the story even if all of it isn't explicitly documented. 
• Confirmation - The story is defined well enough that we can write an acceptance test for it. However, no team I know of does perfect Agile / Scrum, and almost all teams I have worked with have lacked in the area of TDD and ATDD. In absence of acceptance tests, I like to redefine the third C as confirmation received from the Product Owner in a demo.
•  The story adheres to INVEST -
• Independent - The story can be made to stand on its own 2 feet.
• Negotiable - Since the UX or parameters to be accepted from the user aren't expressly defined, the story can be thought of as negotiable
• Valuable - The story adds value by allowing a user to register a new account.
• Estimate(-able) - Teams should be able to put a time / story point estimate on this story - possibly after some discussion. 
• Small - The story doesn't seem overly big. It looks like something the team can accomplish in a reasonably small sprint.
• Testable - The story is testable as someone can query the server or database to see if the account was successfully registered.
• Overall, I like this user story. This is a decent candidate for a 'ready' backlog.

2. As a user, I want my app to be fast and responsive, so I don’t get irritated while using it

• Although this story adheres to the format, the 'fast' and 'responsive' words in the story make it non-testable. The parameters need to be defined in ordered for a tester to objectively pass or fail any implementation.
• Although the sentiment behind the story is good, I wouldn't call this story as 'ready' for a prioritized backlog. Some more work needs to go into the story to define it better.

3. As a maker of smartphones, my company wants all apps in all app stores to be supported on all of my devices across formats and variants, so my company gains 100% market share

• Just by reading the story you can tell that is (a pipe dream) and HUGE! It also looks completely non-negotiable.
• I'd call this a terrible candidate for any backlog. A lot of work needs to be done on this story before it can be worked on by any Scrum team. 

4. As a developer, I want to connect to the database so that I can query for various pieces of information

• Unless your product is the database itself, I don't like this user story too much.
• Connecting to the database, getting the development environment setup and compiling etc. should be done as a part of Sprint 0 - the development and test set-up sprint. This should not be something that is needed in a product backlog when you start adding business value to the product.

5. As a tester, I want to have a separate test environment built for me, so that I don't have to test in production environment.

• I like to think that if your organization doesn't have a separate production and sandbox / test environments you may not be ready for your sprint cycles yet. 
• Having said that, I want to confess that this is a real candidate story from a project I have worked on. The problem we were facing was that our regular sandbox / development environment was going through maintenance causing our servers to go down randomly. This caused a lot of pain points for everyone on the team. It was impossible for us to build an entirely separate test environment. The story was too big, and there was no real value-add to the business, as the system maintenance was scheduled to be complete in about 2 weeks time. 
• We just had to deal with the sandbox system maintenance nightmare by improving communication between the teams involved.

6. As a user, I want to be able to connect to database

• This story has a lot of problems. You can tell by reading it that it does not spell out the business value.
• Users usually don't connect to database, they use the UI to do various actions - which may entail connecting to the database. 
• We need to carefully think about - the actor, the functionality and the business value when we write user stories.

In conclusion, I believe that writing good user stories is really important. Almost all the teams I have worked with find writing good user stories to be really hard work. I like to consider writing user stories as a matter of continuous improvement. You can possibly start off with some bad ones, but it really helps if you devote time and think carefully about the stories.

No matter how good or bad your user stories are, I recommend having a meeting where your team discusses the user stories. This allows for conversations about the user stories between the team and with the product owner. This lead to better shared understanding of the problem the team is going to solve.

Another quick point - Most Scrum Masters I know have talked about a definition of done at some point, but I think it is also important to talk about a 'definition of ready'. This definition can give the Product Owner some guidelines about what your team expects from the user stories in a 'ready' backlog / queue. 

Rate this post!

☆

☆

☆

☆

☆