Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

After adopting Agile for a while now, we started to think that we can improve how we do Agile. But for starter, we need to know how well are we doing now and to identify the problems in our current processes before we can improve it.

One thing we notice is that every team do Agile a little different from another. A ritual might works well for one team but not for another team. So we want to identify these incompatibilities in our team. What are the common tools/methods that your organization uses to identify these problems?

share|improve this question

closed as too broad by MichaelT, gnat, mattnz, Bart van Ingen Schenau, GlenH7 Dec 9 '13 at 13:59

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

4  
Are you shipping on time, with high quality, what the customer asked for? The processes exist to serve these common goals, so the common metrics for success apply regardless of yhow you get there. –  Telastyn Dec 9 '13 at 4:05
1  
Each team having its own rituals/tools is not a bad thing. Every team and every project is different. It's normal that one set of practices wouldn't work everywhere. –  MetaFight Dec 9 '13 at 8:54
    
You are right. I think I'm asking the wrong question here. Though the initial focus was about the effectiveness of the rituals, but it looks like it's more important to ask questions like the ones @Telastyn suggested. –  Phelios Dec 10 '13 at 2:16
add comment

2 Answers

Have you tried (company-wide) retrospectives?
Generally, it's a moment where the team comes together, usually after a sprint, to discuss what went well, what didn't go well, what they should start doing, what they should do more, what they should stop doing. At the end, you should have one or two actionable improvements to implement for the coming sprint.

Usually, this is done per team, but retrospectives can scale up to a whole organisation. However I would recommend an experienced facilitator for this. If it goes badly, you won't easily get a second chance to do it company-wide.

Holding retrospectives is an art in itself; you could take a look at using gamestorming to facilitate these retrospectives: http://www.gogamestorm.com/
This is one technique which was very well received where I work: http://www.scrumalliance.org/community/articles/2013/february/iteration-retrospective-activity-turn-the-tables
One last caveat: don't do the same retrospective technique everytime, people get bored easily.

share|improve this answer
    
Yeah.. Retrospective is not very effective so far. +1 for the lists!! –  Phelios Dec 10 '13 at 2:18
    
@Phelios Yeah, I can relate, they're difficult to get right. In my experience, you definitely need a facilitator (someone who moderates the discussion but generally stays out of it) and it is highly recommended to follow some sort of structure. This can be as simple as a post-up, or you can use one or multiple gamestorming games... If there's no facilitator and no structure, you usually wind up with a bunch of people talking about nothing specific and with a lot of important stuff that remains untouched. –  Stefan Billiet Dec 10 '13 at 7:18
add comment

Here's what we focused on after implementing Agile:

  • Are your story definitions getting better?
  • Are your storypoint estimates getting better?
  • Is the team's velocity improving?
  • Are you holding end-of-sprint retrospectives?
    • Are you addressing the issues raised in these retrospectives?
  • Do you have a good Product Owner
    • Is your Product Owner actually owning the product, or do other roles in the team pick up their responsibilities?
  • Are you good at keeping a Sprint's content fixed?
    • Will you cancel a Sprint if failure is unavoidable?
    • will you cancel a Sprint if the requirements have changed too much?
  • Is the culture one of no-blame/every body is equal?
  • Are you automating your regression testing?
    • This is key for an iterative approach
  • Do you have the necessary tools in place?
    • Source control
    • Continuous integration
    • Scripted deployments
    • TDD or BDD
  • Are you addressing the technical debt association with iterative development?
    • Are you doing periodic refactoring/hardening sprints?

And there are more, but I haven't had my second coffee yet.

You'll find that, at first, there's always room for improvement. But gradually the team will fall into its groove and begin working like a well oiled machine. At which point you'll start seeing less and less improvement between sprints. That's OK, though. It just means you're approaching the team's optimal efficiency.

Once at this point, it's still important to constantly be self-evaluation. Don't stop having retrospectives. Don't stop asking how you can make things better.

Oh yeah, and a Scrum Master (if you're doing Scrum) should be able to help you with all this. I say should because in my experience the importance of a trained Scrum Master is usually under-appreciated. The role typically falls onto the Project Manager whom does not have the training to play the role.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.