Also posted on SogetiLabs: http://labs.sogeti.com/the-fte-illusion/
Working as an Agile coach I am often told by Scrum Masters or Product Owners how they cannot understand how a 5-person team cannot become as productive as they should be in Scrum.
Lately, I have been asking the follow up question: Do you count FTE (Full-time Equivalent) or actual persons when you say “a 5- person team”?
Within companies people are often considered to be resources (hence the department Human Resources). The problem I see with this is that humans are NOT resources at all. We cannot assume that one person can be equally effective when they have to work in four teams at the same time.
FTE is effective if you want to reduce costs or to throw a wannabe project a bone, or to give your program director a project plan that looks favorable enough to get the funding you need to get started. Within Agile however the FTE illusion is the cause of a lot of pain.
My assumption (and I hate assumptions) when a company chooses Agile is usually that they will put dedicated teams on the products they want to develop. An assumption that has proven wrong in many companies that I have helped to transform from traditional to Agile.
Agile is built on four pillars, of which the most important one is Communication. The Agile manifesto states “Individuals and Interaction are preferred above Processes and Tools”. Individuals, NOT FTE’s are preferred and their interaction. This is what Scrum Masters will focus on. To increase, for instance, the communication between Product Owners and Development teams.
A problem that arises when you start measuring teams in FTE and not assigning full people to those positions is overhead. If a person is .5 FTE in one team and .5 FTE in another, the ceremonies and meetings will still be double for both team-positions. This problem also comes up when a Scrum Master is not dedicated to one team. I have been a Scrum Master to more than one (in fact even four) team. The teams were also working on the same portfolio so they were synchronized.
Every Sprint end and start I was looking for ways to accommodate and facilitate all the teams I served. And since cloning is still in its infancy I was physically unable to attend all the meetings and ceremonies. Agile helps teams and individuals focus and also helps in reaping higher performance.
Please keep in mind that individuals are undividable.
Als ik aan kwaliteit denk komen beelden in mij op van dingen, objecten die de tijd hebben weerstaan. Oude bruggen die nog feilloos werken, het horloge van mijn opa uit 1914, de apparaten die zelfs met dagelijks gebruik nooit problemen geven.
robuustheid, maar ook producten waar aandacht aan is besteed toen ze gemaakt werden.
Aan deze stevigheid ligt vaak een kwaliteitsproces aan ten grondslag. Trots zijn op het product dat je bouwt, geen fouten laten doorsijpelen in het product.
Deze gedachte is waar Jidoka voor staat.
De geschiedenis van Jidoka is terug te vinden in de fabrieken van Sakichi Toyoda, de grondlegger van het merk Toyota. We kennen Toyota voornamelijk van de auto’s, Jidoka is echter ouder dan de Toyota autofabrieken.
Meer dan een eeuw geleden ontwikkelde meneer Toyoda een automatisch weefgetouw. een van de problemen die automatische weefgetouwen eind 19de eeuw hadden lag in het moment dat het garen brak of op raakte. De machine gaat gewoon door en het herstellen was een groot probleem. Het weefgetouw van Toyoda stopte de machine meteen waardoor men meteen het probleem kon verhelpen.
Bijna 30 jaar later ontwikkelde meneer Toyoda een andere machine waarbij de machine niet meer stopte maar verder ging met een nieuwe spoel.
Automatisch, dat is wat Jido in het Japans betekent. Voor Toyota verwijst Jido echter niet alleen naar machines die automatisch bewegen, het verwijst naar machines die beslissingen nemen. Jidoka betekent Automatisering met een menselijk kantje.
In de na de tweede wereldoorlog opgestarte autofabriek werd Jidoka ook ingevoerd. Het gaat hier om het proces waarbij als er een probleem wordt geconstateerd het produceren stopgezet wordt.
Wanneer het produceren stopt kun je het probleem verhelpen, Jidoka gaat echter verder. Het proces van productie wordt aangepast zodat het probleem niet meer op kan treden. Dit is het gedachtegoed achter Jidoka, kwaliteit inbouwen in het proces. Het probleem treed niet meer op en de kwaliteit is verbeterd. Dit werkt alleen als de teams zelf beslissingen kunnen nemen om het proces te verbeteren, Jidoka werkt dan ook alleen als je autonome teams in je proces opneemt.
Traditioneel is testen een van de laatste fasen in het project-proces. Na het testen gaat het product dat men heeft gerealiseerd naar productie.
Het oplossen van de bevindingen moet dus voor die tijd gebeuren om te zorgen dat een kwaliteitsniveau gehaald wordt. Vaak heeft hiervoor een maandenlang bouwproces plaatsgevonden.
Weet u nog wat u twee maanden geleden heeft gedaan? De meeste bouwers in ieder geval niet.
Om kwaliteit in te bouwen zal het proces moeten wijzigen. Als blijkt dat een fout of defect bijvoorbeeld te voorkomen is door een processtap (denk aan reviews, testen, automatiseren) dan zou dit overwogen moeten worden.
Wil men intrinsieke kwaliteit dan is dit gewoonweg nodig.
Waarom accepteren we fouten? Met het Jidoka gedachtengoed zijn buglists onacceptabel! Als je iets bouwt en je merkt dat er een fout in zit, is het je eer dan niet te na om deze fout op te lossen?
Willen we terug naar producten die robuust zijn. Producten waar we trots op zijn, dan zullen we ons gedachtengoed moeten aanpassen. Fouten oplossen en zorgen dat ze nooit meer kunnen optreden. Pas dan krijgen we intrinsieke kwaliteit.
Posted on SogetiLabs, date: August 20th, 2015 – http://labs.sogeti.com/future-wholeness-the-advances-in-prosthetics/
In the age of the Internet of Things I am eagerly anticipating new amazing research. Something that I have been specifically following in the news, is the advances in prosthetics. When I was a kid I met a number of amputees who were struggling through life with the loss of their limb(s). My father worked as an HR manager at a government company that provided a workplace for people who had trouble finding jobs due to mental or physical disabilities. At that time, I met many of his colleagues and they instilled in me a desire to find ways to restore and/or improve the lives of people who lost mobility through the loss of limb or movement in limbs.
A very important image in my mind was the scene from the movie “Star Wars, the empire strikes back” where after losing his hand in a battle with his father, Luke Skywalker (the protagonist) gets a new hand fitted. I have been hoping for advances in electronics that could make a prosthetic like that possible.
In the past few years the advances that have emerged in this field have made my mind boggle. These advances were not just in electronics and mechanics, they have also been in the understanding of phantom pain, and treatment for that. One of the treatments is mirror treatment, where the visible movement of a missing limb is recreated by seeing the mirror image of the existing other limb make the same movement. This could of course be helped by actually having the limb back, but since growing limbs is still in its infancy, it may be a long time before we get that.
In the meantime, there have been advances in making the amputee feel again. This could be the next thing in treatment, seeing your artificial hand move does not do much to counter phantom pain. But when you can feel it move or touch again – that would definitely help.
My interest in these advances also keep me looking for new developments in the field of electronic interfaces. One interesting development has been around for several years already. It’s the epidermal electronics development which make wearing electronics (essential with advanced prosthetics) lightweight enough to not hinder. I have not seen this kind of electronics be integrated with electronic prosthetics, but I am hopeful these fields of study will eventually merge.
Using an epidermal electronic interface may help in the development of a lightweight exoskeleton that can help people who have lost mobility, either with or without limbs. I wish this would have been possible for my friend Philippe who died of muscle dystrophy this year. A hero in his own right with a tremendous will to live.
I will keep monitoring the news and web for new discoveries and maybe, if I am lucky, I may help people become whole again, man aided by machine.
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.[1] He names three things:
Autonomy
Mastery
Purpose
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?
[1] 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 week I started at the Dutch Railways on a new assignment. A very interesting one as I never figured the organization would be Agile. As it is the department that develops the website has been using Scrum for a while and they just needed someone with more experience to help them out.
I see a lot of challenges, but I see even more chances to improve this organization. What I thankfully also see is a lot of willingness to improve within. Everyone I speak to seems to want to change the way of working so that things improve.
Who am I to not oblige. I really want to help them become more Agile and I will do my best to get them to speed up.
There is a lot to do though, the bottom layers are still very traditional and the upper layers want Agile but need to be made aware what it means to allow Agile as well.
This was posted on July 29th, 2014 on SogetiLabs: http://labs.sogeti.com/bring-back-intrinsic-quality/
Source: http://www.merriam-webster.com/
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[1]):
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[2] has led them to decide to replace their robots with people [3] 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[4]. 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.
