RICE: Prioritizing Roadmap/Backlog by (Reach + Impact + Confidence) / Effort

Reach: how many people will this impact? (Estimate within a defined time period.)

Impact: how much will this impact each person? (Massive = 3x, High = 2x, Medium = 1x, Low = 0.5x, Minimal = 0.25x.)

Confidence: how confident are you in your estimates? (High = 100%, Medium = 80%, Low = 50%.)

Effort: how many “person-months” will this take? (Use whole numbers and minimum of half a month – don’t get into the weeds of estimation.)


Não Existem Rituais ou Cerimônias Ágeis

Um pedido que tenho: parem de utilizar os termos “rituais” ou “cerimônias” ágeis.

Parem. Por favor, parem.

Por quê? Rituais e cerimônias trazem o significado que é um culto, algo religioso, algo que deve ser feito sem questionar. Ágil não é uma religião, não somos “xiitas” em seguir diariamente os mesmos processos.

Lembre-se do primeiro valor do Manifesto Ágil: “Indivíduos e interações mais que processos e ferramentas”. O processo sim é importante, mas é um meio para indivíduos trocarem conhecimento e alinharem seu trabalho através de interações. Não são ritos, nem cerimônias a serem repetidas sem questionar.

Lembre-se do primeiro princípio do Manifesto Ágil “Nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de software com valor agregado.” Nossa maior prioridade não é, absolutamente não é, seguir o processo.

Utilize os termos reuniões ágeis, workshops, encontros, open spaces.

Busque melhoria contínua sobre reuniões. Reflita e adapte frequentemente o próprio processo.

Em nenhum lugar do Guia do Scrum se fala em cerimônias ou rituais. Apenas reuniões. XP, mesma coisa. Método Kanban? Idem.

BDD Scenarios should be automated

Last February, I had this conversation with an agile coach (AC) at an organization in an agile transformation:

AC: – “We started up on BDD today!”

Me: – “Really? That’s awesome! Automating scenarios?”

AC: – “No, just writing scenarios.”

Me: -“So it’s not BDD… It’s specification by Example.”

AC: -“Why not? BDD doesn’t need test automation.”

Me: -“We can say that’s half way to BDD. Scenarios shall be automated after writing it.”

After few minutes, no agreement.

Lean Inception is About Making People Awesome

Lean Inception is a method to build a product focusing on Minimum Viable Products. MVPs like Lean Startup. It can help small or large organisations to realise what’s the priority to build next. It addresses a week-planned agenda with Product Development and UX techniques like Elevator Pitch, Personas, User Journeys, Brainstorming and Sequencing of Features, and the Canvas MVP, the proper result of a Lean Inception.

It was developed by the easygoing-geek genius Paulo Caroli from need. With his newborn son in 2011, it was virtually impossible to balance work and family running an old-fashioned Inception for weeks. More constrains, more creativity. Lean Inception was created to accomplish a product inception in a week.

A facilitator leads the process. Key business and product people do a kick-off presentation in the beginning about what shall be about the product, and for who. The team attends the entire 5 days agenda, presenting the results to those interested in the MVP(s).

However, even Lean Inception is a method, it’s not just about to build the next MVPs. As Dwight D. Eisenhower said “Plans are worthless, but planning is everything”. A perfect MVP planned is worthless without people engagement.

Lean Inception is about making people awesome, engaging them to build an awesome product.

Awesome because they are part of the process, part of the product. They feel like owners of the product, because they helped to decide what to build. Even business knows what to build and UX decided for who, it’s very important encouraging the team develop the product too, doing the Elevator Pitch and sketching Personas.

Take a look at the satisfied and happy people after a long day of the serious-fun training of Lean Inception. They are awesome. Photo taken at my first class as a Lean Inception trainer.

Discover more about Lean Inception at martinfowler.com/articles/lean-inception/ or reading the Lean Inception book.

Enterprise Agile Coaching: The Ivory Tower Syndrome

The Ivory Tower Syndrome happens when top management decisions are disconnected from the reality of the organization. Enterprise Agile Coaches are in the Ivory Tower when they are dealing with agile transformation decisions without spending time in the Gemba.

Gemba means factory flood in Lean manufacturing, which means where the Value Stream are really happening. If you are not looking into the place where the root problem is happening, it’s not easy to find a proper solution. Otherwise, are you working on plans and presentations? Thinking about process and tools? Hum…

I have been working as an agile coach since 2013. So in 2018, I worked as an Enterprise Agile Coach for six months. I was happy in the beginning, very hopeful to make impact in the organization. In the midst of it, I realized I was working mostly with managers, leadership, surveys, organizational assessments, that I was in the Ivory Tower. Ouch. That hurts. I was not happy, but hopeful. So when I perceived all that plans were not really happening, I felt being like a failure, then I had to ask to leave.

To avoid the the Ivory Tower Syndrome, the Enterprise Agile Coach must go to the Gemba. Not just going, but working on there with individuals and teams.

I believe the name Enterprise Agile Coach is wrong. Agile is about individuals and interactions. Coaching is about unleashing the best version of individuals and teams. It is a kind of contradictory having this name when the role is working far away from the value stream. Maybe the name Agile Transformation Consultant/Mentor/Specialist can be much better.

So there on the top where the Enterprise Agile Coach most works, in the Ivory Tower. Unless they are going to the Gemba.

There’s a Zen quote I remember about it.

“From the pine tree, learn of the pine tree; And from the bamboo, of the bamboo.”

Matsuo Bashō, Japanese poet

From the teams, learn of the teams. It doesn’t matter how much assessments, surveys, the Enterprise Agile Coach works on.There is no better assessment than going to listen to the teams and understand things that cold assessments would never tell.

Go to the Gemba everyday.