Why is Agile adoption fraught with danger?

Why is Agile adoption fraught with danger?

Or more specifically, why does Agile seem to get a poor name in the larger corporations?

Well I have been privy to a number of Agile methodology proposal forms, for the large bank where I am currently contracted. These are documents which have been produced by large corporations and well known Agile specialists outlining a plan to introduce either Agile itself or a more Agile way of working.

The proposers themselves have been given a significant amount of time to size up the business needs, and deliver their plan of how to introduce Agile.

Interestingly I read something which was based around the values of the “Agile Manifesto” in only about half of these proposals. Not one of them mentions the obvious flaw in the concept of waterfall and how that could be used to persuade people to change; how it was used as an example of an anti-pattern yet people liked the diagram, it made sense so they implemented it! (have a read here: http://www.interaction-design.org/references/authors/winston_w__royce.html)

What I found most interesting was not proposals that looked like they could work, but in fact the ones that were not really based on the “Agile values” at all! For me it was a great insight into peoples’ concept of Agile, when really they had no idea. The documentation from a distance looked vaguely Agile, seemed to use the right words, full of catch phrases and truisms. (How many people have heard “Evolution not Revolution”?). But probing a bit deeper and looking at their statements in context you can clearly see its all middle management tripe. Bringing in a large number of governing boards and committees to somehow measure process with heavyweight monitoring. Sound familiar?

Sometimes they have tricky catchphrases that sound good, but the process seems to strive to fit around making the word work rather than delivering working software and increasing visibility to the stakeholders. In fact it seemed that a management consultancy had just taken a cut and paste approach in some places and also did a find and replace on key words such as replacing “waterfall” with “agile”, “governance” with “monitoring” etc..

What is also an obvious giveaway is when that stop focusing on the individual and talk about them as resources. e.g. Our systems processed over 1500 resources last year…. as opposed to – last year alone we educated over 1500 people in the principles, values and behaviours of Agile.

Is it any surprise that some companies fail to find Agile success when there are so many “wolves in sheep’s clothing” out there? Instead they find something that looks like Agile, and is pretty dead, they strive with it, and eventually reject it. When the real deal comes along bearing Agile slogans and promises they offhandedly reject it. “We’ve tried Agile before and it didn’t work” – they say.

Sounds a bit like an inoculum to me. I wonder how many corporations are out there, inoculated against “Agile”.

Posted in agile adpotion | Leave a comment

The power of the phone camera

The power of the phone camera

Whats the quickest way of recording data? Write it down? Take a recording?
A printout of a whiteboard? (We’ve all seen those, and if you haven’t they look poor at best).

This is where the humble camera comes in. Yes you could could purchase a digital one and it would be very good, but even the humble phone camera is averaging over 4-5 megapixels these days, easily enough to take a picture. Even the iPhone 3GS’s 3.5 megapixel camera would be enough. (Finally the iPhone 4 has caught up a bit with its latest offering at 5 megapixels). The good news about the phone camera is everyone has one on them, so you can take a pic and email it, or synch it with your pic (make it act as an external hard drive) and WHAM your pics are there for all to see.

This is exceptionally good for recording the board status and sharing it on the wiki for distributed teams.

Point 6 (above) 🙂

In fact here is a list of them, feel free to comment and add your own ideas as I am sure I am just scratching the surface:

  1. Recording Story Board statuses
  2. Recording retrospective board
  3. Taking pics of teammates so you know what they look like (distributed teams)
  4. Recording the results of breakout sessions
  5. Taking ad-hoc pictures of design drawings (if they are still useful)
  6. Taking random desk pictures of coffee 😉

Meaning you help on communication, recording data, and if you take daily pictures of your board you can have a flickbook of progress that tells a story that other burndown charts can never do. When showing them back to people it can really spark memories of what happened which can help in retrospectives.

Posted in feedback, recording, retrospectives | Leave a comment

Agile Requirements by Collaboration

I recently attended the “Agile Requirements by Collaboration” presentation at Skills Matter lead by Ellen Gottesdiener from EBG Consulting. Here are some of the main points I got from it.

Ellen described how collaboration needs to happen on several different levels of granularity along the way requirements are viewed on agile projects – the product (which establishes the product or portfolio roadmap), the release and the iteration (or work in progress),  Exploring these views can occur in several different facilitated workshops, from the roadmap workshop, to the release workshop to iteration workshops. The corresponding requirements that are clarified or driven out from these workshops also appear on different levels – boulder, rock and pebble.

The idea is that the pebbles form your user stories and are driven out at the level of the iteration workshop. Projects can encounter rock sized requirements at the iteration level and suffer a time delay as new pebble requirements are chipped off from them. This brings to question the level of “doneness” for a user story.

tamp down those requirements!

Tamp down those requirements!

Agile planning involves a technique called rolling wave planning; this is a form of progressive requirements elaboration.

Why progressive requirements elaboration? Well – (as Ellen pointed out) have you ever run a project where you knew all of the requirements from the start, and that they didn’t change? No? Well this is where progressive requirements elaboration (and responding to change) helps.

Ellen went on to describe how to elicit value out of workshops by using the 6 P’s.

  1. Purpose (why are we having this meeting – short and concise, resonates with the stakeholders)
  2. Participants (key decision makers and involved people)
  3. Principles (guidelines for participation owned by the group but led by the facilitator)
  4. Products (outcomes of the workshop)
  5. Place (where you are having the meeting)
  6. Process (resulting in the agenda; one tip: how key stakeholder(s) kick-off the session and then return at the end with a show-and-tell summary)

A few of the other valuable one liners I got from that session included:

  • everyone on the team needs to think like a product owner
  • a stable team is key (done a few iterations, everyone knows each other’s strengths)
  • Workshops should contain the 6Ps (see above)
  • Problem space overlaps solution space, so you need to iterate and spike!
  • Tamping down requirements (or Doneness of a user story (see pic above)).
  • Cone of uncertainty, can be reduced by breaking it down into smaller cones. (see pic below)
  • Don’t be afraid of using both left and right brained processes to solve problems (using physical props etc.)
  • Collaboration is the engine of team value!
cone of uncertainity

The “Cone of Uncertainty” (first described by Software Engineering guru Barry Boehm) shows that our estimates at the start of a project are way off, but get better as development proceeds through time. As Ellen pointed out, in agile, we do many short development and delivery cycles over time, allowing us to improve our estimating each cycle and thereby decrease the delta between estimate and actual.

Afterwards we went to the pub and discussed Agiley things. Good fun and useful, in fact to quote a fellow Agileer “You don’t come away knowing less do you?”

All good, except for on the way home I chipped a tooth, but that’s a different story….

More resources:

Agile Requirements by Collaboration: Making Smart Choices about What and When to Build by Ellen Gottesdiener
Amplifying Collaboration with Guerilla Facilitation by Ellen Gottesdiener
Requirements by Collaboration: Workshops for Defining Needs by Ellen Gottesdiener
Numerous article on Ellen’s company website in the categories of agile and facilitated workshops and requirements.
Ellen’s blog

Posted in Agile Estimation and Planning, Agile Requirements, skillsmatter | 2 Comments

Cappuccino

Lots of literature on the Internet about cappuccino.  When I say cappuccino I am not talking about that powered frothy stuff that you get out of a packet that puts a bubbly colloid on the top of some boiled water with instant freeze-dried coffee in. Ask any good coder about coffee and you will have an interesting discussion.  Ok it might not be that straightforward but anyhow, most people have an opinion on Starbucks, Costas, Nero, Coffee Republic, their own machine (Ben) my own machine (Me).

fantastic crema from internetz

So which is best? Well actually the answer is “it depends”.  It depends on who is serving, the state of the machine and whether they are in a hurry.

  1. Who is serving – I have had better coffees off some people (consistently) than others, hence technique plays an important role
  2. Are they in a hurry – Even off my favourite servers, there is some inconsistency, if they are rushed or not paying attention my coffee quality will suffer, that’s not acceptable to me
  3. Is the machine in good order, currently my nice Gaggia Classic has been under-performing, even Ben’s machine is producing better coffee, – time to roll on the tartaric acid descaler.

Q. Erm excuse me whats this got to do about software delivery?

Well actually not a lot, I just like coffee! ……………. Except!

Comparing it with developing software for one moment.

  1. Some developers use better techniques than others
  2. Even the best developers will produce bad quality code if they are under pressure or overworked
  3. Sometimes you need to maintain and revisit the way you do things to keep your “axe sharpened”

Well how do you get from the problems to the solutions or something better?

Feedback!

Regular feedback will help teams improve.  The feedback has to involve customer contribution. i.e. the person drinking the coffee/ using the code.  With valuable feedback you get great coffee/code because

  1. The “best” can train others
  2. You can shield your workers from the pressures by using a better system – check out http://leansoftwareengineering.com/2008/05/21/coffee-cup-kanban/ for a Kanban reference, read the comments too some valid points there.
  3. When you compare with others in the field sometimes its a good benchmark, this also provides feedback for action (from de-scaling the machine to refactoring code or processes)

Ps. If I can, I always talk to the baristas, then I can gently introduce feedback as how I like my coffee, they want me back so they oblige.  eg. I like my cappuccino really frothy, and I don’t like a lid on the top it ruins the “head” for me.

pps. What makes the perfect Cappuccino? You are only going to find out from feedback from satisfied customers. Like with Agile, you don’t follow a set of rules, you follow a framework which involves testing (and tasting) the end result and adapting.

Posted in coffee, feedback, kanban | 1 Comment

Agile Estimation and Planning

Went to Martine Devos’ seminar on Agile Estimation and Planning last night and as always she was excellent.
For me it was not that the subject matter was new because I had heard it previously when she took us through our Scrum Master certification course,
but sometimes you need to hear things more than once, and when you come back to it you see it in a new light.

It also keeps the axe sharpened!

Some useful things I observed, which were a nice refresher:

1) You can estimate in multiple places, during the day, the sprint, the release and the portfolio ( for larger corporations)
2) You can align Story Points with a budget in a corporation by first talking about Relative Points (sounds easier on the corporate ear) and having some history
of velocity.  Then you can use “yesterdays news” to plan out what will be delivered in a sprint. This will allow Product Owners to estimate based on velocity.
3) The most important story, will have the most detail available as its on the Product Owner’s mind.
Other stories will not have as much detail so beware false precision with that, and you can use the Fibonacci styled sequence to help you.
4) The Fibonacci styled sequence will add buffer for you, 1,2,3,5,8,13,20,30,50…. but when  you get to the larger numbers forget the “odd number” eg. 21 as that can give the impression of false accuracy again.
5) The highest priority user story may have some low priority details that can be rescheduled
6) A good way to break down MSC out of MoSCoW, is that Must = delays to project if not done, Should = no bonus if not done, Could = a competitive advantage is lost if not done.

All good stuff!

Posted in Agile Estimation and Planning, skillsmatter | Leave a comment

Agile, is it just a set of rules? part 2.., a tale of Yorkshire Puddings..

“So Rob” you say… “if its not a set of rules, then where do the rule come in?”

“Ah ha” – I respond, well the rules come in at the beginning….  Check out the Dreyfus model of skill acquisition.  (http://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition).  Here you will see that people are at different levels of competence at different things.  In order to learn and gain competence you start off as a novice.  Novices must first start with the rules… quoting Wikipedia here exactly..:

“In the novice stage, a person follows rules as given, without context, with no sense of responsibility beyond following the rules exactly. Competence develops when the individual develops organizing principles to quickly access the particular rules that are relevant to the specific task at hand; hence, competence is characterized by active decision making in choosing a course of action. Proficiency is shown by individuals who develop intuition to guide their decisions and devise their own rules to formulate plans. The progression is thus from rigid adherence to rules to an intuitive mode of reasoning based on tacit knowledge”

Yorkshire Puddings!

This might further be explained by Yorkshire puddings.

Or rather how to make them.  We in England all love Yorkshire puddings.  But how do you make them? Simple just google a recipe from the BBC recipe website (http://www.bbc.co.uk/food/recipes/search?keywords=yorkshire+pudding&chefs[]=&programmes[]=) the problem is that currently there are 35 recipes for yorkshire puddings. All of them are relatively different, and few if any really talk in depth about the technique of making them.

There you have it, the paradox of choice with recipes, the temptation is to say some work and some don’t after you have tried some.  The real answer lies in understanding that each recipe was created in a context, and depending on a series of circumstances (ie. how naturally gifted a cook you are, your cooking style, how good your oven is, the regional quality of ingredients etc…)  some of these will work for you and some wont.  Not only that but you will find that after picking a favourite recipe, you will probably modify it yourself to your personal preference, perhaps you want a little mustard in the mix, or you might want them fluffier or cooked more etc…..

so what do the Yorkshire puddings tell us?

If you think my Yorkshire puddings talk to me, they don’t.  However the example of the Yorkshire puddings does tell us that we are not to take rules as values, and what works for some wont work for others, it doesn’t make it wrong, it just makes not not applicable to you at this moment, but it also could be “not for you… YET”.  Some Agile ideas that don’t work in one company will work in others and vice versa, but as long as they are supporting the Agile values which should be at the heart of the framework then that’s ok.

Posted in Core Agile | Leave a comment

Agile, is it just a set of rules? Part 1 the danger of the rulebook

Part of being an Agile coach is that persuasion and communication is key.
But is it as simple as a set of rules? Well….. no.

You could argue it is by saying, Agile is having:

  1. Stand ups at 9.45 am
  2. Weekly or Iteration retrospectives
  3. Continuous integration
  4. A story board with a backlog
  5. User stories making their way across from ToDo to In Progress to Done
  6. Automated test builds
  7. Pair Programming
  8. etc…

Do all of these and then you are Agile.

Except thats not the case. Yes all of those are important aspects of Agile, and you could use them in measuring “Agile-ness” except for one thing.  They are the fruit of Agile, not the root of Agile.  You cannot take the fruit of Agile, write it down into some sort of cook book and expect another team to automatically follow the rules and become “Agile”.

The danger of the rulebook

After a while some people will get a little frustrated at some of the rules and ditch them.  For example, some personalities are not well suited to paired programming.  Or you might have inherited a monolithic piece of work where there are no unit tests available, and automated test builds is out of the question, after all the business want you to build new software not spend their money on something that’s already live and working ok!

So for whatever reason some of the rules wont work for them, so they will then say, these rules don’t work for us, therefore Agile doesn’t really work for us.  Therefore Agile doesn’t work.

Agile as a framework

The answer is subtly different from that.  Agile is a framework rather than a set of rules.  Looking at the Agile manifesto you will see that there are 4 main values (http://www.agilemanifesto.org/), supported by 12 principles  (http://www.agilemanifesto.org/principles.html).  Out of the values (the root) you could get the 12 principles (branches leaves and eventually fruit).  You must remember though that these are values and not rules.

Let me put it another way, Ken Schwaber describes scrum as a game of chess (http://kenschwaber.wordpress.com/2010/09/08/scrum-as-a-framework/) I like to think that its like a large toolbox, there are lots of different ways and different options available to achieve the same goal.

If its not a set of rules then what is it?

Its quite simply a set of values. You can illustrate these values with examples, methods and …wait for it…. rules… I’ll explain in part 2…..

Posted in Core Agile | 1 Comment

Agile Decisions…

When I became “Agile” the first thing that changed about how I approached my software development was my daily decision making.  Rather than following a set of rules or going on an “Agile” course or directly following a book I began to ask myself some questions. Different questions every time, but they followed this broad flavour:

  1. Is what I am doing now going to generate feedback?
  2. Is what I am doing now going to be visible?
  3. Can I easily explain it to someone
  4. Can I get it done in a short period of time

Points 1) and 2) are the most pertinent here and I will briefly explain below:

1) Is what I am doing now going to generate feedback?

Yes? Great! do it. If you get feedback on it then you know straight away whether its good or not.  (Remember that feedback without conversation is just criticism). If “No” then you need to ask yourself whether its worth doing.  Are you commenting code that will never be read? Are you doing something that will never be noticed?  If its an important piece of code that only you can write, consider telling someone about it; code written by only one person is more likely to be bug ridden and a “problem sticking point” than code that has been viewed by more than one person.  Even if they are not an expert or a fan of pair programming its a good idea to talk someone through the code! Firstly it forces you to re-read the code, talk about the code, hear yourself talking about the code and ALSO your peer might be able to see improvements that can be made in the code.

2) Is what I am doing now going to be visible?

Agile is all about visibility, how are you monitoring your progress? If the piece of work you are doing not going to be seen why are you doing it? This overlaps somewhat with point 1 above.  However, visibility allows for accountability.  Accountability allows for priority.

This is where you must be thinking of how your time (ideal hours or points) is being spent on the project.  If what you are considering doing now cant be accounted for as something that is visible then ask yourself why are you doing it?  There are two broad areas of accountability you can involve yourself in

  • Project based (time spent on user stories)
  • Learning based (time spent on learning)

Anything else.. its just personal admin (or Foosball).

How do you make yours ?

Posted in Core Agile | Leave a comment