Wednesday, March 30, 2011

PMI Agile Certification - what is it worth?

The Project Management Institute has started beta testing a new certification of Agile Project Leaders. What does this mean? Where does it fit in with the existing certifications? And what impact will it have on the Scrum Community?

Gregory Balestrero, President & CEO of PMI, attended the Orlando Scrum Gathering in 2009. When he got there what did he see? Half the attendees had a PMP!

These attendees were members of the PMI for whom the PMI was doing nothing! So this Scrum and Agile stuff was not just a passing fad, but represented a real need in the software space. The PMI had to do something, and that something is the PMI Agile Certification.

The program has now been published on their website. According to the PMI, their certification program should enable practitioners to:
  • "Demonstrate to employers their level of professionalism in Agile practices of project management
  • "Increase their professional versatility in both project management tools and techniques
  • "Show they have the capacity to lead basic Agile project teams by holding a certification that is more credible than existing training-only or exam-only based offerings."
The last point is clearly a poke in the ribs at the Scrum Alliance (basically a training-only certification) and Scrum.org (an exam-only certification).

What must you do to become a PMI certified Agile Professional? The details are spelled out on their website; here are the most essential points:
  1. General Project Management Experience — 2,000 hours working on project teams, earned within the last 5 years. Those holding a PMP credential already satisfy these requirements.
  2. Agile Project Management Experience — 1,500 hours working on Agile project teams or in Agile methodologies within the last two years.
  3. Agile Project Management Training — 21 contact hours; hours must be earned in Agile project management topics  
  4. Examination — Tests knowledge of Agile fundamentals and ability to apply to basic projects 
  5. Maintenance — 30 PDUs/3 CEUs every 3 years in Agile project management.
Note that Agile Project Management Experience cannot be double counted with general project management experience. A total of 3500 hours is necessary for the certification.

Twenty one contact hours basically translates to three days of Agile Training. The PMI has recognized  Scrum Alliance certified courses in the past, so this should continue in the future. Note that over the three years after initial certification, an average of 10 PDUs / year (1 PDU = 1 hour of training, conference attendance or similar activity) is required to maintain the certification.

What does the PMI Certification mean?

I was always impressed by the tag-line of the PMI: "Making project management indispensable for business results." It sounds to me like their primary purpose is to ensure their own existence, just like a bureaucracy would do. And in fact, when I visit companies, most of them want to shake off the sluggishness and bureaucracies that phase-oriented development models produce. The tag line of the Scrum Alliance: "Transforming the world of work". It's not just about managing projects, but making the workplace a better place to be.

What speaks in favor of the PMI certification? Certainly the size, influence and stability of the PMI mean that this will be an important certification. The Scrum Alliance has had problems establishing cohesion and direction since the split with Ken Schwaber. Schwaber's Scrum.org is a dot-org in name only. Scrum.org belongs to Ken Schwaber's family business, Advanced Development Methods, Inc. The PMI is on much more stable footing than the Scrum-specific alternatives.

A number of highly thoughtful and influential Agilists were involved in creating this program, including two CSTs and the leaders of other important schools of Agile thought. So the certification comes with good pedigree (although there are some caveats, see below).

For the candidate, it will be necessary to demonstrate substantial commitment, knowledge and experience. So I think the certification will enjoy a lot of credibility the marketplace. I believe it will have substantial impact on training programs related to Agile.

Still, Agility is not just a collection of practices. It is a frame of mind. The requirement that you already have a PMP and 2000 hours of classical, non-agile experience bothers me. In French, this is called the 'Déformation professionelle'. Training and experience form you, but they also deform you. PMI certified agilists will bring a lot non-agile baggage with them.

Remember the spoon scene from The Matrix?
Spoon boy: Do not try and bend the spoon. That's impossible. Instead... only try to realize the truth.
Neo: What truth?
Spoon boy: There is no spoon.
Neo: There is no spoon?
Spoon boy: Then you'll see, that it is not the spoon that bends, it is only yourself.
Learning Scrum is a lot about learning how to bend spoons, that is, learning to change yourself and your environment so that both become happier and more effective. Of course, I could be wrong on this one, but I while I see the PMI certifying many Agile Project Managers, I don't see the PMI producing the next generation of spoon benders. Yes, I think the PMI Agile Certification will be successful and influential. And yes, I think Scrum (and its relatives and descendants, e.g. XP and Radical Management) will continue to grow and thrive.

Tuesday, March 29, 2011

Good Profits, Bad Profits, and Roaming Profits

Today, I opened the latest issue of K-Tipp (the Swiss equivalent of Consumer Reports) and they reported on the new Data Roaming Rates of the three big Swiss Telcos. Although the Telcos claimed simpler, lower rates for customers, the rates are still high and confusing. I believe these companies are doing a tremendous disservice to themselves, which will eventually cost them market share and profitability. They are creating Brand Debt.

Under the new rates, Switzerland's leading provider charges 30 Swiss cents / 30 KB. There is a daily limit of CHF 7, unless you exceed 5 MB, in which case, access costs 30cts per additional 30KB. Why don't they say CHF 10/MB? Here in Europe we have the metric system for a reason! And what is this limit that is not a limit?

It sounds like I could send an email up to 30 KB for 30 cents. Is that true? Far from it! I measured the data volume to sign on to the internet and check my email: 1330 KB with no new messages! (OK I'm a special case: I have 5 IMAP accounts and a VPN). I check my email at least 5 times per day, so I'm looking at CHF 33 / day, just to check email (before I even do anything!) If I actually read mail, send mail, surf the internet (or heaven forbid, listen to internet radio), it would cost much more, even if I took one of the roaming packages these carriers offer.

What's wrong with these rates? Obviously some people pay them and I am sure the carriers make a lot of money off of data roaming. The problem is the additional messages that these companies are sending to their customers:
  1. Our goal is to make sure you can't figure out what the service will really cost.
  2. We will hit you for all we can!
  3. GO TO ANOTHER PROVIDER!!
These are Bad Profits.

How can you make Bad Profits with Data Roaming? Roaming is a great concept! I can take my telephone or PDA anywhere in the world and be reachable, make calls or surf the net! It's a great idea that can simplify my life tremendously. The engineers have done a great job of building a great product. All the potential is there for the customers to be delighted.

But the people who decided the pricing policy have said, "let's milk it for all it's worth!" Why is this a bad thing? Because they are accumulating debt. Brand Debt. Someday they will have to pay this debt.

Everybody understands that financial debt is a bad thing. You borrow money and have to pay it off with interest in the future. Over the long term, you cannot spend more than you earn (unless you are a government). Sooner or later, you have to pay off the debt. If you can't service the debt (pay the interest), you are bankrupt and lose your house and other valuables.

Engineers know that technical debt is a bad thing. If adding a new feature to your system causes more errors than it creates in value, your code is effectively dead (bankrupt). So good engineers know they have to write tests, refactor the code, review their work, and build safety nets to ensure that they are not taking on technical debt when they implement new features. Otherwise, sooner or later the technical debt will be so great that they cannot add new features. They will have to throw the product away and start again from scratch.

If your brand has a good reputation, people will trust you, perhaps even love you, and be happy to buy your services. Look at Apple: People stand in line to buy every new product they bring out.

Accumulating Brand Debt means you are chipping away at the value of your brand. Remember the 70's joke about two GM product lines, Chevrolet (the people's car) and Cadillac (the top-of-the-heap luxury car, before Mercedes took over this position)? What is the difference between a Chevrolet and a Cadillac? Oh, about 6 thousand dollars.' That was a serious case of brand debt. It took Cadillac a long time to recover its position. (Did it ever recover its position?)

Bad profits mean you are accumulating Brand Debt. Bad profits look good on paper might be easy money because your customers don't (at the moment) have good alternatives, but they annoy your customers. Given enough time and brand debt, your customers will surely find an alternative.

How can you tell if your company is accumulating Brand Debt? Here are some warning signs:
  • You're afraid to talk to your customers due to the problems it might cause
  • Your revenue is stagnating or shrinking, especially in a growing market
  • You're thinking, this market will cease to exist in a few years, so let's milk it for what it's worth.
  • The alternatives to your product are substantially cheaper than your product, only inertia is keeping your customers on board
With Scrum, the team is focused on creating value for customer or user. This is essential for creating great products.

But having a great technical team is only half the battle. Your company needs the right purpose. The purpose is to delight the customer. Good profits are what you get when you delight the customer.


Interested in continuing this discussion? Join us for a Gathering on Radical Management in Washington DC, May 12 & 13, 2011. Earlybird pricing until March 31.

Saturday, March 26, 2011

Plan B: Eject the Warp Core!

I don't often write off-topic, but the images coming from Japan are just too troubling. I am not sure which images trouble more - those coming from Fukushima, those that came from Chernobyl or this video from Swiss TV:

Einstein vom 24.03.2011

What would happen if something like Fukushima or Chernobyl happened here in Switzerland? 800'000 workers were needed to contain Chernobyl; 50'000 of them have died of radiation sickness. The radiation in the Chernobyl reactor was so intense that even the robots failed.

Switzerland's population is only 7.4 million, of whom 2.5 Million are adult males, aged 20 to 60. If an accident on the scale of Chernobyl happened here, that would mean more than 1 Swiss in 10 -- or more likely, 1 adult male in 3 -- would be called into service and around 1 adult male in 30 would die. An area nearly the size of Switzerland would be rendered uninhabitable.  Where would the rest of us go?

How can we expose ourselves to that kind of risk?

Either we need to get rid of nuclear power plants or we need a better Plan B.

Plan B

On the way home from work a few days ago, I was wondering how would Star Trek solve this problem? I could almost hear LaForge screaming "Captain, I have to eject the warp core!" How could a nuclear power plant eject its core?

Sending it into space is not option -- too dangerous -- and beaming doesn't work either. So there is only one direction available: Down. Fortunately that is relatively easy to do. Gravity will do most of the work for you. (You can demonstrate this by jumping from a diving board, throwing something off a tall building, or letting a ball roll down a hill).  You just need to prepare the reactor and path, so that the reactor core can fall or roll into a secure area on command.

The harder part is preparing the pathway and ensuring that there is enough material to isolate what is left of the reactor core and prevent the radiation and other products from contaminating our ecosystem. While this is not possible after a nuclear incident, an ejection could be prepared beforehand.

One approach for long term storage of radioactive materials is the so-called 'deep borehole.' The idea is to drop the waste down a very deep tube, say 5 km, then cap the tube with earth, rock and water to prevent leakage.  

Why not build the reactor directly over a borehole? In the event of an emergency, the reactor core could be separated from its mountings and allowed to fall into the tube. The deployment might look something like this (click to enlarge):


Would this be sufficient to safely dispose of a reactor core? There is a natural precedent. A mine in Oklo, Gabon had been site of a natural U235 reaction. The remains of that reaction are still radioactive, but the sandstone around the uranium deposit contains the radiation.

Can we build a suitable borehole? The current record for a deep boreholes extend over 12'000 meters into the earth's crust! Obviously, an eject borehole would need to be substantially wider than existing boreholes for pumping oil or scientific research. The final resting site probably should be below all aquifers.  And there are surely other issues and technical challenges. But there are precedents for the solution. And without a Plan B, nuclear power is just too dangerous.

Plan C

Would this Plan B have helped in Japan? I don't think so. An earthquake is liable to leave the boreholes blocked or otherwise unusable. Which brings us to Plan C: If there is no viable Plan B for securely and quickly shutting a reactor and isolating it from our ecosystem, then then nuclear power is just too dangerous. Shut it down or don't build it in the first place!

Monday, March 21, 2011

Call for Participation: Lean Agile Scrum Conference Zurich 2011

The third LAS Conference will takes place on September 14, 2011 in Zürich. The conference is a forum for practitioners of Scrum, Lean, Agile and related disciplines to learn and share their experiences. As a low cost community event, it is open to a large spectrum of interested parties.

This year's motto is: "Field Reports on the Road from Pilot Project to Corporate Strategy" The organizers, the SwissICT Lean, Agile & Scrum group, once again seek to bridge the gap between C-level executives, managers, project leaders, business analysts, developers, testers and connect the management perspective with the view from the trenches.

The day starts with a keynote by Stephen Denning in the morning. After this free event, the official conference starts at 10:00 with tutorials (90 minutes) on Scrum, Kanban and a yet undefined topic. The afternoon sessions open with a keynote by David Anderson, followed by eight experience reports (45 minutes) in 4 parallel tracks.

You are invited to submit abstracts for tutorials and experience reports. Full details are on the conference homepage (English, German) Submission deadline is April 15, 2011.

Interview with Steve Denning on Storytelling and Radical Management

I met Steve Denning on the Agile Business group at Yahoo! He had joined a discussion on the best way to get started with Agile and implement the change process.

A few months later, he asked for reviewers for his new book and I signed on. His "radical management" (sounded like 'extreme programming') struck me as a synthesis and extension of key patterns, principles and practices from Scrum and Lean (which I have been promoting for years), something new called Leadership Storytelling, and a sharp focus on delighting the customers. His book is written in clear language for people outside the IT and Automotive sectors.

It clicked immediately with me. When I heard about the Washington Gathering, it was clear that I had to go! What does Steve say about Agile?
I believe that (genuine) Agile is a better way of managing and a great breakthrough in terms of management innovation.

But for this to be recognized and for Agile to have its rightful place in the overall scheme of things, it needs to be communicated so that people outside the world of software understand it, believe in it and and want to have it, rather than close it down as an unintended accident of a mindless cost-cutting exercise.

-- Steve Denning, writing in Agile Business, July 10, 2009
In preparation for the Washington Gathering, I asked Steve to explain some of key concepts of Radical Management. 

What is leadership storytelling?

Leadership storytelling is a way of communicating ideas through narrative. It uses the natural power of storytelling to convey ideas quickly, easily and powerfully. Because people naturally understand the past through stories, think about the present in stories, plan the future through stories and make decisions through stories, leadership storytelling communicates with people in their native language. By contrast, abstract or analytic language is a kind of foreign language that is much less engaging.

In a business setting, the leadership stories that work best are typically short factual stories about something that actually happened and that illustrate the point that the leader is trying to make. The story enables people to get inside the idea and imagine themselves being involved in it so that the idea becomes part of their own repertoire of experience. The idea thus starts to become their own idea, which is the essence of leadership communication.

Why do leaders need to know about leadership storytelling?

Why storytelling? Nothing else works. Charts leave listeners dazed. Text remains unread. Giving reasons leads to arguments, not agreement.

When leaders are faced with the task of persuading a group of managers or front-line staff in a large organization to get enthusiastic about a major change, experience shows that storytelling is usually the only thing that works.

What led you to write 'The Leaders Guide to Radical Management'?

Several years ago, I began examining why the traditional management that is prevalent in large organizations tended to kill the most creative activities, such as innovation, lean manufacturing, agile software development, marketing, knowledge management and even leadership storytelling. After all, these were the activities that would create the future for the organization. Yet in firm after firm, I watched as traditional management would kill these activities in the name of ever greater efficiency.

So I began looking for organizations that were doing things differently and instilling a culture that supported the creative activities in the organization. The book is about organizations that are doing exactly that. I discovered that these firms incorporated five big shifts, including a shift in the goal of the firm from making products and services to one of delighting the customer, a shift the role of managers from controllers to enablers, the use of dynamic linking rather than bureaucracy to coordinate work, a shift from value to values and a shift from command to conversation and storytelling. The book is about why they adopted these principles, how they have gone about implementing them, and what the results are.

Who has applied radical management principles?

Much of the most advanced thinking about radical management comes from software development, such as Agile and Scrum. Firms like Salesforce.com and Systematic Software (Denmark) are examples in software. Radical management means taking the principles of Scrum and Agile and adapting them to the whole business.

In manufacturing, Toyota and Thogus are examples. Apple (since 2001), Ford Motor Company (since 2006) and Amazon.com are exemplars among large global organizations.

The book gives many other examples of firms in a wide array of fields, including sales, marketing, venture capital, accounting and legal work.

How has implementing radical management changed their business?

Deloitte’s Shift Index indicates that traditional management is in steep decline. The rate of return on assets of US firms is one quarter of what it was in 1965. The life expectancy of firms in the Fortune 500 has declined from around 75 years half a century ago to less than 15 years. Only one in five workers is fully engaged in his or her work. Innovation remains a critical issue.

By contrast, radical management generates disciplined execution, continuous innovation, high staff commitment, and client delight.

Firms such as Apple, Amazon and Salesforce.com are experiencing exponential growth in sectors where competitors are struggling. Their ten-year share price tends to show increments of more than ten times, while firms deploying traditional management struggle even to maintain the same value.

For these reasons, the adoption of radical management is inevitable: the economics will drive the change. The question is not whether it will happen. The only question is when. Companies that do not adopt it will be unable to compete.

Why is the Gathering in DC so important?

The Gathering in Washington DC brings together practitioners from around the world to explore how to implement the principles of radical management. Unlike most conferences where participants listen to prepared speeches, the gathering will be organized so that the organizers and the participants can co-create the future, drawing on the experiences of the practice partners as well as the inputs from the participants themselves.

In effect, the participants will create what radical management means for their own context and then collaborate with the other participants to work through how they can implement it and overcome the constraints in their own setting.

I believe that the gathering will be a foundational event for the global movement to move from traditional to radical management, to shift the focus of firms from outputs to outcomes, and to transition from an inside-out approach in management to an outside-in perspective, focused on continuous innovation and customer delight.


You can join as at the Washington Gathering: Revolutionizing the World of Work. These two days, hosted by Steve Denning and Seth Kahan, will be dedicated to remaking the management mindset; that is, reinventing business, government, education, and health. I am proud to participate as a practice partner. Perhaps you will join us! If you are interested, check it out now as the early bird registration ($100 discount) expires March 31st. More information... Register...

Monday, March 14, 2011

Success Factors in a Scrum Sprint

Last week, I posted a summary of the responses to my poll on scrum sprint success and story size. I also proposed a simple definition of success: a successful Scrum team delivers what it promises.

A good Scrum team does not systematically over-commit. It doesn't under-commit either - not one single response indicated that the team usually delivered more that 110% of its commitment. By this definition, 32% of the respondents are "successful" while 68% are "improvable".

Let's take a closer look at Team Size, Story Size and Sprint Duration and how the relate to relate to successfully completing the a Scrum Sprint.

Team Size and Sprint Duration

Two week sprints are by far the most popular with 50 respondents, and the distribution of on the number of stories committed to each sprint looks pretty much like a bell curve centered around 6 stories/sprints. Three week sprints a relatively popular - 17 responses - but the volume of data is probably too small for a curve to form.  With a total of 13 responses, it's unlikely that the data for 1-week and 4-week sprints is at all representative.



Number of Stories

The number of committed stories peaks at 6 to 8 for teams doing two-week sprints and 4 to 5 for teams doing 3-week sprints. I am puzzled by the dip at 6 to 8 stories for three week sprints.


Number of Story and Sprint Success 

Queuing theory tells us that implementing more, smaller stories should be more predictable than fewer large stories. The numbers generally bear this out. (The data point for 2 to 3 stories is probably not representative - there were only 5 responses, all others had 15 or more responses).


Sprint Length and Team Success

Are shorter sprints better? A lot of common wisdom points to this conclusion, but it is not supported by the poll data. The average of all the data was that 38% of the teams are 'successful.' Teams doing 2 and 3 week sprints reported slightly worse than average and 1-week teams slightly better.

Most intriguing are the teams who reported 4 weeks sprints. They reported a success rate of 75%! There are only 8 teams reporting, so it may not be representative. But it may also be that the value of longer sprints are underestimated.



Team Size and Sprint Success

Teams with 1 to 3, 6 or 9 to 10 remembers were less successful that the other sizes. I don't think there is much of a trend here.

 
Maximum Story Size and Sprint Success

I was expecting that teams which took on very large stories would be less successful than those which do not. This was only true for those teams which reported taking on stories larger than 40% of the teams capacity for the sprint.  11 Teams reported taking on stories larger than 40% of the team capacity, only one reported being usually successful in accomplishing the sprint.

Much to my surprise, teams reporting taking on 35 to 40% were the most successful, followed by teams that limit the largest story to 5%. The sample sizes for those data points were rather small, with 5 or 6 respondents in each category, so I would take that with a grain of salt. Among those categories with more than 15 responses, the range of 15 to 30% did best.




Summary

Having analyzed the data, I think the survey would be much useful if there were a factor of 10 more data points - 800 to 1000 would be really good. Still, looking at this data, some trends are taking shape:
  • Doing Scrum well is very difficult. Most teams do not reliably deliver their sprint commitment by the end of the sprint.
  • There is no one right way to do Scrum. Both "Successful" and "Improvable" teams come in all sizes and configurations.
  • At least up to a point, more stories per sprint are better. It looks like 10 to 15 is a good number. Most teams should consider slicing their stories smaller.
  • Very big stories are are unlikely to be completed in the sprint, but an occasional moderately sized story doesn't look like it's a problem.
  • Maybe 4 weeks sprints are better than their reputation. The results could be wrong, but should be explored more deeply.
P.S. Does anybody with substantial readership think this study was cool and useful? I would love to repeat it with the goal of substantially higher feedback and see the trends become more apparent. Please contact me!

The story size poll is still active - I'll keep an I eye on it and when I get 200 responses, I'll evaluate the data again. Presently I have 85.


Sunday, March 6, 2011

What is the optimal Story Size?

Last November, I started a quick poll on Story Size, Team Size, and Sprint Success. I wanted to explore that variables of team size, sprint duration, average and maximum story size, and whether there is any correlation between between these parameters and team success.

I received 81 responses (presumably from 81 different people and hopefully from 81 different teams, but I have no way of checking this). 78 claimed to be doing Scrum, one claimed XP, and two did not reveal their preference. This article presents a first look at the results.

Team Size

Scrum recommends an Implementation Team size of 7+/-2, so 5 to 9. Based on the poll, 63% of the respondents are in the range of 5 to 10 (should have sized the response blocks differently!). 28% have 1 to 4 people and 9% have 11 of more.





Sprint Length

These results were something of a surprise to me. More than half (63%) of all respondents indicated they did two week sprints. Only 1/3 that number reported 3 week sprints. In May 2008, I ran a quick poll on sprint length, and the answer came up even: almost exactly 1/3rd each were doing 2 and 3 week sprints, another third where spread around 1 week, 4 week, 1 month and variable.

Obviously the poll tells us that something has changed, but not why this change has happened. And in all honesty, I am not sure this represents a real change. The previous poll had only 34 respondents and even 81 is not a huge number.

On the other hand, the influence of XP on the Scrum community has grown, there has been a lot of discussion on "Scrum-But" since my original poll on the Nokia Test, and queuing theory tells us that shorter sprints with more stories per sprint should be more predicatable.

Number of Stories per Sprint

In my trainings, I recommend teams to take on at least 10 stories per sprint. This means that the average story size is around 10% of the team's capacity. What do teams actually do? 74% of all teams take on between 4 and 13 stories per sprint, which puts the average around 7 or 8 and the average story size around 12% to 15% of the team's capacity.


Largest Single Story

During my first Scrum Project as ScrumMaster, I made the observation that if my team took on a story that was 40% of their total capacity for the sprint, their chances of not completing the story were, uh, "excellent." In the mean time, I have conversations with people who suggest 25% is better maximum. I was surprised to see that there are teams out there who will take on a story that represent 50% to 100% of the team's capacity for the sprint!


According to this data, 54% or all teams insist on stories <= 20% of their capacity, and 79% insist or 35% or less.

Success rate

Success is a tricky thing to measure. For this poll, I define success to mean, 'the team delivers that which it commits to.' This does not say anything about the productivity of the team. I once saw a 12 person team double its performance in story points after being split into two 6-person teams. But the team had been delivering what it promised, so by this definition it was a successful team.

I choose this measure for success for two reasons. 1) Delivering on commitments is a fundamental skill of a Scrum team. It builds trust between Implementation Team and Product Owner. 2) It is relatively easy (uh, possible) to measure in this context ("the light's better").


Looking at this graph, you might get the impression that a 70 to 90% success rate is OK. I don't think so. The goal is to be a reliable partner. Yes, a team needs the safety to fail once in a while, especially when they just start out with Scrum, and if you focus too much on the goal of certainty, then other things, like performance and creativity, may suffer.

Scrum is Hard to do Well

So I would interpret this data differently. There are teams that are doing well, "successful" and those that need improvement:


...but I think we're getting better!

It looks like 38% are doing pretty good Scrum, delivering on their commitments, and 62% could be doing better. This compares favorably with the 76% of all respondents who scored 7 or fewer points in the 2008 Poll on the minimal Nokia Test.

The interesting question is what are the signs of a good (or bad) Scrum team? I have been playing with Pivot Sheets and will post some analysis of the relationships between the various factors. (And if anyone is good with statistics and/or has access to better tools than Excel for this purpose, your help would be most welcome!).

Update 6.3.11: Here is the original Poll and the actual data in spreadsheet form. (Don't use google's graphical summary of the results. For reasons I do not understand it is not correct).