Thursday, 21 January 2010

What about an effective meeting?

Like so many others, I made some resolutions at New Year and will probably only manage to keep to them until the middle of February, but one of them was - how predictable - to rejoin the gym. In fact it was not just to rejoin the gym, but to actually go to it several times a week too and therein lies the challenge!

To keep my motivation, I am combining the gym attendance with working down my backlog of podcasts (I have about 100 hours of "stuff" that I want to get through). This evening one cast really stuck in my head - "Timely meetings" from the manager-tools team.

Admittedly, I have written about manager-tools' "Effective Meeting Protocol" before (see here for links and a brief overview), but I think it is worth reiterating (at least for myself if not for others!). In this latest cast they focus on the timeliness element of effective meetings - starting on time, having the agenda out in advance (and with time allocations for each discussion item).

18 months ago, when I first wrote about this, I was humble enough to admit that I am not the best at this (humble not necessarily being a trait that I am really known for, I think it worth mentioning). Today, I find I have to admit that I have got worse. It is frustrating to recognise how easy it is to slip on very simple things when under time pressure and when it is seen as nothing unusual.

So it is time to "get back to basics" and that is, in fact, my small business related resolution for the year; be on time to meetings, no meeting without an agenda, define goals upfront, seek to have actionable results leaving the meeting.

I remember well one of my first managers when I started in the consulting industry; a charming man, but ruthless in the workplace and the lesson I learned from him (though I admit, I find myself getting sloppier over time) was that simply keeping meetings running on time has an enormous effect on increasing focus and raising the sense of urgency within a project.

For that I thank him, (though we never did see eye-to-eye on my belief that it is possible to achieve the same effectiveness in meetings with a "light touch" (i.e. without forcing the formality of a meeting structure artificially and cutting off fruitful discussion - do "timeout" and "take that offline" sound familiar?).

Good luck to us all on improving our effectiveness with simple small steps this year!

Tuesday, 5 January 2010

Another year, another resolution

OK, let's just pretend that my New Year's resolution post from last year, was in fact posted at the weekend and carry on.

The good news is that, although I have not blogged for almost a year, I have been collecting articles, links, blogs, video-casts and topics that I am interested in sharing and commenting on for most of that time, so I have a huge backlog.

I considered posting some headlines now to force myself into writing the entries this year, but I am going to wimp out on that. Instead, let's start with something a little lighter - without doubt my favourite you-tube video from last year: the death star canteen (OK, it has been around for years, but I have only just discovered it).



Eddie Izzard is brilliant.

Saturday, 7 February 2009

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.

Thursday, 15 January 2009

Authentic experience - the next level of economic value?

I know it is becoming a little bit too much of a recurring theme, but today's TED lecture is a cracker. It is fairly uncontroversial and familiar terrain (the progressive shift from products to services and then to selling experiences to differentiate to the customer). Joseph Pines basically argues that "authentic" experience is becoming a key to successs and provides a nifty corporate 2x2 matrix ("true to self" vs "be what you say you are") to show various flavours of experience. He gives a few simple commercial experience examples and manages to frame it all with a quote from Hamlet, all in 14 minutes.

Here it is:

Monday, 12 January 2009

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.

Sunday, 4 January 2009

A very happy and successful 2009

Resolutions for the New Year? Well privately I have any number, but one that I am willing to post is that I have resolved to post an item a week on average this year. Today the post is short and to the point: the latest manager-tools podcast is a good one worth listening to if you are new to project management. Horstman has reduced his approach to project management to one simple statement "Who does what by when?" - not a bad summary! I have only heard the first part of this extended podcast, but it is promising start - just ignore the "we are the heroes" undertone. I expect that the "trademarked" actionable content of the advice is going to be in the follow on casts.

You can find it here at the newly upgraded and improved manager-tools.com.

PS: I will save the (predictable) story related to my flight being delayed yesterday for another day.

Monday, 8 December 2008

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):

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.