29 February 2012

4 Phrases v1

A few months ago (far longer than I had originally hoped), I asked Craig to send me a ppt doc with 1 word or short phrase on each slide. I would not open the document until the mic was on and recording, so you could all hear my random thoughts on whatever it was that Craig would ask. The below short video is the fruit of that labor.

27 February 2012

The Heretic's Guide to Best Practices

How could you resist a title like that one?

Australian bloggers Kailash and Paul wrote an outstanding book on the perils of Best Practices.  This books roots are in complexity thinking, and comes thick with both stories from the field and academic, all integrated with an amusing and entertaining.

I highly recommend the book. I even wrote a review on Amazon.

To help you take action, links to the physical and kindle editions are below.

23 February 2012

Model Storming

In this week's edition of Agile Thursday is about Agile Modelling via Scott Ambler.

Scott is an advocate of several agile analysis and design techniques and frameworks including IBM's Agile Unified Process, a variation on RUP, and has been writing, training and coaching on them for years.

He has written a book on the topic. Probably more usefully he has also written a virtual book on the topic.  That is, while his book is more structured and comprehensive, his online articles are easy to access and cut to the heart of the matter.  My recommendation: Start with the website and if you want further guidance, buy the book.

Scott introduces his book (and website) thus;
An important concept to understand about Agile Modelling (AM) is that it is not a complete software process. AM’s focus is on effective modeling and documentation. That’s it. 
It doesn’t include programming activities, although it will tell you to prove your models with code. It doesn’t include testing activities, although it will tell you to consider testability as you model. It doesn’t cover project management, system deployment, system operations, system support, or a myriad of other issues. Because AM’s focus in on a portion of the overall software process you need to use it with another, full-fledged process such as eXtreme Programming (XP), DSDM, Scrum... (etc) "
Examples of techniques Scott recommends include Storyboarding, Wire framing, Activity diagrams, Flow charts and many more.  A particularly excellent section presents a table of modelling tools, some notes on their 'agile usefulness' and links to pages with descriptions and examples.

Principles he guides his ideas with include Modelling in small increments, Model with Purpose, Embrace Change, and more. Check them out.  It's well though through and can help you understand how to improve your analysis and modelling practices no matter what development planet you live on.

Lastly, Scott also shares a bunch of typical Enterprise bad practices on a page about "Modelling Anti-Patterns" which are kind of amusing. At least to me :)

I hope the site delivers value to you frequently. I'd love to hear your feedback.

16 February 2012

Daily Stand-up meetings | Doing it right

Summary: Go read this

When you go to agile training, read agile books and talk to agile practitioners they all have a common story.  The daily stand up (aka daily scrum) is a team tool to facilitate collaboration and understanding and to quickly identify and action risks and issues. Keep the meeting focused on the purpose and keep them short.

Time and again when consultants, coaches and trainers get together the share stories of stand-up meetings gone wrong. People get together for 45 minutes or more each day, issues are not identified and escalated out of the team.  People talk about stuff.

What goes wrong?
People never take the time to understand the purpose of the stand-up and you get cargo cult practices. Or people fall into old habits and don't realise they are wasting time and energy on doing it wrong.

Sometimes it less less tragic than other times, but there are still problems impeding the effectiveness of the session.

And sometimes, just occasionally, everything is fine with your team's stand-ups but you want to push your effectiveness boundaries just a little bit more. Or sometime you just want to help the team down the hall.

What do you do?
If you are me you refer them to the great article "It's not just standing up" by Jason Yip.  I am yet to find better.

9 February 2012

What is Story Mapping

Story Mapping is an Agile technique for managing product backlogs developed by Jeff Patton.  I first discovered the term Story Mapping via a blog post by Jeff called The New User Story Backlog is a Map.  The blog post is a very insightful and clear explanation of Jeff's motivation for the idea.  Rather than me repeat his content in detail you should just go read his content.

Jeff himself first articulated the idea publicly in an article in Better Software called How you Slice It (free PDF.)  It's a technique for sorting and simplifying backlogs that are too large and complex for a simple list.  How can we create different views on the backlog that help us understand what is happening and how the product is evolving?

There are arguments against the story map concept. The one that springs to mind is that you should have a lean and small backlog and so you shouldn't need all this high faluting modelling.  In reality, most of us, especially those of us in large organisations, need tools like this to help us sort through the complexity.

When I talk about Story Maps in training and coaching sessions I am always drawn to BJ Clarke's diragram which I think is great. What I like about this diagram is the way he blends the structured three tier form of a story map with the rough and ready hand drawn notations.  For me this just feels like a good diagram.  Thanks BJ.

Another blog post I discovered via the nice diagram is via Dreamfeed, which also has a really nice blog post on Story Mapping that I think you should read.

Story maps don't stand alone in Jeff's metal model for managing product development.  This all happens in a context that includes developing persona's and designing with the user experience in the centre of your thinking processes.  It's all about thinking big picture so you can delight your clients.  A micro-focus is good when doing the work, but a macro-focus is also needed when thinking about the customer.

For example, when I create story maps they end up looking very much like a top three layer of a WBS with a Prince2-like product breakdown style to them.  They don't always end up like this and they don't have to either.  Other people I know fall into other habits like building story maps around process maps.  I am not sure what Jeff thinks off these variations on his idea, but I'll keep an eye out on the topic.

What stories do you have to share about Story Maps?

8 February 2012

Systems thinking or People over Process

A topic I still haven't reconciled in my study of management theory is whether systems are 95% of the success or failure of a process (Deming) or whether it's People over Process (Agile Manifesto.)

Of course it's neither, and that both systems and people matter, but I haven't squared away the dichotomy into an easily managed aphorism yet.

Perhaps "systems that enable people" are they key. Or perhaps it's "systems that facilitate collaboration."

There is no doubting that systems play an important part in getting things done. But in what ways to systems and people interaction find the optimal balance. And what is the model illustrating the point?

7 February 2012

Karl Scotland on the Science of Kanban

Karl Scotland has done a nice blog series on the science underpinning the Kanban Method (with a little help from Clark Ching's multi tasking game.)  I highly recommend reading the following posts:

Case Study: Creating Collaboration

The lightning road

I signed up as a line manager of a team of business analysts and web developers at a large corporation. My role was to manage the team which had three main functions; (1) identify and implement process improvements into call centres an back office processing centres, (2) co-ordinate communications and training around new product roll-outs, and (3) act as SMEs and process analysts for infrastructure and new product development projects.

The team were, when I joined them a classic case of the “No department.” Business analysts and project managers that had to work with them did so only under sufferance. Frontline business unit managers groaned as the technocrats rolled out a new procedure in an increasing complex and difficult environment. Quality assurance officers and frontline workers, often in dispute over what constituted the right way to do work, cheered them as they ironed out all grey areas in all procedures and work instructions.

I realigned the team structure to mirror the client organisation’s structure and changed the role from one oriented to product and process orientation to one of client focused consulting. The team’s new brief was to spend time in the call centres and processing arras and look at operations from their client’s point of view.

Opportunities for improvement were to be assessed on the size of the problem and the potential for improvement- a minor business case analysis. Candidates for process or system improvement were identified from first hand interaction with users and customers, and from data from operations report. They were then prioritised based on evidence. Solutions were implemented in partnership with the operations managers and their teams.

The consultants’ new role was to help local managers discover the most important pain points and help facilitate the solutions, not to impose tinkering on work instructions and create impediments to capitalised projects. Within 12 months stakeholder satisfaction feedback had increased five-fold, clear and measureable benefits worth several millions of dollars had been rolled out and most of the tinkering had ceased.

My role as manager, after changing the system the team operated in, was to coach the team members in consulting, analysis and problem solving skills, but essentially they created their own virtuous improvement cycles by talking among the team and dealing directly with their own set of clients.

2 February 2012

What is a User Story

I have been at Wikipedia again. This time at the User Story page.  I didn't like the contents as usual, and this time I drafted a variation on the Wikipedia page and published it in the Business Analysts Handbook. A copy is recreated below for your interest.  It also serves well as a first post in the Agile Thursdays series.


A User Story is a marker indicating a request for work to be done.

User Stories are often conflated with software or business requirementsbecasue on first impressions they look like requirements. They are actually independent things.

User Stories were first introduced to the world by the XP community in the late 1990s, although the concept of stories and narratives being effective tools for communicating requirements daes back at least into the early 1980s.

Important things to consider about User Stories 

  • They are a token for doing a piece of work and are not a software requirement in the traditional sense 
  • They are a 'trigger for a conversation ' and build upon the Agile Manifesto principle that face to face conversations are the most effective form of communicating ideas 
  • A User Story is likely to evolve over time as people's knowledge on the topics area matures 
  • Generally, when a software team starts work on a User Story a clear 'definition of done ' should be available 
  • User Stories are ideally written on index cards or similar because of the value of visualizing the workflow , keeping them simple and osmotic communication . 
Card Conversation, Confirmation
The three essential elements of a User Story are the card, conversation and confirmation.

These are described below under the following headings.

  • Card = Physical v Electronic 
  • Conversation = As a Product Owner I want a template 
  • Confirmation = Start with the end in mind 
Physical v Electronic
User Stories are typically written on index cards or post it notes because of the value of osmotic communications, the lightweight nature of the tool and because face to face communication is optimal for project team communications.

Many teams also capture User Stories in electronic media such as requirements management or test tools.

There are many purpose build product backlog management tools on the market.

As a product owner I want a template so that it's easy
Since the mid 2000's a 'common form' of User Story has become dominant. It is presented in the following form;

  • As a [user type] 
  • I want [an interaction+outcome] 
  • So that [I get some form of value] 
The benefits of this templated form are real and tangible. An important part of both requirements management and workflow management is effective partitioning or dividing of the model elements into smaller parts. Diving the stories by the user type is a useful technique. Occasionally a feature or service will be identical for multiple users but more often than not there are differences, subtle or obvious, that the division helps surface.

The "I want" element generally describes some tangible interaction or feature. Because of this element a User Story is often conflated with a Use Case, a scenario or a feature. And it may well describe any of these or other thing.

Again partitioning is relevant and important here. But the main driver in this space is to partition the work into a small, independent pieces of work. (See the INVEST mnemonic.)

Software developers usually have a lot to offer in relation to requirements and how they should best be fulfilled. Often they have been constrained by a lack of awareness of the motivation for the requirement. It's also a common client failing to jump to solutions to early. Asking for the motivation in terms of business value helps everyone focus on what's most important in the story. SO explain why in the "So that" clause.

But the template has it's detractors.
By proving a tamplate in the first place you provide a platform for people to communicate in written form with the idea that the communication is sufficient and complete.

Unlike requirements a User Story is not a complete brief. It is aimed at being a trigger for a conversation and is purposefully incomplete so that the conversations can be had to further elaborate understanding collaboratively.

Start with the end in mind
A clear definition of done is important for User Stories as they re work requests. By being clear about 'done' teams are better able to determine when they have not yet met the minimum quality and capability thresholds, and when they have gone too far.

Typically the definition of done is created via a test case or acceptance criteria prior to commencing work on the user story. Early User Story advoctes simply used the trigger "This will be done when..." to stimulate the discussion on 'done. More recently the idea has been elaborated. From the same vector as the "As A, I want, So that" template comes Behaviour Driven Development (BDD.)

BDD is more than just a form for acceptance criteria. It is also a framework for managing stories and requirements more broadly. But it has also been adopted as teh dominant form for acceptance criteria on User Stories with the template;

  • Given 
  • When 
  • Then 
Where given describes a starting state, when describes a trigger or catalyst and then describes the new state of being. This template form suffers the same strengths and weaknesses as the "As a I want" template.
Further reading

Related topics

  • INVEST - A quality checklist for User Stories 
  • Kanban - another concept for work tokens 
  • Story Maps - a way of managing large numbers of stories 
  • Behaviour Driven Development - Test thinking applied to stories
  • Stories as Inventory - understanding the cost of too many stories (or requirements)

1 February 2012

Agile Thursdays

I thought I might try something different with my blogging: A structured approach.

In the early days of this blog I was exploring and discovering techniques and models from the engineering paradigm of project management and requirements.  I learned a great deal of useful stuff, some of which is re-emerging now as part of the Kanban movement.  Given there is so much interest out there in the agile thing I thought I might try a regularly and specifically themed agile blog.

I'll be drawing the post topics from the local Agile meetup groups.  Their goal will not be to give definitive answers on topics, but to raise awareness and to provide a platform for further investigations.  I hope they are useful.

If you want to see a summary of all the topics covered to date try searching the blog for "Agile Thursdays."  

Better than a Requirements Template?

Technical Writing Templates - Sys Admin GuideCheck lists beat templates hand down.  Checklists say "Have you done enough?"  They help you think through the issues.

And they can become mindless activities as well.  Checking the box unthinkingly, or adding new items to the checklist without ever taking the time to trim some unnecessary items.

But I reckon they are still better than templates. They are definitely more lightweight.

I just created a checklist to help someone with little project experience think through their project needs.  Take a look. I'd appreciate some feedback.
It's not perfect.  It's not even complete, I'd say.  But how would it stand up as a newbie guide?