I didn't get the chance to jot down my thoughts after a couple of days at IBM Pulse last week but I didn't want to not share my observations and thoughts. So here we go as I fly off to itSMF Norway's annual conference ... It's somewhat random but what did you expect from me? A Katy Perry inspired title?

My view of the IBM Pulse keynotes …

The IBM keynotes covered many of the things you would expect (see my pics below) such as: big data, cloud, mobile, smart-things, and big data. And did I mention big data? It's a key challenge/opportunity for IBM and its customers.

What really resonated with me during the keynotes, however, was not big data but the use of a certain lexicon – with words like "value," "customer-centricity," business outcomes," and even "Outside-In." It was my first proper IBM Pulse so I was unsure whether this was the norm or whether IBM has started "thinking outside the data center" – a criticism I have previously used with other vendors.

Given IBM's traditional focus on enterprise-spanning deals and business, rather than IT challenges/opportunities, it's probably the former but IMO a key part of helping enterprise IT organizations support their customers is IT service management (ITSM). And IBM despite having a fit for purpose ITSM offering and probably thousands of ITSM "experts" throughout its organization has just not been in people's minds and ITSM conversations the last two years.

IBM markets at the enterprise level and this means many potential customers don't think “IBM” and then think “ITSM” (or the reverse) as they would with other ITSM tool vendors. It might seem a harsh thing to say but I believe it to be the reality. I think this might be about to change though – I'll come back to this after a quick detour.

We've seen a number of misconceptions about Agile come and go. For example, the urban myth that Agile is all about velocity gets far less circulation. More people have seen Agile in practice, witnessing first hand the other potential benefits (more chances for mid-course corrections, greater predictability of outcomes, better business/IT alignment, etc.) than just writing code faster. More people are starting projects with these potential benefits in mind, so Agile has clearly moved past the perception that it was some perverse cult of speed. Speed has no intrinsic business value, aside from keeping a twitchy software developer who has consumed way too much Mountain Dew from chewing his own foot off in frustration about delays and obstacles.

As many of you know, Forrester conducted a joint research study earlier this year, in conjunction with the US chapter of the IT Service Management Forum (itSMF-USA). The report is finally now available to the deserving. Forrester clients can download it using the normal access methods. Members of itSMF-USA will receive their copy from itSMF-USA. If you contributed, but do not fall into either category, Forrester will be sending you your copy.

You can read a few of the finding in my original post announcing the completion of the study. An example of the findings is the level of satisfaction with service desk solutions. While satisfaction in general is higher than one would think, a SaaS model has proven especially satisfactory:

Please let me know if you are having difficulty obtaining your report. Thank you again for all the participation that led us to these findings! We look forward to next year’s study!

Complexity is the nemesis of application developers everywhere. While software products' complexity may be, to a great extent, unavoidable, we don't have to complicate software development to match it.

That's the conclusion driving many of the new approaches that app dev teams are embracing. For example, Agile breaks down humongous, complex projects into incremental deliverables that are far easier to scope, build, test, and deliver. Lean practices simplify processes, making it easier for teams to achieve a state of flow. DevOps advocates are trying to eliminate the needless complexities that result from throwing software over the wall from one team to the next.

But there's more to Agile, Lean, and DevOps than just a common enemy. It's no accident that practitioners often speak of this trio in practically the same breath. The Kanban board is the symbol of this convergence of practices. Here's an increasingly common use case: an Agile teams uses a Kanban board to manage work with other groups, including the DevOps team. 

The evidence for this convergence is more than just anecdotal. When we survey app dev professionals, they report that they're mixing methodologies all the time, including Agile and Waterfall. For a variety of reasons, Agile teams have made the adjustments necessary to accommodate Waterfall. Not every planning activity at the beginning of a project can be handled in a strictly Agile fashion, and not everyone involved at the end of the project (release management, operations, and business users) is necessarily sold on the idea of rapid, continuous delivery. If you work in a regulated environment, you're required to take extra steps at the beginning and end of a project.