Today I want to sum up a McKinsey Quarterly article, which describes how to reduce IT costs and complexity in 3 steps.

The IT architecture of a company can be seen as formal description of its business operations, business applications, databases as well as the equipment that run the applications. As the IT architecture is growing organically over the years, it is hard to control. In almost every established enterprise you can find duplicated systems, inconsistent data and provisional (data and application) integration. IT initiatives are often driven by short-term needs, not by a long-term blueprint.

Time to clean up this mess! Especially now, in times of the economic crises, it’s a unique opportunity to reduce IT costs and boost business agility significantly. It’s time for a clearly defined IT blueprint with organization-wide guidelines for the most appropriate and efficient systems and processes.

Business leaders must evaluate the business requirements and processes that underlie the existing architecture and then explore more efficient alternatives. For minimal disruptions and maximal benefits, the article suggests a three-phase approach.

Phase 1: Immediate Cleanup

The first phase should have a length of three to nine month. The team’s task is to generate quick wins through cost reductions by rationalizing software licenses, canceling noncompliant projects and decommissioning little- or never-used applications.

The savings in the first phase are not that high, but they are important to keep the management on track for the next steps.

Phase 2: Reducing Complexity

The second phase should have a length of six to twelve month. In this time the team decides if existing IT applications and system are really needed in future. The following methods are used to reduce complexity:

• Enforce out-of-the-box solutions
• Reuse existing components
• Consolidate databases
• Standardize technologies
• Reduce interface complexity
• Consolidate systems that do similar things

When IT and business managers analyze different opportunities, they must keep an eye on the trade-offs between short-term benefits for business units and long term costs for the entire company.

Phase 3: Business Innovation

The third phase should have a length of at least one year. In this most ambitious phase companies must consider transforming or even completely reinventing themselves. IT can play a major role in implementing big changes in the way companies run their business by supporting strategic innovation. Therefore, the IT must assess alternate operating models and shape the future with new solutions, for example using the Internet for online collaboration among employees or product innovation with help of customers and suppliers. New tools and processes can help to find profitable niches in declining markets and increase productivity.

The answer to the current economic situation is not only IT costs reduction. The answer is also IT complexity reduction, which leads to improved agility, greater flexibility, faster times to market, more efficient and effective business processes as well as faster growth once the turnaround begins.

I stumbled upon a blog entry from Jeff Langr today in which he challenges the concept of »chickens and pigs« in agile development.

His line of reasoning: Having a rule which forbids communication is not agile at all. He suggests to sustitute an other agile value instead: courage. Simply ask people who are not helping in the daily to stop. And talk about it.

You can read his full view here.

I like his suggestion for dealing with chicken-rule-fetishists:

The next time someone calls you a chicken, let them know that there is a new animal in agile. It’s the ass. The ass is the person who dictates how things must be. They are stubborn, controlling animals. Perhaps the best thing to do with an ass is to give it a good swift kick.

I think Jeff has a valid point there. Nothing is more tedious than being constantly remembered by a Scrummaster(tm) that something »isn’t following the Scrum rule book«. On the other hand these rules are necessary scaffolding for beginning project managers without a lot of experience under their belt. Maybe the truth is somewherein  between again. If you need this rule, use it. But get rid of it as soon as possible.

What do you think of this rule? Do you use it?

No special reason for this post. I just found this photos documenting the result of a two day agile retrospective session we facilitated some time ago and wanted to share the »agile beauty« ;o)

Day 1

more »

[This article is a rerun from the old blog. Because the matter is still interesting (to us) we migrated and republished it.]

Today I want to answer a question which I  pondered about for quite a long time:

»What does lightweight really mean?  Does it mean anything at all?«

What annoyed me most was that everyone nowadays seems eager to point out (MULTIPLE TIMES AND IN CAPS) how lightweight his process or framework or whatever is supposed to be. The fact that no one seems to gloat over the fact how »heavyweight« their product is arose the suspicion in me that the whole heavy- vs.  lightweight comparison is more a marketing- or coolness thingy than something helpful to dispute or even base decisions and strategies on.

I deliberately used past tense in the last paragraph because thanks to Lu Kim Man and Keith Chan these times of doubt are finally over for me! In their book »Software Development Rhythms«  these guys give a definition of »lightweight« even  I can understand an use:

The weightiness of software processes and practices is a matter of the values that arise from them and the degree to which activities directly benefit and contribute to core developers (i.e., people) and core software programming (i.e., products). [...] For example, a software process that requires writing all-embracing design documentation for commercial database applications may be considered heavyweight as it does not directly create value for the core development.

They further state:

Heavyweight processes have their place. In this case, detailed documents come in handy when we are going to outsource technical support and software maintenance abroad.

This finally makes the term a useful tool to use in discussions and for decision making. The meaning is clear and the trade-off between the extreme opposites can be assessed and evaluated in concrete contexts.

For those wondering: The emphasis of people and product in the quotation refers to the agile mantra »People over Processes, Working Code (=product) over Documentation. Seen this way one could reason that »the more lightweight you do the more agile you are (little padawan)« but this is a job for the evangelists out there which I don’t want to awake with my humble shenanigans. If you are interested in my opinion: It’s BS.

Let’s summarize:

• The weight of a tool or process can be defined as: »How directly do developers and programming tasks benefit from it?«  In other words: If the answer to »Does it speed up development in the short term?«  is Yes we are on the lightweight track.
• Sometimes we sacrifice short term benefits in favour of long term, project overarching goals. By doing this we enter the heavyweight realm.
• There is place for both strategies. Neither one is evil.

Amen.

Can you live with this definition? How do you define »lightweight«?

Lets begin this post with a rant: I really really hate it if people try to turn agile principles against the customer. The mission: Mask laziness by gaming the system.

The sort of situations I talk about look like this:

A: »Do we have to refactor this code? It’s really ugly and may or may not break somewhere in the future.«
Variant 1:
B: »Don’t bother with this, the Product Owner didn’t say anything about quality.«
Variant 2:
B: »Let’s ask the PO! PO, what is better quality worth to you? Prioritize! You can have more features or quality for the ones we already implemented.«

Oh yeah?  It’s unfair and plain nonsense. Don’t get me wrong here: There are cases where bargaining over different qualities of service (QoS) has its right and is essential. But most of the time it hasn’t and isn’t. Especially if the code implemented is brand-new.

In all agile methodologies I know you promise the PO to deliver a baseline of quality from the start. It should be clear that »just getting things done« in guerilla combat mode is not enough. As a member of an agile team I implicitely promise to do things like e.g.:

• Planning the architecture
• Weighing my options
• Communicate
• Deliver the best code I can
• Test it
• …

without asking the customer every time: »What is it worth to you?«. Cope with it: If you don’t consider this activities as included and mandatory a priori you are not an exceptional doer churning out code like the Chuck Norris of development. You are just lazy.

From the perspective of the customer this behavior looks like an eternal loop of terror:

1. Deliver crap.
2. Whine over how you need a whole full-time month to remove technical debt.
3. GOTO 1

The Manifesto for Software Craftmanship explicitely addresses this by postulating to commit to the following principles:

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration,but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.

Bravo. Software should be seen as a craft. Get over it: Every time we deliver crappy code and apologize with »I had no time to plan!«, »The PO didn’t want quality!«, »You wanted results: you got it!«, we already lost the cooperative game. Why? Because of two things:

1. What the PO asks you to do is to implement her ideas as simple as possible (YAGNI, KISS) but not simpler. What this minimal effort looks like is up to you and can only be judged by you. The PO can’t know this!
2. If there really is a trade-off between time and quality we should have presented the PO the options beforehand. If she doesn’t seem to care: just don’t commit to it! It’s all  about nuts-in-advance versus whining-after.

FTW: Yes I’m an craftsman, too.

If you are interested in more views on the topic be sure to check out this InfoQ article.

I fiddle around with market positioning of professional services firms a lot to gain understanding of what we are doing as one of a bazillion consulting firms. David Maister is THE Maister when it comes to professional service firms and their specialties.

There are lots of models for market positioning that all go like this:

On the left hand side you have the Procedure work, also cold Standardized, Applying the Body of Knowledge or Commodity. On the other extreme to the right we do have the Rocket Science guys with smartest brains around.
In the middle tier we see Customized services and more senior consultants can deliver Gray Hair stuff.

The biggest differentiator is the leverage that the firm can use as a profit driver, i.e. how many consultants can be utilized by one Partner in the firm.
In Commodity companies 45 consultants will work for 1 Partner in a project, for example a software development project. In contrast one Rocket Science Partner can only manage as less as one non-partner consultant. So you see the profoundly different dynamic in these business models.

As we are focussing more and more on the human side of IT projects we came across complex adaptive systems, also known as software developer teams I am confident that we do not need to tell you about agile, lean, SCRUM and so on to improve performance of these complex adaptive systems.

My colleague Daniel pointed me to the Cynefin model with the 4 common domains simple, complicated, complex and chaotic  plus 1 special domain Disorder.

(c) IBM Systems Journal Volume 42, Number 3, 2003

What struck me with this framework is that the 4 positions in the PSF market and the client problems dealt with in each slot match quite good to the Cynefin domains!

There are a lot of insights to be gained by consultants and their clients. For example one can see that in a complex or even chaotic system or situation there is no value in the standard process of sense – analyse – respond as there is no clear cause-and-effect relationship.

Any consulting firm that has THE exact best practice solution for your complex problems that is tried and tested did not really understand complex systems. Maybe they will solve your simple or complicated problems in a very efficient manner but NOT the real problems that partly lie in the interaction of humans.
What are your thoughts on this?

Did you ever had a project where someone (maybe even you?) produced loads of documents for specification purpose pouring in days and even weeks of hard work only to find out that the next guy in the software not-engineering process needs an awful lot of time to understand, correct and re-factor your specification to implement it – at best?

As you can see I probably get paid for long sentences, so I am in my business analyst role.

Wait, there is a thought blocking my further requirements engineering – WASTE WASTE WASTE!?

Anyone?