Agile in Action – How Codesion Does Agile Development

April 18, 2011 Willie Wang

Agile in Action WebinarLast Thursday I hosted the webinar – Agile in Action – how Codesion does Agile development. We had an excellent turnout and a lot of great questions as a result. I went through the process of how we define and groom our product backlog, run sprint planning meetings, do daily sprints, and reporting. If you missed the session live, you can watch the recording and download my slides.

As promised during the session, here’s the follow up to the live audience questions.

Q: We have a small team but very distributed. Do you think this agile methodology helps and how?

Agile Scrum, to be specific, ideally requires a team that you can dedicate to a sprint without interruption.  If you have a small team that will be interrupted frequently due to emergency issues, then Agile Scrum-Ban may be more suited for you.  It’s a hybrid approach to Agile Scrum and Kanban. Take a look at this knowledgebase article onhow Codesion uses the Scrum-Ban methodology.

 Q: How do you manage daily scrum over multiple time zones?

We have multiple scrum teams.  Therefore, as much as possible, we try to have team members in the same timezone.  Of course, this is not always possible.  We currently have a sprint with team members in the US, Australia, Europe, and India.  In this case, our daily scrum meeting is at 9:30 PM US PT.  Because we keep our scrum meeting less than 15 minutes, a team member in the US typically works 15-45 minutes in the evening in this case.  15 minutes or less for scrum meeting, and another 15-30 minutes to have quick discussions with other team members or product owner.

Q: What about the stand up meetings? How do you manage to run a visual management between different timezones?

Stand up meetings or daily scrum meetings are not a project status meeting.  You do get to know the status of each team member as a by-product, but that is not its purpose.  Usually at Codesion, we don’t have a visual stand up meeting. The team members answer the three questions – (1) what did you do today, (2) what are you doing tomorrow, and (3) what, if any, impediments are you facing? The meeting lasts no longer than 15 minutes and generate follow-up discussions that happen after the stand up meeting between team members.

Q: Does your tool allow for both stack ranking of PBIs as well as grouping?

Yes.  TeamForge Project can do stacking ranking as well as grouping on category, additional custom fields that you create, or via planning folders.

Q: What technique do you use to split large projects into ones with 100 PBIs or less?

Potentially, you can break the project into Phases.  Another way to do this would be to have a higher level Epic that contains many user stories.  Therefore, in the planning folder, you will see Epic with children user stories.

Q: Does TeamForge Project also offer a task board where you can move cards during a sprint?

TeamForge Project does not have a task board per se, but via planning folders, you can categorize and tag each product backlog item (PBI).  The Rank feature allows you to move the stack ranking within the web browser.

Q: What is the difference between a folder and a category?

It is up to you on what definition you want to use to taxonomize your Product Backlog. You can define category as development, infrastructure … etc.  Or different product components.  The planning folder is just another way to categorize.

Q: How do you manage Story Point assignment between different seniorities in your team?

I think this question is asking how best to assign a particular task to a specific team member based on their seniority and experience.  The answer is that the team has to decide who does what, not the Scrum Master or Product Owner.  Remember, each user story, with story points, are broken down into tasks.  Therefore, the team should discuss, together, who is the best and most effective person to take on a task, at the same time taking into account distributing the load across team members.

Q: Can tasks associated with a user story be assigned across people on a team (i.e., some tasks to one person, some to another)

Yes, user stories can have many tasks, with each task being assigned to a single person.  Within TeamForge Project, you cannot assign a task to more than one person.

Q: How do programmers know certain number of story points equal one week? (if they only have the user story and not a detailled design?)

Sometimes it is helpful to translate 1 story point to number of work hours.  For example, my scrum team came up with 1 story point = 1 person’s work week. Therefore, if we run 4 weeks per sprint with 4 resources, that is 16 story points the team can do in a sprint.

To answer the question on detailed design, the story point is just an estimate, so you do a best effort estimate.  If you don’t have enough information to estimate, take the time to do some research. Time box 1 day of research and get a better estimate for the sprint versus ‘guesstimating.’

Q: Where does IA/UX fit into this?  Is there an element of it before a Sprint starts?

Most user stories assume that you will need UX design.  In a brand new project, you may want to invest time into UX design before the sprint starts.  That way, your user story can include documents and images on the UX.  If it is an existing project, chances are that you already have an existing UX.  Therefore, if you are making improvements like adding a new input box in an existing UX, that may not require extensive UX design before the sprint.  It may just require a quick conversation with the product owner to make sure the team member knows where to place the input box and following existing UX design guidelines.

Q: How do you integrate user interface in your process? Do you have wireframes done before?

This is similar to the previous question.  Yes, in a new project, you may want to do wireframes before the sprint starts if that is necessary.  In fact, if necessary, you can run 2 week UX Design sprint if needed.  At Codesion, we do wireframes or mockups depending on the project.

Q: How do you specify in the product backlog the dependencies that certain PBI have? (i.e. meaning PB3 cannot start if PB2 and PB1 are complete?)

As much as possible, I would avoid dependencies between user stories.  The reason is that it quickly becomes unmanageable.  There are several ways to work through this problem.  For example – lets say that you have one user story that is a report (story A).  You have another user story that aggregates the data that the report requires (story B).  It would seem that A depends on B.  However, that is not necessarily how you run the project.  You can, with a conversation, figure out what data fields that your report needs, and agree on the format of the data.  Once you have that, you have removed the dependency between A and B.  As long as story B results in the specific data fields and format that A requires, both can work separately.

Q: Can you print out user stories in a notecard format? I find that product owners like being able to move cards around on a table to rank.

It’s a great suggestion. I’ve even seen people use sticky notes on a wall. With our team being distributed across the globe we haven’t had a need for this and I do not believe this is available in TeamForge Project.

Q: Can you create a project burndown chart in addition to a sprint burndown chart?

Yes, you can via planning folders.  For example, you have a planning folder called Project 1, in Project 1, you have 2 sub-folders called Sprint A and Sprint B.  Both Sprints are monthly Sprints that begin 4/1/2011 and end 4/30/2011.  You can view the aggregated burndown chart in the Project 1 planning folder, and also each individual Sprint burndown chart in the Sprint A and Sprint B planning folders.

Q: How do we manage using this tool if the product owner keep adding tasks into one sprint.

A product owner in Agile Scrum methodology should not do this in the Sprint Backlog.  He can add as many PBIs that he wants into the product backlog, but not in the sprint backlog once the sprint has started.  If the team finishes PBIs in the sprint log early, then the team can pull additional PBIs from the PB.

The product owner does not push – only the Team, with the Scrum Master facilitating, should decide when to pull additional work.  However, there are cases where you work in an interrupt driven environment where you always have crisis and emergencies.  In that case, I don’t recommend using Agile Scrum.  Instead, I’d recommend Agile Scrum-Ban.

Q: Who determines the amount of story points for each user story?

The team members.  Not the Product Owner or Scrum Master.

Q: I see that ScrumWorks Pro is coming soon to Codesion’s Professional Edition product.  What are the key differences between using TeamForge Project and ScrumWorks Pro for managing product backlogs and sprints?

ScrumWorks Pro (SWP) is specifically designed for the Agile Scrum process, where TeamForge Project has additional application lifecycle management features in addition to Agile Scrum planning, such a document repository, wiki, discussions, and file releases.

If you just want a simple, Agile Scrum specific tool, SWP would be a good choice.  If you use multiple methodologies (including waterfall), and you need other capabilities like document management, SVN commit integration, traceability throughout your application lifecycle, then TeamForge Project would be better suited for you.

Q: Do you plan to add Git support to TeamForge Project?

Yes, in the future. It’s on our roadmap for later this year.

Q: If the team hasn’t met the committed number of story points for a few sprints, do you recommend the Scrum Master setting a cap on future sprints?

That would not be the approach that I would like.  If I was the SM, I would ask the team on why the team does not meet the committed story points.  Are the team members getting interrupted?  Are there team problems?  Are there morale issues?  Are there conflicts within the team?  Or perhaps there are systemic problems in the development process.

One of the key tenets of Agile is continuous improvement.  Therefore, I would want to see if we can use automated testing, continuous integration (CI), or other ways to improve the team.  If it is true that nothing helps the team to achieve the story points (though I highly doubt this would be the case), then perhaps the team just over-estimates how many story points they can accomplish.

Previous Article
Open API this…Open API that…BIG DEAL right?
Open API this…Open API that…BIG DEAL right?

Well it kind of is! There has been a lot of “hoopla” around VersionOne’s Open API and how it provides users...

Next Article
Refactor Your PMP – Part 5: Communications Management
Refactor Your PMP – Part 5: Communications Management

As promised… next up we’re talking about Communications Management. According to PMI, Project Communication...