The Three Amigos Infographic

My first attempt at an infographic.
I used easel.ly.

Feedback welcome.

A BDD lesson from my past - Part One

So, a few years ago I was involved in an agile transformation.

I was part of the consultancy brought in to work with a client.

As part of our learning through trial and error, we decided to try Behaviour Driven Development.

I wanted to learn from what we went through and share it with others.

I also wanted to learn what some of the people on the client site learned.

I worked with two separate people and we came up with 2 talks.

We worked with the same theme but taking their different experiences and personalities we created different talks.

It worked quite well.

Thanks to @andrewjutton and @brightoniant for joining me on this exercise and also being willing to go through their first presentation experience with me.

Recently @friendlytester wrote a post which reminded me of that time.

His post prompted me to write this post.

Are you sitting comfortably? Good. Then we'll begin.

Many moons ago, a few people came across SpecFlow and this lead them to Behaviour Driven Development.

We didn't spend time thinking through exactly what we wanted to achieve, or how we'd know if we were getting there.

SpecFlow, however, was shiny and new and we were still working on how exactly we were going to use automation in testing. 

We were lucky that people with the business knowledge were available.

We were unlucky in that the people with business knowledge were offsite most of the time.

We decided to trial BDD, which was driven by the tool and by the 'Software makers', which at the time did not include anybody from the business.

This (now) seems wrong and didn't work as effectively as it could have.

I have no evidence to back this up, but I believe that having the business suggest the idea of BDD would change the approach completely. 

BDD is about focusing on collaboration, not focusing on a tool.

You can work with BDD without ever using automation and receive plenty of value.

In-some cases you'll be better off as you won't get lost in the tool and focus on the collaboration.

Collaboration is the key and point.

So, there we were; Giving it, Whening it and Thening like mad.

Mostly written (solely) by the Business Analysts and therefore bypassing a shared understanding and attempting to share one person's understanding.

Here's an example:

Scenario: Display ‘Insurer Selection’ screen

Given that Insurer selection screen has been invoked
When the Insurer selection UI is rendered
Then the ‘Insurer Selection’ page is displayed
And the ‘Risk Variation Name’ field is displayed
And the ‘Risk Variation Name’ field is selected
And the ‘Customer Name’ is displayed
And only breadcrumb ‘Select Insurer’ is displayed
And all insurers setup in the system for the policy type are displayed
And all insurers setup in the system for the policy type are not selected
And the ‘Next’ button is disabled

We were learning.

We hadn't quite grasped yet that the how wasn't important, it's the what that is important.

What is actually trying to be completed?

End of part one.

Blast from the past: BDD Lessons Learned

Change how you change presentation - Agile Tour London 2013

Have you seen what is happening at The Wesley?

In a few weeks Agile Tour London 2013 will be upon us.

Agile Tour London is a conference, a part of the Global Agile Tour. Since its conception in 2008, it has become a hugely successful worldwide event spanning 30 different countries. The idea is simple yet powerful: create a world-wide network of local agile events open to everyone interested in Agility: From Confirmed Agile Practitioner to Agile Newbie.
Global Agile Tour has come to London for the first time this year. This event for agile enthusiasts is an international conference composed of several excellent Lectures and Workshops given by Speakers from the UK and abroad. You can check the program to discover all the talks.
The London edition will happen the Friday 1st November 2013 in The Wesley Hotel close Hudson Station and Saint Pancras.
The registration is open with regular tickets at the price of £100 Follow the @agiletourlondon on twitter and in linkedIn with the Agile Tour London Group

Check out the program!

Theory of Constraints and Agility
Craig Strong and Daryn Holmes

Agile Leadership
Alex Cuva

Discovering Scrum: An Introduction
Peter Stevens

Xanpan — a personal take on all things Agile
Allan Kelly

Frameworks: supporter and mischief-makers of Agile Development
Oliver Szymanski

So long, and thanks for all the tests
Seb Rose

The future is Agile
David Tanzer

The Emperor's New Clothes: Meaningful Interactions in Stressful Situations
Portia Tung

How to Develop Great Scrum Master
Ángel Medinilla

How to be agile in a waterfall company
Dror Helper

Code Dojo
Nigel Runnels-Moss
(Bring your laptop and your favorite IDE!)

XP at Unruly
Rachel Davies

Personal continuous improvement — a myth?
Brindusa Axon

Agile UX, Is Agile from Mars and UX from Venus?
Carl Myhill and Steve Hayes

Methodology Patterns: a Different Approach to Create a Methodology for Your Project
Giovanni Asproni

When TDD goes awry: Useless tests, infesting mocks and other horrors
Uberto Barbini

Change how you change
Tony Bruce

« We Do Agile ». Why Is It Difficult for Solution Centers to Be Agile?
Ernst Perpignand

Flow - an agile method for Devops
Steve Arnold


Not a day you want to miss. See you there.

I attended an agile open space 2013 in Tenerife. #aos2013

Recently I attended an agile open space.

It was organised by agile Canarias and agile Spain and held in Tenerife at the CDTCA.

It started on Friday night and was held over Saturday and topped off with a party on Saturday night.

Friday was a good start, there was a bit of a explanation on what an open space was then people presented their ideas.

There was a wide range of topics such as pair programming to impact mapping to changing minds.

I don't speak Spanish and I must admit I felt a little out of place as the announcements and the like were in Spanish and although they were repeated in English initially, that soon stopped.

Not so odd if you consider you're in a Spanish country, little bit odd if you consider there was a push for more international attendees.

I think the push (and therefore the use of English) may have been news to some of the attendees though and it seemed like it may have also been news to some of the organisers.

I'm glad I went but I must admit at the time I felt awkward being there.  I was one of about 3-4 that aren't able to speak Spanish so I suppose it was awkward all around.

I attended a session on changing minds which was facilitated by Laura Morillo and a user story workshop facilitated by Juanma Gómez.

In the change session we discussed a number of things ranging from changing manual testers mindset to use (some) automation to how to change colleagues' minds to try new things.

In the user story workshop we talked about things like size of stories, what kind of details should be in them and different approaches.

Juanma in action

I was lucky to be able to run my own session which was on responsibility.  We talked about things like team vs personal responsibility, taking responsibility vs being told you're responsible and blame.

I enjoyed the session and I hope the attendees did too.

I met passionate people who are looking to help each other and improve.  Good times.

Here are some other blog posts about #aos2013:
http://www.carlosble.com/2013/06/agile-spain-o-espana-agil/
http://juanmagomez.wordpress.com/2013/06/23/reinventaos-2013/
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=aos2013

And here are some photos.

And here are some random photos I took of Tenerife.

I went to Mile High Agile 2013 and I liked it.

I went to Mile High Agile 2013 and I had a interesting time.

The Keynote was from Joe Justice who spread the word about Team Wikispeed: building a 100 MPG car using Agile & Lean methods
You get the drift of the talk from the title, it was great to see how far they've come using these methods and also how they are able to help others using the methods.

The Keynote was filmed but I don't know what happens with the recording, whether or not it's put online for public viewing.

Find out more about wikispeed.

I managed to catch Paul Rayner's DDD Workshop which I enjoyed.  I think it gave a good introduction and a few take aways to think about.

We worked through a exercise and we were working out our domain model.  I won't write down too much detail as I don't want to give it all away.

Paul's was the only session I managed to catch as I spent a lot of the day in the coaches clinic.

The coaches clinic is a great idea and the basic setup is that people can drop by a booth and book in some time with a coach to talk about about pretty much anything agile related.

Whether it is issues they are experiencing or things they are unsure of and so on.

I enjoyed the clinic and it was interesting to talk with people who needed help with some different areas.  I hope I was able to help with some things to take away and think about.

Some of the things we discussed ranged from whether or not to use Scrum or Kanban to how to get more out of Product Owners. 

While I didn't make many of the conference talks I definitely feel my time was well spent.

My thanks to Pete Behrens for inviting me to be a part of the clinic.

My own talk was at the end of the day and it was still a pretty full room which I was surprised about purely because usually some people have left by the last talk.

My talk was about Change and the Prezi is available.

I caught a glimpse of the feed back forms and it was a mixed bag which is pretty good, in my experience it's hard to have a talk that is going to reach everybody the same way.


I do wish that the people who didn't get much out of talks would offer more feedback.  It seemed like the people who got something out of the talk offered comments and the people who didn't just marked down a score and left it at that.
That makes it very hard to improve.

All in all a good day, had a lot of different conversations, hopefully gave some people some things to think about in both the clinic and my talk and met a lot of really dedicated people.

My thanks to agile Denver and all the volunteers for bringing me along for the ride.


After the conference I got to meet Lisa Crispin's donkeys , Ernst and Chester.

Matt Barcomb was also Lisa's guest and it was great to be able to spend time with Matt, Lisa, Bob (Lisa's husband) and Lisa and Bob's extended animal family.

It was great to meet Matt and I'm looking forward to his (and Jim Holmes's) session at Eurostar.

My thanks to Lisa and Bob for inviting us (my wife and me) over. They are fantastic hosts and we had a great time.

 Matt and Lisa

My wife Marisol

Explaining testing: agile testing

Pete Walen asked this question: For software testing professionals/craftspeople, what is it that differentiates Agile Testing from any other testing?
 
My reply: - I have wondered the same myself. And as with most things, it seems like it is contextual. It depends on what you're working on, who you are working with, what is available to you, who is available to you, etc.

It also depends on your mindset and behaviours. I think it's a openness and a willingness to learn and working together closely, perhaps closer than people from some environments are used to. You need awareness of yourself, and whether or not it is a place for you, things move quicker and you can't hide.

In some agile environments some of the Testers will be very technical and focus on automation and knocking up tools, frameworks, etc to help with the testing. But that doesn't mean that a Tester with different skills won't be able to add value. And ideally it's good to have a mixture.

I also think it's not so much what differentiates A/agile Testing from from any other testing. It's that Testers who have been doing the bare minimum are more exposed in a agile(ish) environment. Issue with that is that some people don't realise they are doing the bare minimum because they are doing what is asked of them.

People who have tried to change things, or looked for ways to improve things will probably be able to adapt easier to agile.

Those who have not been increasing their skill set, learning new things, etc can find it hard when things are moving quickly. Those who are used to spending days/weeks/months knocking up test scripts to follow may find themselves a little lost when they don't have that security blanket.

You need to be able to manage yourself and get on with things and in a more agile environment you are able to do so.

The thing is, there is no one, true, right answer because both 'agile' and 'testing' mean different things to different people so you get my rambley answer :-)

Huib Schoots has a excellent post about agile testing.

Inbetween talks - Agile Dev Practices 2013

So #agiledevprac has been and gone.

I had a great time.


During the Monday my fellow speaker Ant and I had a chance to hang out with Maik Nogens.

Maik's a great guy, if you see him (you can't miss him, he's 8ft tall, although everybody looks 8ft tall when they are standing next to me) say hi.

We had a walk around Potsdam and sampled a couple of Bratwurst.  This is my second time in Potsdam and I think it's a great place, nice, quiet and picturesque.

On the first night there was a speakers dinner at Walhalla.

Jose stood up and gave a short speech welcoming everybody.

The food itself was OK, the company was great.

Ant and I had both chosen a fish dish which came with bacon sauce. BACON. SAUCE. How could you not?!

We'd been waiting and looking forward to it for weeks. We'd been imaging all sorts of amazing creations.

It was one of the biggest disappointments ever. It is a cream sauce with bits of bacon in it.

Ant and I shared a table with a number of people and we spent the most time talking to Ray Scott and Vagif Abilov.

I've come across Ray and Vagif before in my travels but have never had a chance to sit down and have a proper talk.

It was great to do so.

After dinner there was a short visit to the hotel bar and then off to sleep.


Over the next few days there were:

• Pop-up coding dojos.

• Conversations all around with people from the world over.
• I would love to list the names of everybody I had a conversation with but there are too many.
• Ant drank his first ever full pint of beer, followed by his second, and third, etc.

 

• A social dinner event complete with improv comedy troupe.
• Ant and I were on the same table and again had a number of diners with us. During dinner we spoke mostly with Ray Scott and Krystian Kaczor. 
• After the meal we spoke with a few more people.
• A group of us went for a meal, sat down and realised none of us speak German.
• We had 2 English guys, 1 Hungarian, 2 Spanish guys and 3 Russians.
• Luckily, one of the waiters spoke Russian so we were able to get a meal organised.

 

Unfortunately I didn't get the names of two of the (Russian) guys at dinner, the rest are:

@carlosble

@brightoniant

@ooobject

@gasparnagy

@vgaltes

It was great to catch up with some people, meet new people, have some great meals and have some great discussions.


In my opinion, over the next few days there were some good talks, some OK talks and some talks that didn't quite work.

Conferences are essentially a meeting of people who want to contribute, teach, learn and share.

It's not just attending the talks.

Make the effort to meet new people and talk and you will get untold value from a conference.

Reasons to be at TestBash 2.0

Program

• I'll be there!
• Talkers from all over the world.
• Attendees from all over the world.
• You can share.
• You can learn.
• You can teach.
• Did I already mention I'll be there?
• You can meet.
• You can discuss.
• Ministry Of Testing put on good events.
• You can talk authors of a number of books:
•  Agile Testing: A Practical Guide for Testers and Agile Teams
• The Secrets of a Buccaneer Scholar: How Self-education and the Pursuit of Passion Can Lead to a Lifetime of Success
• Bepaal je koers! Toekomst en Trends in Testen
• Brighton is a great place to visit.
• It's cheap!
• There's a get together the night before.
• Apparently some people feel the need to run (for no reason) so there's a joint run in the morning.
• There's a leancoffee.
• There is a chance to do some really short talks.
• Good way to do your first talk.
• Good way to raise a point.
• Good way to start discussion.

Check out Make The Most Out Of TestBash 2.0

Don't miss out, you'll be grumpy if you do!

Reasons to come to Agile Dev Practices

Program Overview

1. I'll be there.
2. Good mix of sessions.
3. Good mix of tutorials.
4. Good range of subjects.
5. Did I mention I'll be there?
6. Good range of workshops.
7. My colleague Ant will be there.
8. 25% off with code ATDC4P_025.
9. Potsdam/Berlin is great.
10. Markus can sign 'ATDD by Example: A Practical Guide to Acceptance Test-Driven Development' for you.  
11. You can talk to Gaspar Nagay, main contributor of the open-source .NET BDD tool, SpecFlow. 
12. Ellen can sign one of her books for you.
13. You can talk to Chris Matts and Olav Masssen.
14. Díaz & Hilterscheid have put on a great event.
15. You can talk to people who make software from all over the world, share your stories. 
16. You can teach.
17. You can learn. 

There are more reasons, what am I missing?

It doesn't make sense.

I stole this, I changed two words:

People work with one set of ideas about how the software is. Everything they do, be it experimental or theoretical work, is informed by, and framed within, that set of ideas. There will be some evidence that doesn't fit, however. At first, that evidence will be ignored or sabotaged. Eventually, though, the anomalies will pile up so high they simply cannot be ignored or sabotaged any longer. Then comes crisis.
13 Things That Don't Make Sense - Michael Brooks.

To me, this is a pretty good explanation of software development, although of course, not in all cases of software development.

It's also a pretty good reason why things like agile, devops, devs, bdd, etc have come about.

We do approach things with a set of ideas and we do frame things with that set of ideas in mind.

We stick to our own ideas, even though some of our ideas have been born out of others' ideas and thoughts and words and we've blindly made them our ideas and thoughts.
- For more on this train of thought refer to Leprechauns of Software Development or various kinds of certification.

When we have ideas that we have actually conceived it can be a good thing because we all have different experiences, we all have different thoughts, we can all add something.

I think the problems occur when we don't let go of theses ideas (when beneficial) and learn from others experiences and listen to others ideas.

A lot of time we don't conceive ideas together for something we are supposed to be working on together.

What's wrong with us?

Doesn't make sense to me.

Make sense to you?

Continuing with the excerpts from 13 Things That Don't Make Sense The next paragraph starts with the sentence:

Crisis, Kuhn said, is soon followed by the paradigm shift in which everyone gains a radically new way of looking at the world.

Does it? Not for software development, not as much as needed.

In the context of software development the sentence would read:

Crisis, Kuhn said, is soon followed by a attempt to throw more people at, work longer hours to stem and follow the procedures that caused the crisis in the first place until the next crisis arrives.

What's wrong with us?

Why would I need excuses?

Recently uTest posted "8 Common Excuses in Software Testing" and within the comments there was a link to "Excuses for testers when bugs are caught in later testing cycles/UAT/Production".

My immediate thought was 'WTF? Why would I need excuses?'.

Reasons, yes, explanations, yes, but excuses? Hell no.

Am I wrong? Do I need excuses?

Or am I getting reasons and excuses mixed up?  Are some people taking them to mean the same thing?

At the end of "Excuses for testers when bugs are caught in later testing cycles/UAT/Production".  There is this sentence 'Well these are not actually excuses. These can be the actual reasons why an application is shipped to client with major bugs.'

The way I understand the two in this context are:

Reasons

1.a basis or cause, as for some belief, action, fact, event, etc.: the reason for declaring war. 

2.a statement presented in justification or explanation of a belief or action.

Excuses

1.to regard or judge with forgiveness or indulgence; pardon or forgive; overlook (a fault, error, etc.): Excuse his bad manners. 

2.to offer an apology for; seek to remove the blame of: He excused his absence by saying that he was ill. 

3.to serve as an apology or justification for; justify: Ignorance of the law excuses no one.

I am not a gate keeper, I am an information provider, I have limited time to provide what information I can.

I will do my best, the people around me will do their best and sometimes we will not be able to investigate everything.

I'm happy to explain things but make up excuses?  I think that will do more harm than good.

There are plenty of reasons why issues end up in production, learn from them, explain, improve how you test and what you test.

Don't make excuses.


28/01/13 Update.
Forgot to add, what and how you are testing and what you are not testing should be communicated and continuously communicated as you delve deeper into the software.

London Tester Gathering - Tues 15th January - The Shooting Star

The January London Tester Gathering will be on Tuesday 15th January at The Shooting Star.

Address:
125-129 Middlesex St, London E1 7JF

The plan:
We have a room from 6:00pm onwards

Talks:
Weeknight Testing Q&A
Net-A-Porter are hiring.

Sponsorship:
Net-A-Porter
http://www.net-a-porter.com

Hope to see you there.

http://www.meetup.com/agiletesting/events/95777622/

Cheers and Kind Regards

Tony Bruce.

London Tester Gathering - Thurs 11th October - The Shooting Star

The October London Tester Gathering will be on Thursday 11th October at The Shooting Star.

Address:

Function Room 125-129 Middlesex Street London E1 7JF 0207 929 6818

The plan:

We have the function room from 5:30pm onwards.

Talks:

Intro to Project Partners

Extending the page object pattern with widgets and

reflection - Rob Fahey

Sponsorship:

Project Partners, part of the Hydrogen Group

RSVP: http://linkd.in/UaSXyN

Hope to see you there.

Cheers and Kind Regards

Tony Bruce.

Tyrion Lannister - the agilist.

He is intelligent, witty and has skill for political manoeuvring. 


Because he is an outcast, he also has great sympathy for outcasts and the mistreated and helps them improve.

He is disliked by some and treated with respect by others.

He has lived and experienced all that life can offer him.

He has been on trial, adapted, worked out a solution and used only the appropiate tools to survive.

He meets hostiles and wins their support.

He adapts and adapts those around him.

He is adapt at bureaucracy.

He keeps his friends close and his enemies closer.

He learns strategy.

He learns from books, experience and people.

He is effective.

He is a surviver.

He is a leader.

He is agile.

agile schmagile

Am I the only one bored of 'agile'? It doesn't seem like it.  As far as I can see it's causing confusion and still has bureaucracy issues and can be a right pain in the behind.

There seems to be a number of issues , here are some I’ve picked up on.

1. agile as intent is great* but agile is not defined, there is no one concept, people have their own understanding and this can cause problems because people are trying to achieve different things

* So when I write that 'agile as intent is great' that's my understanding of agile, which probably differs to yours

2. People have pre-conceptions and stick to them

3. People have a cookie cutter approach

4. People try change without help.  It's extremely difficult for a group of people to change their ways, especially if they don't see why things need to change

5. People don't see the bigger picture, 'what am I doing is fine (at least I think it is) so I'm going to keep doing it this way, it's not my problem if there are issues with the team/project/organisation'.  People also try keep a hold of their corner

6. agile is not a silver bullet, agile will cause confusion and uncertainty, all change will and does

 7. There is a huge psychological factor to changing to agile, in all kinds of areas, trust, egos, a change of thinking, etc.  This needs to be taken into consideration. The change in thinking required to 'be agile' will not be for everyone

8. agile and/or change can take time, most people don't like change and uncertainty, people won't 'get it' at first and it can causes scepticism, stubbornness and resistance

9. agile is not about productivity, it's about improvement, productivity will happen by default when you improve

10. Scrum is not agile, it's a project management methodology

11. For most of the organisations that have success with agile it's been hard and took years to get there, realise this

13. There is no one way to 'be agile' it requires trial and error, things will go wrong, mistakes will be made, things will also go right and great improvements will be made

You need to realise this and be able to deal with both scenarios

14. Learn from what others have done and consider that it might not be quite right for you. IE 'that's not a user story, there is no xyx'.  Who cares? Does it work for you? Yes? Great, keeping doing it. No? Tweak it until it does.   If it doesn’t work, ditch it. By the book doesn't always work

15. People hold back because of uncertainty, fear and worry

Re-Regression Checks + Regression testing = Regression testing?!

Sharath recently wrote a blog post to which I decided to write my own post in response.
Sharath's post is here.

Sharath mentioned being slightly confused by BDD and ATDD which I see a lot, however the confusion I see is based on my ideas of what is what, make your own up and decided.

I've included some stuff from Liz as she writes better than me do write as well as my own 2 cents.

ATDD vs. BDD, and a potted history of some related stuff
Acceptance Criteria vs. Scenarios

What is interesting to me though is that as far as I've seen, ATDD doesn't include the business as much as BDD does. I see a lot of Testers and Devs getting together for ATDD and for BDD alot of everybody getting together like PO's, BA's, business people, etc.  That is where I personally see a difference. I prefer BDD and getting as many people as I can involved.
On the other hand, call it whatever name works for you.

Back to Sharath's blog.

One of the things that can (and in my opinion should) be done is that every time a bug/issue is reported automation is written that would find that issue before the issue is fixed - essentially creating a regression/consistency suite/pack/whatever. 
As well as automating any useful information gained from the ET.

I've also tried to use a test points reference (idea from paper by James Lyndsay and Niel van Eeden) with little success, mainly as I didn't push it hard enough.

What I have done is similar to what Sharath has done and created a mind map with areas for further investigation/automation.  Had slightly more success with that.

If you don't have people to automate you can essentially use your regression doc (mind map, doc, whatever it may be) to cover off areas, splitting it between the whole team.

I also try and push the idea of a demo before check in, together we can spot anything obvious before it gets checked in (and therefore a bug/issue).

There is really no one answer, is a case of finding what works for you with the people you have.

Agile Practitioners meetup - 'In Theory and in Practice'

Last night I attended an Agile Practitioners meetup where Daryn* gave a talked titled 'InTheory and in Practice'.

Here are my notes from last night and the Italics are my thoughts

He took us through a recent project (for a client) to build a Excel plug-in which connected to a third party.

Didn't really go into complexity, wonder if the same approach would work with a larger team.

TDD and BDD were used

BDD details weren't really discussed but it sounded more like acceptance tests were written rather then 'full' BDD.

There were 2 Developers and Daryn acted as a sort of co-ordinator.

The Deverlopers were able to practice pair programming and found having to voice and explain/justify your ideas a little odd at first but found great benefit by doing it.

Teaching/learning and writing better code

Code reviews were carried out by Developers on other projects.

Daryn also talked briefly abou the NUMMI case study, I'm not goint to write anything about that as there is loads of stuff around.

It's a good case study and I've not researched it enough but I wonder about the variables such as if the improvements were partly due to there being nowhere else for people to work and does that matter (in terms of the fact there were huge improvements)

On the project the first thing they talked about was testing, or how much/what could be automated.

They used Specflow for automation and I think Coded UI may have been mentioned as well.

            Were other options explored?

They were given uses stories which contained impementation details and luckily they were trusted enough to re-write the stories and change them to just the what rather than the what and how.  This meant they could look at different ways of implementation and were able to simplify the solutions.

            Were they written with the people who write the original stories?

They were able to decided at the last responsible minute and Daryn shared some pointers:

* Share partially completed designs
* Colloborate
* Develop a sense of how to absorb change

            What did they do to develop that sense? Or how was it handled?

All the stories were based on business value only and nothing had been written for the implentation, frameworks, etc. Essentially all the kind of stuff that becomes tech debt.

This also meant that this work wasn't visible.

            It was mentioned that this wasn't a issue, be interesting to know why this wasn't a issue.

A couple of burn down charts were shown and generally speaking they were pretty smooth and showed improvement.

Excel was used as the overall management and data collection tool

Of high importance was the people side of things, building a good relationship with the PO and the third party.

Daryn shared some general project pointers:

* Don't do too much upfront
* Too large a context change/switch can cause performance hits, ie, work on 1 project, don't work on multiple projects.

Data, information and quotes were resourced from Jerry Weinberg, Lean SoftwareDevelopment*, The New New Product Development Game and various conferences.

*Didn't get Daryn's surname. 

*Not sure which actual book it was.