ONLINE TESTS EDITING BOARD
RO
EN
×
▼ BROWSE ISSUES ▼
Issue 19

Tom Gilb. Why delivering value to customers makes your business successful and sustainable

Alexandra Beşe
Marketing Assistant
@ISDC
MANAGEMENT

November 28, Cluj-Napoca, ISDC. Tom Gilb and his son, Kai, visited Cluj recently to share their evolutionary expertise in how to deliver value to stakeholders and create successful customer experiences through agile delivery. And, in return, make their own impressions of Romania and its IT talents, at first hand.

It was their first Romanian trip to meet with anxious and gifted engineers in the land that they"ve only known via media and stories of people met in their international trips. Tom and Kai spent one full day in ISDC and engaged with the ISDC engineers, project managers, testers and other roles in a roller-coaster quest for value: more than 8 hours of intensive workshops, open sessions and myth-busting conversations on topics like "Architecture, Requirements, and Project management", "Non-functional requirements / quality attributes", "Continuous Improvement", "Ten key Agile principles". The interaction in ISDC was intense and thought-provoking on both sides of the table. Tom"s conclusion was that he met intelligent, open, responsive, inquisitive people that are a living proof of a forward going, innovative industry.

And it"s exactly people that determine the threshold for value. When it comes to market differentiation, many people refer to Agile as the new miraculous cure for faster time-to-market, more customer intimacy, more feedback "tolerated" in the development process, and more collaboration between business and IT. Surprisingly enough, Tom agrees that Agile continues to be a market differentiator on one condition: if it is well applied. But, like most methods on the market, Agile is badly practiced. So, eventually, when it comes to competitive organizations, the key differentiator is - like always - quality.

Tom Gilb

Why is then quality still such an intangible asset? Tom used an analogy that for many of us in the outsourcing world sounds probably too familiar. When Indian outsourcers, Tata Consultancy etc., started up, they did not consider quality a factor, only price. Tom advised them to profile themselves with superior quality primarily. They did so using CMM levels. "You know, when I was growing up in the 40"s, the Japanese were trying to break the American market and everything they were building was of bad quality. And then someone woke up the Japanese by addressing one simple question - what about quality? And these days, Japanese products mean exceptionally high quality! I"ve also told my Indian clients that Americans will not buy their services because they are cheap; they will only take a chance with them if they have clearly superior quality to internal production and maybe a niche price!"

And Tom continues: "They did that and adopted the following strategy: we are going to get CMMI certified. Every Indian company has CMMI level 4 or 5, while Americans can hardly get to level 2, ever. So Americans got the message: Indians are superior therefore they are cheaper so why not buy the Indians? And so began the Indian adventure of outsourcing."

Another example provided by Tom to support his idea of a quality-centric philosophy was that of NASSCOM, the Indian Services organization that was to chair a conference in India. Tom strongly advocated to them and in the conference the importance of having focus on quality. For Indian companies especially, this meant a shift or reorientation towards "no cure, no pay contracting." People will pay for the value delivered and not for the labour hours.

So, what will happen to Agile in this highly transformative context? Where will Agile go in 10 years" time? Tom predicts a gloomy future. "Agile will be defeated, dishonored. Not because Agile isn"t good but because it is badly practiced like almost all the other fads that are coming into software. I"ve been here 55 years; new fads come in, there are maybe some good new ideas but people look for shortcuts, oversimplified practices and then they blame the method - Ah, it"s Agile, it"s bad, it"s not for us! So, the solution is to adapt a better method which we will then practice badly and blame the method. It"s been going on for 55 years. It"s a joke!"

"You see it happen all your life; people adopt a good method, practice it badly, blame the method and move on to a new one. People don"t have a culture for doing things really well. There are cultures like - let"s pick music or painting - where if you don"t do really well, you are not up on top. We, in the software industry, don"t have such a culture, a concept of doing things really well. We have a concept of "people are stupid enough to pay us lots of money for doing bad work, so let"s have fun while the party is still on." It"s really sad but it"s worldwide. Any organization, like your own organization, can change things at least for themselves and then you can influence your community by teaching others how to do things really well."

Conclusions

Organizations strive, in general, to learn and excel. The speed at which things are done determines the success. When it comes to tips and tricks for success, try to define attributes that are pivots. For instance, pivot from "We do Agile" to "We deliver VALUE." This is a major mentality change. "If you do that, I predict that you will get a competitive edge because any client would like to get the value, not just the software that they think will bring them value. We are talking about the possibilities of refocusing on the delivery of value to stakeholders and business customers - that"s where the action has to be. When you do that, you will discover that all your competitors are still busy writing code to the expense of delivering value and you will be the one looking really good! You will be able to have a different contracting model because you should go charge the value delivered and you can just as well tell your clients - You don"t take any chances with us. You don"t pay a thing if value is not delivered."

What to practice for yourselves according to Tom:

  • focus on delivering value
  • do things really well so that you can end up on top
  • good implementation of software methods is a market differentiator so don"t blame the methods for bad practice
  • get to know the past otherwise you are doomed to repeat it

Tom & Kai Gilb

"The Gilbs are not "academic" - but light, yet focused, and intensely practical."

www.gilb.com

Tom Gilb and Kai Gilb have, together with many professional friends and clients, personally developed the methods they teach. The methods have been developed over decades of practice all over the world in both small companies and projects, as well as in the largest companies and projects.

Tom is the author of nine books, and hundreds of papers on these and related subjects. His latest book "Competitive Engineering" is a substantial definition of requirements ideas. His ideas on requirements are the acknowledged basis for CMMI level 4 (quantification, as initially developed at IBM from 1980). Tom has guest lectured at universities all over UK, Europe, China, India, USA, Korea - and has been a keynote speaker at dozens of technical conferences internationally.

Kai Gilb has partnered with Tom in developing these ideas, holding courses and practicing them with clients since 1992. He coaches managers and product owners, writes papers, develops the courses, and is writing his own book, "Evo - Evolutionary Project Management & Product Development."

There are very many organizations and individuals who use some or all of their methods. IBM and HP were two early corporate adopters. Recently over 15,000 (and growing) engineers at Intel have adopted the "Planguage" requirements methods. Ericsson, Nokia and recently Nordea and Statoil and A Major Multinational Finance Group use parts of their methods extensively. Many smaller companies also use the methods.

This interview was realized on the ISDC premises with Tom Gilb.

Sponsors

  • ntt data
  • 3PillarGlobal
  • Betfair
  • Telenav
  • Accenture
  • Siemens
  • Bosch
  • FlowTraders
  • MHP
  • BCR
  • Itiviti
  • Connatix
  • UIPatj
  • MicroFocus
  • Colors in projects