# Monday, 29 April 2013

I've often heard Agilists referred to as Evangelists, and it's always rankled with me. Lately I've been wondering why that is, and this is what I came up with. 

It's hard to talk about Evangelism without touching on religion, which is often an emotive subject. Nothing in this post is intended to offend anyone's beliefs of any kind, but rather based on bare facts as recorded in history. If I have managed to offend you, I apologise, it was not my intent.

Lets study evangelism. I've looked it up from several sources and what I understand it to mean is:

Evangelism: the act of spreading the word about a religion (usually but not always Christianity) with a view to converting people from other religions. 

So in other words, Agile Evangelists are seen as people who are trying to move other people from their old beliefs into the 'new' religion of 'Agile'.

Evangelist

Why would I object to that? Let me count the ways:

1) Religions by definition are based on faith in a set of beliefs which cannot be otherwise proven scientifically or empirically. Agile is a set of practices and patterns which have an empirical basis. We can prove our beliefs using scientific method to show they do work, and how they work.  For example, if we are talking about the agile practice of 'Limiting WIP' I can use games to show you how it works, then show you the maths to prove why it works. 

2) Evangelism is a religious word implying we are somehow religious fanatics challenging people's existing beliefs. I've never yet seen someone fight to convert people to agile. If we try, then in effect all we manage to do is to polarise the beliefs  of the person we are trying to convoke, and make it harder for them to understand.

3) We are coming in straight at the belief barrier. I would suggest you go read / listen / tweet / converse with Benjamin Mitchell about 'double loop learning' and 'the ladder of inference'. Even if you don't, it's simple for us all to understand that if we say "The thing you believe in is wrong, this however, is the right belief" that you are going to have a lot of work on your hands to convert someone. 

4) We are assuming that Agile is the only game in town that works. That is clearly wrong or the IT business would have died a long time ago. Waterfall can work. Agile can fail. I would suggest that if you look into it, the projects with the best implementation of the chosen Methodology or framework are the ones most likely to succeed, and the ones with poor implementations are the ones most likely to fail.That said, emergence and dumb luck are also factors.

I would say that having run projects both ways, a good agile implementation is better suited to emergence than a waterfall one, and therefore less likely to fail, but I honestly believe that a good waterfall implementation has less chance of failure than a bad agile implementation. I don't have the data to back that statement up and it would take a piece of work to long for me to undertake to go through enough suitable case studies to back that up.

I also think it's important we talk in terms of failure rather than success in that statement, just because something succeeds, it doesn't mean that thing was less likely to fail along the way. Just occasionally a lower league team wins the FA Cup. It's far more likely that one of the big premiership teams would win, but just occasionally it happens anyway. 

What's the alternative to Evangelism? 

As an astronomer I am led to think of Galileo Galilei. He was the guy who made the case for Heliocentrism, which isn't quite as catchy as Agile as a title, but  is the astronomical model with the Sun at the centre of the solar system, and was far more contentious at the time. We know this to be true today, and we'd probably mock people who believed in the old models like Ptolemaic system where the planets and sun orbited the earth.

Galileo didn't come up with the idea for Heliocentrism, far from it, it was proposed thousands of years earlier, but no-one could prove it one way or another. Even a hundred years before Galileo, Copernicus presented a heliocentric system, but again couldn't prove it.

Nicolaus Copernicus Heliocentric Solar System

Galileo got the data. Galileo improved telescope design and was able to observe the moons of Jupiter and Saturn, and crucially record their phases. To this day, the four largest moons of jupiter are referred to as the Galilean moons, and can be seen with a standard pair of 10x50 binoculars on a clear night.

Why does this matter? He used scientific method. Tycho, Copernicus et al were correct in their hypothesis, but couldn't devise an experiment that could be run at the time to prove or disprove the hypothesis.

Scientific method is to: a) have a hypothesis or idea; b) devise a set of experiments to test the hypothesis; c) run the experiments and gather empirical data to show the validity of the hypothesis; d) accept the results which ever way they go. 

Galileo had the equipment to prove the Ptolemaic model was wrong, and that heliocentric models were correct, so he ran them and published his results. 

Hang on a minute wasn't Galileo vilified? 

Yes he was. He had the facts that showed the truth in what he said, BUT he was going head on with the core beliefs of the current Pope. The inquisition was sent round, and he was instructed to recant or be excommunicated. He was subject to a papal decree that he was not to teach Heliocentrism again. 

He took on the accepted general beliefs with real data, and still didn't win. In modern parlance, he built it, but they did NOT come. We need to learn from this too. Proof is not enough!  In a recent engagement the CIO told me, "Don't tell me about Pairing. I've seen all the 'proofs' and the 'data', I just don't believe it's more efficient to waste time having 2 guys doing one guy's job." Proof didn't counter his beliefs, and he told me that all agilists are evangelists! Thinking back, that is probably the origin of this blog post… 

What should we do instead. 

Get the data, and talk from a position where we are dealing in scientifically proven facts. It's really important that you don't only believe what you are saying, but that you can prove it. Even then, it takes more than proof is not enough. People put a lot of time and effort into their beliefs, and often don't want to hear that they might be wrong. 

Remember who you are talking to, and ask yourself how they got there. If you're talking to a senior programme manager or higher, the chances are they were a good project manager in the past using PMP, Prince or something similar, and ran successful projects. They already know what works, they did it to get where they are. Telling them waterfall doesn't work is not only factually wrong, it is something they intrinsically know to be wrong because it was what they did themselves. You just threw away all of your credibility. Do not pass go, do not collect £200. 

How do we convince them? We talk about common outcomes. Work with them about trying to get to a common place where we can do things better. Don't take them on head on, even with the truth on your side. Being right didn't help Galileo much at the time, did it? I've never heard about a project that didn't want early and frequent delivery, the ability to change quickly as needs change without wasting project money on the things you will never build. They are talking to you because they know something is up, so help them understand how things can be better and have more chance of success. 

Always make it clear when we are talking about our beliefs rather than something we can prove. We need to be honest and open if we want to gain trust. And if you can't prove it, ask yourself why you can't, and either get the data to back yourself up, or consider stopping saying it.  Remember what I said about a good waterfall implementation being less likely to fail than a bad agile one… well I never said this stuff was easy did I?

Come on people let's stop evangelising and start educating!

 

 

 

 



.
Tags: Agile | Kanban | WIP

Monday, 29 April 2013 17:40:58 (GMT Daylight Time, UTC+01:00)  #   


# Wednesday, 10 April 2013

A common thing I hear in new agile adoptions is the concept of making the team Cross Functional. That is, the team should have all of the skills necessary to complete the work being undertaken. 

However, what I then often see is a desire to make the individuals within the team cross functional, rather than the team. In effect, the organisation seems to be looking for a team made up of Cross Functional People. I think that this is just plain wrong. Let me tell you why...

Lets pretend we have a team made up of 3 disciplines. QA, Dev and DBE (database engineers). A bit like this

Venn1

I've intentionally intersected the skill sets in this Venn Diagram as this how people are, we like to pigeon hole them into one thing, but in reality we know  a lot about our area of expertise plus a bit about other areas. Assuming you only need these three skillets to deliver your work, the above Venn Diagram represents a cross functional team. 

The problem I am blogging about is the tendency to try to move people from each specialism, into the middle of the diagram where all 3 skill-sets are intersecting.

Venn2

But why not?

If you are unaware of the work of Dan Pink, may I take this opportunity to point you in his direction - watch this 10 minute video 

If you watched it, you will now understand a little about Motivation - and the key drivers of Autonomy, Purpose and Mastery

How do you think it will affect the motivation of a DBE Expert to be told that their expertise is no longer valued and instead we want them to become a cross functional generalist who is just as good at all things? Ever heard the phrase "Jack of all trades, master of none"? You are effectively destroying their Mastery driver. Hands up if you want to actively sabotage your team members' motivation and have them be less performant... 

So what should we do with our specialists?

Let me hazard a guess that you are already thinking something about annual (half yearly, quarterly) objectives in the back of your mind here. If so - go watch the Dan Pink video again and chastise yourself.

One of the key principles in Kanban is to "Respect the current process, roles, responsibilities & titles" (see David Anderson's blog post here)

We should be trying to work on our individual areas of intersection, while still respecting each team member's core expertise. In effect anchor your team members in their core domain of expertise, then look for natural opportunities to increase their areas of overlap into the other disciplines as appropriate.  We should do this in a continuous evolutionary manner, rather than try to revolutionise the way each individual works. Why would we have the QA specialist pull the Work Item that is very heavy on DB work, and pair on it with a regular Developer, while the DBE is forming test cases with another developer. Surely we should have the DBE pairing with someone from another discipline, say a QA, on that Work Item. In that way we are making best use of our expertise to finish the work item, and allowing the DBE to flex his DB mastery while expanding the knowledge of the QA into the DB area while still having them come at the work from the QA perspective and flex their QA mastery muscles. 

Venn3

This way you are actually feeding their mastery motivator as you are allowing team members to grow their area of mastery, without giving anything up. They still get addressed as the expert in their field, but are able to meet their Purpose driver by being more able to work with and understand the needs and views of the rest of the team. A subtle difference, but one that can make a whole world of difference to the individual team members. In the end, its what the team is able to deliver that matters, so helping the individuals in the team to work better seems like a good idea. 

 



.
Tags: Agile | Kanban | Lean

Wednesday, 10 April 2013 11:00:22 (GMT Daylight Time, UTC+01:00)  #   


# Wednesday, 27 February 2013

If you know me, you'll know I'm a fan of both Scrum and Kanban, and get irritated by those who see them as opposing forces. So this post is definitely not me having a pop at scrum. However I do have a problem with the term "Sprint". You'll also know I love a good metaphor. 

As dev teams we often focus on running at full speed, trying to do more faster. Sounds like a good way to eliminate waste and get things done as quickly as possible, but lets have a proper think about it...

A lot of what we are asked to build are big things, and this is where the problem starts for me. 

Lets get to the metaphor. Sprinting comes from athletics, so lets focus on the big one - the 100m sprint. Look at the photo below. The winners of the 100m sprint and the 10,000m at the Olympics this year in London 

Mo Farah and Usain Bolt 2012 Olympics (cropped)

In the 100m, the athletes don't take a breath, it is anaerobic activity. Ask an athlete to try to run the 10,000m that way, and you have a doomed project. It is possible for a human being to 100m in under 10 seconds, but it doesn't follow that you can run 10,000m in under 1000 seconds. The world record for 10,000m is 1577 seconds, which is about 50% greater. I suspect that Usain Bolt has never run a 10,000m track race, and if he did, I think it is fair to say he would be significantly slower than 1577s but if he did, I think its a good bet that Usain would be unlikely to run the first 100m in 10s. That pace is the definition of unsustainable pace

If you have a software development team approaching their work as a series of individual 'out and out' sprints where they go as fast as they can to deliver software without thinking about the long game, and the quality and the technical debt they are accruing, then they are trying to run a 10,000m like a series Usain Bolt 10s sprints. Mo Farrah might take longer over the first few 100m, but he will run the whole 1000m distance much faster than Usain could. 

All too often we focus on the 'how fast' and forget about the 'how well', but I'm prepared to say that the same people who push us to sprint as fast as we can, would never back Usain over Mo in a 10,000m race. 

The risk of using metaphors is that you stumble into someone else's metaphor. In this case the Scrum Sprint metaphor. I've already stated I'm a fan of Scrum, but Scrum is often implemented badly. As a coach I've had to walk into organisations and help pick up the pieces, so I know this to be true.  If you treat your Scrum Sprints like a series of 100m races, and go on like that for 100 sprints, you will have accrued so much technical debt and a bug list so long that you will no longer be able to deliver any value work in a reasonable timeframe again.

Most of your delivery capability will be tied up dealing with failure demand. A good scrum implementation will acknowledge this, and therefore ensure quality is front and centre where it should be, and spend time every sprint on keeping the bug list down and use refactoring and 'boy scouting' to keep the technical debt down. This means not going as fast as you can out of the blocks doing only new feature work, but it also means that more value work is delivered over the time you're delivering your MMF, and that the pace is sustainable.

A good Scrum team or Agile team must be able to maintain its pace indefinitely. In my metaphor, athletic runners are either 'Sprinters', 'Middle Distance runners' or 'Long Distance runners'. So the same people often  compete in the 3,000m, 5,000m, 10,000m, Half Marathon and Marathon races. They are showing the ability to use their sustainable running pace on varying lengths of race. 

The long distance runner seems to be a better metaphor for most of us to follow than the sprinter. There are situations where the 'out and out' sprint is the right approach - I've heard tell of banking apps that are built very quickly for a single niche purpose, used for a day or so, then discarded. That would suit the 'out and out' sprint as the tech debt and bugs are thrown away with the code, then the team starts afresh. 

So people - lets make sure we are honest to ourselves and our stakeholders about the kind work we are undertaking, and then approach it with a view to the success of finishing the kind of race we are running. 



.
Tags: Agile | Kanban | Lean | Quality

Wednesday, 27 February 2013 11:29:38 (GMT Standard Time, UTC+00:00)  #   


# Wednesday, 16 January 2013

How did we get to the moon - Part 2

Here's a daft question, which mission first landed humans on the moon? Apollo 11 of course, but lets think about that. It wasn't Apollo 1, it was Apollo 11. What on earth were the other 10 missions costing millions of dollars for then? 

Apollo 11 footprint

Well, I've had a good think about it, and this is another aspect of I find admirable about NASA's approach. As I mentioned in my last post, they had a backlog, and took achievable chunks from it, and finished them before moving on to the next. 

Mercury was all about getting manned spaceflight, Gemini was what NASA called "a bridge to the moon" - to work out how Apollo could be achieved, and Apollo was about getting to the moon. 

So lets start at Gemini. The mission goals were 

  • To subject man and equipment to space flight up to two weeks in duration.
  • To rendezvous and dock with orbiting vehicles and to maneuver the docked combination by using the target vehicle's propulsion system;
  • To perfect methods of entering the atmosphere and landing at a preselected point on land.

(source NASA)

All of these were the perceived steps needed to prove that a mission to the moon was possible. In a very agile way in 1964, NASA worked out that the original goal to land on land was not needed after all, so the mission was brought to a close early. 

So what did they get from Gemini? They got:

Validated Learning

They got the Validated Learning by delivering real missions. How often have you come across IT projects that are in a 'proof of concept' phase that deliver no real working value. The team gets to have a whale of a time playing with code that "we don't need to QA because it will never go into production" with the aim of getting learning of how to do real work. Only to find out a month later when the real work starts that most of what they learned was invalid, and that reference architecture we built was a bit Mickey Mouse. 

Proof Of Concept still means going live

Freeflyer nasa

Not NASA, they built real rockets, with real spacecraft on top, put real people into them and conducted real work that went into production. I can't imagine the rocket scientists saying, "we didn't bother testing the space suit systems properly, because this isn't a production mission to the moon, it's just a proof of concept." The astronauts were going out into the vacuum of space, so everything had to work with quality. 

Gemini had 10 manned space missions in about 18 months. They turned around their iterations quickly in manageable chunks, with the first 4 missions going from 4 hours to 4 days, to 8 days, to 14 days. Goal 1 achieved, two week manned spaceflight, move on to goal 2, docking. Interestingly part of the 14 day mission was a subgoal attempting to dock craft which failed. A lesson in limiting WIP for NASA right there ;-)

Keep the team together

The Gemini mission was piloted by names you will find very familiar - Armstrong, Aldrin, Collins, Lovell et al. Names you know from famous Apollo missions (11 and 13 in this case). In other words they had another Agile principe at heart. They built a great team, finished the mission, then kept the team together and brought the next mission to them.

How often do we put together a team for a project then disband it, and put together a new team for a new project? Good agile has teams staying together and work is brought to the high performance team as it completes other work. 

On to Apollo

Similarly with Apollo, each mission was designed to gain validated learning. 

As13 nasa

Apollo 1 was a disaster with a fire in the cabin killing all of the crew, which led to changes in the cabin design, and better escape systems. A harsh lesson that led to important learnings for the rest of space flight. As with most projects that go wrong, the lessons we learn tend to be the most important ones. 

Apollo 8 was the first mission around the moon - the furthest away man has ever travelled. 

Apollo 9 was the first time the Lunar Module was tested separately from the Command Module, launching, manoeuvring, and docking in space. 

Apollo 10 was everything up to but not including lunar landing. They launched the Lunar Module and went down to within 9 miles of the surface of the moon, then came back up, docked and came home. 

Apollo 11 was the biggie. Neil may have fluffed his line ( "one small step for a man," is how it was supposed to be) but mankind was on the moon for the first time. 

Apollo 12 onwards was about finding out how man could spend longer time on the moon, and potentially set up a base there in the future - hence the lunar rover etc. 

Each mission built on the learnings of the previous mission, adding another valuable increment of validated learning, until the final objective was achieved. 

EugeneCernanOnMoon

This equates to a project releasing valuable increments and evolving through the validated learning gained until you have a Minimum Viable Product to launch to market. Gemini and Apollo 1 through 10 gave the increments and validated learning so that Apollo 11 could happen, and that progressed throughout the programme to the final mission to the moon (40 years ago). 

One Final Thought For Mankind

Can you imagine the Big Bang waterfall approach as applied to the Apollo programme? Imagine if Gemini 1 had to go and land man on the moon with no missions in-between. Do you think it would ever have even taken off? I suspect it would have been cancelled after 15 years of theoretical work, and been an abject failure. They just didn't know all of the things they needed to learn up front, it was only by launching the missions that they found out all of that Validated Learning that made the objective possible. You don't learn everything you need in a theoretical POC phase, you learn by doing things for real. NASA was doing this on the highest profile project in the world in the 1960s. Finishing one small step at a time. 

 



.
Tags: Agile | Kanban | Lean | LKU | NASA | WIP

Wednesday, 16 January 2013 11:22:06 (GMT Standard Time, UTC+00:00)  #   


# Wednesday, 09 January 2013

With the BBC going all Stargazing LiveI thought I would start this blog by sharing some of my space based Agile and Kanban thoughts. Being an amateur astronomer, and someone who naturally seeks out metaphor to help understanding, I do like to draw on the universe to help me explain things.

SaturnVSeparation

So how did we get to the moon? Well first of all there was the space race, and NASA started behind the USSR space programme who already had satellites and put Uri Gagarin into space first, but they caught up and overtook the USSR programme. How did they approach their mission? One mantra captures what NASA is about for me:

"Do one thing at a time, with supreme excellence."

For me, this embodies the spirit of Kanban in a way that nothing else ever has. Let me break it down.

Do one thing at a time

Focus on the finishing. Put your effort into releasing your value. All of these things really boil down to Limit your Work In Progress. We have Little's Law to show us mathematically why Limiting your WIP is the most effective thing you can do to affect your Lead Time and your Throughput, but I've never seen such a big and government funded organisation be so single minded in what it did as NASA was (and is).

They started off with a very simple high level backlog of things to do.

  • get a satellite into orbit
  • get a living thing into orbit
  • get a human into orbit and back
  • conduct a space walk
  • dock 2 spacecraft in orbit
  • put man on the moon

Then they worked out that the back of the list was so far away with so many unknowns that they focused on the value they could deliver, and called it the Mercury Programme, which stopped at getting man into orbit.

They then finished the Mercury programme. And that is all they worked on, the whole of NASA finished Mercury and nothing else. Do one thing at a time.

Even now, NASA no longer works directly on the ISS mission, they use subcontracted private space companies, and the Russian space programme to keep that running for them. Now they are focused on getting to mars. How about the NASA JPL (Jet Propulsion Laboratory) which is in effect a different organisation? Well, it did Hubble ST, then the Mars Rovers, then Mars Curiosity, and now it is focusing on the James Webb Space Telescope. Yes some missions run for years (look at Voyager 2 - over 14 light hours away from earth and launched in 1977 - you can even follow it on twitter here ) but their FOCUS is on one thing at a time. Getting things Launched has a slightly more immediate meaning at NASA.

With Supreme Excellence

This sounds simple, and it indeed it is. If you are going to put humans on top of, or in close proximity to rocket fuel and liquid oxygen, and measure the amounts those substances in thousands of tonnes, then you really want to minimise your bugs. In the world of Rocket Science, things seem to either go well, or go catastrophically badly, so you must ensure quality.

In Software Engineering, we say the most expensive time to fix bugs, is when they are live, and earlier we catch them, the cheaper they are. The cheapest time to fix a bug is actually before you write it (pairing sceptics take note).

In space missions, it is often impossible to fix a bug once it has gone live and been found the hard way as evidenced by the price paid by the crews of Columbia, Challenger and Apollo 1 and very nearly Apollo 13.  Do you remember the cost of fixing the initial Hubble Space Telescope focus problem, and the media furore about that bug? If they have similar issues on James Webb Space Telescope, there is no way to fix it. Humans have never been as far away from earth as JWST will be, so once it's there, it cannot be touched by human hand again.

So focus on the quality. I remember my first reading through of David J Anderson's Kanban book, and being somewhat sceptical as that being the place he suggested the readers start.

Then I walked into my first true Kanban implementation at YouView TV, and seeing the sheer amount of bugs my team was generating. Looking back , it would have been easy to have said that the team's primary output was bugs and secondary output was software. Harsh, and probably not really true, but it makes the point figuratively.

So I duly did focus on the quality with the team, and it made a huge difference. I'll probably do a blog on that separately in the future so I'll avoid too many spoilers, but I did track back one small bug. It took only 3 hours to write the whole feature, and if it had taken 3.5 hours, the bug wouldn't have existed at all.  6 months later, it took 3 days to fix the bug. The original developer had left, the rest of the system had moved on, and the cost of (re)working it all out in order to fix the bug rose to 3 days. And of course the down stream integration and system test team also had to spend more effort retesting the bug fix, so there is further hidden cost downstream. What could have cost under 30 minutes of Dev time, actually cost 3 days of dev time plus some other unquantified QA time.

In my career to date, I've never heard an operations / support team complain that the quality of the code delivered was too high, or the business complain that we were spending too little of our development capability on live support and bug fix, or had too little downtime on live systems due to bugs.

People often say that high quality is aspirational, or too expensive. They might even be bright people saying it. It doesn't stop them being wrong. I'm sure Albert Einstein must have came up with some right nonsense from time to time. Let me explain:

Truth be told Quality IS expensive, and the cost is front and centre where everyone can see it and point at it.

However, developing with low quality is MUCH MORE expensive overall, but the cost tends to be hidden, and late in the day, so it can appear to be cheaper up front.

It is always more expensive to fix things later. We all know that intrinsically. Do you top up the engine oil on your car when it needs it, or wait for the engine to blow up? Do you replace your tyres when they are getting low tread, or wait for a blow out at 70mph on the M3? Do you fix a dodgy bit of brickwork on your house, or wait until it falls down? Should you fix the bug now 'in sprint', or wait until the website goes down right in the middle of the peak sale that accounts for 40% of the company revenue for the year? Do you refactor the basket component as you work, or just leave it until the point that no-one working in the company understands it any more so the risk of making a small change means you have to rewrite the entire basket component, and the interfaces it has to all of the other systems?

Do you build your rocket with a high quality approach, or just hope it doesn't blow up on the launch pad?

NASA choose to focus on quality, but still have accidents. Imagine if they didn't focus on quality…

It wouldn't be as catchy to say Limit your WIP and focus on quality, but that is the essence of the message. Do 1 thing and do it as well as you can also works.  If it's important enough to spend money on doing, then don't do anything else, and do it as well as you can. I like to thing everything in Agile & Kanban is plain simple common sense or counter intuitive but still common sense.

I've only talked about costs and throughput in this blog, and I've deliberately stopped myself from 'going off on one' about intrinsic motivation amongst the team, and craftsmanship etc. I probably will at some time in the future but in short, the hard facts of when YouView focused on throughput, my team had 18 'funded heads' but we could only maintain 13 real developers at any given time as every time we found a good one to hire in, another left. When we had a quality craftsmanship focus we had the same 18 funded heads, and we had 18 people working there. Throughput also went from '8' to '13' so we had happier people, and got more done, as well as the higher quality. If you love throughput, forget the throughput and focus on the quality instead. Counter intuitive, but common sense none the less.

If you want to discuss anything about this, please catch me on twitter @KanbanDan



.
Tags: Agile | Kanban | Lean | LKU | NASA | Quality | WIP

Wednesday, 09 January 2013 11:47:39 (GMT Standard Time, UTC+00:00)  #