AgileZen Limping Towards the Drain

I’ve used plenty of project tracking tools over the years many of which I detested and a few I was OK with. AgileZen was a pleasant surprise when I came across it and I wrote a review and lobbied for using it at my current company as a Kanban style lightweight tool. It worked fine for us for a year or so, but gradually we noticed it was getting no love. The UI in tools like Pivotal Tracker were getting more responsive and event driven and AgileZen was stuck in the old request response cycle with a smattering of AJAX. Eventually it was obvious to us that it was dead software walking.

Rally Software promised that the beta would improve everything, but in the end they never released it. I’m sure it was a business decision where they didn’t see enough upside in improving it and decided to just eke out a profit with the current dwindling subscribers.

We ended up back in Pivotal Tracker which has served us well, but I still wish there was a nice Kanban style replacement for AgileZen.

Daily Agile Standup Comedy

“So this mornings standup is brought to you by this ethernet cable, because you guys are so connected”

I’ve seen numerous standup rituals over the years, from passing along a Rugby ball to signaling the end of stand ups by noting it was time for lunch. Some of the rituals help keep everyone engaged and focused on the central goal of the standup, coordinating the team and making everyone aware of potential obstacles. Recently I became a participant in a novel approach to leading off the daily standup.

One Monday our manager walked into the standup room carrying an ethernet cable. Mistakenly I took it as another standup totem. We regularly have used books, cups, or packages of black licorice as standup tokens. Today though he held up the cable as he began the started and opened up with a themed joke to lead off the startup. There were groans and chuckles, but little did we know for about the next month or so the stand ups would start with these humorous tokens and little sayings. The black licorice with a mention of ‘like black licorice we all were experts in different things’ or the day with a tack that ‘we were as sharp as this tack.’

It’s a very small thing, but it’s details like these that keep a process fresh. You really don’t want the daily standup to degenerate into a complete ritual, so mixing things up keeps people alert and thinking. Not a bad practice to try out sometime if you find your standup getting a bit stale. And for other ideas you can always check with Jason Yip’s exhaustive patterns on standups.

AgileZen for Solo Remote Development

Over the past few months I’ve been working on some remote projects as a solo developer. Knowing I wanted a light weight tracking tool I took some time to experiment with a few tools and I’ve recently come to appreciate the lightweight character of AgileZen.

Despite many warnings to use the simplest thing that could possibly work, often stickies on the wall or simple index cards, there have always been a number of options to translate these planning/tracking tools to software applications. Despite settling on the power of physical wallboards for collocated teams throughout my career I have looked into using a number of tools for feasibility ultimately deciding none of them worked as well as a cork board and some stickies or index cards. Tactile and visual cards rock.

Some of the tools I’ve looked at in the past include:

I never felt any of them where worth the effort to maintain in the end despite many high hopes. I’m not immune to tool fascination, but I tried to honestly evaluate the worthiness of the given tool. As a manager much of my focus on this was to please stakeholders and other managers with a nice visual report that could be shared via email and web browsers. In my Agile rollouts it turned out that I was ultimately more successful showing off my cork boards and cards. We did maintain an Excel spreadsheet with backlogs as well to meet some documentation standards for PM groups. It was a small compromise I was willing to live with.

My most recent projects presented me with a different challenge. As a solo developer I’m largely on my own and not sharing the project tasks with anyone else, but I like to have an organized workflow at all times. My home office doesn’t have much in the way of space for a nice corkboard, and again I wanted to fiddle with tools so I tried a few to see how they might work for me.

A first attempt was with Pivotal Tracker. I love the things Pivotal is doing out there with a focus on TDD/BDD, pair programming and producing high quality code. Pivotal Tracker is a nicely polished tracking tool that largely simulates the idea of a wall board with an emphasis on iterations that contain a set number of story points. It’s an opinionated piece of software with this and assumes that you are very concerned with ordering of stories based on points and how you pull them into the backlog. After a lot of work trying to understand how it wants me to work I found it not a great fit as a solo developer. It assumes you want to have tracker plan your iterations automatically based on your velocity. In fact they admit that you can change some settings for the current iteration to allow you to drag stories in or out, but it will still automatically plan all the other iterations in the backlog. In the end I might be up for trying it with a non-collocated team, but for a solo developer the overhead was a bit higher than I prefer.

AgileZen was my second attempt. I remember from some old twitter and blog posts that several people had said it was a really nice lightweight tool. I realized arriving at the site they had been acquired by Rally. I’ve used Rally’s tools, but for collocated teams I didn’t really think the overhead of using Rally was worth it. It appears that AgileZen is their attempt to provide a lighter more Kanban style tool. I liked the little bonsai tree on the login and found more to like when I went in and attempted to setup my current project. I watched the short series of screen casts showing how it worked, maybe 5-10 minutes in all. After that I’ve been very productive without having to dig into any help. The central metaphor is just a digital task board:

Agile Zen focuses on the concept of cards and a board with very lightweight workflow. You create a feature or user story and ‘hang the card on the wall’. You then just move the card to progress it from the backlog to started. You can do some customization, but the default workflow was perfect for me as a single developer. It also looks like it works quite well for remote teams and appears to support more options like marking cards as ready or blocked. I’ve even used the blocked status for a card once where I wanted to run a design idea by a colleague before I continued further on that particular story. And I’m a sucker for some auto-generated stats, but it has a nice page where it calculates your throughput with a pretty graph. It will take more time to see if the stats actually give me useful feedback, but did I mention they look nice:

Overall the tool feels closer to a digital taskboard than anything else I’ve experimented with. I’d still use a physical task board for a collocated team, but for a team working in remote locations or a single developer I think it makes a very good electronic substitute. Now if only it had an iPad version. If you’re a solo developer feel free to try it yourself as it’s 1 project is free for a single developer.

Agile Rollout Warning Signs

I was working with some clients recently when one of them leaned back in his chair and announced:

“Well Paul’s leaving. I guess he finally got fed up.”

The group of developers and sysadmins were disappointed at the news. They wondered why he decided to leave as it turned out he was a key champion from the QA group in pushing a closer working with development. He had a development background and had been key in moving the group from manual testing to working closely with developers on tests and adding automated regression suites.

Early the group had explained they had adopted Scrum in the development group about 18 months prior and it had been going fairly well with now 5-6 Scrum teams. One of the biggest successes had been the closer work with testing. And a familiar problem area had been the problem in getting the true product managers to attend the Scrums as they largely delegated to business analysts and much was lost in the translation.

Apparently the QA team was going to take this hard as Paul had been a champion of theirs in evolving their practices and fighting for respect for QA at the table. It sounded like he had pushed hard and been denied many things because of an unwillingness to imagine QA outside of their traditional role. This shop also had the Mercury suite of testing tools which often is a sign of a dedication to focusing on bug databases and record and playback style automation that doesn’t go nearly far enough in improving the effectiveness of QA.

I hope they succeed as the people I worked with all seemed bright and dedicated to improving things, but a couple of these items are classic warning signs in an Agile adoption that is likely to run out of steam.

  • Agile champions like this QA developer pitching in the towel.
  • Product managers delegating day to day involvement in the Scrums.
  • Use of less than Agile style tools like the Mercury suite.
  • QA still having a real perception problem in the organization.

I certainly hope that this test lead doesn’t turn out to be a canary in the coal mine in regards to their Agile rollout.

Story Time Meetings

Keeping you backlog in order doesn’t tend to happen in isolation. My past experience is the backlog drifts because of a concentration on completing day to day Sprint tasks. You can tell when the backlog has drifted, the planning meeting goes long. Kane Mar suggests an approach of using a Story Time meeting.

A Story Time meeting should be held at the same time and location every single week and involve the entire team, including the Product Owner and ScrumMaster. The sole intention of these weekly meetings is to work through the backlog in preparation for future work. This may include adding new stories and epics, splitting up overly large stories, and sizing.

At my past company this often came up as an issue since backlog items wouldn’t get estimated or explored much until the Sprint planning meeting. The idea is to have the product owner keep up with these items and follow up with people to get estimates as new items show up. In practice that just didn’t happen.

I like the idea of blocking out time to make sure it gets done and it helps ensure the planning meeting is smoother and over sooner. You wouldn’t need to use it with every team since some teams are just naturally better at making the time to keep the backlog in good shape.