Air France stops maintenance in China after screws missing from plane:

Air France suspended the maintenance of its aircraft by Chinese company Taeco after 30 screws were found to be missing from one of its planes, it said Thursday.

The Frustrated Architect:

Software architecture plays a pivotal role in the delivery of successful software yet it’s frustratingly neglected by many teams. Whether performed by one person or shared amongst the team, the architecture role exists on even the most agile of teams yet the balance of up front and evolutionary thinking often reflects aspiration rather than reality.

(Via coding the architecture.)

Update – if you go to this page you can get a video of the presentation; it’s about an hour long. A word of warning: I couldn’t make the video play on the site with Chrome, I had to use Safari.

First the technologies and the development methodologies.

So the first company uses a very Waterfall process and the integration platform is SOA. We’ve managed to build, in the middle of this, a small and focussed Java component that uses JMS in and out to avoid building horrible horrible BPEL or BPMN etc. But at either end, there’s some SOA bits to manage the integration with the “legacy”. So we’ve got this great bit of software, does amazing things, delivers real value to the business, which they want to put into production asap, but at every turn we’re hampered by the organisation or the technology platform. Its not so much the technology platform but the waterfall process the company has put around it. I’ve been told an internal wiki article detailing all the JMS  configuration is not  acceptable and the detail had to be in a Word document attached to an email requesting a not-production server configuration change. Word documents attached to emails are apparently far more “controllable” than a wiki with strong authentication protocols and history details in this world-view. Naturally I cut and pasted my wiki configuration detail into a Word document, spent a morning formatting it, and even added a link to the wiki before attaching it to an email. Acceptable process; configuration delivered. SOA and waterfall go together to make software development hell.

The second project has its many issues but one thing it does not have (for the components I have designed at least) is any SOA. It is all REST all the way down. There are multiple server-side-only components that all communicate to each other with REST over HTTP. Some of the data passed between servers is (or soon will be) JSON. The user interface is about to be delivered in two parts – one through actual REST-inspired web page requests to get the HTML and the other, via JQuery running on the web pages to actual JSON over REST services. These services will also call the REST services on the other components of the system (no database at the UI level). In fact many of the same JSON documents will be used to communicate from server to server as from ui to server. We are using Jersey for the REST. The process is Agile. The organisation hasn’t delivered such a large project with Agile before, and while I’ve been away on the other project there’s been some loss of focus. But despite some critical moments we had last week there’s been a renewed commitment to improving the engineering and project processes to achieve high velocity and good success. Its not perfect but it feels like the senior managers want the agile process to succeed. So, REST and Agile go together to make developer success.

Now, to the organisations. See if you can match the organisational description to the project style.

One of these two projects is a really fascinating piece of software in the transport industry (I can’t say more than that) which is integrating a number of “old” software solutions and creating some really sexy new features that the customer wants and loves. It is across what Eric Evans calls the “core domain” of the business. Not only is it a relatively short piece of work, but it will deliver high value to the business. It also enables a bunch of even higher value business services in the future. Things that directly expand their capabilities they can offer to their customers (which will be many of my readers) and do other related sexy things core to the business. The business salivate over it. It buffs their shine. They want it.

The other project is a little less flashy. The product is a rather niche product but it’s purpose is around the environmental effects of carbon emissions so at it’s core is the mission “save the planet from CO2″ — a pretty high value mission you’d think. However the actual functions of the software product are fairly mundane – based around helping large organisations capture and control data about their carbon emissions, because many of them have been required now to report these numbers to government agencies for a number of years. It has customers, all of then big companies or government agencies, and all the future prospects are similar sorts of organisations.

Which one is which? Which one uses REST/Agile, and which one is the SOA/Waterfall project? Do you think you can guess?

Would you be surprised if I said that the “sexy” transport project is the first one (SOA/Waterfall) and the second one is the REST/Agile project?

Whatever else you do, give yourself a chance: Rename every project, initiative and strategic program in your organization to reflect the business change goal instead of the system name: Sales Force Effectiveness Project instead of Salesforce.com Implementation; Evidence-based Decision-making Initiative instead of Business Intelligence Implementation. The impact is surprisingly large. – Business change methodology gaps | IS Survivor Publishing.

Here is it is in a nutshell. Too often I’ve worked on building a computer program, rather than a business system. Now as I’m a computer programmer, what can you expect? Some might say, “well, I don’t want to know about the business system, just let me code”. And in some circumstances they could be right. But the thing I find is, that often the layers of people, business analysts, architects and managers are rarely thinking about the business system either, and that’s not even usually their fault either. Someone may have, long before project inception, thought they needed a “business change goal” as Bob Lewis puts it, but within a few minutes it is articulated as “we need a computer system to do X and Y” and ever since, that’s what’s been firmly in mind of everyone involved in the issue.

I always find the most useful question to ask any end-user, project manager, architect, business analyst etc, when clarifying ambiguity with them is not “what do you want the computer to do at this point?” but more importantly, “what goal are we trying to achieve?”. This allows me to formulate at least a couple of scenarios as to what the computer should “do” and allow the user to choose the most appropriate one.

This issue has become more and more apparent to me as I’ve been working these past few months on a important, high-visibility project inside a highly visible brand/player in Australian transport. The stuff I’m doing directly impacts the physical operation of the company’s equipment (and the equipment, on it); unlike most other systems I’ve built which are typically about shuffling information – usually monetary – about the place. The software I’m building has the ability to make hundreds, if not thousands of employees’ jobs easier to perform, create better integration between the company and the company’s vital partners, and maybe earn a little bit of kudos with the company’s customers as well (as they definitely use the outputs of the system). But the systems we are building are defined narrowly in scope in terms of just software components with quite limited goals. Talking to the end users and the business sponsor, when they express their needs in terms of what their jobs requires, you can see this vast field of lacunae and we’re not even impacting 10% of that. It’s frustrating to be telling them the usual mantra: “out of scope in this project”. Yet it also appears that at least certain members of management had attached a cargo-cult to the project, in that they thought it would magically solve a bunch of problems that it was never addressing, all the time while reducing the scope. Those false expectations have had to be hosed down in fairly short order. So while the need is clearly apparent to everyone involved, I certainly don’t see any effort to create a bigger “business change goal” anywhere articulated, even though its desperately needed.  Even if there is one somewhere in the higher echelons of management, there’s never been a a plan that tells us down here in implementation just where our project fits in, and how to shape it appropriately to meet those bigger goals, which is an issue. This is not just about strategic vision, but tactical necessity.

I’ll leave you with another quote from Bob’s article about the issue of “politics” (and I’m not saying that my issues above are “political”, there’s just organisational failure issues):

Politics isn’t a thin, unpleasant veneer — a distraction from the “real” work of organizational change. It constitutes, by its very definition, a great deal of the real work of organizational change.

Oh for people who know what company I’m currently engaged at, none of the above has anything to do with recent “issues” that have been in the media about that company either. It’s a deeper sort of malaise, one that’s particularly frustrating because you can sense that maybe there’s some chance that they they could be just this close to actually “getting it”, at least in regards to the project I’m on and the people whom it directly impacts.

So you improve fulfillment (improved quality) and customer service (reduced cycle time). Revenue increases. Try proving your improvements were the cause.

You can’t. You can’t even measure customer satisfaction accurately, let alone demonstrate its relationship to increased revenue.

Which is why those who “run a company by the numbers” so often rely on mindless cost-cutting: They can easily prove the connection to this-year bottom-line improvements, while those who complain about the long-term consequential damage have no proof — only their knowledge of and confidence in the business model.

Managing to the numbers | Bob Lewis @ Keep The Joint Running.

• is afraid of change
• not interested in improvement
• has a rigid top-down process development style
• doesn’t care what you think

I think the greatest problem is the organisation basically doesn’t trust it’s employees to know what they are doing. It doesn’t matter that you may know something better or that you care about improving the company’s performance.  I find when I hear this sort of phrase from in companies I’m consulting at, you soon discover all manner of other issues, idiotic decision making processes, strange convoluted internal processes, inflexible management styles, complete reliance on reporting and long meetings for project visibility, and completely rigid thinking.

What the upshot of all this is, is usually a company that then is left with workers that accept their situation rather then improving it. Ultimately, when such companies confront the reality of their situation and require change to avoid failure, they fail because their employees don’t want change – they’ve had it ground down out of them over the years.

Stasis as a corporate strategy only works for so long.

The repetative (sic) steps that a single worker performs on an assembly line is a good example of a simple task

This is a terribly Fordist/Taylorist view to take of assembly work. That most beloved of industrial examples, Toyota, takes weeks to train its process-line workers to be able not only to do the simple repetitive steps of assembly, but also to be able to identify and rectify problems with the assembly-line. As Steven Spear, author of Chasing the Rabbit (my review here) might say, anyone who thinks that “assembly line” work is simple task probably doesn’t understand the nature of their process enough to keep up with their more innovate competitors, let alone outdistance them. Understanding your process, well more importantly, your organisational goals and how your process does or does not fulfil those goals, is critical to improving your organisation, and it leads me onto the idea of “evangelism”.

I both agree and disagree with Coder Friendly’s position:

Don’t become an evangelist yourself : look at your project and decide which methodologies is the most adapted. Sometimes, Agile is not the right one but if you see that your requirements are far from agreement or certainty, Agile approaches are probably a good choice.

I agree that “evangelism” can be politically off-putting.People don’t react well to being told their old kool-aid contains poison, and to uncritically drink this new kool-aid instead. However the main problem I have with a statement like this is that non-Agile companies use this “adaptation” argument and approach, in order to keep their poor contexts alive. This is the fallacy that’s found in ‘scrum butt’: “Oh we do Scrum, but …”. The clauses after the ‘but’ are typically critical. The organisation concerned is usually trying to keep some essential organisational dysfunction alive, because of politics, resistance to change, simple misunderstanding, lack of understanding about their own process, or maybe even simple laziness. I’ve got no problem with an organisation that is mature in its use of an agile method adapting it to their local circumstance – in fact if you are doing it properly, with its emphasis on empowering teams to own their process and carrying out regular ‘inspect and adapt’ at the end of every iteration, after six or twelve months of this the process will most certainly be adapted to the local conditions.

However, the real danger is at the start of the agile adoption process, when you have people hand-waving about “can’t do that here”, for whatever value of that there is. I’ve seen it said about: pairing; story boards; acceptance criteria; automated testing; retrospectives; daily stand-up; adaptive and emergent design; and just about every other aspect of XP or Scrum process. The reason is, I think, that these organisations rarely understand what the real organisational goals actually are, and they understand even less about their existing process, to the point they just “do” the process that “is”. “It is what it is”, is a great term, and if anyone says this to you it’s just a fatalistic attempt to accept as unchanging something you can change. Accept the bad. Don’t think it could be better.  Attempts to meddle in the process, i.e. change it, induce fear, and with fear often comes timidity.

This is where you need a real agile evangelist. This is not someone who just thinks that Scrum or XP or whatever other process should be blindly substituted for the existing one, but someone who understands that process is about competitive advantage, eliminating waste, and that you have to start from a known position and continuously work towards improvement. Change is not just good, but necessary, and you need those change agents. Passion for doing things better is bad? Only in a change-averse company. So learn your existing process, thoroughly, and then learn the proposed agile process, thoroughly, and only then will you be able to ‘synthesise’ a replacement. Only I think you’ll find that replacement will look a lot more like the plain old agile process than your existing unagile process. After all, if your existing process already has adequate inspect-and-adapt cycles within it (not lip-service ones, real ones), probably you are already doing and agile or lean process even if you don’t call it that, and you’re already number one in your marketplace. If not, perhaps you require the passion of an evangelist.

First up, the easy way out – take a day off, go for a walk in the park, have a nice dinner, get a good nights sleep. You should always work to “sustainable progress” and yes this means every hour you work over 40 hours a week means your quality is steadily decreasing until some point where every extra hour you put will take two to fix it later (in other words, negative impact). Even just pair programming will help prevent this in the first place as long at least one of you isn’t operating on half the sleep they need. But ultimately, all of this just blames the individual, when really poor code quality and technical debt are much more a function of the management system, methodology, total sum of the choices by every on the team, etc. (For a start, why are you up late in the first place? Was that your choice, or an outside imposed deadline?).

As James Adam and “iSteve” point out in the comments – technical debt is different from just “buggy software” and in my experience it’s usually function of management or other types of systemic choices (and “systemic” includes you, the programmer as well everyone else). What it really does is trade easy change now for even harder change later. It wants that sweet sweet sugar hit straight away but forgets about the “sugar coma” that comes a few minutes afterwards. It defers “paying the piper” until tomorrow for that lovely tune today. James Adam rightly says in his comment this can be a valid choice, but all of the team have to be fully aware of the consequences of that choice. One of which is typically that the longer  you defer the payment, the more debt you’ll accumulate, until all you are doing is paying off the interest and not getting to the principal.

As “iSteve” says, management (and maybe “management” might mean just you telling yourself this in your head) always promises to “fix it later” and never does allow that. “Just make the hack” and gloss over the problem is a mantra that we’ve all heard before. Where it gets painful is where every change is now taking twice as long as it should because of the accumulation of hacks. Every single one one of us has been there before, and are probably in various levels of it right now.

In my view this is the much more insidious circumstance because it is systemic.  After all the solution to a bad day’s work because I was too tired to think properly is to simply get a good night’s sleep, roll back yesterday’s coding, and do it again today. All I’ve done is lost a day’s work.  However, an organisation is likely to have accumulated months if not years of organisational cruft that makes changing their context that much harder than just rolling back yesterday’s poor code and trying again – it requires commitment to change from everyone who counts in the first instance.

Agile requires the discipline to move projects through teams. Multitasking is nuts in agile. Moving team members around to have the “best” specialist available for a particular team is nuts. Performance reviews for individuals is nuts. Managers have to change everything they do, if they want to move the organization to agile. Managers need to see the problems exposed by any given project’s transition to agile and work to remove those obstacles before transitioning to agile.

It’s too easy to think that just because you can get one of your teams to use an agile approach, that your organisation is now Agile. Too many managers “see the problems exposed by given project’s transition to agile” and decide to blame the agile process for the problems thus exposed.In far too many organisations I’ve seen have extremely capable teams delivering quality software in an agile process but remain – in some cases years later – completely unsupported by their senior management (and in some cases with very little support even from their CIO level).

That’s a very sad situation as it is and takes all your selling skills to get the management to “get with the program” so to speak. But this situation can be even more compounded when the management have been convinced that Agile is some sort of silver bullet that will cure all their issues. Whenever you are trying to sell agile to management, never waver from the fact that agile is hard (as everything worth doing is nearly always difficult anyway!). Agile takes discipline.

Johanna’s right to say you can’t adopt agile across an entire organisation in a big bang approach. But you can’t also adopt it without skill and commitment to doing so from managers and executives.

But the real kicker was a presentation on Agile Integration, by one of the vendor’s partners (and in the interests of disclosure, a competitor to my own employer). A few slides in and there’s the inevitable “what is agile” slide with a standard dictionary definition and some lip-service to previous history. Now the thing here of course, is that the word Agile in software development parlance is by now a well-entrenched piece of jargon – it has a specific meaning to most people that is fairly precise and different to just the garden-variety common English usage. This is the purpose of jargon in a discipline: to be precise in communication. And the agile manifesto, nearly 10 years old, just means in effect, if you’re in the software development game you just can’t redefine the term to mean something else.

Except of course, you can, if you do, and you’re big enough and enough people listen to your incredibly mangled marketoid-speak. But implementing a SOA solution is not Agile, no matter how many times you make an incredibly weak case that it is or how many times you repeat any other platform-orientated mantra. Yes, you read it right, according to the vendor’s partner at least, SOA is Agile.

This banality made me so angry, it was very lucky that straight after there was the morning coffee break because I was seething and it took all my self-discipline not to launch into an attack during the questions (easy picking, because there were no other questions asked!). I had to vent at my poor colleagues in the break.

Anyway, on my admittedly pessimistic reading it means that Agile Is Dead, as pretty soon we are going to find clients telling people, “Yeah we do agile, we bought the million-dollar SOA package off that vendor”, and then they’ll be saying the reason their integration projects are still failing is because they haven’t installed the very latest patchset, or upgraded to all-new LEANsuite 17.4.15.8 release B with the optional drag-n-drop Super-Agility add-in for Portals, Release 16f (the “f” is for “fail”).

At sushi train lunch afterwards, we made the observation that pretty much the vendor wants to be all the food groups all at once. Kind of like this bit of gluggy sushi I mistakenly lifted off the train:

All the food groups. Nasty.

Now I’m not saying that you can’t do “SOA” with an agile process, if that’s your preferred architectural style, then if you are committed you can certainly develop it in an Agile fashion. You can’t afford however, to confuse the two things. If you do, that picture above is  what your enterprise will look like too if you mistake the buzzword bingo offered by vendors for actual insight into agile development process. Talk to an expert instead.

Sorry to be so negative, the whole morning pretty much sapped my will to live.