Twinstan's interesting links roundup on Diigo (weekly)

• In-Store Signs Get Smart - Technology Review

  I know this stuff is coming no matter what we think of it, but ad-signs that recognise you as you walk by and react is pretty mind-boggling.

• Peter Measures Blog : Business Process Management Suites – the future for business analysts?

  I am not convinced by the tools, but really want to be.

• LinkedIn 2010 Overused Buzzwords: Extensive Experience, Innovative And Motivated

• Virtualisierung und Cloud Computing: 7 Ratschläge für die IT der Zukunft - computerwoche.de

• You don’t need agile to avoid the seven deadly sins of pm

Posted from Diigo. The rest of my favorite links are here.

Use case / user story - who cares?

So much for resolutions. It has been almost a month since my last post and I feel suitably disappointed with myself. And today I only have a short post:

I am repeatedly surprised by the vehemence of different analyst communities on issues of approach (and predictably on the rightness of their approach over all others). One consistent topic that always seems to provoke strong reactions is the question of requirement documentation via use case versus user story.

Personally I suspect that either and/or both approaches can be usefully applied (but then I always was a tiresome moderate) and that ultimately it mostly depends upon the content - I have seen (and written) variants of both that failed to extract what the underlying goal and business need of the user is and the sexiest template in the world was never going to fix them.

That said, I do appreciate that both approaches have value and should be in the analyst's arsenal. So I was delighted to read a posting on John Babcock's blog providing a great overview of thinking on this topic - he has put together a bunch of links to articles and sites that compare and contrast the approaches (of course both Fowler and Cockburn are represented, but there are several other interesting sources).

On reflection, I like the simplicity of user stories and their closeness to real world language, but they do not replace a well constructed use case model (as often as not, it is the model rather than the details that is really valuable) to help make sure that the requirements are complete. So both have value - use what makes sense for a given situation (and that could easily mean both) - how heavyweight do you need to be to ensure that you are capturing all the complexity of your project?

So, no strong reaction on my side. How moderate and boring.

Tough.

ModernAnalyst.com

I came across modernanalyst.com a while ago, but was unimpressed. Quite apart from the name (which sounds to me like it should be a BBC television series from the open university from around 1982, populated by men in checkered shirts with beards discussing the philosophical differences between this and that), it was entirely lacking in content.

Luckily for me, I noticed a link to an article on the site about trends in business analysis for 2009 and although this particular article was not so great - "analysts are at the centre of all successful IT projects" seemed to be the underlying tone - it forced me back onto the site, which has been greatly enhanced.

It is full of interesting articles, a load of useful templates for download and a pretty active forum. It is this forum that I think will be valuable - it is all too easy to forget that there are people out there with exactly the same issues and concerns that you have, and there really is no need to reinvent the wheel - it is enough of a challenge to get one's head around the business, so leave the process templating to the world at large and profit from it!

They also seem to have affiliated themselves with the IIBA (International association of business analysis) - another organisation that I had been unimpressed with until fairly recently. The latest version of the "BABOK" that they produced is much improved - although it is still a bit heavyweight and "stodgy" (for want of a better word) and it looks like they are getting positive feedback for their analyst accredidation scheme.

Agile & user centric design

I haven't written for a little while; life coming up to Christmas is "hectic" (and a bunch of other things not suitable for print on this blog). This weekend, I had been fully expecting to write a short introduction, describing how my string of bad luck over flights was over - I had a fantastic flight on Friday night, landing 30 minutes ahead of schedule. Unfortunately, I am now sitting at Heathrow Terminal 5 watching the delay on my flight back to Duesseldorf go from 10 minutes, to 20, to 60, to 90 minutes as they replace the tyre before we take off. Ah well.

As always it has given me a chance to a) spend more money than I wanted to on cheap DVDs and b) do a little reading on combining agile project management and user centric design. This is a topic close to my heart and something that is akin to squaring the circle. The basic difficulty is clear, user centric design approaches tend to try to map out a complete detailed vision of the user experience for an application or website in order to ensure a consistent and deliberate flow through the entire site, whereas agile approaches focus on evolutionary development of systems, building up the complexity of the solution over time.

There is no reason that these two approaches should not co-exist however. As always it is simply a question of measure; agile doesn't say no upfront design, just enough; user centric design doesn't say don't experiment over time, just understand the overarching customer needs you are trying to fulfill.

I am very pleased to see that there is a nascent discussion finally emerging out there on this topic. The following links provide some food for thought, with plenty of practical steps to making the two approaches work together (as well as giving so more detail on where the difficulties between the approaches arise in the first place):

• http://agileproductdesign.com/index.html - a really good blog, by a guy specialising in the combination of agile and usablity. Definitely someone I am going to be following in the coming months. I particularly like his analysis of where the difficulties arise.
• http://www.slideshare.net/mgiudice/humancentered-design-meets-agile-development-presentation-625465/ - a nice overview on combining approaches.
• http://www.upassoc.org/upa_publications/jus/2007may/agile-ucd.pdf - an article in the Journal of Usability Studies - good to see some designers enthusing about agile.
• http://www.alistapart.com/articles/gettingrealaboutagiledesign - another good blog, with some concrete practical advice on what to do when combining scrum and user-centric design.
• http://www.useit.com/alertbox/agile-methods.html - a recent article by Jacob Nielsen (usability guru) on difficulties with agile that has kicked off some controversial discussions online. Strange; the original article seems entirely common-sensical and compatible with agile as I understand it.
• http://tech.groups.yahoo.com/group/agile-usability/ - a newsgroup with a pretty active discussion around usablility in agile projects.

Really, it all comes down to understanding what the user wants and needs and what the client wants and needs. Agile provides the framework to do this, as long as you can work with your client and users closely to build a strong vision of the purpose of the system up front and then continue to work with both parties throughout the development process to get quick feedback integrated into the system. But the first methodology that really anchors the user-centric design more firmly into an agile setting, will really win my vote.

Back "on topic" with analysis and design!

After yesterday's "off-topic" posting on the inspirational impact of "Where the hell is Matt?", I want to return today to something more related to the central topic of this blog - business analysis and software engineering; I listened to a podcast on the way home this evening. It was a cast from the pm411.org project management forum (http://pm411.org/2008/09/21/podcast-episode-036-mindmapping/) and the topic covered was mindmapping.

I will be honest - usually I don't like the pm411.org cast series; I find them slow moving and limited in content. This week's cast was no exception, but it was interesting in that it got me thinking about how I used to use mindmaps to structure different levels of interrelated information:

Used right, the multi-dimensional representation of information in a mindmap allows you to build an entire requirements document. You start with an informal capturing exercise, relating the information as it comes from the stakeholders. With the right tools you can label and map in the stakeholders too (it is just a question of labeling the lines or nodes with the appropriate tags).

I used to use visio, but that got a little too much like hard work so I moved to mindmanager (which is actually discussed in the podcast). The more you add to it the richer the network becomes. With more advanced tools I am guessing that the structure of the data can then be extracted and used in (for example) specification documentation.

A colleague introduced me to www.mindmeister.com recently. It is free to use and has some nice import/export functions as well as integration with various browsers and other applications (though I haven't played around with them yet). I have been using it for holiday planning, but it is more than sufficient to handle more complex maps!

It occurs to me now that I have probably missed an opportunity to use this simple technique - believe me, I know this sounds trivial, but I guess I am getting rusty and have forgotten some of the basics! - to identify dimensions and structures in interrelated information sets and then to build off of them throughout a project - it is easy to want to jump into more structured requirements hierarchies, flowcharts, sequence diagrams and domain modeling activities.

I am going to try it out again in the next project initiation phase I am involved in to see how much it really adds to the more formal deliverables.

Business analysis basics - library

Over the last few years I have collected a list of key books that I think provide a basic primer for the business analysis discipline - it is a mix of software engineering, user experience, business administration and psychology. It can be found at the following link on Amazon:

http://www.amazon.co.uk/Business-nbsp-Analysis-nbsp-Basics/lm/RLA7LQ1I97H2W/ref=cm_srch_res_rpli_alt_2

Enjoy!

Just another blog for kicks

I have been toying with the idea of writing a blog for a while. I even got as far as creating the profile on blogger several times before, but somehow could never bring myself to actually publish anything - after all what do I really have to say and why would I put it online?

Frankly, I still don't have a good answer to either of those questions, but I feel like giving it a go regardless. That is why "Just another blog" seems to me the most appropriate title for this page.

I have a vague desire to publish some things

• about the industry I work in (IT in the telecommunications world),
• about the kind of work that I do (consultancy, analysis, design, project management and the like)
• and about what interests me online (I must confess to having become slightly obsessed with podcasts, vodcasts and feeds of all kinds and most recently with www.ted.org, perhaps the most fantastic source of *consistently* interesting ideas out there).

It is , however, equally possible that I might end up writing about the trials of living as an englishman in Germany, or on my next holiday.

It is odd, but despite this being a theoretically public forum, it feels more like an opportunity to write for myself (indeed that is probably what it will be!) - something I always enjoyed doing as a child, but somehow I got out of the practice.

Well, we will see where this takes me. Thanks for reading.

Welcome to just another blog.