Software Development Tips You Can Learn From Xing 4.0
Traian Kaiser, Director of Agile Project Management and PMO at Xing, joins Pharma IQ to offer his tips and lessons from the groundbreaking Xing 4.0 project.
Pharma IQ: Please could you let the audience know a bit about your current role?
T Kaiser: Yes, maybe one or two sentences about my history, which is basically 13 years of internet business in different companies like IBM, Yahoo and Xing and some other companies as well, and currently at XING four years. We, as a team, developed here the project management environment and, as we were switching to Agile in the last years, my main role was also to implement Agile development at Xing and what it means for project management. That’s why we call it Agile Project Management; it’s some different approaches. And, of course, what most companies are calling the PMOs or Project Management Office which we also have some functions of.
Pharma IQ: What would you say is the greatest challenge that you face in software development and how do you seek to overcome this challenge?
T Kaiser: This question is very widely asked, but if I have to summarise it to very few points then I would say managing complexity is the first point. Why? Because it’s not only software development; software development always serves a basic solution need and the complexity lies between the creative and product group joining together with the engineering group, delivering one product which has to be technically, but also from a product and creative point of view, delivering the users value. The second is managing technology, especially if you’re in a growing or big environment, making it happen that the whole group can work efficiently and the third part is maintaining leadership and motivation with a big group of highly creative and very intelligent people who have all different roles and maybe some emergent targets. And all these three together are the main important points in having success in software development, I would say.
Pharma IQ: How do you measure productivity in software development?
T Kaiser: That’s a very good question. Productivity in software development for me is basically not very different than productivity in general. Let me give you some information about that. So productivity in maths, if you want, is output divided through input. Output in software development means the value of developed and distributed software solutions for business requirements, which are for me also including quality and time aspects, and the input is basically the cost of created and distributed software solutions through people, through services and also through other resource that’s needed. If you want to say that more simply then you would say productivity in software development is doing the right things – equivalent effectiveness – and doing the things right – equivalent efficiency – and the two things are very important here.
Doing things right and doing the right things are two different things to do, but they are always dependent on each other. So it means everything that is influencing these two aspects is always, in the normal case, also influencing the other aspect. Let’s take an example. If you want to be faster, if you want to have a faster time to market, it also is influencing how we have to work. So if you want to do the right thing for your customer, it also influences how you have to do the things in development and it’s always this kind of trade off which makes it so complex to make the right decisions and increase the overall productivity without optimising doing the thing right and doing the right things independent from each other because this is not the reality. And that’s basically productivity in software development for me.
Pharma IQ: Linking to this, what would be your do’s and don’ts of handling and measuring efficiency and effectiveness in software development?
T Kaiser: There also, to make it short and to just summarise the conclusions of myself on that, first we have to consider that software development is a creative and complex process. The creativity part is clear, but the complex part I want to make the point that complex does not mean complicated. So a car can be complicated, but if you understand how to build it, everybody can build it with a plan. A complex environment like, for example, nature cannot be understood to the lower levels, so it means there are so many dependencies which interact with each other that you can’t really describe nature. This is complexity and this is why software development as a whole is creative and complex. Recognising this and recognising dependencies between efficiency and effectiveness, this basically means that productivity metrics can be very dysfunctional.
Their only function is if you use them as a feedback for your teams, both for the product and engineering group. Ideally, they’ll work anyway together, but, using them as a feedback for teams, metrics can make a lot of sense. Using them as a metric for bonuses or other incentives can be very dysfunctional and work against what you really want to achieve. And cutting effectiveness and efficiency metrics also is very essential, meaning that you can’t just focus on one of those – just on the value of the user or on other KPIs like revenue – you also have, of course, to check on, for example, metrics that visualise you if you are building up technical debts or things like that, which, of course, will penalise you later. And both together makes a lot of sense and, as I said, bring that to the team, not to the management. That’s basically the essential point I would recommend here.
Pharma IQ: Turning to the delivery of big projects, what did you learn from delivering Xing 4.0 and what would you recommend?
T Kaiser: Delivering big projects means that you’re working with a lot of teams on one target and there are some things which have to be considered here. One is you should build your organisational fractal, which means that you build up your basic structure and the same in the above layers, so representing, for example, the roads ahead. You are probably in good advice if you are building a meter or a boot camp team, like we call it sometimes, which is working in the first and the last phase of a big project. In the first phase, making all the decisions needed – setting standards, working on concepts and discoveries, then scaling with these people to the bigger group of people because you can’t start on big projects with 150 people in the first day. And then in the end what this kind of group is doing is merging all the results of all the teams together and finalising, let’s say, all the remaining impediments and issues, bringing it a focus to deliver it in time to a product which really makes sense to the market and where decisions can be made fast. So this is another aspect. Then you have to take care that, if you work in the big group, you are managing the communication in a way that you’re working with different layers. So a lot of decisions have to be made on the lowest possible level, in those teams which are on the bottom, if you want, and you should cut the decision-making between hierarchies, so don’t let a decision go through four hierarchies; that will kill you basically. And that’s why you need the right roles and responsibilities in that.
And last, but not least, set-based design in big projects makes a lot of sense. Set-based design means you are trying to kill the critical path in the project which you only can do if you have at least one of two different alternatives on each part of your critical path. To give you an example, if you’re working on redesign you might want to have more than just one alternative how you do the redesign which has, of course, implications of not only benefits, but also on effort and while the time to make this decision is coming and you try to do it at the latest possible point, then you make the decision not only based on the most valuable decision, but also on pragmatic aspects like remaining time, skills which you have in your teams in other aspects, meaning that you have more option to decide on how you can proceed with your project while you’re going and I think this is much better than implementing a buffer into projects then, which in the end is not lowering the risk the right way, from my point of view. In the short term this is what I would recommend.
Have Your Say
Rate this feature and give us your feedback in the comments section below
Interview conducted by Helen Winsor.
Please note that we do all we can to ensure accuracy within the translation to word of audio interviews but that errors may still understandably occur in some cases. If you believe that a serious inaccuracy has been made within the text, please contact +44 (0) 207 368 9425 or email firstname.lastname@example.org