Published for me by SogetiLabs on June 26th, 2015: http://labs.sogeti.com/trust-goes-all-the-way/
The effect of trust on Scrum teams
Trust is something that any work situation demands. However, it’s hard to find trust nowadays, as it has been replaced by ‘control’ in traditional work environments. Our business models, leadership principles and relationships at workplaces, usually, do not accommodate trust.
I’ll give you an example from my youth. As a young student, I got an evening job in a supermarket. I helped replenish the store’s in-shop inventory. One night, my supervisor accused me of stealing. He claimed to have seen me putting something into my pocket (later, it turned out to be my own watch that had slipped off my wrist while doing my job). This incident questioned my integrity in a big way. I felt scared of losing the job and my reputation; and my expectation of justice suffered a severe blow. Although, I was cleared by HQ later, the relationship with my supervisor was never the same. He never trusted me after that and I must admit, I could never trust his judgment either.
Now, when I train people on Scrum, I hear about different work situations where ‘the level of trust my supervisor showed in me’ is quite common. When I say that a team should be self organized, they (management) object that people will slack off. I have never seen a team slack off in a Scrum environment; in fact, they thrive, improve, and have more pride than a lot of other teams. Scrum teams put more effort to deliver quality work and demonstrate technical excellence, exhibiting great performance overall. Often, I’m asked to validate it by providing relevant statistics, metrics, etc.
But trust comes from within. If you don’t give trust, you will not get it. Once a team is controlled, they may/will start to meet the numbers by using various devious means. For instance, they can double the team velocity without doing anything more, they can lie about the time spent or they can increase estimations to build in risk; so, eventually, the team output will decrease. Even worse… team members would get demotivated, because humans like their freedom, and controlling them too much will make them look for other opportunities. It affects loyalty, happiness and work satisfaction.
Just because the job I had at the supermarket was a student job, I decided to stay on long enough to make sure my reputation was restored and that I could leave without suffering from the incident. It did not affect my image and a few years later, I got through an atomic clearance investigation for a military position without any trouble. However, I used to get insecure every time I met my supervisor, even as a customer of the supermarket!
Also posted on SogetiLabs date: March 19, 2015: http://labs.sogeti.com/measuring-performance-in-scrum-teams-is-an-act-of-sabotage/
Revitalized on December 28th, 2015 because it was the 3rd most viewed post of the year.
Lately, I’ve been asked a lot of questions by managers and teams alike about the organizational need to measure performance of Scrum teams. Of course, most people refer to the Development team within the Scrum team… but that is where Scrum creates confusion.
The Product Owner and the Scrum Master, together with the Development team, form the Scrum team. The idea is to include all the roles in a nice package called Scrum. The Development team, however, is often called the ‘Team,’ because that is how the Product Owner and the Scrum Master address people who create the product.
Many of us realize that we don’t measure the time spent on the individual tasks within the Development team. We work with fancy units such as feature points, or complexity points, or story points (when using User Stories). The unit, however, does not matter as long as you realize it’s not the time spent. It is a relative value obtained by comparing the effort and complexity or a chunk of work with that of the rest of the work to be done.
What many do not realize is that these points we use are NOT productivity metrics. In fact, they are there only to aid the Product Owner and the Development team in their work. Reporting to the management about the amount of points burned down in a Sprint, only serves as an effort to ensure transparency (with the management), which is characteristic of Scrum.
The expectation that these points are metrics for productivity and that we can use them to push the team to a higher performance level is like measuring a company’s performance using the amount of people working for them. Why would we measure performance of a Development team based on velocity increase, function point analysis or the amount of coffee they drink, when (in reality) a company’s performance (usually) gets measured on the basis of the Return of Capital Employed, profit, turnover, etc.?
The main goal of a Scrum team is to increase the Return on Investment (ROI); the people who make this possible are the Scrum team’s developers. Pushing developers to the edge, by demanding a higher volume of output, leads to the following undesirable outcomes:
The team gets demotivated and/or overworked and the productivity decreases.
The number of errors the team makes increases; more bugs in the system results in more problems in operation.
The team cuts corners to get more work done under pressure and, consequently, technical debt increases, which in turn bogs the team down over time, while they refactor the code bit by bit.
It creates a rift between the Product Owner and the Development team. The Scrum team, as a whole, works to create value and increase ROI, but the Product Owner is responsible for the ROI; the Development team is responsible for the work done.
This anti-Agile behavior reduces the effectiveness of the Scrum framework, which is best when the Development team is empowered. In fact, self governing can achieve a sustainable pace.
The job of a Scrum Master is to help the team become better by facilitating their work and removing anything that keeps the team from going at the pace they want to. I personally believe that people in the Scrum team and the Development team WANT to work at a cutting-edge pace while creating the best possible product. Interfering with this will sabotage their dynamics and will achieve the opposite of what you force them to do.
Focus on measuring ROI of the product and you will be happier.
Published on SogetiLabs on November 27th, 2014: http://labs.sogeti.com/say-no/
Recently I tweeted the following: “What makes a good Scrum Product Owner? The ability to say NO to stakeholders when suggested functionality adds no value to the product.” This was of course a tweet that didn’t just come out of nowhere. I have known a lot of Product Owners and some are really good. Responsibility for the product, the ROI from the product, the Product Backlog that is Ready, or Ready-Ready, or just a list of wishes… The reality is that the work of a Product Owner is hard. It’s a fulltime job! In organisations where I have coached or been a Scrum Master I have found a lot of examples of Product Owners that have been “given” this position, or who have made themselves the position and often they do the job as a side. But Product Ownership is HARD. And if you are the Product Owner of a new and exciting high profile product you will find that everyone will want to have an influence on the product. In large organisations where a new product will most likely give another boost in profits and will increase someones chances for promotion, higher KPI or other advantages, these someones will want to be able to influence this.
Scrum is all about trust, and we often think it’s the trust a Product Owner needs to have in the Development team, but this trust is much more. It’s also trust the organisation has in the Product Owner. One of the most important jobs for a Product Owner therefore is Stakeholder management. With the product that will boost the company’s ROI one of the stakeholders is obviously the upper management and controllers. The funding depends on them. And there is Marketing, Sales, Security, Maintenance, etc. So many stakeholder and in principle everyone can add to the Product Backlog. Often the items on the product backlog make sense. New product and new ideas, unique selling points, necessary functionality of a product. All these items are what a Product Owner needs to order. Which is more important, which will appease my stakeholders best, which will make users happy and return ROI. But the most important question a Product Owner will ask him or herself is “Which of these will add the most value, on the short and the long term”.
Sometimes a stakeholder will add an item that adds no value at all for whatever reason, maybe the functionality does not fit the product, maybe it is something that stems from misunderstanding the product and it does not fit the Product Vision. However… this non-value item might be invaluable to the Product Owner’s main stakeholder. This can lead to a dilemma. It might be because the Product Owner is prone to Political pressure, or there is an other reason why the Product Owner may consider the item. This is where the Product Owner needs to be strong. You may end up with functionality in the product that does not add value at all, or affects functionality that IS valuable. This may not seem serious, but it is also functionality that may define the product. It still has to be maintained, or it may be hard to consolidate.
Please Product Owners, learn to say NO, make it a diplomatic “no”, I know that you catch more flies with honey than with vinegar. But learn to say “no” anyway. It’s your Product Vision, YOU are the Product Owner. Your strength of will will be what defines the product.
This post was published by SogetiLabs on October 17th, 2014: http://labs.sogeti.com/scrum-world-domination-2/
Since I started working at Sogeti in 2007 I have made it a point to bring Scrum to the company, my colleagues and the customers I work for. This has been an active choice because I believe in Scrum.
When people ask me what my future plans are in regard to Scrum I will tell them that my plans are Scrum world domination. People will laugh, they will joke with me at that point, but I am serious.
Think about Scrum, think what it has brought us. People will complain about lack of documentation, or they will say quality is a serious issue when you use Scrum. I have a lot of experience in Scrum and can tell you; problems with documentation and quality stem from a bad implementation of Scrum. If you buy a city car and drive offroad with it all the time and then complain “this is a bad car, it just doesn’t work very well” is that a fair statement?
Why do I believe in Scrum?
There are many reasons but I will give you a few compelling ones. Some may sound familiar and you will hear them from many people, maybe if you hear it that often there is some truth to it; after all, once is an event, twice is coincidence, three times or more is definitely a pattern.
Scrum is a motivator, it allows people to improve their skills, encourages teamwork and team empowerment, and sets purpose. Have you heard these words before? I do quote Daniel Pink often. He wrote a book called Drive in which he talks about what motivates people. He names three things:
These three will motivate people that do work that involves cognitive skills. Scrum is usually used in environments that require people to use their mind. The teams are autonomous in the work they do when it comes to “how” they achieve a sprint goal. A goal is set every sprint and helps the team make decisions, but it also motivates them to get things done! Working together as a cross functional team helps the team to improve their skills and learn from each other. Scrum boasts that teams will improve their speed immensely. This is aided by the team learning to understand the product that they work on. When they know the product through and through they will be better equipped to make this product better for the market or users.
There is a tradeoff… Teams cannot improve effectively when the team keeps changing. Adding and removing people from the team in an effort to improve the team from the outside will distort team dynamics and will only slow down the team and cause quality problems. The teams will start asking for more information to get the backlog ready as they are unsure what the next change to the team will cause and where the knowledge will be kept. The other trade off is that the team needs a Single goal, not several. They will also have trouble when there is more than one product to work on.
Scrum helps create value. Because the product owner can order the backlog in what brings the most value to the product, the team will always work on that which will deliver the most value. Value is a fickle thing though, and the product owner will have to work hard to define what adds value. A product owner is not a side job. The order of the backlog changes along with the emergence of knowledge on what brings value. New technologies and new insights will affect the backlog and will affect the roadmap of the product.
This is also why in Scrum it is not possible to give the business a firm grasp on what the product will look like in the long term. It is not a lack of desire that the Product Owner (leave the team out of this) cannot give you what no other framework or method could ever guarantee. Any Product Owner would love to have that crystal ball in which he or she can see the final product.
Advantages are that the end product will be the best product for its purpose, tradeoff is that the product will evolve over time to become this “best” or most valuable product.
One of my previous blogs was about Product vs. Project, I wrote that for a reason. What IS an end product? Like everything a product has a life cycle. If you look around you it will be apparent that all products have changed over time. Who had an iPhone 3 in 2008 might now be walking around with a brand new iPhone 6. The Volkswagon Beetle from the fifties now looks all futuristic as the New beetle.
Products evolve, they change because the market demands it to become better or to conform to rules. Driving without a seatbelt is no longer an option, I doubt though that the Citroen 2CV had seat belts when it came out.
Doing projects that end after the deadline has been reached will cause a product to entropy. New budgets to put changes in the product mean new projects with probably new project teams and new people to lead the teams and the product development. Imagine a team that knows the product through and through working on the product until the effort to improve the product becomes more precious than the return on investment.
Scrum evolves as well
I was in a session recently where someone asked the participants what the next hype (referring to Scrum and Agile) would be. I will not address this notion and will just refer to the definition of hype and point out that Scrum has been around for at least 20 years, if not longer. Also Scrum is constantly evolving. It has to be to make the most of the improvements that have been emerging while creating thousands upon thousands of products with using Scrum. The Scrum guide is being worked on and reviewed time and time again and has changed significantly. Even wording of ceremonies and events change to fit the current times. What we used to call Backlog Grooming is now called Backlog Refinement, mainly because of the negative connotation that Grooming developed on the internet. If Scrum as a framework evolves, it in effect gets new versions. As a Scrum adept it is necessary to stay up to date with these changes. It is important to know what is going on in your field of work, so stay with us!
I am very much aware that Scrum needs the right environment to thrive. A company that thinks that Scrum is merely for the IT department and is like a black box where we can throw wishes in to receive products as gifts will have to change their thoughts. Traditional expectations will as tradition has it be met with disappointment. This mind shift is something that Scrum Coaches and Masters need to address. Being a Scrum Master does not stop at the Development team’s door.
I genuinely believe that Scrum will improve products, lives and ultimately the world. This is my plan for Scrum World Domination, to make the world just a little bit better to live in.
Anyone have a hollow volcano I can rent?
 Pink, Daniel H. (2010). Drive – The Surprising Truth about what motivates us. 2815 of 3967: Canongate Books. ISBN 978-1-84767-888-1 also look at his video:
This was posted on July 29th, 2014 on SogetiLabs: http://labs.sogeti.com/bring-back-intrinsic-quality/
The effect of intrinsic quality on Agile
Intrinsic quality, I put the terms together to imply that quality is best when it is an essential part of the product or work. It is part of the essential nature of “a thing”.
When we think of quality we think of how good “a thing” is.
If I ask people my parents’ age how they perceive quality, they often refer to how things used to be sturdier and better when they were young. My imagination often goes to Victorian age quality, the kind you find back in movies like Harry Potter where the sturdy hinges of big travel chests are near indestructible. I do realize that:
My parents aren’t THAT old
Quality does not necessarily mean something has to be bulky.
When something is bulky is it going to withstand the test of time? Is that intrinsic quality? I doubt that is what makes things sturdy, of higher quality.
I am active in Agile circles and there is a big influence in Agile from Toyota and the Toyota Production System (TPS). In addition to TPS being the source of Lean manufacturing and many ideas within Lean can be traced back to TPS, it has also been an influence of Agile and Agile methodologies and frameworks.
In TPS there is something called Jidoka. According to Toyota (I reference the TPS Brochure of Toyota forklifts):
Jidoka translates as “autonomation” and can be described as “automation with a human touch”. Quality is monitored throughout, with each team member being responsible for performing quality checks before delivering the goods-in-process to the next point in the production line. If a defect or error is identified it is addressed immediately – even if this means temporarily stopping production.
So you FIX a defect or error when it is identified, EVEN if this means temporarily stopping production.
This is very important to Toyota, fixing errors when they are identified. What kind of quality does this give “a thing”?.
Example: You are writing a blog post and you notice that you typed a word wrongly. What do you do?
Ignore it, if you do not fix it in your final read-through your editor will most likely fix it for you
Make a note of it on a piece of paper, count the lines where the error is, what kind of error, mark the type of error on a separate list where you count the severity of the error and check your list of allowed severity to decide which you will fix first
Fix it now!
Though I know most people will think B is ridiculous, I would like to remind you of this later in this post. I will start with A.
Will ignoring save you time? Do you think you will find the error when you read over your blog again? How many errors will go through anyway, even after it has been reviewed by your editor, your colleagues and the first readers of the post?
I do not claim you won’t find any errors in this blog post, but I do claim that this mentality is what I see a lot with developers. But Latin mottos sometimes say “amat victoria curam”, Victory favors care.
You probably guessed it already, I favor the last answer. If you fix errors now it will lead to better quality, quality now, and it will lead to Jidoka.
Fixing errors now, Is that intrinsic quality? The simple answer to that is No. But the mindset that when you encounter a problem you fix it immediately is what I mean with intrinsic quality.
We all get older, and when we are asked “what is quality to you?” you might remember that bike you got for your 10th birthday, one that had been fixed many times by you and that always took you everywhere. Or the car that was part of your youth for many years. It might be a bit overshadowed by nostalgia. You may not remember all the frustration you had having to fix the damn thing. But you may remember that you perceived that as being quality.
A product that has that feeling of sturdiness, what was the defect count? And did you tolerate 2 Major defects, 10 Minor defects, 50 Trivial defects?
Did you keep a list of the defects?
Did you contemplate fixing your breaks and then ignored it as the costs for fixing the slightly worn out breaks outweighed the chance of crashing into other traffic users?
When I train people in Agile and mention Jidoka to my students I sometimes get the question “but why does Toyota have so many recalls? “.
I like to answer the question with a counter question, “Why do other car companies have so little recalls?”. I can refer to cases, even recent ones, where car companies did not recall cars even though they did know about the life threatening problems with some of the cars parts. Why did they not recall those and let deaths occur?
Legal costs is a plausible answer, and so is Image name. Some companies apparently weigh these and decide if they do a recall or not. Are you driving in a car like that?
Maybe the sense of quality that Toyota displays in their recalls, despite the damage to their name has led them to decide to replace their robots with people  as people learn and robots do not…
Intrinsic quality does not ensure there will not be errors, “errāre hūmānum est”, to err is human. When you are a customer you DO expect that there is quality, especially when you buy something on which you will rely. Some of the most common causes of skydiving fatalities are issues with a person’s landing or malfunctions with the skydiving equipment. Landing is a skill, but skydiving equipment is your lifeline.
In Agile and specifically Scrum I EXPECT intrinsic quality. It is most likely the biggest misunderstanding of Scrum that I know. And I do understand that when you move from a control focused way of working, where metrics and directing people on numbers is important, that you rely on numbers.
What does that mean, Intrinsic quality in Scrum? It means that when an error, defect or problem is identified, the team FIXES it! It means that the Scrum team has a focus on delivering quality. We’ve been teaching this for a long time. Scrum gives you constant quality. Then lets live up to that.
This also means we are not going to keep defect lists, nor are we going to accept known bugs. As far as I am concerned, there are no bugs in Scrum. There is only work. To quote my mentor Jim O. Coplien in our trainings together “Fix it!”.
Bugs are work, just like the features that the development team in Scrum builds. When defects are detected they are pulled in by the team and fixed. If they cannot be fixed right away they are put on the backlog so the Product Owner can look at it.
“Isn’t that the same as known bugs?” It is inasmuch the same that known here means visible. All the work in a product backlog is visible. There is no special list for defects, so defects are picked up by the team when work is picked up. The right person determines if the work is important, not the person who found the defect. All the work is important.
This does change work for the testing world. After all, the tests that are carried out by the whole team also include detecting defects and fixing them right away. But I know how many in the test world still expect a defect list.
Agile in itself is a mindset, it is reflected in the Agile Manifesto and it means there will be a paradigm shift. Intrinsic quality for me is part of Agile, and most specifically part of Scrum. We know what it means, it’s having heart for the product you work on, it’s making it something of your own. It’s being proud of what you create the same way master crafters of old were proud of what they made and it usually made them famous. They usually gave their clients a lifelong guarantee on the product, especially when it came to production issues. I’d also like to see that kind of trust back, trust in the product or work that you deliver.
This was posted on May 21, 2014 on SogetiLabs: http://labs.sogeti.com/projects-dead/
Last week I spoke to a colleague who has made his career in IT architecture. We’ve been working together in a special interest group that focuses on Agile and Architecture.
My explanations on Scrum led to great revelations for him.
“So if a company uses Scrum they have to forget about projects and start thinking in products?”
“Yes, that’s the gist of it.”
“Wow, that’s a major paradigm shift.”
And yes, I guess it is. I’ve been working in Agile or would-be Agile organizations and I believe that thinking in products is something I don’t see often enough.
One of the first publications that mentioned “Scrum” was “The New New Product Development Game” by Takeuchi and Nonaka, who wrote about how product development should change from sequential to more cooperative.
In this publication the team works together to achieve a common goal: making the product that has the most value.
It is known that this publication was the inspiration for what lead to a framework called Scrum. In this article they don’t mention a project owner, they talk specifically about the Product Owner.
In the assignments I have had at airlines, government agencies, and other companies I have often been confronted with implementations of Scrum “projects”. Often these were driven by a wish to make the project organization work together with the business.
But in my view projects have the wrong focus. Products have more importance, both for the business and operations. And if you think about it, would things not improve if we think product more in the IT organization?
Development teams work together to create products, they work on this product all the time, know in-depth how it works, and they also fix the product whenever it breaks down in the field. If they are confronted with software they developed that has bugs they created they will have a better understanding of what quality improvements they have to undergo. They will also feel more ownership and pride of the product. If they are only there for a project, a limited time stint, where the team is thrown together to create something, and then after that stint they are put on a totally different project and might never see the previous one go into production, what ownership do they feel then?
I remember working on a machine, writing the software, and going to the plant to see it start producing products that were available in my own neighborhood supermarket. When I went grocery shopping I found the product and remember checking out the packaging for errors and feeling proud that it was flawless…
Companies I visit as a coach want to work Scrum because of the advantages it brings, the speed it delivers, and the cost effectiveness it would give them. But they seem stuck in project thinking. With embracing Scrum it seems time to also embrace product thinking and to shift our focus from reaching the end of a project to delivering value.