Refining Your Process - Part 2

In my last post I talked about taking a step back and evaluating your software development process to see what's working and what isn't.  I recently did this for my team, and found some places where we needed to improve. The main area of improvement I talked about last time was in the number of stories that were carried over as incomplete from sprint to sprint.   To address this I talked about being clearer about story definitions and acceptance criteria.  

Some other areas of improvement I found were:

• Making sure you realistically account for the number of hours a team member can work on stories.  We had assumed team members were devoting 100% of their time in some cases, because we also track all of our bugs through the Scrum process and thought there would be little unaccounted for time.  This just isn't true -- even an 80% work allocation can be aggressive for some people.  There are certain experts who need to be involved in design and architecture meetings, customer interactions, etc and they will be pulled away from development stories just by the nature of their job.  
• Defining "experimental" stories better -- we have a lot of research stories where we explore new technology.  It is important to define exactly what the outcome of these stories will be -- either a final recommendation, a prototype, or a report on potential uses.
• Dealing with unexpected bug fixes -- if possible, it would be helpful to have a dedicated team who fixes bugs and consults with customers so that the team in the sprint doesn't have to be pulled off to support critical issues.  In practice this is difficult; sometimes experts will be needed to help diagnose issues, especially in smaller companies.  I don't see a clear solution for this, other than leaving team members with slack time, as mentioned in the first bullet point.

I hope this helps to think about your own Scrum and Agile processes and to identify some areas that need attention or improvement.  Learning from your own experience and course correcting as you go is a valuable skill to have that will benefit you and your team in the long run.

Refining Your Process

Perhaps your foray into Scrum and Agile isn't working out as you'd hoped. Or maybe your team is rolling along with Agile but something feels off.  Maybe it's time to take a closer look at your processes, where it's diverging from what's recommended, and see if you need to adjust.  I recently attended a class to obtain Scrum Master Certification and it was a great way for meet to get a refresher on the basics and evaluate what we are doing right and what we might want to improve.

I'm not a religious zealot who things that a process like Scrum and Agile must be followed to the letter in order for it to benefit your organization; however I think it's very beneficial to understand why you are deciding to change a process and what you're going to get out of doing so.

One of the things I noticed about our current process was that we often left a lot of unfinished items at the end of the sprint. We did a lot of work, but that work wasn't being counted in the sprint, and we would just end up carrying it over to the next one.  During class I was reminded that stories in a sprint need to be completed in that sprint in order for that work to be counted, and that provides some of the push to get things completed in a "shippable" state that meets whatever acceptance criteria you define.  Since we were letting so many things slide over in to the next sprint it was starting to make the sprint definitions less meaningful, not to mention we were slipping on creating good unit and end to end tests  for each new story.  Working on a better acceptance criteria, or "definition of done" was a good way to help us get back on track and create doable stories that provide distinct, useful features and functionality.

I'll go into some other lessons learned from taking a look at and refining our processes in my next post.

Have you improved your work by stepping back and taking a look at what's working and not working?  If so how?

Scrum Tools: ScrumDo

ScrumDo

I only had a limited amount of time to review ScrumDo, but I was very impressed in the short time that I was able to spend with it.  The philosophy of ScrumDo is:

"We aim at providing the best and easy to use Agile story management application for distributed teams to manage agile projects easily. Our mission is to introduce the easiest way to manage your Scrum projects. We at ScrumDo believe that the tool should not become the process..."

I emphasized the last sentence because when you interact with the product it is evident that they wanted the tool to get out of the way of the process.  It's very intuitive to use like Trello (see my earlier review) but in this case you can tell that the tool was specifically designed for Scrum and Agile, rather than for a broader application.  It also doesn't feel like a heavy-weight enterprise tool and is extremely easy to use out of the box.  

Pros

• It is very easy to create epics, stories, and tasks within stories.  
• You can also create multiple projects. 
• It was easy to set up a new sprint (they call it an iteration) and add stories to the backlog and move them back and forth between iterations.  
• There is a way to easily prioritize epics and reorder backlogs via drag and drop
• The scrum board is also nicely laid out and easy to use.  
•  I didn't gather enough status to create them for my test project, but screen shots of burndown charts show that their reporting feature seems very well done.

Cons

• Searching and reporting on custom groups of issues does seem to be rather limited, but according to a recent blog post they have enhanced their query syntax to provide for better searching.  
• Release planning is not natively supported, but users can manage this by making a project equal to a release, tracking releases by epics, or using tags to assign a story or epic to a release.
• Configuration and customization seem limited although that is to be expected for a tool that wants to maintain simplicity and ease of use.  I did see mention that swim lanes/workflow on the scrum board could be customized, but I couldn't quickly figure out how to change from the standard To Do / Doing / Reviewing / Done.

Time tracking and email notification were not enabled for me in the free version so I can't comment on how well they have been implemented.  Planning poker is also not enabled in the free version, but stories and epics have an easy way to assign story points. 

Pricing

Plans range from absolutely free for a limited-functionality, 3 user plan to $149.95 a month for 50 user access. Yearly pricing plans are also available.  The free 3 user plan is great for trying out the product and gives you a good flavor of what it's about, but it is missing key features that I would want, such as email notification and time tracking, not to mention the 3 user limit is quite restricted.  Most smaller development shops would be happy with the 25 or 50 user plans that provide the complete feature set.  

ScrumDo – Free and Sweet Open Source Scrum is a helpful review that provides more detail and screen shots of the application if you want to take a closer look without signing up yourself.

Bottom line: if you're a small to mid-size development shop checking out ScrumDo is definitely worth your while. Larger enterprise organizations could benefit as well, and might want to explore the yearly pricing models.

Scrum Tools: Trello

Trello

Trello is an organizational tool that provides a way to create a "board" containing different lists or categories of items.  Each item is a "card", and the card can be really simple -- just an idea, statement,  or todo list item, or it can be very detailed and have its own task list, owner, label, and more.  Trello isn't specifically marketed to Scrum or Agile but its board structure adapts itself easily to the notion of a Scrum board. The Trello site states "Trello is the fastest, easiest way to organize anything, from your day-to-day work, to a favorite side project, to your greatest life plans."  The structure and design of Trello makes me think of a text-based Pinterest.

There is a Trello Scrum extension for Google Chrome that provides estimating and hours tracking, but it is up to you to set up and configure your boards to match the difference stages of the Scrum process.   The interface is clean, modern, and fairly intuitive, and mobile and tablet integration is very good.  Where I think Trello breaks down is for managing large projects with many backlog items.  Search is built in and that can help you find particular backlog items, but there seems to be a real danger that a large product backlog could quickly get out of hand. I also don't see support for Epics or Themes, other than having to create your own system for naming or color coding cards.  Making dependencies or links between cards also doesn't currently seem possible.  Finally, release management isn't natively supported and there is no native support for burndown charts, although  another third-party tool, Burndown for Trello, works with the Chrome extension to provide it.

To be fair, this blog post Five Tips for Using Trello for Scrum does provide some helpful ways to manage larger projects or releases, such as using separate boards to manage product backlogs and sprints.  However, I am still not convinced that Trello would scale well although I would definitely use it to help organize small personal projects.

To sum up, it is a really well-designed product, and would be very useful for small startups or other small teams that want a free tool for an initial foray into Scrum.  However, without a lot of discipline around its use it may not meet the needs of a development team as it grows.

What is your experience with Trello? 

Scrum Tools: Jira Agile (formerly Greenhopper)

Jira Agile

The next few posts are going to talk about different tools that you can use to manage the Scrum process. There are quite a few out there, but I"ll start with the one I'm currently using, Jira Agile. It was formerly known as Greenhopper and is part of the Jira family of the Atlassian bug tracking and project management products.  Many Open Source projects use Atlassian tools to manage development so lots of people are familiar with Jira, for better or worse.

I've taken a liking to it, but it may be that I've not had much to compare it to. Prior to adopting Scrum/Agile my company used Bugzilla for bug tracking and that was it, but we needed a tool to help manage Scrum online since our team has many remote members. Many teams find that a large white board with post-it notes and an Excel spreadsheet for the product backlog works great; we needed a virtual whiteboard instead of a physical one.

We now use Jira Agile for bug tracking as well as the Scrum management process, as all new issues are now managed as part of the product backlog.  Now that I've been using the tool for a while, I'm efficient in inputing the data, updating items, and such.  It took a while to get the hang of where everything was located, but now I can easily update our estimates and move stories around when we are in the middle of our sprint planning meeting.

From a cost perspective, price is pretty reasonable and you can opt for a cloud-hosted site or create a local installation.

Things I like about Jira Agile:

• The Work view of the Agile Scrum Board is a really useful way to visualize the status of your stories. It shows all the stories in the current sprint, who they are assigned to, and in what stage they are in. This view is shown in the picture above. You can customize the workflow and have different lanes as needed for your process. We happen to use To Do, In Progress, In Testing, In Review, and Done.  I bring this up during every daily Scrum meeting and use it to refer to when team members are discussing their status.
• The Plan view of the Agile Scrum Board lets you easily reorder the product backlog and move stories into different sprints.  It can get a little clunky dragging when your backlog gets big, but  overall this feature is very useful.
• You can do original estimates in story points, then track time in hours once stories have been moved to sprints.  Velocity can then be expressed in story points for stories completed.  You can also do original estimates in hours and calculate velocity that way if you so desire.
• The Report view of the Agile Scrum Board automatically calculates sprint burndown and velocity charts for you throughout the sprint.  Other areas of the system allow you to calculate release burndowns for stories assigned to a particular release version.

Things I dislike about Jira Agile:

• In the Plan view of the Agile Scrum Board you can sort Epics by priority in the left hand pane, but you can't view the priority order of these Epics in any other way that I can figure out. I can search for and get a report of all Epics, but cannot seem to sort them in the priority order shown here.
• Email notifications aren't very good.  Email notifications are configured to be sent whenever certain activities take place, like when a story moves from In Progress to In Testing. However, this can cause a lot of clutter because Jira sends one email for each piece of data that is changed.  I think that Jira should bundle up changes and send a summary only of changes done say in a 5 minute window. Typically when you update a story you might update the hours worked, add a comment, and change status.  You'd like to get just one email instead of 3.
• There was some pain around getting everyone to have an easy to use view of their currently assigned sprint stories.  Our solution was to use the Work view and create filters to show only stories assigned to you, or stories that you are assigned or are watching.

I've gotten into a groove using the tool and I can say that I would recommend it, especially if you need to track bugs for an existing system.  In the next few posts I am going to reevaluate some other Scrum and Agile tools to see how they measure up.

What tools do you prefer for Agile and Scrum?

Bundling Bugs

Sometimes you end up with a lot of bugs in your product backlog.  This can be difficult to manage, especially if you already have a large amount of backlog items.  I recently attended a scrum master certification class and asked about this issue.  One suggestion for dealing with this is to create a single backlog item that bundles more than one bug for a particular component together into one backlog item. Bundling smaller, related bugs together (as long as they can be finished in a sprint) allows you to manage the bugs from the product backlog without unnecessary clutter.  It doesn't solve the problem of having too many bugs in the first place, but it can hep you to manage them more effectively.

How does your team manage bugs in the product backlog?

Would Scrum Have Saved HealthCare.gov?

This NPR story, It's Easy To Blame The Canadians For HealthCare.gov Problems, talks about the federal government's rules for dividing up large contracts amongst many contractors and how that may have contributed to the issues with the HealthCare.gov website.  It contrasts the situation with the more trouble-free website from the state of Colorado's health insurance market's site.  Colorado built its system with what appears to be an Agile process, rolling out the portal in stages and realizing that some advanced features would not make the original release date but core features would be completed.  Could Washington streamline it's contract process to allow large projects to be done using an Agile process like Scrum, or does its heavier bureaucracy make it impossible?  Obama has recently put a new manager in charge; I hope we get a peek at what he does to solve these issues.

Where Did Scrum Come From?

Seems like you can't talk about software development without someone bringing up Scrum and Agile these days.  Ever wonder where it all started?  

Jeff Sutherland created the first Scrum team in 1993 and modeled the new software development process on a 1986 Harvard Business Review article called "The New New Product Development Game", written by Hirotaka Takeuchi and Ikujiro Nonaka. Takeuchi and Nonaka are highly regarded business school professors and researchers who have studied leadership and management in top companies in Japan and elsewhere. Their observations became the root of Scrum, which Sutherland then adapted to software development.  

You can read more about this history of scrum on Sutherland's blog:Takeuchi and Nonaka: The Roots of Scrum

Planning Poker Estimation with Remote Teams

(Image from agileconcombre.blogspot.com)

Even though Agile software development favors co-located teams, sometimes getting everyone together all in one place is just not possible. If you have team members that work remotely all or some of the time, or are working with different company divisions or outside consultants and need to do estimation during release planning it can be difficult if you want to play Planning Poker.  This blog entry from fourkitchens.com describes a clever way to use Google Docs to help remote team members vote. It's a great idea that doesn't take a lot of time to set up and can allow this particular estimation process to run more smoothly when people can't all be in the same room.

On Scrum: Playing Planning Poker with a Scattered Team

What's the best day to start a sprint?

When do you start and end sprints at your organization? Do you always start and end on the same day, or does it fluctuate? My teams currently end sprints on a Friday and start them on the following Monday, and that has worked well for us.

We typically do sprint demos on Thursday afternoons, disuse the sprint progress with stakeholders on Friday, officially end the sprint that day and then start sprint planning on Monday.  There can be problems with people being off for long weekends or holidays, but in general that's not been too much of a problem, and by doing the demos on Thursday afternoons that helps a bit.  We realize that the demos might not have all the features in place, but we try and reserve Fridays for lower priority bug fixes or loose ends to tie up to finish off the sprint.  A weekend break is also nice as a Scrum Master or Product Owner/Manager, because you can use the weekend to react to stakeholder priorities as needed. 

Most importantly, what do the teams think?  Let them have a significant say in when your sprints start and end.

Other teams have found that starting in the middle works better for them. These links pose that a mid-week start can be helpful:

http://www.agilebuddha.com/agile/when-is-a-good-day-to-start-a-sprint

http://blog.agilebuddy.com/2010/01/sprint-start-and-stop-days-whats-best.html

What's your best practice?