A combination of holidays (why, thanks for asking, they were very nice) and work has meant I've been a bit quiet recently. Anyhow, picked this up from O'Reilly, which also hit the radar of one of my colleagues (Ian Davies) who was fortunate enough to actually be part of the discussion. Either link will fill you in...
It's one of those things you read and find yourself nodding in agreement. None of it was "new" in my book, but it is refreshing and concise. Couple of things I'd like to add:
Documentation: I've been working on a documentation strategy for describing our platform recently, and the analyst team have been putting a lot of work into becoming far more agile in our specification approach. So I take issue with some of the comments regarding avoiding investing in a business plan and, especially, the comment "Build things, don't talk about building them. Don't write specs that will be outdated and totally unrelated to your final product. Don't create the technology and then slap a UI on it -- instead build the UI first, iterate and learn from your mistakes. Then, once the UI is done, put the actual technology behind it. Let the UI screens be the specification for your technology."
You need to document at high level - to strengthen understanding (it reinforces the thought process), to communicate, to scope, to build. The key thing is minimum documentation (yeah, yeah, all part of the agile principles). Its about documenting just enough and moving on when you're not adding value. This applies to the early business planning, business requirements, market requirements, project docs, vision/scope, etc, and equally applies to your functional specification. I wouldn't build the UI first, I'd storyboard first. May do a bit of work nailing down the customer problems and goals. Couple of use cases or scenarios may help, or they may not. Diving straight into the UI is going to get you a whole lot of grief. However, the sentiment is right. Do just enough work/documentation to understand, then "just do it"!!! The key problem is knowing when you've done "just enough" and that comes primarily from experience.
Features: I'm so with this. Less is definitely more. Just look at the i-pod. It was such a success over far more "feature rich" mp3 players because every feature added value to the user and let them achieve their immediate goal efficiently. There are no features to distract or create noise. Mobile phones are another one here. I use about 5% of the features on my phone. There are probably another 5% which would be really useful to me. But the feature noise is so high, this deters me from making the investment because "it makes me feel stupid". And I'm a techno-freak! Cooper has some wonderful stuff on this in his 'running the asylum' book.
I left libraries and moved to Talis for many reasons - one key one was that I wanted to make a difference to the lives of users, and the way the public sector works just doesn't encourage this (too much red tape!). Skywalk (the library instance of our Web2.0 platform - more at the Talis Insight conference) is going to be a wonderful tool to realise my goal - which is to realise the goals of all the institutions and their users who consume the web services we offer. What is going to be key is finding those key features which will make that difference to peoples lives and exposing these first/now, rather than delivering 101 features en masse a year from now when all those goals have changed. Less features = less noise = more value.
No comments:
Post a Comment