tag:blogger.com,1999:blog-53640582024-03-13T05:12:41.118+01:00Mark T's information blogIt's all about managing ideas and making stuff useful. My major interests are business analysis, project and portfolio management, user-focused design and usability, knowledge management and innovation, but I'm interested in any side road that means ending up with an improved result...Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.comBlogger267125tag:blogger.com,1999:blog-5364058.post-83383774142678418882015-03-30T16:20:00.004+02:002015-03-30T21:23:23.645+02:00Why estimate?I have been reading with some interest the recent debate around <a href="https://twitter.com/hashtag/noestimates" target="_blank">#noestimates</a>. <br />
I think the movement is somewhat misnamed, in that it is not “estimates” which appear to be the problem, so much as the decisions which are taken around them. To some extent, I think this comes from a misunderstanding as to what estimation is (and is not). If the movement calls attention to this misunderstanding, then this is all to the good, and all critical thinking which drives deeper understanding as to how to handle project uncertainty, the better.<br />
I am interested in estimation, mostly owing to the fact that - when left to my own devices - to come up with a single point estimate, I am more than often hugely wrong. But therein lie a couple of the major issues: estimation is not about being right, and it is not an individual effort.<br />
<h2>
The estimate is not the deliverable</h2>
“Here is my estimate.” Seductive words, yet nevertheless, dangerous words. Estimation is an ongoing activity, not a deliverable. Estimates are essentially a form of risk management, a way in which we can deal with uncertainty in order to set co-ordinates and move forward. An estimate can therefore be considered as an impulse to action.<br />
<h2>
Estimates are for decision-making and lead to commitments</h2>
An estimate is an input to a more important process: usually that of decision-making, and this is where I first start to deviate from some of the #noestimates thinking. <br />
Estimates set bounds on the unknowable, but they are not the same thing as targets, nor the same thing as commitments. Communicating this single fact is vitally important in estimation activity.<br />
I may estimate that a project is highly likely to be delivered in Q4 of the current calendar year. The internal Marketing Department may be targeting the beginning of Q4 for launch, and therefore my Project Management team may have committed to a Q3 delivery. Herein lies the actual problem: my high confidence estimate lies outside of the project commitment, so I need to now frame my level of confidence in delivering to the committed date (NOTE: this will of course not be “highly likely”).<br />
Estimates are therefore a management issue, and a political hot potato, and this is doubtless where much of the annoyance with estimates comes from.<br />
<h2>
The future is uncertain: deal with it!</h2>
Estimates, like projects, live in the future, and the future is unknowable, so no one technique is going to help out for all projects, and what is key is to tailor the estimation process to the project in question. however, some general pointers can point everyone in the right direction:<br />
<ul>
<li><b>Start estimation early:</b> this way you can frame the commitment discussion.</li>
<li><b>Re-estimate often: </b>this is just tracking actuals against baseline. The “cone of uncertainty” will slim as you approach your target: if you check your direction often, you can make sure you are still on target. You need to learn from your estimation activity, and continually correct for “error”.</li>
<li><b>Estimate from what you can measure:</b> accuracy is less important than precision. Try to use the same measures in the same way to estimate.
Raise the red flag: when you look like your delivery is straying from your commitment, raise the red flag (as soon as you notice). This will always hurt, but remember, estimates are an input to decision-making: the decision to continue or not is an important one, and relies upon good, timely data.</li>
<li><b>Don’t overcommit:</b> this is the hardest line. At least make everyone aware of your level of confidence in any commitment (and if you can manage to have it formally recorded as a risk, then all the better). This is not a CYA: again, your level of confidence is an input to a decision-making process, so don’t edit yourself: speak now or forever hold thy tongue!</li>
<li><b>Don’t make an individual estimate: </b>gather several individual estimates from several perspectives, and use these to decide upon best case, likely case, and worst case scenarios. Individual (and particularly expert) estimates have proven to be wrong, group estimates tend to be more accurate.</li>
<li><b>Don’t use one technique: </b>again pick three or four techniques to make estimates and centre in on the most likely scenario - for instance, a wideband delphi estimate; an estimate using proxies of effort (e.g. number and length of requirements based upon similar historic projects); a bottom-up estimate using T-shirting all used together will give you some sense of directional likelihood.</li>
<li><b>Pick the right techniques for the right point in time/right type of activity:</b> don’t use heavyweight methods for small, rapid projects. Cut your cloth according to the type of project you are working on , and its perceived risk/benefit profile. Don’t invest too much time in estimation - rapid, timely estimates will have more value than a deeply modeled, but effort-intensive approach. All estimates (even the accurate ones) cannot predict the future, they can just help to reduce the uncertainty.</li>
<li><b>Check for change: </b>when estimating from historic data or re-estimating in a project, be aware of what has changed and what has stayed the same. Make sure to adjust your model for change.</li>
<li><b>When estimating for effort, also estimate for productivity: </b>we all forget that productivity ebbs and flows. A manday of effort is not always equivalent to a one manday delivery: most of us fail to hit anywhere near 100% productivity, and our productivity varies wildly during a project. Maybe assume a 60% productivity rate is more likely or set out with a 100% productivity estimate and then adjust it as you see that delivery never reaches these levels.
Don’t let overtime skew the picture: death march projects make ample use of overtime to swell a mayday from 8 hours to 10, 12 ore more hours. If you are using overtime, keep track and don’t let it skew the picture: people are (in general) less productive the more they work, so keep an eye on total hours worked.</li>
<li>Estimate range and confidence: try, try, try to not give single-point estimates. Try to give a tight range with a level of confidence attached: e.g. "We are 90% confident of hitting Q2 delivery, but only 75% confident of doing so before the end of May". If you are asked to commit to a single-point, remember not to overcommit...</li>
</ul>
My final recommendations would be to read up on estimation. I really like Steve McConnell’s “<a href="http://www.stevemcconnell.com/est.htm" target="_blank">Software Estimation: Demystifying the Black Art</a>” as a great overview.<br />
Finally, read the pros and cons of the #noestimates argument: making an informed decision about the right approach to take, at least leads to a mindful project delivery approach. Some good articles I have seen so far are:<br />
<ul>
<li><a href="https://medium.com/backchannel/estimates-we-don-t-need-no-stinking-estimates-dcbddccbd3d4" target="_blank">Estimates? We Don’t Need No Stinking Estimates!</a></li>
<li><a href="http://allankelly.blogspot.com/2014/09/estimates-or-noestimates-that-is.html" target="_blank">Estimates or #NoEstimates? that is the question</a></li>
<li><a href="http://ronjeffries.com/xprog/articles/the-noestimates-movement/" target="_blank">The NoEstimates Movement</a></li>
<li>And for a little framing from a planning perspective: <a href="http://www.projectmanagement.com/articles/288933/The-Fallible-Future--and-How-to-Fix-It-" target="_blank">The Fallible Future (and How to Fix It)</a></li>
</ul>
Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-75825377166573878582013-01-16T13:41:00.000+01:002013-01-16T13:41:49.132+01:00Whinelist: things users don't care aboutCare of <a href="http://radar.oreilly.com/" target="_blank">O'Reilly Radar</a>, comes this great little post from <a href="http://petewarden.typepad.com/searchbrowser/2013/01/things-users-dont-care-about.html" target="_blank">PeteSearch: Things users don't care about</a>. I'm in complete agreement with the list: no-one really cares about how much effort a project took, they are only interested in the end product and their own use of the product. Although I agree that singing "<a href="http://en.wikipedia.org/wiki/Nobody_Knows_the_Trouble_I%27ve_Seen" target="_blank">Nobody knows the troubles I've seen...</a>" is not much help, I must confess that the list does break down into things users don't care about and shouldn't (e.g. your project effort), and things users don't care about and probably should (without necessarily having to be aware of them) into which bucket I would throw the "URPS" of <a href="http://en.wikipedia.org/wiki/FURPS" target="_blank">FURPS</a>: items like extensibility and architecture. Any way, it's a good post, and advice worth remembering...Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-59230342058831338832012-10-24T18:30:00.001+02:002012-10-24T18:30:54.474+02:00A short film about bugs......which starts with an apology for the pretentious title.<br />
<ol>
<li>Anyone can identify a bug.</li>
<li>Many fewer people can resolve a bug.</li>
<li>Far fewer still can anticipate a bug and stop it from rearing its ugly head.</li>
<li>Anticipation is a greatly under-estimated skill.</li>
</ol>
Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-79077261770381459542012-03-18T15:52:00.000+01:002012-06-10T17:02:00.180+02:00Writing Good Specifications the Simple WayWhen writing specification documents, whether requirements, functional specifications, software design specifications, use cases, user stories or even briefing documents and statements of work, it is easy to become caught up in technical detail: is this a functional or a non-functional item, do I draw up an activity diagram, or model state...? <br />
As <a href="http://de.wikipedia.org/wiki/Friedrich_Schiller" rel="nofollow" target="_blank">Schiller</a> (very loosely) said, <br />
<blockquote>
Don't try so hard, pleasing everyone can be a bad thing.</blockquote>
After many years of specification writing, and diving deep into IEEE standards, UML, semantic models and a myriad of other fine, worthy, but complex approaches, I have come to the conclusion, that you should just think like a primary schooler (grade schooler).<br />
Specification is about communication: whether from a client to a technical team, from one member of a technical team to another, or from a technical team back out to a client or a regulator. When you first learn to write, your teacher's initial focus is on having you communicate i.e. express your ideas clearly.<br />
So - even though thorough, technically focused systems can be great - the cornerstone of a good specification is plain, understandable, concise English. A very simple structure can take you a long way and - like "progressive enhancement" in HTML - allows you to build a more complex structure around it. So:...<br />
<h2>
SIMPLE RULES</h2>
<ol>
<li>Don't write passive sentences. Specifications are about a system or parts of a system doing and responding, so <b>focus on active sentences</b> - it's just good object orientation anyway...</li>
<li>Do structure any specification with <b>WHO, WHAT, WHY, WHERE, and WHEN</b>.</li>
<li>Then add to your structure with <b>WHO NOT, WHAT NOT, WHY NOT, WHERE NOT, and WHEN NOT</b>.</li>
<li>When you've done this, <b>give examples</b> (for both paths)</li>
<li>Then focus on the <b>HOW</b>: first of all HOW OFTEN, HOW MUCH.</li>
<li>Next focus on the <b>HOW TO</b> (which is unfortunately where a lot of specification starts).</li>
</ol>
Keeping to these simple rules and practices is often all that is needed for a comprehensive, understandable and deliverable specification.<br />
<br />
<h2>
PUSHING FURTHER - JOINING IDEAS TOGETHER</h2>
Of course, if you want to push further, then:<br />
<ul>
<li>If you need to link ideas up into activities and flows, <b>try to keep in binary mode</b>: it will keep the flow and decision points simple. </li>
<ul>
<li>(For example for inputs it is a good idea to specify for valid, invalid and null values, but rather than keeping a three-value decision point, split it into two binary decisions i.e. value provided - Y (not null)/N (null); then value valid Y (valid)/N (invalid).)</li>
</ul>
<li>Break use cases into simple "SIPOC" (supplier, input, process, output, customer) stories by not mentioning SIPOC at all. Instead, just note down: </li>
<ul>
<li>what you "<b>start with:</b>", </li>
<li>who this is "<b>provided by:</b>" will deliver you with a great set of preconditions for your... </li>
<li>...big "<b>do: something</b>" block. </li>
<li>finishing up with "<b>end with:</b> (result)", </li>
<li>and adding "<b>given to:</b>" will keep you results-focused and looking at the next use case in the value chain.</li>
<li><i>You can - if you are feeling adventurous - add some useful detail in a series of use cases by being clear about what "does change" (variables) and what "does not change" (constants) during the use case.</i></li>
</ul>
</ul>
<ul>
<li>Never take anyone's model (including this one) at face value - there will always be cases when it does not quite fit: <b>one format does not fit every type of specification item</b>, so just <b>pick the most appropriate item</b>. For instance, "plain English" may not be the most appropriate specification language for communicating with physicists!</li>
<li><b>Know when to add complexity</b> (by reading about and understanding all the different ways and means of specifying - see "Reading and Improving")</li>
<li><b>Know when to stop paper-specification and move to code</b> (including tests and comments, for example JavaDocs) - or you will spend a great deal of time maintaining paper documents which will ALWAYS be slightly out-of-date and inaccurate.</li>
</ul>
<h2>
READING AND IMPROVING</h2>
A short blog post talking about simplicity will never be comprehensive, so I would strongly recommend the following books and authors (just a short(!) selection):<br />
<br />
<ul>
<li>Requirements Engineering Fundamentals (Pohl & Rupp)</li>
<li>Any of Karl Wieger's books on Software Requirements</li>
<li>The RSpec Book (Chelimsky et al)</li>
<li>Specification by Example (Adzic)</li>
<li>Writing Effective Use Cases (Cockburn)</li>
<li>Test Driven (Koskela)</li>
</ul>
If you are interested in what Schiller actually said, it is:<br />
<br />
<blockquote class="tr_bq">
Kannst du nicht allen gefallen durch deine Tat und dein Kunstwerk,<br />
mach' es wenigen recht; vielen gefallen ist schlimm.</blockquote>
<br />
I will try to follow up on this post with more detail on the SIMPLE RULES, but in most cases, just thinking about each of these super simple questions without any other background is a really helpful technique, as I hope will become evident in the example below.<br />
<h2>
Examples</h2>
<br />
Just to make things somewhat easier to understand, here is a completely invented example which is far from perfect, but shows how applying the simple rules can help to build up into a solid requirement or specification item.<br />
<br />
1. Not "an email will be sent"... BUT "<b>The software's email component </b>will send an email" (active sentence)<br />
2. Even better still is..<br />
<br />
<ul>
<li> <span class="Apple-tab-span" style="white-space: pre;"> </span>"The software's email component will send an email <b>to the designated recipient</b>" (who)</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>"The software's email component will send <b>a confirmation email </b>to the designated recipient" (what)</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>"The software's email component will send a confirmation email to the designated recipient <b>to allow him/her to know their request has been successfully processed</b>" (why)</li>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>"<b>When a submitted request has been confirmed as completely processed,</b> the software's email component will immediately send a confirmation email to the designated recipient to allow him/her to know their request has been successfully processed" (where and when)</li>
</ul>
<br />
3. Even better still is...being very precise about "triggers" and "non-triggers".<br />
<br />
<ul>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>"When a submitted request has been confirmed as completely processed, the software's email component will immediately send a confirmation email to the designated recipient to allow him/her to know their request has been successfully processed. <b>A confirmation email will not be sent when the request has not been confirmed as completely processed or where a designated recipient has not provided his/her email address.</b>" (NOT)</li>
</ul>
<br />
4. ...and adding in the "how often, how much" detail helps also...<br />
<br />
<ul>
<li><span class="Apple-tab-span" style="white-space: pre;"> </span>"When a submitted request has been confirmed as completely processed, the software's email component will immediately send a confirmation email to the designated recipient to allow him/her to know their request has been successfully processed. A confirmation email will not be sent when the request has not been confirmed as completely processed or where a designated recipient has not provided his/her email address. <b>A confirmation email will only be sent once a week to any individual designated recipient regardless of how many requests have been submitted.</b>"</li>
</ul>
<br />
<br />
If you then start to add in examples of each of the elements and what output you expect for each example (such as where a request is in the submission process, or different designated recipient details, or expected content of a confirmation email, or designated recipients who have made single requests, multiple requests etc.), then you really start to get a coherent, complete and testable specification item.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-75315501221155214342011-03-11T00:10:00.000+01:002011-03-11T00:10:56.243+01:00Evernote continued...I'm really finding evernote is hitting the sweetspot: I've dumped reading and linklists in, and started tracking some task and TODO lists and it works pretty well. My only issue is that I'd like to use it at work (where we have no admin rights), and the web interface is somewhat clunky and slow (particularly when the corporate network performance is pokey), so this is hampering my take up and use of it. Otherwise, I'm finding it a great wee app.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-54979841816252381252011-03-10T23:02:00.001+01:002011-03-10T23:03:56.841+01:00Software Reliability and VolatilityI've been working a reasonable amount of late in dealing with considerations of software defect management and metrics to indicate "software reliability". Personally, I always think that reliability is a continuum (like trust), and that a software is only as reliable as its last failure. Software which predictably fails big and often is obviously "unreliable", but much software runs fine most of the time until something "unexpected" happens...is this software then unreliable? Well probably not until it starts failing more frequently, and more predictably, and therein lies the problem: it is difficult to know how reliable a software system is until it stops to be reliable. <br />
<br />
There are pretty much two approaches to reliability - one is based upon trending, and the other on prediction: while I much prefer the trending approach which says check how reliable your software could be considered now, then check at now+1, take a look at the rate of change and this is the indicator as to your vector of reliability, I also think that taking a look forward with a decent prediction model, can help to set a sense of expectation.<br />
<br />
I think this sense of expectation is best summed up in the idea of "code smell" or "defect risk", which could be considered as "is your code smelling better or worse over time" (trend) and "is your code likely to smell worse at any point in the future" (prediction). There are obviously complexity, coverage, sizing, and defect tracking rules which can be applied, but I really like the concept and approach to "volatility" as set out in the article: <a href="http://pragprog.com/magazines/2011-03/software-volatility">"Software Volatility" by by Tim Ottinger and Jeff Langr in the latest Pragmatic Programmer Magazine</a>, since this seems to blend trend and prediction together: the code which you touch most often is the place where code is most likely to break, and the more you touch it, the more likely this is to happen. <br />
<br />
I strongly suggest reading the article, and look to applying a similar approach in a balanced reliability metrics scorecard and inspection process. I certainly don't think that it should replace coverage (which lets you know where you have unit tested), cyclomatic complexity (which lets you know how many tests you should write, and when you might want to consider refactoring), sizing (which just gives you a volume idea of what you are looking at), code analysis (sort of spellchecking for your code), defect classification and tracking (for failure rates and densities)... but it certainly represents a tool worth sharpening and adding to the toolbox.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-91201307029192300132011-02-26T14:21:00.000+01:002011-02-26T14:21:26.916+01:00Too many O'Reilly Books?I was just looking through my O'Reilly digital bookcases and wondering whether it is possible to have too many tomes from this publisher:<br />
(NB: I think the answer is no...)<br />
<br />
Here is the list of what I found:<br />
<br />
97 Things Every Programmer Should Know<br />
Beautiful Data<br />
Beautiful Visualization<br />
Data Analysis with Open Source Tools<br />
HTML5: Up and Running<br />
Learning Rails<br />
Making Software<br />
Making Things Happen<br />
The New Community Rules<br />
The Productive Programmer<br />
The Social Media Marketing Book<br />
Web 2.0: A Strategy Guide<br />
The Art of SEO<br />
Beautiful Testing<br />
Complete Web Monitoring<br />
CSS Pocket Reference, Third Edition<br />
Designing Web Interfaces<br />
Facebook Cookbook<br />
Getting Started with Flex 3<br />
Grails<br />
Information Architecture for the World Wide Web, Second Edition<br />
Programming Collective Intelligence<br />
Search Engine Optimization for Flash<br />
SEO Warrior<br />
Universal Design for Web Applications<br />
Website OptimizationMark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-74960267973471966082011-02-24T16:28:00.000+01:002011-02-24T16:28:47.385+01:00Au Revoir MyBlogLogAs part of the fallout of the Yahoo thinning out (and hoping that delicious finds a buyer), I just received the following mail:<br />
<br />
<blockquote>Yahoo!<br />
<br />
Dear MyBlogLog Customer,<br />
<br />
You have been identified as a customer of Yahoo! MyBlogLog. We will officially discontinue Yahoo! MyBlogLog effective May 24, 2011. Your agreement with Yahoo!, to the extent that it applies to the Yahoo! MyBlogLog, will terminate on May 24, 2011.<br />
<br />
After May 24, 2011 your credit card will no longer be charged for premium services on MyBlogLog. We will refund you the unused portion of your subscription, if any. The refund will appear as a credit via the billing method we have on file for you. To make sure that your billing information is correct and up to date, visit https://billing.yahoo.com.<br />
<br />
Questions?<br />
If you have questions about these changes, please visit the Yahoo! MyBlogLog help pages.<br />
<br />
We thank you for being a customer on Yahoo! MyBlogLog.<br />
<br />
Sincerely,<br />
<br />
The Yahoo! My BlogLog Team</blockquote>Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-68635422557691773892011-02-06T15:37:00.000+01:002011-02-06T15:37:51.082+01:00Evernote...at lastI am not the worlds greatest "Getting Things Done" guy (only got half way through the book, and just could not get around to putting it into place). In a quest for lightweight but useful "To-do" managers and "Do not forget" managers, I have been through the full gamut: I even bought Bento (and have not really done much with it). The one tool I really loved and do use is delicious, but I have the collywobbles with the Yahoo announcement (withdrawal from market, and then a quick revision to "we want to sell it) and have been looking into not losing my valuable brain estate. I've been taking a peek at evernote for a while, and so finally decided to download this and work out how to get my delicious stuff into it: easy-peasy, just follow these instructions - works a dream: <a href="http://dr-palaniraja.blogspot.com/2010/12/import-delicious-bookmarks-to-evernote.html">Instructions to import delicious into evernote</a>...Lovely.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-15451384822264018462011-02-05T00:09:00.000+01:002011-02-05T00:09:56.682+01:00More reviewing...pt2So, I've started on the first chapter of "Mining the Social Web" proper, and realise it will involve much side reading, as 1) you really do need to know python (although this is already installed in OSX, joy!) 2) you really need to read all the APIs and 3) it looks like the book is going to look to install a large number of python packages. Still, using the twitter package and pulling down the timeline content in terminal is quite cool.<br />
<br />
I think I will probably need a once through hands-off, then a once through hands-on, as the first chapter is moving pretty fast, and making some fairly heavy assumptions on development confidence.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-21455530485672951182011-02-04T03:44:00.000+01:002011-02-04T03:44:16.518+01:00Starting out on the O'Reilly Blogger Review ProgrammeThose nice folks at O'Reilly have started a Blogger Review Programme, and kindly let me be a part of it. Essentially you commit to write a review of an O'Reilly tome in return for a digital review copy - just like I remember it from my real journalism days!<br />
<br />
I've been insomniac the past couple of nights (it is 3:45am in Geneva), mostly churning some Measurement & Analytics annoyances in my head, so am now sitting reading the intro. to my first Blogger Review book "<a href="http://oreilly.com/catalog/0636920010203">Mining the Social Web</a>" (and I suppose I should really try and write this posting in hReview (but I can't be bothered)). So first thoughts are: looks interesting - looks like social network analysis for the social web, so ties nicely into some of my usual old hobby-horses. First gripe would be that all the code is in Python (which I don't know), so I'll have to get to grips with that. It looks like it might hook in nicely with the really interesting, but slightly forbidding "<a href="http://oreilly.com/catalog/9780596529321/">Programming Collective Intelligence</a>" (which if I remember right is also chock-full of Python) - could be a useful companion piece.<br />
<br />
Since the O'Reilly review is a 200 worder, I'll try and run a longer review chunk by chunk as I work my way through the book, and then try to some up the overall impression.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-25544282756388602752010-02-22T13:19:00.002+01:002010-02-22T17:03:32.168+01:00Use Casing with Your Clients - BDD or Given, When, Then...Sitting at home, feeling sorry for myself as I am off work sick, I thought I might write a short blog post on using Behavioural Driven Development (BDD) for Requirements work with clients - a technique which I am starting to use with some (note the qualification) success.<br />
<br />
I'm a big fan of use casing "As is" models and "To be" models to get a really nice sense of the contexts in which a system is supposed to work (and by system, I mean people, process and technologies), but this can be hugely tough unless you are working with clients who are formal, systematic, logic-driven thinkers.<br />
<br />
And this is how I stumbled upon <a href="http://dannorth.net/whats-in-a-story">Dan North's BDD</a> - as a way of reducing the formal use case methodologies (pre- and post-conditions et al.) into a very simple story formulation. <br />
<b>Feature</b>: As a <i>stakeholder</i>, I need <i>a something</i>, in order to <i>meet my goal</i> (High level business requirement - main system "features")<br />
<b>Scenario:</b> Given <i>a starting context</i>, when <i>something happens to change this context</i>, then <i>this should be the result</i>. (Lower-level scenario and low-level "feature" descriptions).<br />
<b>Note</b>: <i>I write "feature" as feature is a controlled word in BDD</i>.<br />
<br />
The greater joy of this technique is that it effectively shrinks the distance between what the client says he wants, and what your technical team is capable of delivering back to satisfy these requirements. Why? Well, as <a href="http://blog.objectmentor.com/articles/2008/11/27/the-truth-about-bdd" title="an interesting take on BDD">this fine blog post points out</a>, it is because this is a business language way of describing states, event triggers and test conditions. Even more importantly, through the use of JBehave or <a href="http://cukes.info/">Cucumber</a> with Automated Testing tools like Selenium, your developers can start by writing failing tests for your requirements (requirements-driven, test-driven development), and then - if it is worth the overhead - write automated functional and acceptance tests. <br />
<br />
I'm desperate to get this rolling from Business Contact through Business Analyst to Developers and Testers within the company I work at - but I wondered if anyone else has gone ahead and implemented this fully as an end-to-end requirements and development methodology. In the meantime, I'll get my act together and make a couple of posts (when I'm feeling better) as to a few workshop techniques which work nicely for the client-end of BDD.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-91108017310508082032009-11-22T18:15:00.001+01:002009-11-22T18:15:27.369+01:00My Review of Website Optimization<div class="hreview"><div class="item"><p><a href="http://oreilly.com/catalog/9780596515089">Originally submitted at O'Reilly</a></p><div><img src="http://images.powerreviews.com/images_products/09/56/5332272_100.jpg" class="photo" align="left" style="margin: 0 0.5em 0 0"><p style="margin-top:0">Is your site easy to find, simple to navigate, and enticing enough to convert prospects into buyers? <em>Website Optimization</em> shows you how. It reveals a comprehensive set of techniques to improve your site's performance by boosting search engine visibility for more traffic, increasing con... </p></div><a href="http://oreilly.com/catalog/9780596515089" style="display: none;" class="url fn"><span class="fn">Website Optimization</span></a></div><br clear="left"><p><strong class="summary">Diverse, related topics in one place</strong></p><div>By <strong>thristan</strong> from <strong>geneva, switzerland</strong> on <strong><abbr title="20091122T1200-0800" class="dtreviewed" style="border: none; text-decoration: none;">11/22/2009</abbr></strong></div><p><div style="margin: 0.5em 0; height: 15px; width: 83px; background-image: url(http://images.powerreviews.com/images/stars_small.gif); background-position: 0px -144px;" class="prStars prStarsSmall"> </div></p><div style="display: none"><span class="rating">4</span>out of 5</div><p><strong>Pros: </strong>Concise, Helpful examples, Easy to understand</p><p><strong>Best Uses: </strong>Expert, Intermediate</p><p style="margin-top:1em" class="description">This is a hugely useful read, particularly if - like myself - you have a range of responsibilities for managing online assets ranging from design, deployment and testing to site promotion and marketing. <br xmlns:pr="xalan://com.pufferfish.core.beans.xmlbuilders.xsl.Functions"><br>Much of the information on each vertical section can be found elsewhere - for instance SEO, PPC and performance optimisation - and individually, each section provides solid information which might not surprise. <br><br>The real advantage of this book is that it forces the reader to think of each of the diverse threads as being intimately related in the customer's experience. If you are a UML geek, think of it as an answer to an end-to-end use case (find site, load site, explore site): if you are a marketeer it will expand your horizon in understanding how technical, offpage elements can contribute to satisfaction, bounce rate reduction and improved conversion; if you work in application deployment or support, it will give you some useful pre-launch direction to load and performance testing and gain you brownie points with your Sales and Marketing customers.<br><br>So, short order review is that while individual sections on their own may not deliver any surprises to someone with existing expertise, the overall remit of the book will expand the horizons of most who read it.</p><p style="margin-top:0.5em">(<a href="http://www.powerreviews.com/legal/terms_of_use.html" rel="license">legalese</a>)</p></div>Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-40611748394831492512009-10-06T19:22:00.003+02:002009-10-06T19:34:34.285+02:00Corporate Programme Management for the WebI've worked for a number of blue-chips for a number of years, and am continually surprised by the fact that - since online is not a primary or secondary revenue base - sensible, value-driven approaches to managing a Web portfolio are few and far between.<br /><br />Many larger companies play lip service to the concept that the Web is (or can be) a hugely important component in the process of "doing business": they show initial interest (in terms of capital investment) in a couple of pilot projects, and then seem to rapidly lose interest in keeping up with the Internet as a "going concern".<br /><br />The complexity of stakeholders, risk management, the "agility" of a larger corporation, and - of course - competing (core) investment concerns all play a role in making it difficult to apply a longer-term, strategic programme approach to online activity, and ensuring that this is delivered according to best practices.<br /><br />Benchmarking helps, but - funnily enough - when speaking to colleagues working in related roles for different companies, I find that this is, in fact, an endemic problem. So this is a call for comment, input and assessment from anyone working in an internet management role where the core product is not sold online, but where the Internet is "considered" a core component of business activity - correct me if I am wrong, maybe share successes and failures, and indicate the righteous path forward...Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-32919287421406601702009-02-22T12:33:00.002+01:002009-02-22T12:38:20.432+01:00Disentangling blended feedbackHaving just been working on a project where workforce and audience acceptance of a mix of new hardware, software and content needed to be assessed & tested, I'm keen to find out the best way of gaining a blended system acceptance view without confusing the feedback for the separate elements. I know this should focus on asking precise questions, and directing users to complete specific targeted tasks, but users often seem unable to disentangle feedback in one dimension from another... (usually blaming hardware or software for eveerything). Does anyone have any helpful advice? I must confess that I'm not used to adding the hardware angle.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-50245102491923821972009-02-08T14:49:00.003+01:002009-02-08T14:58:24.429+01:00This Blog is still alive...!...just.<br /><br />Having just logged into Blogger, I now realise that it is only a week shy of a year since I last posted to my blog.<br /><br />In case anyone is still out there occasionally reading the blog (it's been a while since I checked out the analytics also), the main reason behind this has been moving countries, and then trying to move house.<br /><br />While this isn't inline with previous post content, I suppose it does count as "information" to be shared: if you are moving to Geneva, make sure you give yourself at least 6 months to find accommodation (unless you are so wealthy, you can gazump the market!). It actually took my family 8 months to be able to move from temporary accommodation into a permanent home - and this was with sizeable local knowledge, friend networks and work & family support...phew!<br /><br />If anyone is interested in knowing more, leave a comment, and I'll add some detail, otherwise, my next post will be back to normal themes of IA, KM, usability and needs analysis.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-60743006949385758252008-02-13T18:43:00.003+01:002008-02-13T18:54:01.216+01:00PRINCE2 and AgilityOver the past couple of years, I've dabbled around the fringes of agile programming/project management mostly looking at XP, but I have to confess that I've always struggled to reconcile agility and the structured control delivered by PRINCE2. I've always erred towards early, hands-on prototypes (whether paper or digital), prioritised requirements lists, and facilitated, collaborative meetings, so I was delighted to discover that all three of these feature strongly in DSDM. I've now taken the plunge, and am reading (the - so far - excellent) short tome on merging DSDM with PRINCE2, "<span style="font-style:italic;"><a href="http://www.amazon.fr/Agile-Project-Management-Running-Projects/dp/0113310587/ref=sr_1_11?ie=UTF8&s=gateway&qid=1202925180&sr=8-11">Agile Project Management</a></span>" by Keith Richards. I'm starting to come around to the idea that web projects might be ideally suited to a stripped-down mix of the two (perhaps something more PRIDE on the PRINCE2 side). Certainly the inherent difficulties of managing rapidly moving web projects within a PRINCE2 change management framework appear to be addressed by such an approach, as would integrating early and frequent usability tests.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com1tag:blogger.com,1999:blog-5364058.post-37231493577931400832007-08-25T18:28:00.000+02:002007-08-25T18:46:25.875+02:00I'm not here at the moment, but...I'm on holiday and paternity leave at the moment, enjoying the French Alps, and learning to live without sleep (I'd love to know when babies biorhythms start to match those of their parents). A couple of days before departing, a colleague in our Human Resources department asked me to deliver a presentation on the corporate intranet (as a communications and knowledge management tool) to our graduate work placement intake...two days into my break.<br /><br />However, I hesitated to decline as there would not have been anyone to do this in my stead. So, as quickly as possible, I cobbled together a variation of the absentee acceptance common to awards ceremonies ("Kirk Douglas cannot unfortunately be with us today, but he recorded the following message...").<br /><br />The limiting factors were time and the need for the presentation to be delvered in a known format (as the HR team would be delivering the presentation). However, armed with a couple of pieces of software, a headset and webcam, it was just over an afternoon's work to put together. <br /><br /><ul><br /><li>Microsoft Powerpoint to advance the slideset (using insert > movie and embedding Flash movies using the activeX Flash object and the Flash rewind plug-in);</li><br /><li>Blueberry software Flashback Express to record the video screen-capture and voice over;</li><br /><li>A Logitech webcam to record a few short video introductions;</li><br /><li>Snagit for some static screen captures as slideshow graphics</li><br /></ul><br /><br />I settled on using Flashback Express for the main voice-over as I found the quality of Powerpoint's record narration function to be severely limited (although given the time constraints, I didn't have the chance to check out whether this is a known limitation or an indication of my own inexperience with the function).<br /><br />The great thing is that I was able to hand the HR department - 5 minutes before heading off on holiday - a single package where the only input required from their team was to advance the presentation slide-by-slide. I haven't yet heard how well the presentation went down, but in the absence of available time and a replacement speaker, I would recommend this as a very useful tool, which, once you have got into the screen-casting habit can be very rapid.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-16317543303193367602007-07-11T18:03:00.000+02:002007-07-11T18:08:25.238+02:00Change in status...on becoming a dadI haven't had the opportunity yet to write up my thoughts on KCUK, as my wife and I have been busy with our new son, Theodore, who chose the auspicious date of 07/07/07 to mark his entry into the world.<br /><br />There are very few "Thristan"s in the world (obviously not including the Christian name), so I think Theodore may take us up to a count of about 15 worldwide.<br /><br />I will blog on KCUK and other things soon, but in the meantime, may try to catch up on some sleep!Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com1tag:blogger.com,1999:blog-5364058.post-84530915325021903462007-06-29T17:26:00.000+02:002007-06-29T17:36:24.790+02:00Knowledge Management PresentationI was over at Ark Group's <a href="http://www.kc-uk.co.uk/programme-day2.asp">Knowledge and Content UK</a> this week, along with a colleague, and will try to write up a lengthy post regarding this within the next few days. However, given that it's my wife's due date tomorrow, and she has already been having contractions, it may take me a few days to find time to gather my thoughts and reflections and get them up on the blog.<br /><br />My presentation went pretty well, although - as I had a graveyard slot - the audience was perhaps smaller than anticipated (but appeared pretty engaged with the discussion on best practice management). <br /><br />This year's conference seemed generally to mark a refocus on the "people" elements of KM with a healthy dose of social software and Web 2.0 references sprinkled in. I would have liked to hear a few more tactical KM war stories, rather than so many similar strategic approaches, but there were some excellent speakers, and I had some engaging discussions during the breaks.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com1tag:blogger.com,1999:blog-5364058.post-13625772162273667002007-05-26T22:31:00.000+02:002007-05-26T22:49:39.113+02:00MyBlogLog and WinkIdly meandering through the Yahoo Developer Network, I clicked on MyBlogLog - which I signed up for ages ago, but never did anything with. It's an interesting conceit - so if you do <a href="http://www.mybloglog.com/buzz/members/thristan/">read my blog, feel free to sign up to say you do</a>...Likewise, I'm trying to sort out a <a href="http://wink.com/profile/thristan">Wink profile</a> as I like its use of MicroID - again, feel free to engage!Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-34013940293280061802007-05-14T16:36:00.001+02:002010-03-11T20:17:22.445+01:00Web Project Management Best PracticeI was contacted to take part in an e-consultancy review of Online Project Management a short while ago, and received <a href="http://www.e-consultancy.com/publications/web-project-management-best-practice-guidelines/">a link to their report on best practice in this area</a> today. [UPDATE 16/05/07 - Linus Gregoriadis, Head of Research at e-consultancy, let me know I was pointing to a link for survey participants only, so - just in case you have bookmarked this, the link has now switched.] <br />
<br />
I have to say, having skim-read the first-half, that it very much matches my experience. For instance, as a <a href="http://www.prince2.org">PRINCE2</a> qualified practitioner, I would have to agree that the PRINCE2 "exception"-led model of change management (and over-reliance on detailed specifications) can work against managing rapidly moving Web projects (where <a href="http://www.extremeprogramming.org/">XP</a> and other Agile methods build this into a rapid and iterative loop). <br />
<br />
The great thing about a Web project is that you can manage the overall project with one methodology and branch off (in a controlled manner) software development, for instance, in a slightly different direction. I think it pays to be cute and take a pick-and-mix approach, rather than try to adhere to a monolithic approach, all in the name of getting things done. I don't think this has to be at the cost of losing control of time, cost, quality and associated risks; this is one of the reasons that I enjoy <a href="http://www.basecamphq.com">Basecamp</a> as a Project Management tool: it helps me control the project while being flexible enough to stand setting up PRINCE2-type methods, controls and stages as categories.<br />
<br />
Note: prince2 link updated on 10/03/2010 thanks to helpful comment.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com10tag:blogger.com,1999:blog-5364058.post-69992143013202155712007-04-16T16:27:00.000+02:002007-04-16T16:36:13.096+02:00Recognise pattern, fail to changeI'll probably write this up in more detail when I have two minutes to myself, but reading a recent copy of Wired last night on the plane from Geneva to London, I was just very aware of one very major strength in the human psyche, and another - related - weakness. <br /><br />It's not a surprising revelation, but I feel that sometimes it is worth stating the obvious: people are great at recognising patterns, but hopeless at turning these patterns into action. I think that therein lies the failure of many a great, intellectually cogitated strategy.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com1tag:blogger.com,1999:blog-5364058.post-88478337132063787192007-03-09T14:02:00.000+01:002007-03-09T14:13:16.267+01:00So much for digital whiteboardsVia <a href="http://www.orangecone.com">Mike Kuniavsky</a>, here's <a href="http://www.orangecone.com/archives/2007/02/philips_drag_dr.html">an interesting toy which allows you to interactively project drawings in real-time</a>. I know the intended audience is for kids, but this is a very cool way to make a big drawing in real-time when you don't have a whiteboard available. Just project on the wall.<br /><br />This very much reminds me of <a href="http://www.nationaltheatrescotland.com/content/default.asp?page=home_showWolves">a play of a Neil Gaiman book called "The Wolves in the Walls"</a> which my wife did some digital compositing and projection work on where an After Effects animation was composited and projected onto the stage using Watchout software. The effect was to enable the actress to "draw" on the stage in real-time. Depending on the artistic skills of the actress, this toy would have been a simple replacement for this one effect. Scientific Progress does not always go "Boink" to mis-quote Calvin and Hobbes.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0tag:blogger.com,1999:blog-5364058.post-66048102898956037392007-02-27T18:08:00.000+01:002007-05-26T22:28:45.670+02:00Scrollable, multiple selection checkboxesVia Bim Egan of the RNIB, and passed on to me by my colleague, Sonia Carter, is this nice little accessible solution to multiple checkbox selections and saving space (i.e. "making it look good") at the same time.<br /><br />This was, as pointed out by Bim, discussed on <a href="http://www.webaim.org/discussion/mail_thread.php?thread=2701">the webaim discussion board</a> a while ago - to be honest, I was stuck back in the days of thinking that CTRL+ multiple option selection was fine for the "select" <code><select></select></code> element. But, care of Bim is this neat solution on C82: <a href="http://c82.net/article.php?ID=25">"check it, don't select it"</a>. I really like this - neat and easy to code.Mark Thttp://www.blogger.com/profile/12870416406574109081noreply@blogger.com0