Agile Brazil 2013 workshop

Here are the slides from the workshop that I presented last week, at Agile Brazil 2013, Brasília DF.

From sketches to code, the Agile way

The workshop started with participants coming up with stories and sketches to support a particular scenario.  Most things were left open so they were required to come up with something, either by making assumptions or asking some questions about how they could approach their task.

Then they presented to the group.  I asked each pair / group the following questions:

1. How many stories did you come up with?
2. What was the most important or tricky part?
3. Was there something else that you would like to add?

Some had chosen the lean start-up method from the get go, choosing a couple of stories to implement before testing this to their customers and proceeding with the rest of the application; some did the traditional way of coming up with the entire design, with icons, welcome page, search… all that jazz.

After they have presented, I then threw a curve ball: the product owner has come back with a challenge and had given one of three different ways that the fictitious company makes revenue.  The next task was to ask them to change what they have currently, and re-work their stories and sketches to their new fate(s).  Then, of course, they have to present again.

The second round of exercise, the curve ball, was meant to test how much up-front thinking the participants have done before validating their assumptions in their learning journeys.  It was a great exercise, albeit painful, to have some of them see that the majority of their work go to waste because they have found out that the curve ball actually had gone against what they had initially thought was the money-maker.  They had to scrap stuff from areas they had thought were the most complex, because a completely different functional area was the key in generating revenue.  On another level, this was to simulate a situation where they are dealing with lots of ambiguity, and the that they should be thinking about what is the least amount that they should do to validate their thinking, before producing more work that would risk going to waste?  In my opinion, a critical element in any analyst’s skill set.

At the end of each exercise, we had a quick debrief on the whole experience, and got them talking about how they had felt when doing the exercise, whether it had mirrored in their real-life experience or not.  This was a great way to listen to how some folks might have perceived their usual way of working, contrasting with this particular exercise.

The workshop then ends with a quick walk-through on a field example, with annotated notes on how to deal with tweaking the amount of information you should put into each story that is appropriate to their project environment.  This was an eye-opener as I had demonstrated the differences between a co-located team versus a distributed team (for the latter, there were lots of gasping as they did not expect a story to typically include that much more detail).

Overall, it was a really good experience — by the end of the workshop a group had gathered to ask more questions (~30 minutes in addition to the 80 minute workshop, talk about dedication!) prompted by the many areas that we have touched upon, and of course, sharing more experience.  I hope I have inspired more people to try out new techniques and to ask more good questions that will help improve the way they work.

Thank you Brasília!

Turning stories from good to great

Ask how stories are written in an Agile or Scrum environment, and you will inevitably get the “As a …, I want …, so that…” bog-standard, cookie-cutter answer.  But ask yourself this, is that all you write in a story?

User stories in the Agile world is a means to achieving a goal in software applications.  The umbrella definition, if I may call out, is a placeholder for a conversation.  We say stories are a shorter, leaner, lighter version of capturing a business requirement, whilst never, ever, intended to replace a good conversation.

This is a perfect prelude to a modern myth: that user stories do not need to be written with the standardised business requirements document format, with use cases, UML / sequence / state diagrams, compatibility matrix and all their glory in the old world…. which means they do not need to be written with the same level of rigour.  Anyone who could muster “As a .. I want ..” can therefore write user stories.

In truth, rigour is thoroughly practised, if not more so than requirements in the traditional sense; the rigour and discipline are actually found not in the documentation format but in the content.  Having written user stories for years at ThoughtWorks, there are a set of principles that really help me to turn stories from good to great.

1. Get your story right

As an editor,

I want to create drafts for my articles before publishing,

So that I can show them to the editor-in-chief for tweaks before my articles goes out.

I have lost count on projects where stories are incomplete.  How many times have you seen the “so that” part missing?  It is often the most difficult part to express in the entire story, so many people just leave it out.  Do not make this mistake.  The story format is laid out like this for a very good, real, reason.  It is so difficult to get this part right, let alone having this part, because it forces the author to think hard about WHY this story needs to exist, the very reason for being.  It is justifying why the company should spend its money on developing this over another story.  Which means that if there is no real reason for it to be there, it will be de-prioritised or deleted altogether.  However if you omitted this part, there is very little telling on the true value it delivers.  It will just be a list of wild wishes mixed with legitimate wants and needs.  It also encourages behaviours like “whomever shouts the loudest gets the most stories that they want” — ending up in this situation is a sad place to be, really.

Another pet-hate is seeing “As a user” for all hundreds of stories.  Do you have only one user?  Really?  Just one type?  No personas whatsoever?  … I will gracefully leave this out for another time.

2. The unwritten rule of what goes inside

I always have at the ready The List, regardless of what domain I am working in.  The List contains the cornerstones that tell you whether your stories have the minimum sufficient amount of information to express what you want to do, for the development team:

• Story: As a, I want, so that
• Description
• Assumptions
• Technical notes
• Out of scope
• Acceptance criteria
• Estimate
• Priority

Going through The List really spells out whether you have gathered enough information to begin development.  It is no longer acceptable to write half-baked ideas and masquerade them as requirements, under the Agile or Scrum label.  Please, don’t blame Agile or Scrum when you are really just lazy; being Agile does not mean we have any less attention to detail.  It is focusing on the right level of detail in the right places at the right time.

3. Choose your words carefully

As you are writing less, really mean what you say when you say it.  Make sure you are using the same language as the domain and not adding another hoop for the team to jump through.  When you are writing stories, make sure you are referring to the terms correctly and consistently.  Been using the word graph? Don’t switch to say chart mid-story.  Even if they mean the same or similar things to you it would not always be the case for someone else.  I have a few more examples:

• Picture vs. Image vs. Illustration vs. Diagram vs. Graphic
• Description vs. Content vs. Blurb vs. Stub vs. Paragraph
• Number vs. Digit vs. Character
• Table vs. Chart

Same goes to when you are talking to QAs, developers, product managers and stakeholders.  Be aware that terms and names are used for mapping out the domain model, lives in the codebase as well as unit tests, functional tests and end-to-end tests … so being consistent will only help everyone understand what you mean clearly.

4. Use acronyms sparingly

Do not build the barrier to communication higher by putting in loads and loads of (even commonly known) acronyms.  One person’s understanding of CMS, CRM, GDP, SAT, SIT is quite different to another.

5. Convention over OVER-complication

In life and in story writing, use plain English as much as possible, strive to use this rule as often as possible.  There is no better way to put this.

Whether you like to admit it or not, no one wants to read reams and reams of waffle when they are really looking for the boiled down facts — so show only the boiled down facts — and show it clearly.  Lots of analysts grow frustrated or disheartened, or both, when they found out no-one was really reading their documentation.  Worse still, many miscommunication and misunderstandings stem from the fact that implied requirements are hidden in paragraphs of text when they should be clearly spelled out line by line.  Be explicit, unambiguous and concise in your words.  Adding unnecessary terms to things can only confuse people and it is everywhere: words like framework, repository, structure, XYZ manager when you are naming features may be intelligent-sounding but really build towards the fluff that people learn to disregard.  Shock horror, not (!)

I hope this is useful.  As with most things in a collaborative environment, ask for feedback from your peers if you are unsure of the right level of detail; you never know, a little feedback goes a long way in the world of continuous learning : )

Agile Brazil 2011 talk slides

Two weeks ago Danilo Sato and I had spoken about the techniques on how to define a big chunk of feature into something that can be consumed by the development team, at the Agile Brazil 2011 conference in Fortaleza.

The motivation behind this is to get people involved in development team, from the immediate team members to product owners and beyond, to think about how to articulate and express feature wants and ideas in a form that will best deliver the most valuable goals in an iterative way.  Splitting large chunks of features into stories has been one of those topics that very few people have mastered, and for the most part the precise techniques are largely unknown.  For this talk we used a worked example to demonstrate how to slice and dice a high-level feature in multiple ways that help address different priorities, which could be business driven or technically driven.  We then shared ways that we use to help stakeholders keep track of stories that had been split as a result of delivering features iteratively.

The slides for the talk, “Slicing and dicing your user stories“, is now available on SlideShare:

Feedback and thoughts welcomed.

The necessity to adapt

One of the more exciting things about being an analyst at ThoughtWorks is that you get to be at projects of very different business domains.  On one project, you could be in an investment bank, sitting in a room next to the trading floor; or, you could be studying the differences between 5 different designs on presenting a retail trade show, and you are within earshot of a fashion shoot.

Such differences in the physical working environment scream of an indicator of how you may need to adapt your ways of working.  Adapting your ways meaning that you need to tweak how you communicate and deliver your ideas to your audience so that the message can be heard in the correct way.  Same everywhere else, same for Agile.  The specific method of execution needs to be tailored to the specific needs, wherever you are.

Some of these so-called differences are apparent, for example, working environment or physical space that the project is located, others are more subtle and is picked up through interaction.  As analysts, we not only learn about the kind of tools that help facilitate people, but in what situations you would apply them and how.  By acknowledging these differences, it may help you to identify the best possible approach you take whatever project you are in.

Here is a sample of things that have helped me through various projects.

Adapt your tools

Capturing requirements on the fly from day zero is a big part of analysts.  Just because you are capturing requirements, it does not have to be done in one rigid way.  At some point, you may be doing this on 4″x6″ index cards, it may be on Excel if you are faster at typing, or you might even be doing this on Mingle.  Choose the method that is best for you and the situation.  What’s important as an analyst is that the essence of the story and the ideas behind the conversation are being captured.  You can do this quickly as long as you can recall such conversations or the high-level idea, because it allows you to go back to the people who first came up with them and continue with those conversations.  That is the main goal of your actions.

For instance, when you are in a time-pressured scenario such as story writing workshops, you could not afford to spend all your time in one afternoon discussing a handful of stories only (if you did that your inception would probably last for months, and would lose all the other valuable conversations that you could probably have had instead).  Scribble things using pen and paper, carry a fancy Moleskine to not lose the scraps of drawing (or the notebook even).  What about the white board and taking photos on your smart phones?  Present it on your iPad?

Adapt your methods

How you present your captured requirements is just as important as what you have written.

In a previous project, the clients were extremely visually oriented people and do not respond well to lists, documents or narratives well.  Or anything that consists of reams and reams of text.  In these circumstances you either go ahead and do it anyway, running the risk of your clients losing interest in the meeting, or you think of other methods of communication that will capture your audience and convey the same message well.  This resulted in facilitating a prioritisation workshop with images drawn on  cards.  I sometimes capture conversation points on a mind-mapping tool — simply because visual tools speak louder to me and I love being able to present this to the client.

Adapt your own interpretation to the local domain

Not literally the local language (though I have done this), but adapt your vocabulary to the client’s.  Immerse into their world.  Use their domain language to break the communication barrier, and you will find that you would not be fighting so many battles based on trivial things such as “We call it Iteration and you call it Sprint”, and instead focus on solving real world problems.

Continuous improvement and continuous learning

Agile is not a prescribed set of methods that, once utilised step-by-step, it will solve all your problems.  It defeats the name and defeats the point, really.  The trick is not apply any single tool so blindly that you hinder yourself from spotting a different way to solve a problem.  I have seen far more dangerous practices / restrictions that have been applied to projects or departments that, in the end, did more harm than good.  Just because you do stand-ups, you are not Agile (you are still practising waterfall methodology everywhere else).  It is not a label associated with a practice.  It is the underlying principles of Continuous Improvement that so many overlook; of knowing that you are not here to adhere or conform to the set of rules, but to continuously look for a better method of doing things; constantly asking yourself this question, knowing that you will inevitably find those improvements that will outdo and outsmart your previous ways.

It is not about coming up with the smartest, sophisticated system and let monkeys run wild with it; it is actually putting the smartest people you can find in any system and trusting them that they will come up with the smartest system for themselves.

Filling a bucket of ideas into a release

One of the things Business Analysts do is to facilitate customers in shaping their release.  You could be shaping what the next immediate release be, or indeed, planning multiple releases that span months if not years.  A good practice that we foster here at TW is to guide our customers to a direction that will best help them figure this out.

To give a counter-example, picture a chaotic release planning.  Little considerations have been placed in selecting what features were to go into the next release, except for one rule: cram as many requirements as one could possibly squeeze (all taken from good old backlog, pick from largest estimated features).  There was no collaboration or group discussion between business stake holders but a checklist being sent out via e-mail afterwards, and all manners of chaos and pain followed.  Now back to reality and into the world of product development where this counter-example is not an option – release planning is no result of a random act, as the next release could well make or break your customer’s impression of your software that could either cause them to embrace your software, or leave.

So how do you help your customer figure out which features to have in a single release?  First, let me introduce you to the bucket.

The Bucket Analogy – Your release as a bucket

Imagine for a moment that your release is a bucket.   Now, you have a few bigger stones, a few bunches of pebbles and some sand to fill this bucket up.  The size of the stones and pebbles are relative to the size of features that go into your bucket, your next release.  A bigger stone is a bigger feature with a larger estimate, a pebble a smaller feature, and then you have the bunches of sand that make up the smaller features or tweaks that you know will be great to have, such as delighters that will help make things easier, faster or less painful.

So the goal is to fill the bucket up with the most useful things… no rocket science and straightforward enough, surely?

Prioritisation Tool – How to pick and choose to fill your bucket

Here comes the nitty gritty bit.  You know your bucket is not a bottomless barrel due to budget –  be it money, people, time.  Besides, a bigger bucket would probably not help you release any quicker – that’s a different discussion – the key to this point is figuring out how many, and what stones, pebbles and sand to fill your bucket.  And oh yes, don’t forget that each feature has to give you the most value in the most efficient, timely way.

In an attempt to answer this, I want to first borrow a leaf from a different discipline, Psychology studies.

There are 2 tools to help understand the basic concepts of this idea.  The first tool is the Herzberg hygiene/ motivator theory.  Herzberg says that there are different levels of job satisfaction.  Hygiene factor – having a safe and adequate working environment to carry out work, and the motivation factor – making work enriching for the people.  Apply this to software thinking: we need to make sure that the features in a release will not take away any hygiene factors, otherwise the people who use it will grind to a complete halt and not be able to do their job.  If you had taken away some of the enrichment part, they may not be able to do things quicker or easier, provided you give them workarounds, it will not stop them from completing a certain task.

The second tool is Kano model.  This is a way of helping customers think in terms of building quality.  This tool is the most apparent when applied in product development situations.  Kano model states that product attributes can be mapped to customer satisfaction levels: Basic, Performance and Excitement.  This model can be applied to requirements.  Imagine all requirements can be grouped in the 3 categories: Basic, Performance, Excitement.  You can build quality in a product release by choosing how much to invest in the 3 categories that will make your product meet your users’ most pressing needs.

The most difficult aspect of this is to do a balancing act of judging which features are to stay, and drop which ones in the release.  Which ones we can live without for now, provided that we get it later? You as BA for sure do not have all the answers and insight in this, so this needs to be executed in a workshop or a series of workshops to get you to your goal.  It also pays to verify the assumptions with your business stakeholders and indeed the end users.  Having said that, you are there to help shape their thinking so make sure that they understand every feature they are asking for has justified reasons, financial, strategic… Or perhaps not, in other cases.  Playing devil’s advocate sometimes help, as is re-playing conversations (“Last meeting we got all the stones in place for next release and we have pebbles next”) and key movements (“So last Friday we said we would want X and Y in the next release, and not Z because performance was not a showstopper…”) as pit stops throughout the session.

Whilst we are on the topic, there is also a clarification.  Be careful this is not to be interpreted as the Must have, Should have, Could have (MoSCoW) categories that is so commonly used.  By no means basic maps onto must-have, performance to should-have, and excitement to could-have.  This is because the brutal truth is that not all releases contain all Ms, Ss and Cs – some only have Ms and Ss and Cs never make it to the next drop.  However you need to be aware that all elements of basic, performance and excitement need to be present in a particular release.

Amalgamating 2 brilliant ideas, and turning it into one concept

Herzberg’s two-factor theory teaches us that there are some feature that you just cannot live without.  Kano model tells us what impact each feature would have on that release if you had taken those away.  By first introducing the bucket analogy, a simple conceptual model to imply the need to prioritise, and then combining the 2 theories behind the logic of what to pick and choose, then instil this to your client in order to help them gain the much-needed focus and the courage to prioritise effectively.  Try it, use that in your next release planning exercise.  It’s essentially 2 ideas amalgamated into one.

In a recent project I encountered this situation head-on, and this is how they have adapted the theory into practice and I thought I might share it here as an ending note.  This is what they have done:

Requirements, in the form of stories, are first associated with an estimate and a priority defined by the customer.  In addition to this, a parity field was added.  This field had a reincarnation of Basic, Performance, Excitement terms from the Kano model (known by different names, cannot disclose sadly)…  As soon as the idea of filling a combination of them in a release bucket was presented to the client, it took off almost immediately and each requirement were tagged with this.  Basic was the cornerstones of that release, in other words the hygiene features.  It was so well received that,  each release from then on, it has to have a mix of all basic, performance as well as excitement stories, period.  Thinking back the time at the beginning of the engagement which seems like a different era altogether, when the business stakeholders were adamant that almost everything had to be in the first release(!)  Then, slowly and surely, as the project and our relationship evolved, they have learnt to embrace the theory behind stones, pebbles and sand, and gradually realise that some features could wait until a later release.

XP 2010: Kickstarting an Agile project

My XP2010 session proposal has been accepted!

The session is called Inception Workshop: Kickstarting an Agile project.  It is a workshop-based session to explore the tools used to initiate an Agile project.  This is an opportunity to not just talk about, but actually simulate a range of tools used in the context of a given business problem.  Often times you only get to hear about these tools & techniques, but just hearing about it is not quite the same as seeing it in play.  Aside from sharing what tools could be used, I am also interested in hearing the experience of other Agile projects, and how different teams initiate their projects.

Another different approach to talk about this traditionally analyst-led effort is that I will be co-presenting this session with Danilo Sato.  By looking at this from both an analyst’s and a developer’s point of view, we are able to present this topic from both technical and analytical perspectives.

XP2010 will be held at Trondheim, Norway. More details – for those who have registered at the event, it can be found here http://xp2010.agilealliance.org/node/5380.

What does an Agile analyst do?

At work, every now and then, there would be an email that goes round asking what the definition of a particular role entails, in our company.  Here at ThoughtWorks, this question extends to what this role also means on projects.  It’s all very well understood and defined for developers, architects, project managers alike, but what about analysts?  Recently we were asked to give a definition on such a role, when someone wants to join TW as a business analyst.  What do we say in answer to the question “What does an analyst do in ThoughtWorks?”

How do I describe what it is that I do?  I know I could spot one when I interview one, but how to tell others what definitions or criteria you have been using?  There is no obvious, prescribed way to distinguish what a TW BA “is”.  There’s no rule or precise formula.  Every one is different.  It’s more of an art than the result of a pseudo-scientific definition… but these are the cues:

Listening skills.  There are many, many roles and personalities in a typical TW team who would offer advice / opinion / comments at the drop of a hat, so an analyst sometimes needs to take a complete reverse approach, step back, and listen to what the clients are saying.  This, as well as being a good note-taker (itself a major understatement) would help capture the vast amount of information throughout the project, from inception phases, to delivery, and handover.  People laugh when they hear the comment “BAs need to be good note takers”, and thought that well this is a common sense thing that every one can do well in; actually, it isn’t as simple as that.  Ask any team member what difference it would make if they are at the receiving end of a good set of notes vs. badly written scribbles.  Then ask a team member in a distributed project what difference this would make for them.

Understanding and appreciation of technology, without having the technical know-how as a pre-requisite.  BAs are here to help find ways to solve a problem, here to suggest and give educated judgement based on their previous experience and what their analytical minds tell them.  We need them to take part in discovering with clients what they could achieve, and help map the road for them.  BAs in principle are not there to tell you how easy or difficult it is to implement this feature this way or another.  We have our brilliant developers and technical leads for that.

Ask Why, and ask again.  Are they naturally inquisitive people?  Do they just take information at their face value, without questioning why things are done the way it is now?  We want BAs to not be order takers.  IMHO it’s a soul-destroying road to nowhere and diminishes your entire existence in the project.

Last, but not least, having the raw skills of naturally being comfortable working in any domain.  We do not want to hire analysts who can only flourish in one area, and wish to stick to one sector only.  Particularly in TW projects, for practical reasons, we ask analysts to be as adaptable in as many domains as possible.  From investment banks to trading floors, and media publishing companies to fashion houses, it should pose as no barrier that threatens a BA’s effectiveness.

Stop reading now if you think the role of Agile business analyst starts and ends at writing stories.

In a nutshell, Agile business analyst is not the same as Systems Analyst, Systems Development Analyst, Technical Analyst, and is still different to the Business Analyst you find in traditional software development thinking.  But of course there is so much more than just a name and a title.  As with this post in this blog, it is just the beginning.  In the meantime, what do you think an Agile business analyst does?