Contribute and communicate
One of the most difficult things to accomplish in a lean software development environment is encouraging the team to contribute and communicate. I don’t mean the physical work, everyone does their part with the actual “work”. I am referring to the brain storming, the thinking “outside of the box”. All the other parts that come before the coding begins. The pieces of the “Team” puzzle.
In many dated development cycles input from individuals is not something that is encouraged. It was each man to himself. Attempting to transition a team to become involved to the degree that is called for can become a challenge.
As a product owner I could not accomplish any of what I do without my team. Communication between product owner (coach? leader?) and the rest of the team is crucial. I need them to help me to understand what they are talking about and they need me to interpret and filter what the stakeholders want and need.
Asking questions, encouraging them to give THEIR ideas is the first step.
How would you solve this problem?
What do you think we should do?
Why would you do it this way?
Why wouldn’t you do it that way?
What value will this bring the end user?
When we sit down together to plan a new piece of functionality or to talk through a bug that we need to fix it takes a good bit of coaxing to get everyone to share their ideas. This becomes more of an issue in a lean environment where the teams are encouraged to be involved.
By allowing each person to be an individual; thinking for themselves, making their own decisions, acting on these thoughts, with conviction and confidence; we can add credence to the “definition” of Lean.
This leads me to something that I have read and heard numerous times from Jim Benson. Jim often talks about a development team being like a football team. Everything that one person does affects everyone else on the team. Lean software development is a much more mature and involved process than waterfall, for example. The flexibility of lean takes maturity and cultivation to make the best use of the benefits that come with it.
By asking the right questions, having the patience to wait for an answer and respecting the other people on the team to allow them the time to sort through the question on their own is the first step in making this transition successful. Contributing and communicating must occur through out the entire development cycle, from planning to release.
Finding the best way to encourage this contribution from every member of your team is, in my opinion, THE most difficult hurdle of the entire process. We each bring something unique and different to the group. Acknowledging these traits and honing in on them is a way to think lean. Thinking lean will allow you to develop lean, and deliver quality software.
After Ultriva Electronic Kanban Implementation Lean Metrics Prove Impressive
manufacturingreport.netArticle by at 2011-01-05 16:53:42
Categorized in Kanban,
just do what works: meetings
A common gripe amongst agilists is that the traditional “meeting culture” in many companies is choking the life out of agile.
While there may be some truth to that, I’ve also seen many misconceptions about the agile meetings themselves. I’ve even heard accusations that teams I’ve worked with (and agile teams in general) spend all of their time in meetings. That viewpoint may have been biased on someone’s experience with a particular team or purely based on something that was heard or read about scrum/ agile ceremonies.
When coaching teams, one thing I would implore of them is to focus on having only the bare minimum of meetings needed and to have that in bold letters in their team working agreement. This requires a bit of trial-and-error to hone in on the right rhythm for a given team. I’d argue that this approach is far more effective than taking someone else’s word for it. This is a really important element of eliminating waste that all parties involved must be vigilant about.
That said, I feel that the notion that meetings are inherently evil and must be eliminated entirely is very shortsighted - I find it amusing that many agilists take that kind of a stance. What agile really boils down to is intelligent people solving complex problems with “just enough” information to go off of. It’s silly to expect that there will never be a need for some meetings/discussions/ceremonies/whatever-you-call-them in order to step up to the challenges that are asked of a self-managed team.
No One Told the Customer! The Importance of Validation
Too many organizations I work with either gloss over this step or skip it entirely.
The process usually looks something like this:
- Customer reports a bug/requests a feature.
- Bug gets “fixed”/feature gets built.
- Bug/feature gets deployed.
- Profit?
It all seems well and good and you might expect “profit?” to be “profit!”, but is it? Did that bug actually get fixed? Does that feature actually solve the problem your client is having?
Most organizations don’t follow up to confirm that the customer is actually happy with the new situation or if they are even using the new feature! To make things worse, if the customer does complain that the bug isn’t fixed or the feature doesn’t solve their problem the response is typically, “We did what you told us to do”.
These days, being an order taker is not enough. If your organization sells itself on its ability to follow orders, then the customer will either go for the cheapest option they can find, or they’ll just do it themselves.
When customers come to you, they pay you to think! They’re looking for you to solve a particular problem they have. And someone who never validates the results with their customer isn’t a very good problem solver!
In one organization I worked with, we had set up a large Kanban-like wall that showed the progression of a feature through the system from when it was received until it had been deployed.
Once this wall had been setup and was being used, I added a column to the board called “Validated?” after the deployment column.
At first, the response was, “Well, it’s deployed, of course it’s validated” or “[internal person in the company] saw it and is fine with it”, to which I would typically respond, “Well, have they checked with the actual customer?”
In the latter case, the next time I checked in, the person had followed up with the internal person and discovered that no one had told the customer that their issue had been fixed!
This was a frustrated customer who was working around the issue in the interim and was very close to no longer being a customer. And now, a month after the bug had been resolved, no one had told the customer!
I wonder how many customers the organization had lost over the years just because no one told them when their problems were solved?
The impact of not validating your results is not just limited to customers. There is nothing more demoralizing and demotivating than working on a feature that never get used.
While investigating a separate issue, a developer I once worked with discovered that a feature he had spent three months developing had not been used once. He was furious! Three months of his time wasted on something no one was using!
Every organization I visit has a business case for why the feature they want should be built, but so few actually check that what they built was worth the effort.
That’s why it’s always important to build the smallest thing you can and validate it as soon as possible.
Today’s image by joeltelling.
Comment j’ai utilisé un Kanban
C’est quoi déjà un Kanban ?Vous entendrez sûrement ce mot si vous travaillez sur un projet en méthode Agile ou Scrum. Il s’agit d’une technique qui permet de faciliter la conduite d’un projet.
De mémoire (1), il a été inventé dans les usines Toyota pour suivre le bon déroulé des différentes opérations d’assemblage.
Comment ça marche ?On découpe son projet en tâches. Chaque tâche est matérialisée par un post-it.
On crée ensuite un tableau à l’aide de paper-board que l’on colle sur un mur : on y dessine des colonnes. Elles définiront l’état de la tâche (i.e. du post-it). On matérialise l’état initial dans la colonne la plus à gauche et l’état terminal dans la plus à droite. La vie d’une tâche, symbolisée par le déplacement du post-it, se lit ainsi dans le même le sens qu’un texte écrit en langue française.
J’ai choisi de suggérer l’importance d’une tâche par son positionnement dans la colonne : plus le post-it est placé, plus l’importance de la tâche est grande.
Mon KanbanJ’ai fait simple car il s’agit d’une première. Il est constitué de 3 colonnes :
- TODO : les tâches à faire
- ON-GOING : celles en cours de réalisation
- DONE : la tâche est terminée
Je me suis permis de véhicule de l’information par le biais de la couleur du post-it : chaque tâche appartient à un module, le module est caractérisé par 1 couleur. Mais ça n’est pas ni sale ni grave. En effet, pour reprendre la terminologie RGAA2, j’utilise cet outil dans un “environnement maîtrisé” : il sert à 2 collègues et moi et aucun d’entres nous ne souffre de maladie chromatique.
Quel est l’intérêt de cet outil ? Un outil pratique pour la gestion de projetSupport de dialogue (comme peut l’être une diapositive de Powerpoint), il facilite les choses quand on veut :
- se rendre compte du reste à faire;
- choisir le “à faire”;
- prioriser ou changer la priorité d’une tâche;
- se rendre compte des dépendances entres tâches;
- …
Les tâches, visibles de tous, apportent de la transparence au travail que chacun effectue. Le chef de projet devient responsable de ce qu’il a donné à faire. S’il manque des tâches, il doit l’avoir remarqué. Si des tâches n’avancent pas, aussi. Celui qui produit, sachant que l’avancement de son travail est visible, ne tardera pas à remonter un obstacle bloquant (impossible d’”enterrer” un sujet). Plus tôt on révèle un point de blocage, plus vite on pourra trouver une solution ou un moyen de le contourner.
Un moyen de motiverRendre visuellement l’évolution des tâches apporte un aspect ludique à la production : les tâches s’apparentent aux tableaux des jeux vidéos que l’on franchit séquentiellement. Chaque franchissement procure de la satisfaction. Cette satisfaction donne envie d’entamer la prochaine pour la finir et ainsi retrouver plus rapidement cette satisfaction. Au final, on “dépile” plus vite.
Lean / Agile Presentations
I couple of weeks ago I gave some trainings about Lean/Kanban and Agile core values and mindsets, later I will provide several blog posts to cover with more details that…
Mais posts no blog(http://diego-pacheco.blogspot.com/)
The NUMMI story
thisamericanlife.orgThe story behind Toyota and GM’s joint venture, their first joint factory in America, leadership lessons from Toyota and what all the Software industry can learn from this experience.
Ifs the movement towards scrum teams similar to the Toyota Kanban/Kaizen concepts?
Guerra a vista: Kanban vs Scrum
A elite da comunidade Scrum começou?
O líder da comunidade Kanban declarou guerra?
O melhor é tirar o foco de uma suposta disputa.
Ambos buscam estabelecer comportamentos complexos e elaborados através de regras muito simples – cambem em um página ou lista de 5 itens.
Tenha em mente que tudo fica muito mais simples quando se percebe que a agilidade está um nível acima de qualquer método ou prática.
Tendo capturado sua essência (da agilidade), você passa a experimentar qualquer ferramenta com maior liberdade e segurança.
Chuck Norris (Agile) Rules
( courtesy of Planbox)
- Chuck Norris always starts his projects with a Roundhouse-Kickoff.
- Chuck Norris is ScrumMaster and ProductOwner – simultaneously.
- Chuck Norris always wins at Planning Poker.
- Chuck Norris does not estimate, he knows.
- Chuck Norris can do 6-month sprints.
- Chuck Norris does not move story cards, he moves the taskboard.
- When Chuck Norris says “done”, believe me, it’s “done”.
- Even Chuck Norris is not allowed to be late at the stand-up meeting. Now you tell him.
- Chuck Norris can do a thousand sit-ups during the stand-up meeting.
- Chuck Norris answers just two questions on the stand-up meeting. Chuck Norris does not know obstacles.
- Chuck Norris is not afraid of bugs, bugs are afraid of him – really afraid.
- Chuck Norris does not do Kanban. He cannot get any leaner and he’s always there just in time!
- Chuck Norris pairs alone.
- Chuck Norris doesn’t do burn-down Charts, he does Smack-Down charts.
- Chuck Norris doesn’t iterate. It’s right the first time, forever.
Trello
trello.comAplicativo Online de Pipeline de tarefas, estilo kanban online.
Trello | Organize anything, together.
trello.comTrello is a collaboration tool that organizes your projects into boards. In one glance, Trello tells you what’s being worked on, who’s working on what, and where something is in a process.
Lean Thinking in Software Development : Impacts of Kanban on Projects
helda.helsinki.fiInteresting PhD thesis on impact of Kanban in software projects
