AGILE must be destroyed, once and for all

Interesting comment by Tim Anderson on Erik Meijer's outspoken words.

Happy to discuss.

MVP...MMF.... seriously good way to get new software out there, and realising business benefit quickly.

So far, so good. But... I have seen these terms being abused quite severely.

Minimum Viable Product, does not mean, "Cut corners and just get it out as quickly as possible".

It is not "Minimum Quality Product". It is not "Minimum Coding Standards".

It may be the minimum set of features to start delivering business benefit, but there is no point in delivering something that cannot grow, and scale without major rewrites. You want to see if the product is worth further investment, but you won't get that by shipping sh*t as this blog points out. 

Decisions, Decisions...

Had a bit of fun with the team today, playing this game from TastyCupCakes.org.

A group of celebrities are trapped on a sinking ship. The team can only rescue one at a time. They must decide, what order to rescue them in.

It's good fun, and it touches on a number of interesting points about how we prioritise. This applies, not just to sprint planning, but also how we work as individuals.

The team quickly realised that they needed to identify the "must haves", and soon after that, the lowest priorities. The most time was probably spent on the in-between.

In practice, we can get started rescuing the top few, and make a decision later on the middle few once we know a bit more. If that goes well, we might even save a "z lister".

Justin Bieber didn't make it I'm afraid.

Tell me the Problem, Not the Fix

An interesting take from Rick Austin, on providing teams with enough context, so that they can meet the business need. As opposed to Product Owners defining solutions...

"When we create new products or add new capabilities to an existing product, we typically do so in an effort to solve a problem. These product updates may often happen by delivery teams being told to go build these features without a clear understanding of the problem being solved. "

More here: Do you know where you are headed?

Thanks to Kelly Waters for flagging that one

The Myth of Certainty

I've posted before about "uncertainty" as an indicator for estimation. I have also been reading some blogs & tweets on how estimation is pretty useless. Check out #NoEstimates or have a look at Vasco Duarte's blog.

I can certainly sympathise with the views being discussed. People have an overwhelming desire for certainty. It makes us comfortable. But, what does certainty look like? Some of my colleagues, past and present find that only dates and numbers provide that comfort, in as much as they insist on seeing the number of story points for a project up front.

This is pretty useless in reality, as we are pinning our hopes on something that is not particularly reliable. The first thing Ken Schwaber said at my Scrum training back in 2005, was that "estimates are always wrong".
"So", ask the #NoEstimates tweets, "why do we still do estimation?"

If it is certainty that we crave, we should be looking for predictability. Team velocity was one way the Agile community tried to increase predictability, but that wraps an artificial concept (i.e. points)around measuring output. There seems to be some momentum around doing away with story points altogether.

If a team is focused on delivering value, they should always be giving the customer what they need nice and early. Agreeing the MVP or MMF is a good start. Then the team should be breaking down their stories into chunks that they know they can deliver within a predictable time-frame e.g. 1 day. Because they do this, they know that they can deliver, say, 10 stories a week. It is proven, and predictable.

I am going to watch this debate with interest.

Test Early and Test Earlier...

Where does the testing process start? It is quite a change in mindset to get away from the concept of testers as "Defect Police. I've had a good few battles and it can take a long time to alter behaviours.

My mind is drawn to a conversation I had about writing test plans before development started. The QA in question looked shocked. "If the developers know what's going to be tested, they'll just write code to pass those tests. How will I catch them out?" It was then my turn to look shocked.

To me the role of a testing is way broader than catching out software engineers. If anything, they are the guardians of the product. Nothing should adversely affect the product, be that defects, or badly thought out requirements.

We do story analysis "just in time", rather than spending hours in painful and (I would argue) less than effective planning sessions. However, that does not mean that we should rush things.

It is important that we QA the story itself, before we start thinking about how to implement it. Testers have the expertise in finding the cracks. Looking for the edge cases, asking "What if..?". They should be looking at stories and asking the difficult questions, so that Product Owners are confident that their needs are being met, that there is a likely ROI, and developers are getting requirements with clear aims and without ambiguities.

London Lean Kanban Day March 2013 Part 5

I've already spoken to folks about the way Spotify work with teams, but Anders Iversson added a little depth to what I'd already read.
You can download a similar presentation from here.

This then segued in to the keynote speech from David J Anderson.
The talk generally centred around the ideas in this earlier presentation
Not that I like the idea of measuring how Kanban we are, but you could get team members to identify where we are in our journey, and compare notes to see where we need to strengthen.

London Lean Kanban Day March 2013 Part 4

Dan Brown is a bit of a NASA fan, but his talk did help focus on why incremental delivery is a good idea. Imagine if the moon landing was a "Big Bang" release?. Frightening. We need to try things, and we need to fail. Failure at a small level is manageable. Failure at the end of a large project could be catastrophic. This ties in a bit with Dave Snowdens talk on complexity. We need tasks that are "safe to fail", to ensure that we are going in the right direction.

Dan also showed us some maths.

Now, I'm going to take the formulae from here, as everybody knows I'm rubbish at maths.

The team is averaging delivery of about 12 stories per week.

We don't limit WIP seriously enough.

Lead Time is the time between the initiation and delivery of a work item. Currently LT=10.7 days
Cycle Time is the time between two successive deliveries. Currently, CT =0.4 days
Throughput is the rate at which items are passing through the system. Currently TP=2.4 stories a day
WIP – Work in progress; the number of work items in the system. Work that has been started, but not yet completed


And the question is how many stories do we have in progress at any one time?

WIP = Throughput x Average Lead Time
25.68 = 2.4 x 10.7

Therefore, as there is no cap on WIP we are working on 26.68 stories at any one time.

What happens to Lead Time, if I introduce a WIP limit of 4?

Average Lead Time = WIP x Average Cycle Time
Average Lead Time = 4 x 0.4

Therefore, Average Lead Time = 1.6 days

WTF!!!!?????

The formulas used on both solutions are equivalent:

WIP = Throughtput x Lead time
<=>
Lead Time = WIP x Cycle Time

This is an application of Little's Law, which I mentioned in a previous post. As I said, I'm crap at maths, so I'd love someone to have a go at this as well.

London Lean Kanban Day March 2013 Part 3

On a rather less Earth shaking note than Dave Snowden, Pawel Brodzinski has been working on how to use Kanban visualisation to manage programmes. It is a nice concept, and one I will be chatting about with my programme manager. It certainly resonated with me, as sometimes we don't really grasp the whole scope of how projects interact across the organisation.

London Lean Kanban Day March 2013 Part 2

As I settled in to prepare for more on WIP limits and how wonderful we all are because we call ourselves Lean Kanban types, Dave Snowden woke me up. Now, I had heard of Cognitive Edge, but I didn't know what it was about. Frankly, I still don't. Dave is a chap who will happily walk into the Pentagon (Therefore think what he's like in front of a bunch of wimpy geeks) and tell them that they know nothing and their thinking is completely wrong. Throw away all your cards and stickies. They won't help you because, by the time you have your stickies on the board, you've probably made your mind up about requirements, and you're probably wrong. I'm really not qualified to rabbit on about what he said, so here's his blog post on the talk.

London Lean Kanban Day March 2013 Part 1

Well, it makes a change for me to get out and listen to the great and the good of the Lean thinking world. The first Lean Kanban day in London, provided me with a good opportunity. The line up was impressive, and I have to say I enjoyed the speakers and came away with some renewed vigour. I will endeavour to cover the main points I found interesting in these posts. I'm going to to a post per speaker, and then maybe do a round up. That said, I may well change my mind half way through! First up was Mike Burrows with a general take on getting started with Kanban. This was the start of the "Big Thing" that I would be taking away. Understanding queuing, and the affect this has on our throughput. Whilst I have paid "lip-service" to WIP Limits, I have to say, I have struggled to convince people of the effectiveness. Perhaps that's because I hadn't been convinced enough to stick firmly to them, and therefore haven't been effective in convincing others. Mike referred to Little's Law. Sorry it's a link to Wikipedia, but it's a place to start. Now, I haven't read up on this fully yet, but there seems to be some mathematical truth kicking about here. I've had WIP limits demonstrated by playing manufacturing games, but that isn't software development. However, there were some other arguments in store for me. Slides are here

Story sizing and the "Uncertainty Principle"

I often have conversations with Teams about sizing, and more and more, I come back to uncertainty being perhaps the most important gauge for sizing. We use Fibonacci numbers, and when asked by people, "How do I size a story?", I go something like this... 1 - is the smallest size, and a 1 story has the characteristics of being quick to implement as there isn’t much coding involved AND we are certain about what needs changing and the impact. 2 - may need more work, but it is still well understood and we are still certain about what needs changing and the impact. 3 - we are introducing some uncertainty. We pretty much know what to do, and we know it’ll take a few days, but there is a greater risk of unknown factors impacting the work. 5 - we have a fair idea what to do, but we are likely to uncover some problems and so we are not certain about completing within a few days. 8 - there is a lot of uncertainty. It may well be best to create a “spike” story to work out what needs doing, and break in to smaller stories when we know more. Yes, we can add in other factors, and as teams become more experienced, they bring in more subtlety, but this seems a good starting point.

No Sh*t Sherlock...

I'm well behind this piece by Simon Baker #ewnobull http://nobull.energizedwork.com/ It is spot on in a number of ways, or at least it chimes with my own experience and observations over the last decade. There is a lot of "Agile" being practised, and not enough agile thinking. Well worth a read. Thanks to Marta Jasinska for showing me this.

Over Committed to Commitment

Interesting post by Yuval Yeret http://yuvalyeret.com/2011/10/13/scrum-sprint-commitment-rant/

There's a lot in there, but what resonates with me is the danger in commitment becoming at best a "comfort blanket" for product owners, at worst a stick to beat teams with.

Developers seem to be a willing bunch, and often (in my experience) are too eager to please. Now that shouldn't be a bad thing, but it is when you commit to something that you cannot deliver. It easy to skip over the risks in any piece of development work when estimating, and risk is a very hard sell to the business. "Why are you asking me to invest in anticipating problems that might not occur?". Tricky one that.
So, we settle on the "Best Case" scenario as the likeliest outcome. Inevitably, the team will soon be trapped on the "Hamster Wheel of Death", never able to meet the "commitment".

What really matters to me is prioritisation. What gives the business most value, and how can the team best use their resources to ensure swift delivery of that value?

Rather than committing to a fixed number of points, commit to delivering the highest priority item as quickly as possible. Then do the same for the next item. Focus on rapid and continuous delivery of value, and you will feel the love.

Putting the agility back in Agile

Ok, I don't get around to writing much here, but I have been on a bit of a journey. Having been working with Scrum for many years, I have, over the last 18 months or so, begun to question it's effectiveness. No, let's re-phrase ... Scrum IS effective. It will (if done anything near properly, which isn't usually the case I'm afraid)surface the issues that you have with delivering software. Whether you choose to do anything about those issues seems to be optional with many teams, which makes the exercise a bit pointless. This is the where many then start complaining that Scrum doesn't work.

Scrum does work. It will get you from delivering sod all, to delivering something. That is an achievement, so don't knock it!
However, it is possible to deliver more, and that is where you begin to run in to it's limitations.

What if I want to deliver more often than every 2-4 weeks?

What if my business priorities change weekly or daily?

What if I am spending too long in planning sessions?


Dan North gave a talk which captured many of the reservations I've been having, and offered some possibilities. Have a look and listen.

http://vimeo.com/channels/rootsconf#24681032

Heads up!

Wow, it's been a while, but I finally have a bit of time to get back to this stuttering attempt at blogging.

Something that I have come across with teams and maybe others have experience of this, is the need for teams to make sure that they are aware of where they are in terms of the sprint.

Scrum, for example has the basic mechanisms for informing us how we are progressing. The burndown should be on a nice angle downwards, and our stand up questions should indicate if anyone is having issues. But does the team, as a whole, have a good feel for how the sprint is panning out?

I ask this because as an ex-developer, I know how easy it is to immerse oneself in the coding and become a little island.

One thing I like to do is get the team to take a step back and take a good look at the the Scrum board. After a stand up, once you're in to the sprint (but not so it's too late to fix things!) have a look at where the cards are. Do things look ok? Are the top priority items getting done? Will there be time to test and fix?

If not, the team can think about how to deal with things. Maybe switching themselves around a bit to help with blockages.

Now - before you tell me this should automatically happen with the stand ups etc, what I find is that you can sometimes surface things that the 3 question format may have missed.

I also like to remind everyone to lift their heads up occasionally and see how evryone else is doing.

Agile development should be collaborative, but sometimes, as individuals, we drift in to isolation. All I am saying is that it doesn't do any harm to say, "heads up!" now and then.

Scrum doesn't work with fixed cost projects!

I have heard many project managers say "Scrum doesn't work with fixed cost projects!" when discussing approaches to software delivery.

I have pondered this and found that it is a difficult issue to solve.

My current thinking, is that the statement is kind of true.

But before you all jump up and down and protest... I think that the statement is true (in a way), but perhaps the "fixed cost" bit is actually what is wrong. Not Scrum.

Why do projects have to have a fixed cost? In order to "fix" cost, you have to estimate the project down to the finest detail up front. Trouble is, such estimates are always wrong. So you will end up either running over budget, or working late for free, or reducing functionality, or even quality.

So why insist on a fixed price? Why not get a clear set of high level goals, with an approximate release plan, with milestones as guides.

Get a rough cost, and release funding in small chunks, re-assessing at every milestone. You can react to changes in scope & requirements with out storing it all up and fighting the fire at the end of the project.

Am I being too simplistic?

Tools?

Someone has recently posted a question on a Scrum forum, asking about the best software tools to enable the use of Scrum. Ok, they have some issues with remote teams, but they kind of missed the point.

Fortunately, plenty of subscribers have replied with the basic recommendations:
Index Cards (lots)
Post-its
A whiteboard (but a wall will do)
and, if you like the finer things in life, a spreadsheet for generating the burn down graph.

That's what I like about Scrum. It's about doing the simple things (A.K.A "the bleeding obvious") well.

That's not to say I don't like tools though.
I have been trialling some pretty heavy duty tools, and I like them. As a company, we build on a Microsoft platform, and Microsoft have something call Team Foundation Server. It's a pretty nice collaborative development tool that can be used for source control and work item tracking. What's even nicer, is that lots of people are developing tools that sit on top of TFS, that provide templates for managing Scrum. My favourite tool is a "virtual whiteboard" with "virtual cards" that we can move across as we progress. We like this tool so much, we are even considering ditching the physical whiteboard.

But the really important thing is, that we can do this ONLY because we know our process works. The software doesn't make us good at Scrum. It just saves trees and allows us to keep all our information in one place.

The trouble with really neat tools, is that they can easily distract us from the really important thing, which is the process underneath. Don't buy a tool because the packet says that it will cure all your ills. It won't. But if your existing processes are sound, then by all means get something that saves you a bit of time.

Be warned!

Yes, we have no designers (or information architects)

Well, this is the first post on this blog. I did have another one, but I had so little to say, I forgot where it is.

Anyway, I have some thoughts which are bugging me, so I decided to write them down.

I work with a couple of web development teams, and we're 'doing' Scrum and talking all "Agile" and stuff, and it's working pretty well. But we have some new work coming up and something is bugging me.

We're starting on web site redesigns, 'spivving up' old features, adding new ones, improving the user experience, making it look nice and shiny.

Great. So what are we going to do?

Let's call the creative department! Excellent. A good bunch of designers listen to the product owners ("Can you make it more sexy?"), and come up with some lovely visuals. A bit of tweaking goes on, and 3 weeks later a bunch of image files land on the development team's desk.

That's cool, but what have the development team been doing for the last 3 weeks? Well, the deadline for this is quite tight, so they've had to start developing. Database tweaks, new business logic, some nifty new web services.

Hmmm. What's going to happen?

Well the visuals look great, "sexy" even. But we have an issue. The website publishes articles about, let's say, chemicals. Those chemical names are really long, with no spaces. They won't fit in the column. There's a lot of content on this homepage. It'll be really slow. Is that what you want?
When you click that button you are taken to the next page. It looks kind of confusing. I'm not sure I want to be on this page. And my web service certainly won't do that!

Let's call the creative department!

3 weeks later...



There's a few issues here.

The designers are really good, but they are isolated from the product, the users, and crucially to this process, the people building the product.

We're doing too much design "up front". This smells like WATERFALL, we're supposed to be "Agile".

And we're being given a 2-dimensional view of the future. Who's modelling the behaviour of the site? I'm not sure that it should be the product manager.

And how do we know if this is what the user wants?

I don't know if we should go all UCD, but I have worked with teams which had a slightly different make up and avoided some of the mini-niagra issues, and went some way towards thinking about the user.

Typically they would consist of "front-end" developers, "back-end" developers (but a good all-rounder will do), a designer (or a percentage of one) and an "Information Architect" (a what?). I even managed to get a "user" embedded in a team once!

The Information Architect would think about how the system should behave, model the work-flows, data and even organise user-testing. Very useful, but I think we could get by without if we had a DESIGNER.

If we had a designer working with a developer to create quick prototypes, we could find these problems and fix them quickly. We could demo something tangible to product owners and get immediate feedback. Hey, we could even get some users in!

In the 3 weeks it takes to produce some glorious photoshop mock-ups, we could have a whizzy clickable prototype to get any product owner moist.

We're supposed to have multi-disciplinary teams, so... can I borrow a designer for a bit?

I promise I won't mistreat them.