This is the third installment in our five parts series featuring Zvi Feuer talking about our agile processes.
Question to Zvi: "Were you moving the company to Agile more according to ‘inside out’ or ‘outside in’? I.e., were you the Agile knowledge guru pushing the change from within the organization, or, understanding that change is needed, did you reach out to external experts/advisors?"
Well as you know, we did bring in the AgileSparks firm for some consulting. Now we use them less. The move to Agile methodology was born from my understanding that in order to run an organization like this we have to organize into smaller groups and give much more flexibility to people and to our customers. First thing was that I wanted that we become more efficient, so I did read books and learned things, to know how we could free up resources in to be more innovative. Because you can’t be innovative without money, but you won’t get more money – they would laugh at me if I was to go to my manager and say, 'Listen, I need more money so I can become innovative’. He would tell me, 'Go do what you want with the money you have’. You come to people, and you have $50M. You tell them we have to be more efficient in order to be more innovative, and they will say, ‘Ok, so tell us what not to do’, but we should do the things we are doing today, but more efficiently. More efficiency frees up resources for innovation. How to increase efficiency? Through organization structure, methods of working, technology, using new people, new approaches.
Our vision was to turn a software production company into a startup. A startup by definition works quickly, is dynamic, flexible, experiments, goes for new experiences, and some of the experiences will fail. It’s not waste because there is no better way to learn than from failures. If we knew everything we would be some kind of superior being, but since we’re not, and we have to admit that there are some even smarter people than some of those that work here. One of the ways to be innovative, and continually improve ourselves, all the time, both with our old technologies and new ones as well, and create new things – that requires that we experiment. Experiments always have to be brief and in front of the customer, and here also we have to be Agile. If the customer says ‘do it this way’, you move, ‘do it that way’, you move there, always listening to what the customer says.
And in that way reduce the chance of error, but still there will be mistakes, things that you invested in that didn’t turn out well, but if you’re sufficiently quick to act, you can take a step backward, learn from your mistakes and continue forward and start something new. This has been our agenda. In order to be ready to implement this agenda, we had to become more efficient, in order to reach higher efficiency. I had to read a lot of material and reached the conclusion that the best way to make a software organization more efficient is to move to Agile.
"Where’s the expression of the customer’s involvement in our process?”
First of all, the customer can enter at any stage along the way. We always try to allow this, though I say it with some caution, since we’re not doing that perfectly so there’s still room for improvement. But we continually try to keep the customer looking in. When we need something, we have the customer close at hand, and not just ‘after the fact’ – if the customer became involved only after the fact, after development is finished and complete, that would be to return to the old ways.
We want to be with our finger on the pulse all the time, to work facing the customer. If the result is good, we continue, if not good, we fix it before continuing. Many times you build something for the version that’s not innovation, but it is improvement – improvement in speed, quality, fix something. Also you have to know how to work correctly because there are many demands and you have to know what to do first, and which afterward. Also we’re using technologies not used by others, e.g. AI (artificial intelligence) using machine learning that tries to identify which P1 type (top priority) bugs that we need to uncover and fix in order to be certain that we’re not heading into a crises with the customer, but also to reveal which of the P1s we can skip or delay fixing without negative results. At the moment we’re experimenting with it but it seems very promising and it’s part of our Agile practices. It turns out the world is subjective, since we might regard it as an enhancement request, the customer might see it as a P1 bug. So instead of arguing, we said, on the basis of our knowledge base and amassed experience, and 1000’s of P1 bugs that we fixed and others that are still open, so let’s see if by way of machine learning to identify those that, if we fix them we’ll bring significant improvement to the system performance. And not at great cost either – the price of paying a student at the University of Cincinnati. And what’s nice today, because of greater computing power and easily available resources like the cloud and Amazon, you can do things that used to need super computers and millions of dollars but now for very cheap.
There is no real “cheer-leading” coming our direction from other parts of the organization for our business, but still anyone who wants to learn from what we are doing is welcome. Also even if there is someone who thinks you did very well, made a breakthrough, well if he would say, ‘wow that’s great, I also want to do that’, he is welcome to come and learn and we will help him – we don’t hide anything, it’s all in the open.
About the author Zvi Feueris senior vice president of Manufacturing Engineering Software for Siemens PLM Software, a business unit of the Siemens Digital Factory Division. He has more than 25 years of experience in Enterprise Software business management, with a primary focus in the Manufacturing Industries. He has worked for: the Israeli Aircraft Industries (IAI); Digital Equipment, a leading provider of hardware and system integration projects; and since 1995, with Tecnomatix, UGS and Siemens. Feuer’s current responsibilities include leading global teams and initiatives to develop and service customers worldwide and providing Manufacturing Engineering Software solutions. These solutions include optimizing production and service facilities, assembly line design, developing and validating production systems and programming CNC machines in major machine shops. Feuer received his Master of Science in industrial engineering from Technion – Israel Institute of Technology, and also received an executive MBA from UCLA – NUS.