As we continue to optimize our use of Agile techniques at Jama, we’ll share what we’ve learned, any adjustments we’ve made and which techniques are working or not working for us.

If you missed the original post in this series on our Agile Process experiment, you can read it here.

In this post, we’ll discuss two common techniques used for Agile software development that we’ve adopted into our workflow at Jama:

1. The daily stand-up meeting (aka “Daily Scrum” or “Huddle”)
2. Use of a large whiteboard for tracking high-level tasks for all current projects (aka “Task Board”)

These 2 techniques go hand-in-hand and include the entire team.  Our daily stand-up is held at 10am every morning and is 15 minutes or less. One of the principles of the daily stand-up is to keep the status meeting short and high energy (Note: Stay vigilent about the time frame and structure of the meeting otherwise it’s easy for it to get off-track).

During the daily stand-up, we each try to limit our comments to communicate these 3 things:

• What tasks did I complete?
• What tasks am I working on today?
• What do I need help on?

Unlike the formal Scrum meeting, we don’t apply the labels of “Pigs” and “Chickens” to the members of the team – because we’re vegetarians.  No actually, in our case, we work in a small team environment and everyone on the team has skin in the game and would be classified as a pig (well, in the good kind of way).

If you’re new to the concept of the Daily Stand-up, here’s a good resource on it.

We hold our daily stand-ups at the Task Board (or what we call “The Big Board”) which is front and center in our office – visible to everyone at all times.  No sacred cows.  We’ve found this high level of visibility creates a high level of accountability – to each other and to the customers of the projects we’re currently working on.

We’ve divided our Task Board into a matrix with the name of our active projects (& target completion dates) along the left in rows and next to it we track the status of tasks in the following columns:

• To Do – A new task is defined and assigned an owner
• In Progress – A task being actively worked on, not yet completed by owner
• Verify – A task completed by owner, and now being verified by someone on the team internally (and externally by customers when applicable)
• Done – A task has been verified and is satisfactory

As work gets tasked out, each high-level task is written on a sticky note (aka task card) with the task name, owner and projected # of hours required.  During the stand-up, the task owner moves the task card to the appropriate column based on its status.  When help from someone else is needed, such as for the verify stage, that person’s name is written next to the specific task card on the whiteboard with a projected completion date.

As the board fills up, and tasks move from left to right (as work gets done), you’ll be able to see where potential bottlenecks may occur, whether tasks are taking longer than expected (to improve estimates), and at a high-level if you’re at risk of missing the target completion date for a project.

One of the things we’ve adjusted over time is our definition of “done”.  Early on, we didn’t include the “verify” column and we discovered that it was easy to have someone feel like a task was done, but by taking the time to commit to having tasks reviewed by a second set of eyes and formally adding the “verify” column to ensure code quality early on helped minimize defects later in the QA/testing process.  Based on the dynamics of your team, you’ll likely want to experiment with how you run your board to keep the stand-ups effective.

So overall, we’ve found these 2 Agile techniques are good for communicating the high-level tasks and tracking daily progress of projects, but what about the details behind the tasks?  Where do we manage the related requirements, key documents, customer feedback, defects, etc. that go into a project or product release plan?

In our next post in this series, we’ll answer those questions and share what we use (tools and process) to manage the “Devil in the details”.

Until next time, happy agile development (and holidays too)!