aliando is ...

… simple, natural and state of the art form of managing IT
… combining agile management methods with traditional IT Service Management (e.g. Scrum with ITIL)
… literally translated to “uniting people”
… enabling IT Service Management for volatile markets
… focusing on both: results, people and work
… a trademark of Dana Stoll (myself)
… built upon ethics and a working environment worth participating in
… the way I work and want to work
… not for sale.

(… I know you! Skip the self-praising babble …)

Simple?

aliando gives you an easy to use guideline through the current difficulties when doing IT Service Management in modern market environments. Like connecting with rapid application development. It doesn’t keep you busy with a mess of process chains and organisation diagrams. It relies on simple principles, which have proven to be very effective. Therefore, they are independent from tools or actual implementations. Whoever does things the aliando way, can profit from enabling his own mind to get things straight.

Natural?

aliando focusses an a view of people and companies as human beings and their natural actions within their environment. aliando is “green” IT Management :-) So aliando translates complicated terms of IT Service Management into actions which feel like natural behavior to us when we carry them out. Instead of following complicated procedures. We firmly believe that focussing on what people naturally do best and providing decent “defaults” is key to sustainable results.

Traditional?

aliando doesn’t forget about best practice methods which have evolved over the last decades. Instead, aliando presents the important principles of IT Service Management in a modern light, adapting them our volatile markets, which gives you maximum flexibility and allows you to make your own decisions based on your very own situation and experience. The principles and culture which aliando promotes are based on values and beliefs which we deem worth supporting to create a humane environment in a world full of technology. Not following every hype just for the sake of it.

We? Us? I?

aliando as an incorporation means “I”, since there is no separate legal entity, and it’s my trademark. If I’m refering to “I”, then I usually mean myself. If I refer to “aliando” I’m speaking either of the trademark, or the concepts which I assembled and put the label “aliando” on. I do this because I don’t like myself referred to as a method or school of thought. If I’m referring to “we”, I’m not cultivating schizophrenia between aliando and I, but am paying tribute to the small group of (to me) very special people who helped in getting the bits and pieces together to comprehend this. Most of the bunch are IT, coaching or leadership people. We’re some sort of virtual family. Somtimes “we” or “us” will also refer to you and I. You’ll have to decide.

Why do you need to put a label on this?

I wouldn’t want to see my first name on everything I do. I also couldn’t stand becoming a trend. aliando deserves a brand of its own. Maybe I want to do something else, some when, in the far future.

But this is also not another Agile framework. What’s written here is neither ultimate truth nor the only way to do things. I try to find vital points in fixing Agility and IT Service Management together, illustrate what’s important and open perspectives how to do it. There are tons of ways to do it successfully. A lot has already been said by Agile methods. Repeating and sticking a different label on it would be a waste. If it works for you, use it. aliando is nothing more than the way I work. If you think this is “small scale ITIL”, okay. If you think this is “Scrum for IT” or “XtremIT”, I can live with it. If you think it is “Crystal Clear Red White Server”, go for it. aliando® is a trademark, not a patent.

Sure, but what qualified particularly you to do this?

It happened as a result of my work experience. During my last 15 years as a graduted computer scientist I have been working in software engineering, running many IT services from game servers to DAX 100 companies, built and headed the IT department of WEB.DE, at the time the biggest German portal site, for eight years and throughout our major new market crisis, taking additional lectures on management, psychology (and for some strange reason quantum physics), giving lectures on IT service management and ITIL at three universities, even working in controlling, coaching and closely working with some of the most well-known Scrum trainers and IT pros in Germany, even drafted a Scrum certification class for one of them, dug myself into organisation theory for doctoral studies (which I somehow never got the time to finish), and been consulting in business informatics for a major German telco company.

To put it short: I encountered these pieces during the tremendous amount of information and work I ate. I don’t expect many people to have the exact same schedule. At least in central Europe there is a chance that I know most of them who are just as crazy. Also I usually fix the pieces I find together. At some point I have created aliando, simply to have a label to refer to and collect all this. Besides, the name still sums it up very well.

So, from a top level perspective, what’s going wrong?

During the last two decades, professional frameworks concentrated on two factors: maintaining quality (or customer satisfaction at most) and avoiding fraud. Both of these approaches from my experience do not seem to work on a large scale.

Maintaing quality and customer satisfaction has created many quality assurance frameworks, process frameworks, certifications, review processes, assessments and the like. However, they leave you behind with many unresolved issues:

• They work better for cash cow environments where everything is ready defined so best practice can be used upon. However there is a huge gap for all product situations which didn’t reach that stage yet.

• Innovation always takes place in non-cash-cow environments.

• Reviewing the block busters of online applications during the last five years one can find many examples, where quality was outperformed by time to market. Apparently modern customers are willing to take some slack in terms of quality, if they are able to interact with companies even during the development stages, or simply save money.

• The frameworks have grown huge, they overlap, but just not quite. Thus they bind a lot of effort and brainwork within the same organisation, which slows things down, plus requires a lot of people, which you don’t always have. So they may become innovation killers.

• Todays markets are fast paced. There has been a shift away from traditional cash cows towards shorter product cycles and market exploitation. Therefore we once more need to reconsider “best practice”.

• They abstract business from those who have to conduct it.

How about corporate governance?

Avoiding fraud and laws for enhancing transparency on the other hand seem to have created a vast documentation pile, which is almost as outrageous as the quality framework specifications are comprehensive. Sarbanes Oxley (KonTraG respectively), Basel II all had one consequence: the signed pile of paper which states that things have to be as it has been stated has been reaching new heights. And at the same time the mutually dependent lobby grew, who after signature had to assert truth to the signed paper instead of reality. As we now know, none of them helped to prevent our major financial crises.

Each new framework or layer of abstraction you place upon an organisation contains new Chinese whispers about how people at the base really conduct their business. They usually state how things should be, rather than how they really are. Since important people and companies have to testify that things are how they should be, the papers will state just that, because everything else would mean immediate trouble. If they are not quite how the paper says they should be, then there perhaps may be some trouble at some point in the future. Immediate trouble always wins. And once there is a signature, the lobby of defendants for this version of reality is big. Since this applies to all levels of business right up to the top, the consequences will most likely be “relative”, otherwise the “system” would have to jail itself.

And what has all this to do with delivering working IT service processes?

Nothing. People who have to keep stuff up and running take zero orientation for their daily work from all of this. And exactly this is the biggest problem.

Don’t tell me agile methods are all good!

No, they aren’t. For the most part of it, could even have done better: Leave their own universe, stop pointing towards the “traditionals” and putting the blame on them. Instead of helping to dissect all the mess, engaging in mutual communcation at the same level and thus opening ways for effective collaboration. Which sometimes is difficult, if you have to meet deadlines, I have to admit.

What we need is a proper synthesis of the both, dependent on the portfolio of product situations an organisation needs to master, and apply the right tool to the right services. This means bringing agility to IT Service Management, as well as Service Management to Research and Development. And an environment of mutual responsiblity, where people can grow from orientation and thus enjoy contributing, to both.