Le mousquetaire agile: Spécifications Agiles : User Story ou pas User Story. En Scrum, les spécifications sont abordées par la constitution du Backlog Produit.
Il est alors courant d'utiliser des User stories. Mais au fait, qu'est-ce que c'est exactement qu'une User Story ? Et en quoi celle-ci se différencie t'elle d'autres méthodes d'expression du besoin telles que les Use Case, ou les Requirements ? Je vous propose ici de voir plus en détail cet objet étrange qu'est l'histoire utilisateur, et de la comparer à d'autres approches pour réaliser des spécifications Agiles.
Réussir des « standup efficaces autour du tableau Kanban (repost) Effective Standups around Kanban Board par Pawel Brodzinski Vous pouvez entendre ici et là que Kanban s’adapte plutôt bien aux grandes tailles.
En réalité, un des problèmes de Scrum auquel je pense on ne s’est pas soigneusement attaqué, est que faire dans les projets qui nécessitent davantage de personnes qu’une unique équipe Scrum puisse rassembler. Write Better User Stories. The third in a three-part excerpt from Chapter 5 of Introduction to Agile Methods (Pearson/Addison-Wesley Professional, June 2014) by Sondra Ashmore and Kristin Runyan.
Agile has a firm distinction of the line between what the product owner owns and what the Scrum team owns. The product owner is responsible for ensuring that the company builds the right product (the What); the Scrum team is responsible for ensuring that the product is built correctly, or the right way (the How). Engineering culture (part 1) Here’s part 1 of short animated video describing our engineering culture (here’s part 2).
This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears to be mostly true for most squads most of the time :o) Squad Health Check model – visualizing what to improve. (Download the cards & instructions as PDF or PPTX) (Translations of this article: Chinese, French) A lot of companies experiment with ways of measuring and visualizing how their teams are doing.
They’re usually called “maturity models”, and involve some sort of progression through different levels. The intent of these types of models is usually benign – for example managers or coaches in larger organizations who want to get a sense of where they should focus their improvement efforts, spot systemic problems, and help teams become more self-aware so they can focus their improvement efforts too. We prefer to use other terms like “health check model”, because “maturity” sounds a bit… well…. patronizing. Plus, most of our models don’t involve progressing through different levels, and the primary audience is the team itself rather than management.
Making Kanban work in matrix organizations. Blend the principles of flow, queues, theory of constraints, Lean, and Six Sigma to concoct a very powerful message that I have come to believe over the years: ‘You’ve got more capacity than you think!
Use existing capacity to do more The Kanban Way. “Having allocated developers to the project and ensuring that they knew what needed to be accomplished, I was feeling very good about the project. After all, we had commitments from the team. Over the next few days, however, I realized that the team was not able to work on my project at all. Other high priority work demanded their attention.
For those of us working in matrix organizations, this is reality. If the above scenario sounds familiar, you are not alone. How Graphic Facilitation is Agile - Vancity. During graphic facilitation, I’m often asked, “but how do you leave enough space?”
People say to me that it’s “magic” watching the page fill up when everything fits just right. I can tell you that the balance of white space isn’t quite magic, although it can feel that way: there’s a plan behind what’s happening. It reminded me of working “Agile”. In change management, you want your team to work “Agile”: it’s about adaptability, speed and coordination.
That’s also a pretty accurate definition of graphic facilitation. A team at Vancity held an Agile Day, so I’m going to use this as an example to show how I planned out the session visually. To help you picture the event, there was over 100 people in the room and a structured agenda. Adaptability: Plan ahead, but be flexible The first key to success in graphic facilitation is planning ahead and working closely with the facilitation team. Agilité organisationnelle. Wiki Ayeba - 42 tâches qui font partie du boulot de Scrum Master. How to Build a Kick-ass Agile Team. Agile visionaries believed that teamwork is essential to delivering great software and that great agile teams embody "we" rather than “I.
" Nothing is more rewarding than sharing the adventure of building something that truly matters with engaged teammates. Despite sharing common values, there is no formula for the perfect agile team. Some implement scrum while others use kanban. Agile purists prefer co-located teams, but business realities sometimes necessitate distributing an agile team across geographies. Most agile teams possess all the required skills, but sometimes it's necessary to call on specialists for specific work. Build upon a solid foundation After a team reaches the performing stage, development truly becomes awesome.
Here's the catch: reaching the 'performing' stage is impossible if a team's make-up shifts a lot. Keeping agile teams intact takes some organizational discipline, but it pays to protect the team–within reason, of course. What It Takes to Develop an Agile Transformation Strategy. Okay… this is going to be a precursor to a more fully developed whitepaper, but I want to see if I can tightly articulate the LeadingAgile approach to designing and executing an enterprise agile transformation.
This post is going to focus on the ‘what’ and leave out the ‘why’ and the ‘how’ for the time being. We’ll get back to those as the conversation progresses. Any agile transformation starts by understanding of what the end state of your organization looks like and how that organization will coordinate to produce integrated value for your customers. We do not believe that these patterns are intuitive or that most organizations will emerge into them. Therefore we define them up front. That architecture is made up of the following 3 key areas: 1. 2. 3.
Any large scale architecture, organizational or otherwise, is just a bunch of theory until you exercise it and prove that it works. At LeadingAgile, we believe in an incremental and iterative approach to adopting agile. 1. 2. 3.