vincent tencé
Articles de vincent :
- Direct the rider
Provide clear direction to the analytical self, the Rider, to prevent over-thinking and wheel spinning. What looks like change resistance is often lack of clarity.
Use the following tactics:
- Find the bright spots
Focus on the success stories around the change you wish to see; duplicate the things that are working.
- Script the critical moves
Make the key steps clear. Describe specific expected behaviors; don’t talk in terms of big picture.
- Point to the destination
Describe a compelling purpose and paint an inspiring picture of the future. Change will be easier if people know where they’re going and understand why it’s worth it. People will start thinking about how to make it happen.
- Find the bright spots
- Motivate the Elephant
The Rider will rapidly get exhausted if controlling the Elephant, the emotional side, against its will. For action to take place you need to bring the Elephant onboard. The Elephant might be slow to get going, but once in motion, it goes a long way!
The tactics are:
- Find the feeling
Knowing we need to change is not enough for change to occur. We need to feel something to take action.
- Shrink the change
Make the change looks smaller. Big changes feel unattainable and spook the Elephant.
- Grow your people
Help people relate to an identity and shift to a growth mindset.
- Find the feeling
- Shape the Path
Most change problems are about situations and not people. Instead of trying to change people, change situations to make the process of change easier.
Use the following tactics:
- Tweak the environment
Make the change as easy as possible by changing the situation. Situation changes result in behavior changes.
- Build habits
Encourage new habits that reinforce the change. Automatic behaviors do no tax the Rider. Set triggers for change in the environment.
- Rally the herd
Use group dynamics to your advantage. Help new behavior spread.
- Tweak the environment
- They demonstrate their increment of the product to the product owner
- Product owner seats passively
- Product owner accepts or rejects the increment
- No modification is done to the product backlog
- After a while the product owner is unhappy with the current state of the product and the progress being made
- Accountable
- Humble
- Passionate
- Intelligent
- Team-oriented
- Continuous improvement orientated
- Tell me why it is more important for you to be having this conversation with us, rather than being doing something else?
- What are the things you hear yourself most often complain about in your current (or last) position?
- What have you done to change the very things you complain about?
- What would be an extraordinary accomplishment for you?
- What is the greatest contribution that you plan to make to the organization?
- What will you hold the organization accountable for?
- Elevator statement
- Product box
- Business goals
- User goals
- Value drivers
- Key attributes and capabilities
- Risk assessments
- etc.
Les programmes de certification Scrum, comment ça marche ?
Au début de l’été, Eric et moi avons eu le plaisir d’être les invités du Visual Studio Talk Show, un podcast en français sur l’architecture logicielle animé par Mario Cardinal et Guy Barette. Cet enregistrement fut l’occasion de partager ma vision des programmes de certification offerts par l’Alliance Scrum et Scrum.org et de parler plus spécifiquement du programme de formation et certification Professional Scrum Developer pour Java.
J’ai été pendant 4 ans un Certified Scrum Trainer de l’Alliance Scrum. Pendant ces 4 ans, j’ai travaillé avec Ken Schwaber et enseigné Scrum à des centaines de personnes. L’année dernière, j’ai poursuivi l’aventure Scrum avec Ken en joignant Scrum.org après avoir été le premier formateur certifié par Ken pour donner le cours Professional Scrum Master (qui s’appelait encore à l’époque Scrum In Depth). Je partage dans ce podcast les différences de mission, de focus et d’approche de la certification que j’ai constatées entre les deux organisations.
La mission de Scrum.org est d’améliorer la profession du développement logiciel, afin que les clients adorent travailler avec nous et que nous soyons fiers de notre travail. En ligne avec cette mission, nous proposons un programme de formation et de certification pour les équipes de développement. J’ai développé avec l’aide de Marc-André Thibodeau, un développeur Java comme on en rencontre peu, ce programme Professional Scrum Developer Java en utilisant des outils et technologies libres. Offert en version 3 jours ou 5 jours, ce programme de formation offre une expérience intensive unique à une équipe qui veut apprendre à livrer sprint après sprint du logiciel de qualité qui enchantera ses clients. Dans le podcat, Eric et moi partageons les éléments distinctifs du programme Professional Scrum Developer Java et l’emphase particulière qui est mise sur l’automatisation des tests à tous les niveaux.
You need an Agile Product Manager, not an Agile Project Manager
When an organization starts using Scrum, it runs into tough questions. One question that is particularly challenging is:
Is the Scrum Master the Agile Project Manager?
What if you consider that it is not the right question to ask?
Scrum is about product management, not project management. A more useful consideration is that the Product Owner is the Agile Product Manager. Indeed, the Product owner is responsible for the ultimate direction and success of the product.
The job of the Product Owner is like the typical product manager’s job with an added focus on maximizing value, delivering just-in time, and optimizing the return on investment. The Product Owner maximizes value by collaborating with the Team and customers, by leveraging the entire Scrum Team and also by simplifying product absorption. The faster and more often the release, the faster and more often the creation of value. Where traditional Product Management using the waterfall will typically delay the realization of value, the Product Owner uses Scrum to maximize the flow of value and eliminate waste.
Like the traditional product manager, the Product Owner is responsible for many things, from market analysis and strategic product planning to release planning and sustaining the product. None of this matters though, until the product is actually released. Agile Product Managers, a.k.a Product Owners, help their organization quickly seize market opportunities while controlling risk. That is what agility is about from a business standpoint.
How to change things when change is hard?
That’s the question the Heath brothers address in Switch. I had great expectations before reading the latest book from the authors of best-seller Made to Stick, and man, I was not disappointed. Switch delivers some very solid advice on the subject of change. It’s simple and powerful. It made me wonder why no-one had explained change to me that way before.
Switch presents the change challenge around an analogy borrowed from Jonathan Haidt in his book The Happiness Hypothesis. We have an emotional side, the Elephant, and a rational one, the Rider. Perched on top of the Elephant, the Rider seems to lead the way. But the Rider’s control is an illusion or at best precarious, for when the Elephant decides to go its own way, it easily overpowers the small Rider.
Change efforts often fail for a simple reason: the Rider cannot keep the Elephant on the Path of change long enough to reach the destination. When the Elephant stops moving forward, change fails. I can recall tons of personal examples when this occurred.
For change to occur, we need to appeal to both the Rider and the Elephant and shape the Path. Our Rider is logical, responds well to reason and facts and is useful for long-term planning and direction. Our Elephant looks for short-term gains and instant gratification. We need the Elephant to provide the energy and passion to get things done. If the Rider can keep the Elephant moving down a well prepared Path then there is a good chance for change.
Switch proposes a framework to guide us in situations where we need change to occur. The framework addresses each of the three parts of the change challenge:
After reading Kotter’s Heart of Change and Bridges’ Managing Transitions, I find that Switch addresses change management in a clear, practical and engaging way. The book is full of stories that illustrate the behavior leaders need to adopt for sucessful change to occur.
If you’re a ScrumMaster in an organisation, I recommend you read the book. It will serve you well. And don’t forget to drop some copies on your high-level managers’ desks.
You need a ScrumMaster to change the old style
There seem to be a confusion between the role of the ScrumMaster and one of a team facilitator. Jason Little recently wrote that you might need a coach, not a ScrumMaster:
So what is a coach going to give you compared to a Scrum Master? Scrum talks about a Scrum Master as the team facilitator, someone who is there to protect the team, remove obstacles and help the team function better. Essentially the scope of a Scrum Master is local optimization for the team.
A coach, on the other hand, will be focused on optimization of the organization. Often they are working and thinking on multiple levels and deeper when team output is exposing other organizational dysfunctions.
I disagree. This is a misinterpretation of the role of the ScrumMaster. Scrum is a tool that an organization can use to address hard problems. It is a tool to foment change. An organization that decides to use Scrum to address its issues is choosing very hard work. Only few organizations will fully take advantage of Scrum. The remaining organizations will try to use Scrum and run into ScrumButs. ScrumButs are the reasons why they cannot take full advantage of Scrum to solve their problems and realize the benefits. Each ScrumMaster is responsible for fighting ScrumButs by maintaining the integrity of the Scrum process, even if it is in conflict with the organization. This is much more than a facilitator role, right?
Of course, when a ScrumMaster starts working with a team, he or she might act as a parent, teaching the team how to self-organize. As the team gets more mature though, the ScrumMaster will spend more time working with management on the ScrumBut backlog to remove the dysfunctions of the organization. The ScrumMaster is not a team facilitator, it is a secret change agent!
Start doing sprint reviews, not demos
There’s a misunderstanding I’ve noticed in quite a few Scrum projects. Teams use Scrum and at the end of their sprint they do what they call a “sprint demo”. It works out like this:
There is nothing like a sprint demo in Scrum. But there is a sprint review.
Scrum is empirical, meaning that there are inspect and adapt points along the way. The sprint review is the inspect and adapt point where the product increment, the most current product backlog and the current conditions are for inspection. The adaptation is the modified product backlog.
During the Sprint Review, the Scrum Team and the stakeholders collaborate about what was just done during the sprint and what are the things that could be done during the next sprints. The presentation of the product increment is not the goal. It is used to understand what should be the next sprint goal. The sprint review provides input to the next sprint planning meetings. One of the possible consequences of this evaluation is the decision to not proceed further with the development of the product. Another possible consequence is the decision to release the existing product.
Consider your next sprint review. If you get out of the meeting without a modification to your product backlog and an insight to your next sprint goal, it’s probably because you’re not inspecting and adapting. You might be suffering from the “sprint demo” syndrome.
Asking powerful questions to hire right
Many organizations spend a significant amount of time defining the experience, education, skills and other factors required for open positions. Most of the time, though, their hiring process fails to make sure they hire right. If you’re looking for a different way, you might be interested to know how it works at Pyxis.
This morning I sat down with François to prepare the first hiring interview of a candidate looking for a software developer position. We decided to not have a look at his resume just yet. Since one of our colleague had recommended the applicant, we trusted he was a good candidate and wanted to understand if there was a cultural fit.
We talked about the values, characteristics and behavioral traits we wanted to find in a potential colleague. We figured out we wanted someone who shared the following characteristics:
We then devised a series of powerful questions to help us figure out if the applicant was someone we wanted to work with. Below are some of the questions we used during the interview process. Keep in mind that those questions are no more than tools we used to orchestrate the conversation. How we frame the questions is decisive. To make sure we hire right, the questions have to be ambiguous, personal, and stressful:
With answers from the candidate to questions such as these, we now have a pretty good idea whether the candidate is a good fit for our organization or not.
The next step is to validate the technical skills of the candidate. I know of no other way to validate the skills of a developer than to orchestrate a conversation around code. So we will give the candidate an opportunity to show us what kind of developer he is through his code. But that’s another story.
Making good use of assertion messages in tests
Have you ever struggle with coming up with useful assertion messages in your tests? Well, I have; until not so long ago.
I remember when I started using JUnit. It was summer 2000, and I became addicted to writing tests first. I was already writing automated tests at that time, inspired by my lecture of Thinking In Java. Not using any automated unit test framework, I was writing my tests last in the good old main() function. I had to inspect the outcome of my tests for correctness each time I run them, and that was painful.
JUnit was a discovery that changed the way I programmed and approached software development forever. Central to xUnit frameworks is the notion of making the tests self-checking by using assertion methods, basically utility methods that evaluate whether an expected outcome has been achieved. Now I had a way to express the expected outcome, let the computer check it for me, and produce a useful message for me (and others) – the human readers – to help diagnose problems. One of the goals of automating tests is to use tests as documentation. In case of test failure, what you want is for the test to act as a tracer bullet, helping you understand very quickly what the problem is. Assertion messages play a role in this. A well-crafted assertion message makes it clear which assertion fails and what the symptoms of the problem are. Now that’s easy to say, the hard part is to figure out what the message should say.
As Nat Pryce and Steve Freeman explain in their book, during the test-driven cycle, after you make the test fail, take a moment to read the assertion message, ask yourself what the reader will get out of it, and adjust to make the diagnostics clear. They provide a number of best practices in the book to help with test diagnostics. One is about making the assertion messages explanatory.
I have long been in the school of thought that strives to have a single assertion per test method and as result, for a long time I felt no need to use assertion messages. If you use small and focused tests and name them well, the tests will tell you most of what you need to know to diagnose the problem. For example, when the following test fails:
calculatesGrandTotal() { String[] prices = { "50", "75.50", "12.75" }; BigDecimal expectedTotal = new BigDecimal("138.25"); for (String price : prices) { cart.add(anItem().priced(price).build()); } assertThat(cart.getGrandTotal(), equalTo(expectedTotal)); } the failure report can be considered enough to understand what the problem is:
Expected: <138.25> but: was <139.25> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at test.com.pyxis.petstore.domain.order.CartTest.calculatesGrandTotal(CartTest.java:53) ... Indeed, the name of the test tells us that the cart fails to calculate its grand total correctly. The assertion messages shows the difference between the expected and actual outcome. Yet we can make the diagnostics even easier for the reader by simply adding an assertion message to identify the value being asserted:
assertThat("grand total", cart.getGrandTotal(), equalTo(expectedTotal)); See how that helps:
grand total Expected: <138.25> but: was <139.25> I’ve come to adopt that practice since reading Pryce and Freeman’s book. Assertion messages are not used as often as they should. They can really help make failure reports more helpful, whether you have a single or multiple assertions in your test.
Another help in making assertion reports clearer comes from using Hamcrest matchers and assertThat(). Consider the following example:
findsItemsByNumber() throws Exception { havingPersisted(product); havingPersisted(anItem().of(product).withNumber("12345678")); Item found = itemInventory.find(new ItemNumber("12345678")); assertThat("available inventory", found, itemWithNumber("12345678")); } In case of failure, here is what we get:
java.lang.AssertionError: available inventory Expected: an item with number "12345678" but: number was "87654321" at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:8) at test.integration.com.pyxis.petstore.persistence.PersistentItemInventoryTest.findsItemsByNumber(PersistentItemInventoryTest.java:56) which I hope make the point.
As Pryce and Freeman say, diagnostics are a first-class feature. I now do my best to make assertion messages helpful so that whoever has to change the code in the future will understand what the expected behavior is.
Change is the job of the ScrumMaster
I recently finished reading Community, the Structure of Belonging, by Peter Block. While reading the book, I could not help but draw parallels with what I teach about Scrum.
In his book, Block talks about the small group as the unit of transformation. I already wrote about Scrum as a tool to foment change. In the context of Scrum, the Scrum Team is that small group, that unit of transformation. It changes the context of work in a way that alters how we think, behave and thus work together, which in turn can radically improve performance. François shared a similar view recently on Scrum teams, compelling goals and performance.
Block also states that for real transformation to occur, it is not more or better leaders that we need, but more care and belonging. I’m often asked what role management plays in Scrum. People ask the question : “So in Scrum, that means we don’t need managers?”. Mike Cohn has already addressed part of that question in his last book, Succeeding with Agile, by saying that management has a key role to play by creating the right environment for self-organization to occur. To add to that idea, we can say that management task is to shift the context, so that it creates in the Team a sense of belonging and ownership. Engagement from the Team will come from care so we must be careful to choose care over speed or scale.
Scale, speed, and practicality are always the coded arguments for keeping the existing system in place.
Scrum is all about changing the existing system. This is why the ScrumMaster primary responsibility is to ensure the Scrum process is followed. He or she uses Scrum as a tool to ask powerful questions to spark off change.
The ScrumMaster job is to change the conversation. The ScrumMaster is initiator, facilitator and leader of real discussions. This is a leadership role about creating commitment and accountability, which are the building blocks of self-organization.
To make a difference we must start by naming the way things are, use powerful questions as a tool, and listen, rather than advocate or defend.
ScrumMasters, take the time to master the art of orchestrating conversations, for this is what your job is about.
Scrum is not about project management
I often hear people talk about Scrum as a project management framework. I don’t like that idea. Scrum is for managing complexity to provoke change. I don’t like the notion of Agile Project Management either. Nor do I believe in the Agile Project Manager.
Our conventional approach is to solve problems. In fact we love problems and we take pride in devising complex solutions. We operate on a belief that we can make a real difference with more or better problem-solving. It’s only natural then, that we think of products in terms of projects (project resonate with problem to be solved) and that we see Scrum as another approach to manage projects (hopefully a better one). In my experience, product developments that use Scrum as a project management approach rather than a tool to ask powerful questions to spark off change, do not make a real difference. They only manage to project the past into the future.
Scrum is about the art of the possible. It is when we start thinking in terms of products, people and possibilities that real change is possible. To make a meaningful difference in our software development efforts we have to embrace uncertainty (and the anxiety that comes along) and tap into the possibilities it brings. We have to acknowledge that we don’t have all the answers, and that we’re going to explore how to best meet our goals and that of our users.
Product vision and Strategic Design
When I coach Scrum teams, I usually spend a significant amount of time working with the Product Owner to teach her how to create an effective product vision, one that will act as a guiding light for the Scrum team and stakeholders.
I don’t want to delve into the details of product envisioning activities. I usually use a number of workshops and techniques to produce some (or all) of the following artifacts:
What I’m interested in talking about is the activity of defining the product quality attributes and how strategic design (in the Domain Driven Design sense) fits in. Thinking about the quality attributes is key to defining “done”. Product quality attributes give meaning to the product being potentially shippable.
Among the quality attributes, some will pertain to the external quality of the product, like usability, securability or availability for instance. Others will focus on the internal quality. This is the case of maintainability, modularity, evolvability, etc.
Yesterday, I was out for beers with my colleague Ernst Perpignand and Greg Young. Greg was in Montreal to give his Domain Driven course and we (at Pyxis) sponsored the event by hosting the course in our Laval office. Of course during the evening we talked about CQRS, Event Sourcing, write and read models and all the stuff Greg likes to talk about. Needless to say I had a great time.
Those discussions made me realize how important it is to communicate that context maps are strategic outputs of the product vision activities. There are good reasons why Eric Evans talks about strategic design when he discusses bounded contexts and distillation. He refers to the conceptual core of the system as the “vision” of the system. It is indeed the guiding vision for internal quality attributes of the product. Determining our own bounded context and its relationships to others is both a political and business decision. We need to understand where the potential for ROI lies to design and architecture in consequence.