Devops et agilité
67.1K views | +0 today
Scooped by Mickael Ruau
onto Devops et agilité!

Canary tests | Blog Arolla

Canary tests | Blog Arolla | Devops et agilité |

Canary Tests are minimal tests to quickly and automatically verify that everything you depend on is ready. You run Canary tests before other time-consuming tests, and before wasting time investigating your code when the other tests are red. If the canary test fails, you know you have to fix something on the environments first.

This idea of Canary test is different from the Canary Deployment. In Canary Deployment you deploy to a small fraction of your users to check everything’s fine before rolling out to more users.
Mickael Ruaus insight:

Canary tests check for the obvious and frequent sources of issues, such as:

  • connectivity to network: firewall rules ok, ports open, proxy working fine, NAT, ping below a good threshold
  • databases and middleware are up
  • disk quota for logs not almost full
  • every needed login and password is valid
  • installed software available in the right version: dll installed, registry set-up, environment variables set, user directories all exist, the frameworks and OS versions are fit, timezone and locale are as expected
  • reference data integrity and consistency (dates, valuations…) are ok
  • database schema and audit of applied scripts are as expected
  • licences are not expired (there is usually a way to check that automatically)

Canary tests should run regularly, ideally before any expensive tests like end-to-end tests. Of course you want to run them whenever there is a trouble somewhere, before wasting time on manual investigations in your code when the expected environment is not fully available.

Even at the code level, a canary test is just a trivial test to verify that the testing framework works correctly, as mentioned by Marcus on his blog:


Don’t forget to verify that your tests can fail too!

No comment yet.
Devops et agilité
DEVOPS, agilité, tests, déploiement, sécurité
Curated by Mickael Ruau
Your new post is loading...
Your new post is loading...
Scooped by Mickael Ruau!

The Top 10 Benefits of Kanban | Nave

The Top 10 Benefits of Kanban | Nave | Devops et agilité |
Kanban can help you run your business better, make your processes more efficient and empower your team to accomplish more, faster. Learn 10 ways Kanban benefits your business!
Mickael Ruaus insight:

Traditional management methods rely on planning upfront and pushing the work on to your team. This results in teams struggling with more work than they have the bandwidth for. Kanban suggests the implementation of a pull system – the team pulls tasks into the workflow only when they have the capacity to do so.

One of the core Kanban practices is imposing work in progress limits on each process state. When the WIP limit is reached, no new tasks are allowed to enter that state until another task has left. WIP limits prevent teams from working on too many tasks at the same time.

No comment yet.
Scooped by Mickael Ruau!

Domptez vos refactoring avec la Mikado Method

Domptez vos refactoring avec la Mikado Method | Devops et agilité |

D’après une étude du « The Crash Report 2011 – 2012« , le coût de la dette technique est estimé à 3,6 millions de dollars pour une unique application de taille moyenne. Réduire cette dette est une nécessité pour pouvoir maintenir et faire évoluer un système d’information. Les développeurs doivent souvent travailler sur un code non testé, difficile à comprendre et à modifier, c’est ce qu’on appelle un « code legacy ».

Faire évoluer un code legacy est souvent considéré comme un art. L’artisan doit maîtriser des techniques et des outils mais aussi bien s’organiser pour ne pas se décourager face à la complexité de la tâche.

Une pratique importante qui est souvent négligée ; le refactoring du code legacy. Sans cette pratique nécessaire, la dette technique s’accumule et le coût des prochaines évolutions et modifications de notre code augmente. Un bon refactoring se fait en petites étapes (des baby steps).
No comment yet.
Scooped by Mickael Ruau!

Your Impact Outweighs Your Intention

Your Impact Outweighs Your Intention | Devops et agilité |
When I first became a Scrum Master, I heard the phrase assume positive intent over and over again. And it really resonated with me. It made sense. I started to notice how quick I was to jump to conclusions about other people’s intentions. When I check myself on the assumptions I am making about other people’s intentions, I am more effective at navigating situations in a positive and productive way. And my stress goes down.

However, in the past few years, I’ve noticed the phrase assume positive intent sometimes being used in a way that doesn’t feel good. I’ve seen it used in a way that limits inclusivity and shuts down productive conflict.

I still assume positive intent. This concept helps me be a better coach, a better trainer, a better colleague, a better friend. I even talk about assuming positive intent in my blogs and in the online course Scrum Master: Grow. I just knew there was something more to it.

And then I had the a-ha moment.
Mickael Ruaus insight:


“Your impact outweighs your intention.”

This statement was made at one of my Co-Active Leadership Retreats. And suddenly it all made sense.

While it is incredibly helpful to assume positive intent when we engage with others, that does not mean we give people a free pass. It does not automatically make their words and behaviors okay.

Because leadership is about owning your impact.

No comment yet.
Scooped by Mickael Ruau!

The original Lean "versus" Agile for knowledge work - or is it "and"?

The original Lean "versus" Agile for knowledge work - or is it "and"? | Devops et agilité |
"When will it be done?" is a damaging question when dealing with complexity & uncertainty. Leadership needs to be about blaming those who fail to help or who fail to ask for help, over blaming those who fail. According to Richard Hackman's research, over 80% of a team's performance is determined by structure, with <10% from coaching after team setup. Indeed, the counter-measures to the 5 dysfunctions of a team are remarkably similar to the Scrum values. Daily Huddles and War Rooms tend to get facilitated by senior leaders. Lean & Agile can provide alignment , and the level autonomy depends on the level of servant leadership. Taken to the extreme, command & control with blame game is a good strategy to bring about the 5 dysfunctions of a team. I put it to you that the ideal for dealing with complexity 21st century is aligned autonomy, self-managing teams, and Team of Teams.
No comment yet.
Scooped by Mickael Ruau!

Building Resilient Teams

Building Resilient Teams | Devops et agilité |
Research suggests that reaching true mastery of a field requires 10,000 hours of deliberate practice. What exactly is needed to grow passion and perseverance to endure such an effort?
No comment yet.
Scooped by Mickael Ruau!

Development Team Anti-Patterns

Development Team Anti-Patterns | Devops et agilité |
After covering the Scrum Master and the Product Owner, this article addresses Development Team anti-patterns, covering all Scrum Events as well as the Product Backlog artifact. Learn more about what to look out for if you want to support your fellow teammates.
No comment yet.
Scooped by Mickael Ruau!

Causes for Zombified Interaction between Scrum Teams and Stakeholders

Causes for Zombified Interaction between Scrum Teams and Stakeholders | Devops et agilité |
The article explores the primary causes of zombified interaction between Scrum Teams and stakeholders.
No comment yet.
Scooped by Mickael Ruau!

Agile Forecasting Techniques for the Next Decade

Agile Forecasting Techniques for the Next Decade | Devops et agilité |

SLE – The forecast at the Day and Iteration layers

To talk about forecasting at the Day and Iteration layers, I use the Service Level Expectation (SLE) as defined in the Kanban Guide for Scrum Teams.

A service level expectation (SLE) forecasts how long it should take a given item to flow from start to finish within the Scrum Team’s workflow

For example, let’s say that historically, your development team completes 85 % of its PBIs in 8 days or less. This is our forecast for an item. It has a calculated date range, 8 days or less, and a probability, 85 %.

As a PBI is moving through the Scrum Team’s workflow, I use its current age in the workflow and compare it with its corresponding SLE to make sure it will meet its forecast.

At our daily Scrum, we can use this forecast to keep track of our current work. If my PBI has been in the workflow for 3 days, I might not pay as much attention to it compared to another PBI who is now to its 7th day in the workflow.

Instead of using tasks with estimated hours on it to track its remaining work, we use the combination PBI age + SLE to monitor if we will meet our forecast. I believe these are two data points of value to track work. I also think they are more valuable than estimated hours. I am using hard data (age and SLE) to track work.

I believe this fixes both problems named above. My team doesn’t spend any time estimating each task. It can still decompose the PBIs if required. But we compare the age of the PBI with the SLE of the team. My team uses a probability in its forecasting, thus leaving the door to some uncertainty that can prevent it from meeting the SLE.
Mickael Ruaus insight:

Throughput and Monte Carlo – The forecast at the Release and Product level

As we go higher in the layers of the onion, we move the conversation from one PBI to multiple PBIs. At the Release and Product layers of the onion, the Product Owner is now talking in terms of multiple PBIs.  For example, a Product Owner might have 54 PBIs left to launch a release. Or she might have a deadline to reach and wonders how many PBIs can be completed on that date. In both situations, forecasting the future can help her narrow her decsion-making process. And as we’ve seen above, forecasting the future requires a calculated value with a probability.

My experience has been that Monte Carlo simulations, using throughput as its input, can generate a forecast for those layers of the onion. Basically, the Monte Carlo simulations will use your historical throughput and simulate the future a large number of times (i.e. 10,000 times).

Let’s take the example above and see how the results of the Monte Carlo simulations can help the Product Owner. I had previously mentioned above the Product Owner has 54 remaining PBIs to complete her release. Running the Monte Carlo simulations with her historical throughput, she gets the following results:

Her first forecast, 25 days with 90% confidence, says there’s a 90% chance her team can deliver the remaining 54 PBIs of the release in the next 25 days. At the far right, there’s a 30 % chance they will deliver them in 16 days. She can now turn back to the business to discuss if 25 days is an acceptable number. If they prefer to have it in 14 days, she can reply the outlook for this scenario has less than 30 % of happening.

For a more detailed read on Monte Carlo simulations and a tool to help you do them quickly, I recommend the post Create Faster and More Accurate Forecasts using Probabilities from my fellow PST Julia Webster.

No comment yet.
Scooped by Mickael Ruau!

Slow Conversations For An Ever Faster Moving World

Slow Conversations For An Ever Faster Moving World | Devops et agilité |

A slow conversation follows these principles:

Making an invitation which allows conversation partners to truly engage openly
Accepting an invitation which allows conversation partners to truly engage openly
Taking the stance when listening of wanting to really understand
Understanding that when talking means truly being heard
Knowing that the conversation will remain confidential
Having no time pressure
Mickael Ruaus insight:

What makes a slow conversation different from a coaching conversation?

When you look at the principles above you might think these are simply guidelines for a good coaching conversation. The difference with the slow conversation is that both participants are there for each other, and the coaching or mentoring role can be exchanged throughout the conversation.

Coaching: the coach remains in an inquisitive, questioning stance with a complete focus on the coachee’s world. The coach offers no solutions, only questions to support the coachee in their thinking.

Mentoring: the mentor starts in a coaching stance and may then share their own experiences as impulses for the mentee.

Important: the mentor returns to a coaching stance after sharing their own experience. By asking whether their input has been useful ensures the coachee takes on the responsibility again for their own next steps.

This will need time at first to work well, however with practice will benefit the relationship in the long term as well as develop conversation skills for the future.

No comment yet.
Scooped by Mickael Ruau!

retrospective_principles [Retrospective Facilitator Gathering]

retrospective_principles [Retrospective Facilitator Gathering] | Devops et agilité |
I created the following 5 Retrospective Principles to use as a framework for explaining/presenting on retrospectives and training retrospective facilitators. I've found this approach useful as it adresses the “why” before getting into the “how”, so allows folks to more easily transform intention to practice(and, I hope, help to reduce the level of template-think!).

Also, as requested, here is the Dilbert Retrospective cartoon - dilbertslide.ppt
No comment yet.
Scooped by Mickael Ruau!

Peopleware Summary in 15 Tweets

Peopleware Summary in 15 Tweets | Devops et agilité |
If you truly are concerned with people, and looking for ways to improve how you collaboratively develop and deliver software, then Peopleware is a must read
Mickael Ruaus insight:

Here are 15 quotes from Tom DeMarco’s and Tim Lister’s book Peopleware, which I also tweet using #peopleware:

The manager’s function is not to make people work, but to make it possible for people to work
Staying late or arriving early or staying home to work in peace is a damning indictment of the office environment
An organization that can’t make some assessment of its own productivity rate just hasn’t tried hard enough

Your people bring their brains with them every morning. They could put them to work for you at no additional cost if only there were a small measure of peace and quiet in the workspace – this one is too large to tweet, but it’s a great quote!

If your people aren’t smart enough to think their way through their work, the work will fail. No Methodology will help
Voluminous documentation is part of the problem, not part of the solution process
Successful learning organizations are always characterized by strong middle management
Peopleware 3rd edition talks about stand-ups and open spaces. I like that!
It’s not reasonable to leave unmanaged the risk for which the consequences are “just too awful to think about”

Our meetings are worse today than they were a generation ago, because a generation ago people wouldn’t have been able to bear them—they would have revolted also too long, but boy, what a great quote!

The ultimate management sin is wasting people’s time
Change won’t even get started unless people feel safe
People feel safe when they know they will not be demeaned or degraded for proposing a change
Paradoxically, change only has a chance of succeeding if failure—at least a little bit of failure—is also okay

Experience gets turned into learning when an organization alters itself to take account of what experience has shown

No comment yet.
Scooped by Mickael Ruau!

Q&R au sujet de l’ouvrage The Professional Product Owner

Q&R au sujet de l’ouvrage The Professional Product Owner | Devops et agilité |
Points Clés

Les Product Owners ont besoin d’être plus que de simples scribes ou des proxies ; ce sont de véritables chefs de produit agile
Scrum est un outil pour la livraison de produit agile, pas pour la gestion de projet
Le Product Owner Professionnel possède un état d’esprit d’entrepreneur
Le Product Owner Professionnel est responsable de la vision, de la valeur et de la validation du produit
Passez votre produit à l’échelle, pas votre Scrum
No comment yet.
Scooped by Mickael Ruau!

Hypothesis-driven development: Get started with Enterprise Design Thinking - IBM Garage Practices

Hypothesis-driven development: Get started with Enterprise Design Thinking - IBM Garage Practices | Devops et agilité |
Continuous delivery demands the use of hypotheses, not requirements, to deliver what customers want. Developers embrace continuous experimentation and adaption.
No comment yet.
Scooped by Mickael Ruau!

Kanban Practices - The six core Kanban practices

Kanban Practices - The six core Kanban practices | Devops et agilité |
In this article we explain in detail the six practices of Kanban. The Kanban Practices The Kanban method is based on six basic practices to create an emerging set of positive behaviors in organizations and achieve better agility in the provision of services. These practices should be applied, reviewed and improved relentlessly: Visualize Limit work in progress Manage flow Make policies explicit Implement feedback loops Improve collaboratively, evolve experimentally Kanban, as a method designed for the evolutionary and continuous improvement of organizations and work processes, is greatly influenced by systems theory. Therefore, it seeks to generate emerging behaviors from the
No comment yet.
Scooped by Mickael Ruau!

Tempo du coach agile

Le coaching Agile m'a toujours fait penser à la musique, rythme, émotion, tension et résolutions... d'où ce titre "tempo" et ces deux questions : - Quel est le…
No comment yet.
Scooped by Mickael Ruau!

Clean Coders Hate What Happens To Your Code When You Use These Enterp…

Presented at ACCU (24th April 2015) It is all to easy to dismiss problematic codebases on some nebulous idea of bad practice or bad programmers. Poor code, how…
No comment yet.
Scooped by Mickael Ruau!

Lean Coffee in 5 Minutes

Lean Coffee in 5 Minutes | Devops et agilité |
Lean Coffee is easy to learn, empowers participants and increases engagement. It is also fun! Give it a try, learn in this video how shockingly simple. Get your own personal copy of the Lean Coffee Poster used in this video and use it as your facilitation guide for your next meeting.
No comment yet.
Scooped by Mickael Ruau!

The 4 Soils - Sprint Retrospective

The 4 Soils - Sprint Retrospective | Devops et agilité |
In every Sprint, Sprint Retrospective is an excellent chance to inspect and adapt the way of working.
No comment yet.
Scooped by Mickael Ruau!

3 Steps to Becoming an Agile Coach

3 Steps to Becoming an Agile Coach | Devops et agilité |
Completing an Agile Coaching certification doesn’t make you an Agile Coach. So where do you start and how do you chart your own journey?
No comment yet.
Scooped by Mickael Ruau!

Remote Agile (Part 2): Virtual Liberating Structures

Remote Agile (Part 2): Virtual Liberating Structures | Devops et agilité |
This follow-up post now delves into virtual Liberating Structures, answering the question of how we can make use of the powerful toolbox of inclusive and collaborative practices in a remote setting.
No comment yet.
Scooped by Mickael Ruau!

Sprint Planning : 5 Dysfunctions

Sprint Planning : 5 Dysfunctions | Devops et agilité |
Every Sprint starts with a Sprint Planning event. It is very crucial to ensure that the Scrum Team comes to a shared understanding of what and how are they going to deliver a “Done” increment that creates maximum business impact. Although, like other events Sprint Planning also is often marred with few dysfunctions. In this post I will bring forth 5 common dysfunctions that I have observed associated with this event.
No comment yet.
Scooped by Mickael Ruau!

Extreme Programming Playing Cards

Extreme Programming Playing Cards | Devops et agilité |
We’re pleased to announce the world’s first deck of Extreme Programming Playing Cards. We created this 100-card deck to help people refine their understanding of Extreme Programming, improve the way they practice XP and have fun learning.

The deck consists of Problem, Solution, and Value cards, each of which has one letter on it:

P = Problem Card
S = Solution Card
V = Value Card

There’s also a Joker since every deck must have a Joker!

Explanations, XP War, Retrospective Roulette and Value Squares are educational games you can play with your deck of cards.
Mickael Ruaus insight:

Here’s a list of games you can play with your deck of Extreme Programming Playing Cards:

  • Explanations This game will challenge your knowledge of XP problems, solutions & values. The game is fun for both new and experienced XPers. We’ve recently created electronic explanations.
  • XP War This game, which is based on the old family card game War, is a fun way to learn about XP solutions and how some are more important than others. This is a fast-paced game that is fun for both new and experienced XPers.
  • Retrospective Roulette This game helps real XP teams assess how they are doing on their XP project. The game can be played during Iteration Retrospectives or during a final Project Retrospective.
  • Value Squares This game helps you learn how XP’s Values - Courage, Communication, Feedback and Simplicity - map to XP’s many practices.
No comment yet.
Scooped by Mickael Ruau!

AFH 095: Exploring the 3 V’s of Product Ownership With Ralph Jocham and Don McGreal

In this episode of the Agile for Humans Podcast, Don McGreal (@donmcgreal) and Ralph Jocham (@rjocham) joined Ryan Ripley (@ryanripley) to discuss their new book The Professional Product Owner: Leveraging Scrum as a Competitive Advantage.

No comment yet.
Scooped by Mickael Ruau!

The Clean Architecture Dependency Rule | The Dependency Rule | InformIT

The Clean Architecture Dependency Rule | The Dependency Rule | InformIT | Devops et agilité |
Learn how to apply the Dependency Rule to your software architecture to create a more testable system.
No comment yet.