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?