Showing posts with label Agile. Show all posts
Showing posts with label Agile. Show all posts

Friday, 3 December 2010

Something for the Weekend - IIBA Barclays 14th October

For those who couldn't make it to the IIBA event we held at Barclays on the 14th October all is not lost! We recorded the lot and thanks to Simon Ward they're now on YouTube.

Due to the time limits on YouTube they're broken into parts;

Building BA Communities - David Avis with opening comments from Gill Reed.

Part 1
Part 2
Part 3



Agile in a Nutshell - Portia Tung - Emergn

Part 1
Part 2
Part 3


Closing messages - James Archer

Click Here


Saturday, 14 August 2010

Something for the Weekend - It's hardly nasal surgery!

I read an interesting story early this week that really brings to life the value of prototyping.

In 2001 designers at IDEO were tasked with working with teams of surgeons to create new improved tools for nasal surgery. During the design session one of the surgeons was trying to explain how the ideal mechanism would be a trigger grip only he struggled to put in to words what he meant. One of the designers picked up a marker pen and a 35m film canister and taped them together. They then picked up a plastic peg and fastened that to the front creating a basic version of what the surgeon was attempting to describe. This might sound like Blue Peter but it saved a huge amount of follow up meetings, through the ability to physically demonstrate what was actually needed.

I love the story as I see similar comparisons day to day in our roles. Where written requirements fail to adequately express the need; quite simply fail to bring it to life or allow for different interpretations. I am, without doubt, an advocate of using diagrams and screen mock ups to validate and elicit requirements so I thought I'd share some thoughts on the topic.

Tips for Prototyping
  • We're using BalsamIQ - It’s a great tool - do check it out at Click Here
  • Recognise that that creating mock-ups won't slow things down, it generates results faster and gets people on the same page.
  • Be clear as to why you're mocking up screens - it's not for the purpose of a final design but to elicit comment and validate written requirements and assumptions.
  • Keep it rough - to have something too polished suggests it’s a final design, enough to get to the answers as quickly as possible is all that is needed - Lo-Fi is the way to go. (just think of nasal surgery!)
Sources & Credits
IDEO

Friday, 25 June 2010

Something for the Weekend - Fail Fast

In a recent interview with Wired magazine, Lee Unkrich (director of Toy Story 3) said something that reflects an important part of any truly successful team. It's also a principle that's deeply embedded into Agile Development teams.




Here's the quote:

"It’s important that nobody gets mad at you for screwing up. We know screwups are an essential part of making something good. That’s why our goal is to screw up as fast as possible."

Without doubt that's contrary to popular belief... People focus on getting everything to 95% before they're prepared to share it... but don't you find that often the 95% position still has flaws? And that often it's too late to really react to them? (Therefore is that really 95%?)

A few thoughts that underpin this:

* In true 'no blame' cultures having the freedom to take calculated risks means that some will pay off and some won't. The key to unlocking innovation and creativity lie in having a 'safe' environment in order to explore ideas.
* No one person should have a monopoly on ideas. The wrong environment can suppress ideas from all but the most confident.
* The trick is to seeing the outcome of any venture as positive, if it's paid off you've increased the quality of what you're doing, if you've failed you've learned from it.

What I'm not suggesting is that it's ok to fail overall... in fact, far from it! The key word in Unkrich's quote is "fast" - The very idea of failing fast is to guarantee success! So how do we do this?

Experiment openly and visibly (through documentation, prototypes, conversations, presentations) - ensuring that all failures become minor setbacks.
* Create a culture where small failures in the delivery cycle become successes in learning, consider them R&D! It's the only positive thing to do if they happen.
* Actively encourage the sharing of ideas - everyone has them.

Sources

Interview with Lee Unkrich in Wired http://www.wired.com/magazine/2010/05/process_pixar/
Spotted via the 37Signals http://37signals.com/svn/posts/2348-its-important-that-nobody-gets-mad-at-you

Tuesday, 1 June 2010

Something for the Weekend… Solution Addicts

    Recently I've noticed an increasing amount of people coming to my desk with predefined solutions, whist to a large degree this is admirable, on further probing there's often a lack of definition about the problem is that needs to be addressed or perhaps more specifically the root cause of that problem.


    It's logical that people do this… traditional business teaches that we shouldn't dwell on the problems but instead be taking action to resolve/improve them, and after a while it becomes a habit, and ultimately an addiction. - We start to think about answers faster, faster and stop taking the step back to really look at what we're trying to achieve. A really clear symptom of this is when new information (inevitably) emerges or challenges arise and U-turns are required on solutions as a result (or worse). Framing problems and root-causes up front help with this enormously… if your solution is addressing the root-causes of a problem, new information can only help to build and evolve a better solution.

    It's our role as analysts to do this, so how do we go about it? The first is step helping people to admit they have problem (i.e. not that they have solution). I've attached an 8 min video to a presentation by lady called Mary Poppendieck - she's a prominent voice in Lean based software development techniques and in this video she does a fantastic recap of pareto charts & fishbone diagrams and the importance of testing your analysis by completing what she terms "Many Rapid Experiments" http://www.youtube.com/watch?v=MhxyO6jUubQ.

    These techniques will no doubt be familiar but digging them out of your toolbox and dusting them off is always a valuable thing to do.

    If you've got any questions on the techniques Mary talks through do let me know.

    Enjoy and have a great weekend-

Thursday, 1 April 2010

Something for the Weekend - Technical Debt

Technical Debt is a metaphor developed by Ward Cunningham to raise awareness of some of the long term impacts of the decisions that we take to get project or technical change live. 
 Ward's metaphor refers more to 'debt' taken with ugly coding or patched together architecture but I think this concept expands well to design too.

We all take shortcuts in order to meet deadlines, restrict cost or work within other constraints. More often than not it’s the right commercial decision but the metaphor really helps to ground the decisions you need to take. 
So what is Technical Debt… imagine it as a bank account, if you take a shortcut with your project/design you go into debt and will, one day, need to repay that debt (correct your shortcut).

Also, just like an overdraft you incur interest... perhaps operational pain, perhaps defects in the code & most likely rework. The longer you live with the debt the more you pay. 
No ones saying you can't go into Technical Debt but there are rule…
  • Make decisions that are deliberate - inadvertent decisions are just bad design (or worse)!
  • Take the debt if its prudent to do so, if the commercial advantages outweigh the debt you're in the right place.
  • Have a plan to repay the debt - a follow up release, back out, etc. Compounding the problem will just make it un-repayable.

This virtual bank account isn't really measurable in £ - it's unquantifiable productivity cost and therefore needs subjective judgment but I really like the concept to articulate some of the decisions we take and live with. 
This cover the basics but if you want to read more check out the links below.

Sources and Credits
http://martinfowler.com/bliki/TechnicalDebt.html
http://senses.thirdi.com/posts/225-what-is-technical-debt/

Friday, 26 March 2010

Something for the Weekend - A Community of Thinkers

Liz Keogh, Jean Tabaka and Eric Willeke are actively involved with the development of Agile Software techniques. They recently met up with the objective 'to give something back to the community' and this week I wanted to share what they created with you.
The output was a statement of commitment, a pledge if you will, for their group - Here's a copy of it:


“A Community of Thinkers”
I am a member of a community of thinkers.
I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.
I challenge each community in the software industry to:

  • reflect and honour the practitioners who make its existence possible;
  • provide an excellent experience for it's members;
  • support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
  • exemplify, as a body, the professional and humane behaviour of its members;
  • engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
  • embrace newcomers to the community openly and to celebrate ongoing journeys; and,
  • thrive on the sustained health of the community and its members through continual reflection and improvement.

I believe that leaders in each community have a responsibility to exhibit these behaviours, and that people who exhibit these behaviours will become leaders.
I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.
”A Community of Thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License. Please attribute to the distributor of your copy or derivative.


Whilst I agree with the sentiment entirely (albeit a little manifesto-ish for my personal taste). The point that interests me particularly isn't as much about the code of conduct itself but the thoughts behind the need for a community in the first place... And the questions of whether we view that we're part of similar communities in our respective worlds.

The statement really acknowledges two things which I think are important to us as a community of Business Analysts (regardless of whether that involves IT development or not):

  • Continuous Improvement - It's obvious but the way we do things today isn’t the only way that we can do them. We need learn from our combined success and our failures in equal measure. The world keeps moving and so must the disciplines and techniques that we use… weather that's for better product, better results or simply to do things faster and cheaper.
  • Respect for Communities - A 'community' in this sense is just a boundary-less, hierarchy-free group of people who are committed to driving their industry forward regardless of their organisation, team or political agendas. The statement to me really embraces the old management cliché of 'people being our most important assets' and does this with conviction. The community are the root of the improvements, innovations and developments that we see.

Equality important is the recognition that we're all part of that community and with that comes an equaled responsibility to contribute & support it. The level of our contribution to the community directly correlates with our success (or failure) and how fulfilled we are by the roles we play both today and in the future.