Scrum Values Retrospective

Either you are a Scrum Team Member or a coach the Values Retrospective can be very powerful. As you probably know at the end of each Sprint we run Retrospectives to inspect ourselves as a self-organized and cross functional scrum team. After few sprints if you don’t have the proper mindset in place you will face a zombie scrum team doing mechanical or flaccid scrum. We definitively don’t want that. I won’t go into the many ways of trying to get back on track with a team like that, but a starting point can be to inspect how we are doing with the Scrum Values.

Reboot the values

Start the meeting by covering the 3 pillars and the 5 values. If you are facilitating, don’t be the only one to speak. Timebox the discussion for each value. Ask the audience what means each value for them. Ask them to not try to inspect the current state of adoption but really what this value is supposed to mean for a Scrum Team.

Evaluate Values Adoption

Ask everyone to evaluate each value from 1 to 5 for example. You can do that on paper, with fist of five, online with a shared tabular sheet… Your choice.

Rank Values

Then ask the audience to rank the values. Which one is the one we totally adopted which one we have the most difficulties to apply to ourselves. You can rank them from 1 to 5 or use any other way.

Discuss the Results & Take Action

Sum the results for each value and look at the one you need to work on the most. This has to be a discussion but don’t forget to come out of it with at least one concrete action to take immediately.

Scrum On !

Why you should consider following a Product Owner training

This article is not for Product Owners as they must follow this training. I want to encourage Scrum Masters, business analysts, testers, developers to think about following this course.

From PSM to PSPO

My agile journey started with the PSM and PSD courses a few years ago. Then I became a Scrum Team member for some time and didn’t feel the need for more training. But when I started to become a full time Scrum Master I realized I needed more tools and practices to help my teams and specially the Product Owner and the organization around. I was facing questions like: how can I order my backlog? What are the key measures to show to management? How do I build my vision as a PO? And many others. Like many I started googling things and did my best to find and forge my tools. I quickly wanted more than that and went for a PSPO training.

Professional Scrum Product Owner

Like the PSM, the PSPO training is a 2 days course. As usual with Scrum.org the content and the structure are perfect and even with few years of experience using Scrum, having a people around sharing their own experiences and techniques is of great value.

Besides that, I came out of the training with a new understanding of the Product Owner job. She or he is not only the person with the vision we all think of. She is the captain, the leader, the beacon of one to multiple teams like a startup entrepreneur. It is a difficult position that needs a lot of support, empowerment, natural leadership and a very pragmatic approach. From the Scrum Team member point of view, you only see few aspects of the job and this is why we lack understanding of this role. For two days you can be in her-his shoes and see what you would do in some situations.

I won’t give you a list of all the practices you will cover but here are some of them: Impact Mapping, User Story Mapping, Key Value Areas through Evidence Based Management. Anyway except if you have a large agile community around you those trainings will bring you more than you think and remember how great was your PSM training experience and you’ll want to go to this one.

Convincing People Series – Why does Scrum works?

Starting your agile journey with a Why question is a good start. Why does it works and what do you need to make it works ?

Empiricism

Scrum is an implementation of empirical process control and this simple fact tells a lot on how it can be successful. When you are building a product in a predictive way you are trying to prevent all scenarios that may cause you problems in building and delivering it on time. And most of the time it fails because of the complexity and the challenges you face. And also because we never take time to look at our issues and find ways of fixing them in a longer term. No lessons learned just firefighting.

If you do it the right way you need to make the three pillars (Transparency, Inspection, Adaptation) the foundations of every decision you are making. This way will allow you to constantly analyse your current situation and adapt in consequence. Every problem you are facing is a learning experiment that you can transform into small adaptations in your process. As simple as it is.

But what make scrum teams successful?

If you choose to go the Scrum way and want your team to be successful you will have to do more than just implementing the three pillars. The five values are the roots for your team to grow and perform. Those values are too often forgotten and this is why they reappeared in the Scrum guide in 2016. Respect everyone, be committed as a team in your every day work, have the courage in taking decisions and try new things, be open and keep your focus on the goal is what it should be all about.

 

All in all Scrum is not a magical framework but helps you through a simple set of roles, events and artifacts to start building software in less than 30 days. Every iteration is an opportunity to measure and learn in order to deliver the best possible product that fits your business. But don’t forget that having experienced people in Scrum implementation and the right training will help you to start in good conditions. Now Scrum On !

Myth Busting – Will I save money implementing Scrum?

“I want my teams to become more agile in order to save money” is probably a sentence you will hear a lot from financial directors and executives. Is this really a myth?

Where Lean is not really what we should be looking for

This myth is often related to a misunderstanding of the relationship between Lean and Scrum. The Lean concept is about maximizing value and reducing waste. If you don’t associate both ideas you are not going to get results. Most executives like the idea of reducing waste and so the cost while getting more out of people. By the way in this scenario we don’t talk about people but resources. So sometimes when you have to assess a team to find ways for helping them going out of a flaccid scrum implementation you also have questions like : who do I need to fire once they get better?

Waste should not be related to people but instead it should be on ideas, vision and value. The whole point of agility, lean and so Scrum is to maximize the value of the product we are building. Finding better ways to deliver better software and not finding better ways for cost cutting.

Saving money : not the idea

What matter the most is to deliver value rapidly but what is value? When you get asked about how we a company can save money doing agile you should reply saying : what can we do to get more money out of your product ? By getting more money in selling a better product we move from the idea of saving money to survive to gaining more to expand. If you want to bring the conversation on this field you should be prepared to answer a lot more questions about defining the “what” of the product. There are a lot of ways to make the value a tangible actionable metric. You can start by monitoring usage of features, product, do user surveys or even analyze how much money you’ve spent to build your minimum viable product. Only having a number between one and hundred is not enough you will have to quickly move to a value coming back from a real use of the product.

Teams of highly qualified professionals

Forming agile teams is where you’ll probably realize that becoming agile is not costless. Specially at the beginning. The best agile teams are for sure made of highly qualified professionals with a lot of experience. As you may know we are looking for self organized and cross functional teams so if your team is made of interns with no experience you are in a dead end. When people are more experienced they are usually more expensive and this is normal specially if they have the expertise you are looking for to build your product. You can build agile teams made of experts and junior but it won’t be as effective as having only experience people.

In summary move the discussion to business value delivered instead of cost. A better time to market and building a better product is not something you can do with small teams of inexperienced people. So find ways on getting the best possible product that can make your business flourish in small but effective steps. That should be all what matters.

The endless talk about quality in Agile Teams

What quality means for Developers (please read Testers, Analysts, Dev, Ops…) in an Agile team is definitely an endless talk. I could write tons of lines about it but I can also tell you that having the discussion is an excellent start. Too many teams rely only on the process and not the practices. In Scrum for example we do not prescribe any engineering practices but the most performing teams are implementing a lot of them in order to deliver a high value product on a long term basis. It’s a fact.

So, how do we define quality ?

If you look at Clean Code‘s first pages you will see this : “The total cost of owning a mess”. Please read it, print it, sign it and display it on your wall. In only one page and one chart Uncle Bob sum it all. We have all experienced this in projects once. When we start compromising the code maintenability to be faster in delivering features. Until it’s too late to fix the mess. In agile projects we call this technical debt. Technical debt is a whole, not only the fact that the code is a mess. In general, when you have some the product backlog is also a mess in general. So, quality is finally a sum of good technical choices taken at every step of the software development. As a team it’s your responsibility to envision your architecture, take time to think of every choice but also admit the fact that it will evolve, move, live.

My Basic definition of Quality

• A Working Software continuously delivered to Users
• Good Technical choices implementing a maximum of the quality attributes : extensibility, maintenability, testability, security…
• No tolerance for bugs in production
• Being able to manage the debt

Don’t forget the principles !

Back to basis. Do you remember the agile manifesto? Yes you read it once. Now let’s look at some principles we probably forgot that will help us regarding quality.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

In a following post we’ll go deeper in those principles and see how difficult it can be to implement them.

 

Convincing People Series – Agility is everywhere let me show you

When you start working on agile projects you realize the most difficult part of the job is to convince people. You are basically swimming against the tide on a daily basis. Exhausting. But if you don’t have the right answers to their questions it makes things even worse. So let’s try to build ourselves the right discours.

Agility is a part of our everyday life

A lot of things around us are what we could call “Agile”. The foundation of agility is empiricism. You try something you get a feedback and then you adapt to the situation. You simply use the feedback to progress in the right direction. That’s it.

The Hotel Shower

For example when you arrive in an hotel room for the first time and you want to take a shower. You don’t know at this time what will be the temperature of the water coming outside the pipe depending on how you have adjusted the faucet. So you try and you measure the temperature with your skin then you adjust again until you find the right one. This is empiricism !

Now let’s look at the same situation from a different angle. This time in a sequential (waterfall) way of doing things. First you need a faucet that delivers an average temperature of 38 degrees Celsius. You go and ask someone to build one. You install it and then you open it and you realize it is way to hot for you. Back to square one, unmount it, back to your vendor and ask him to change it to deliver water at the temperature of 36 degrees Celsius.

I will let you imagine the time and energy spent across the entire process. Without mentioning the frustration. In this first simple use case it is clear that we need to adapt from what we measure and we need to do it as fast as possible to avoid accidents.

The Traffic Jam

Another example this time with traffic in big cities. Today a lot of roads are jammed with thousands of cars coming in during the rush hours. Now let’s imagine for a second that all the cars and motorcycles would be trucks instead. See how it could turn to be a nightmare ? And now let’s say they are all motorcycles. How much smoother the traffic would be?

In Paris we have a lot of traffic jams during the rush hours and during those hours you can see hundreds of two wheels. This is because most of us realized that it was much faster to go between the lanes with smaller vehicles. Again a simple inspect and adapt process that we applied to our every day lives.

 

So now, just pick a story your client can identify himself in and tell him how much better it could be to change the way his products are delivered. And again keep this in mind : start small.

The Agile Triangle a change of paradigm in selling projects

For decades selling and contracting projects was quite clear for all parties. One side wanted to have what they asked for inside a specific budget while the other side tried to make sure they were reaching a certain amount of margin.

The project triangle between Scope, Time and Money was pretty clear and most of the negotiation was focused on Time and Money while the scope was non negotiable. You were receiving a RFP (Request For Proposal) and you were simply replying with Time & Money numbers. Sometimes only with one number : money.

With agile projects this triangle is getting horizontally flipped and now the scope is the center of attention. We still have Time and Money because you still need to manage a budget somewhere. But the good news in this new equation is that you can now introduce the concepts of quality and business value in the triangle. Quality by delivering what you can do with a certain level of quality in the time you have. Value by having to choose between features and thus deciding on what is really necessary for your business.

So as you can see by simply changing our approach and point of view on this triangle we introduced a new paradigm. This is called Agility. No more, no less.

Now if we look at Scrum we see how we tick every checkbox of this triangle:

• Time : an iteration of less than a month called a Sprint.
• Money : a product owner who manages the budget by selecting and ordering what is necessary to build the product in the most efficient way with the help of a self organized dev team.
• Scope : by gathering needs from users, stakeholders and taking feedback the product owner have all she needs to take decisions on what to put in the product backlog and how to order it.

Next time we’ll see how the product owner can steer the Product Backlog with specific engineering practices.

Prepare for PSM I Scrum.org assessment

Becoming a certified Professional Scrum Master is one of the first milestones in an agilist career. Of course
you can live without obtaining it but if you want to move to an agile career path this can help. Whether you are a developer, a functional analyst, a tester or anyone in a scrum team you can consider passing this certification. For developers there is another assessment called Professional Scrum Developer (PSD) but be careful if you are new to Scrum.org assessments. The PSD is a little bit more difficult and it demands PSM knowledge anyway. So I would advice you to pass PSM then the PSD.

First of all let’s see what it is about:

• Fee: $150 per attempt
• Passing score: 85%
• Time limit: 60 minutes
• Number of Questions: 80
• Format: Multiple Choice, Multiple Answer and True/False
• Difficulty: Intermediate
• Language: English only
• PSM Subject Areas < Must See !
• Required course: None
• Recommended courses: Professional Scrum Foundations or Professional Scrum Master
• Practice Assessment: Scrum Open
• Passwords have no expiration date, but are valid for one attempt only

From this short list you can appreciate the type of assessment it is. A lot of questions, not so much time and multiple choices so be prepared !

If you are already working in a Scrum Team I would advise you to do the following:

• Read, read and read the Scrum Guide. You need to understand it deeply instead of basically memorizing it. You need to think like Ken when you answer questions !
• Practice a lot with the Scrum Open Assessments. Don’t memorize answers from this assessment but try to understand the type of questions and the way they want you to think. If you have some doubts about answers go check the Scrum.org forums. Once you get 100% correct multiple times it should be fine.
• Ideally follow a PSM course. It is two days with a Professional Scrum Trainer and even if you already have some experience with Scrum you will get invaluable knowledge from a specialist.
• Check the list of books from this page. Some others can be found for free like this one.

Some recommandations when you pass the test:

• Be careful when reading questions and answers. There are differences between “who should be present at the daily scrum” and “who must be present at the daily scrum”
• If you have doubts regarding answers, proceed by elimination
• There are no Sprint 0 !
• A Sprint starts immediately after the conclusion of the previous sprint. And its timebox.
• The PO drive the product vision, not the team ! And he is the only one to drive it !
• In Scrum we develop products not by technical (horizontal) slices but vertically by features.
• The daily scrum is a feedback loop.
• The Scrum Master is here to facilitate, coach, teach and remove impediments.
• The Definition of Done is the Dev Team check list to consider a PBI ready to be shipped.
• In a multiple teams context (for one and only product) the Dev Teams share DoD so each team work is integrated into one common increment.
• A sprint can only be cancelled by the PO and when the sprint goal is obsolete.
• A Development team is cross functional, everybody is a Dev and the team must have the competencies to deliver what’s in their sprint backlog.

If you’ve never worked in a Scrum Team, find one, work as a member of the team few sprints and then come back here ! If you are a Product Owner think about the PSPO first.

Scrum On !

Can a team survive without a Product Owner ? Or with a ghost PO.

As you probably know it already the Product Owner is an essential link for a Scrum Team to deliver high value product increments to the business. This is no secret that a good PO can drastically improve the amount of return on investment of a project. And this is probably one of the most important aspect of the job. This role is clearly a full time job and requires a lot of various skills but sometimes companies and people are not ready for that. Even in the Scrum guide the first line of the Product Owner definition is opening the door by saying :

The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.

We won’t talk here about the skills required for the job or even try to be exhaustive about what the job is about as this is probably another very long post. Instead I will expand about this particular sentence in the scrum guide definition. Doing so I will tell you about how some of the teams and companies I worked for dealt with those various situations.

We have a PO but he does not give/have enough time for the role

This is what I call a Ghost PO. Usually this scenario happens because somewhere people decided to drop someone from the business in a PO role. That can be a very good idea but a decision like that must be supported with specific dispositions. First this person must be clearly train to be a PO. This can be done internally with coaches or externally in a 2 days training at least. Then the PO must have the time to spend with the team, working on the backlog, be available, talk to stakeholders, gather information from as many people as possible, etc. All of that to effectively give a chance to the project to be a success.

However in my opinion taking someone out of a business role can also be a problem for the company. We are supposed to create value and we are removing someone from a place where he or she is already creating value. That’s why we should really consider the PO role as a new job fulfilled by people with the knowledge and the skills that won’t jeopardize the actual company’s business.

Another scenario is when the PO has the time but is not giving time. That can be fix by the team itself in many ways. Use retrospective to talk to him and let him understand he is an important part of the team. The Scrum Master must talk to him and coach him to really act as a PO. If he is not in the same office space, make him move next to you. Do everything you can to make him feel he is not external to the team and his opinion matter.

How the team can react in those circumstances

Somewhere in the company managers gave a budget for your project to exists. So even if you don’t have the PO you deserve there is a chance to get support to get out of that situation. Your Scrum Master has to take his pilgrim stick and find support for the team.

Work on team’s external communication. Invite as many people as you can in the sprint reviews, draw interest around your project. Keep in mind you need to find people to give you feedback on what you are doing. With more feedback it will be easier to steer the product in the right direction and this is what matter the most after all. Of course this won’t be a peaceful journey and you will have to triage feedback in some ways. But if you want your project to be a success and be happy with what you are doing every day you have to move out your comfort zone. If not you will just have worked for another project that won’t go live.

From what I have seen in situations like that some teams are prepared for this scenario by having a lot of knowledge and skills shared in the team. We are all Developers but some of us have very strong knowledge in the domain we are working on. The sum of the team’s expertise shouldn’t be underestimated and should always be developed as much as possible.

To resume I would say there is no magic and having experienced professionals in the team will help a lot. So Scrum On !