background preloader

Scrum

Facebook Twitter

En route vers l'agilité, SCRUM et XP retour d'expérience. En recherchant à m'améliorer, je me suis mis à m'intéresser aux meilleures pratiques de développement existantes.

En route vers l'agilité, SCRUM et XP retour d'expérience

J'ai commencé à regarder les Design Pattern et les outils facilitant le développement, le test et les livraisons dans un esprit Usine Logicielle en naviguant entre les différentes communautés ALT.NET, XP... Petit à petit ma sensibilité envers ces pratiques m'a poussé à mieux connaître ce type de méthodologie. J'avais des envies, comme tout développeur, d'améliorer mon quotidien, de ne plus me plaindre du client qui nous met la pression, de pouvoir travailler sur la qualité et de maîtriser les éléments pour produire dans des meilleures conditions. III.A-1. Le livre qui m'a sensibilisé▲ J'avais l'envie, je connaissais des pratiques, mais je n'avais pas de ligne de conduite.

Il a suffit d'un livre pour que j'y voie un peu plus clair. Ce livre offre une expérience accessible et détaillée du déroulement d'un projet Agile, il est aussi disponible en version française : III.A-2. Learning Matrix - Innovation Games. Goal: Think of Effective Improvements for Your Iteration Iteration retrospective activities are tricky; it is often difficult to think of practical improvements, and reflecting on negative aspects of the project can leave your team feeling upset and unmotivated.

Learning Matrix - Innovation Games

A great way to prevent these from occurring is to play a game that focuses on the positives while also pointing out aspects that need to be changed. As described in Diana Larsen and Esther Derby’s Agile Retrospectives, Learning Matrix does just this. In this game, teams collaborate to identify what they liked and disliked about a past project, and to point out whom they appreciated and what they believe should be altered for the future.

Whether analyzing the results of a conference, product, or meeting, Learning Matrix can help you uncover your top-priority items to enhance your iteration. Before your meeting, create a 2×2 matrix. Provide players with plenty of sticky notes and markers. Here is this page’s HTML code. A Productivity Comparison of Kanban and Scrum. Scrum is a great agile management framework for iteratively developing complex software systems, and it works well in many circumstances.

A Productivity Comparison of Kanban and Scrum

Certain problems can arise, however, such as a highly fluid product backlog, which make kanban’s emphasis on backlog flexibility a more attractive alternative. Software experts like David Anderson, Corey Ladas, Dean Leffingwell, and Linda Cook point to small, loosely coupled user stories with an experienced agile team as key factors for productivity gains using kanban. Yet, few studies exist to show concrete metrics in productivity gain. In this article, I explain our application of reasoning for using kanban and then show how I computed that our productivity gains were more than 300 percent once we started using kanban. I conclude this article with thoughts on applying kanban in your circumstance. The ProblemWe were in trouble. While agile encourages change, the process cannot be chaos. Is it Time to Stop Estimating User Stories? Most new Agile teams transition from hours based estimates to relative estimation using story points, but do we even need estimates at all?

Is it Time to Stop Estimating User Stories?

Michael Dubakov suggests the following reasons why you should stop estimating user stories: You don’t waste time on estimation You shouldn’t explain to higher managers why it took soooo loooooooong You don’t give promises that are hard to keep You don’t put additional pressure on development team You focus on really important things Stephan Schwab, worries about how estimation can result in silos and prevent team based solutions: Imagine an organization where teams are expected to have a fully estimated backlog in order to determine the cost for the project.

At first glance such an approach seems to be a good idea. Mike Cottmeyer comes to the defence of estimates: Since we don’t like managers and we don’t like death marches, we conclude the creation of software is an unpredictable process, that estimates are bad, and we should never estimate at all.