allan kelly

For a while now I’ve been convinced that a lot of “Agile” is about cultural differences. In particular I believe the canonical version of Scrum, which I often refer to as Hard Core Scrum or Scrum™ is rooted in 1990’s American software management culture.

Unfortunately the role of culture behind many Agile techniques and methods isn’t really stated. This make it even more important to work out what Agile means to you and which tools work in your environment and culture.

I first started paying attention to the cultural differences around teams and Agile after Steve Freeman said something along the lines of “Scandinavian teams just do this, they don’t see much new.” The teams I’ve seen in Scandinavia, and to a lesser degree Holland and the UK, don’t need big lectures in self-organization, left to themselves they do most of it.

I’ve pondered on this for some time and at Agile Cambridge last month I got the chance to talk a little about this with Dave Snowden. We only had a few minutes to talk about this – I was about to present – but it was clear we could have talked for hours.

Take stand-up meetings for example.

When I worked in Silicon Valley I worked in a cube. I hated it. I didn’t even know if my neighbours were in the office, let alone what they were working on or if they had achieved anything that say.

Working in the UK, in open plan offices, usually sitting opposite my co-workers we would certainly know who was in, most likely they would tell me when they had done something.

I believe that stand-up meetings are a good thing in all teams. However I believe they make a much bigger difference in cube and office dwelling environments than in open plan offices. In other words: stand-up meetings have greater benefit in US offices than they do in European offices.

In the original book of Extreme Programming Kent Beck talked of a “sustainable pace” and “40 hour work week”. Beck talks about his experience in Switzerland and contrasts it with the US norm. Although European workers – particularly in the UK – frequently work more than the 40, 37.5 or 35 hours they are contracted for they work hours don’t get excessive for too long. I’m not sure that is the same in the US. Sustainable pace means different things.

Personally I’ve always found “sustainable pace” does not fit well with the Scrum idea of “commitment”. I’ve written before – Two Ways to Fill an Iteration – about the contractions I see. Culturally it isn’t hard to see how “sustainable pace” is easier to do in Europe than the US.

(By the way, I’m limiting myself to the US and European, specifically UK, cultures because these are the ones I have some experience of.)

Now lets talk about the big one: Self-Organizing teams and evil managers.

(Apologies if this comes across as Scrum bashing, I believe Scrum works, or at least Scrum-lite works, and I believe self-organization is best. I just don’t believe hype.)

Some Scrum courses and advocates make a big thing out of self-organization. Personally I don’t. In my courses I I talk about it a little, more if people want to, but I focus on giving people experience of how it works. My style of Agile – yes I’m slowly writing up Xanpan – believes that self-organization is the result of the right approach not a stating point.

Self-organization goes hand-in-hand with an attack on Managers, and in particular Project Managers. Again this theme runs through all Agile but in Scrum is particularly strong. Hard-core Scrum really has it in for Project Managers but then replaces them with Scrum Masters which most companies think is just the same job with a different name. I’ve written about Scrum’s contradictions with Project Managers before so I won’t repeat myself, When did Scrum start loving project managers?

But Scrum’s dislike of managers only goes so far. After all, Scrum is the management friendly version of XP – see Scrum has 3 advantages over XP.

Now I’m not a big fan of Project Managers, in my programming days I too suffered a few managers who tried to hand out tasks and impose their way of doing thing. And I’ve been told No when I want to spend a little money – I once threatened to leave the company if they didn’t buy more RAM for my development box.

When I look back over my career I have to say most of the (project) managers who behaved like this made themselves irrelevant. We worked around them. Certainly removing them would have made us more effective.

But, most of my experience is that managers, even project managers, didn’t behave like this. They may not have been the most empowering of people but generally they left me, and programmers I worked with, to get on and do it. We worked out what needed doing, we divided the work up amount ourselves, we scheduled at the micro-level.

In other words: we did self-organization on a day-to-day level.

Again I think there is a cultural difference here. In my experience America is a more hierarchical culture than Europe (with the possible exception of Germany). Please, I’m not talking class systems here, I’m talking command and control.

I think Europeans are more likely to question their managers to their faces – perhaps it was the 1914-18 experience – or just plain ignore them.

National characteristics are not the only basis for culture. Industries have cultures too. Here again I’ve written before: Agile will never work in investment banking – one reason being that investment banks are very hierarchical.

Most of the managers, even project managers, I meet when delivering Agile training courses and consulting, like the Agile approach and want to work with it for the benefit of their teams. Few seems to be the whip-cracking project managers of folk lore.

Jon Jagger tells a story about one of his clients in Norway. The company was bought by an American competitor. When the engineers started to work together they would convene a teleconference. The American programmers would arrive with their managers while the Norwegians would arrive by themselves. The American’s would ask “Where is your manager?” The idea that the Norwegian could talk and make decisions by themselves was a new idea.

I had a manager in California – Irish as it happened – who used to practice “management by walking around.” Every morning he would appear in my cube and chat. Took me months to realise he was my manager and when I did I wished I had been more guarded with some of my remarks.

This all begs the question, why would American management be such a hinderance to software development? (Note I’m not saying European management is better, that has its own faults, I’m just exploring different cultures.)

For many years the USA was the world foremost manufacturing nature. Part of this success was the superior management practise implemented by the Americans. Such practices made a difference on the factory floor but even here they have been .

I can, and should, write more about managers and their role in the software team. Suffice to say for now: there is an awful lot of bad management out there. I believe good managers, good management practices, can be help companies massively. But on the whole, in the IT industry, there is a lot of poor management.

Bringing this back to Agile.

I think Agile’s anti-management slant is really a reaction to bad management. Hard-core Scrum is the Extreme in this respect. Scrum-Lite, as practiced by most teams, is less so.

Agile, and particularly Scrum, is the product of 1990’s culture, and particularly American work/management culture. Since American culture spreads the fact that Europe never suffered from quite these ills may down to the fact that we were not that good at copying American ways.

There may be a silver lining here: if America adopt Agile, Scrum, self-organization, etc. then we should see it spread out to the rest of the world.

If you disagree with me I’d love to have your comments on this blog. And if you agree I’d love to hear your stories to. Please, leave a comment.

Retrospective Dialogue Sheets continue to be a popular download, and I’m off to Sweden in a couple of weeks to present the sheets at Oredev. Unfortunately I haven’t had time to review the downloads to extract any useful information from the several thousand downloader details but I do continue to get some interesting feedback.

A few months ago Gail from Siemens Healthcare e-mailed me to tell me how she had used the sheets to conduct a distributed retrospective. The team in India had one sheet and conducted their retrospective in their work hours. Several hours later when the US team arrived at work conducted their own retrospective using another sheet. Gail then gathered the findings and reviewed the two sheets and conclusions which were complementary.

More recently I heard from a Scrum Master at Stattnett in Norway about their use of the sheets. What follows is a (slightly edited) account which nicely describes why many people like the sheets:

“thank you for the sheets! We’ve now used them in two retrospectives, and we will continue to use this technique for the future.

My main reasons for applauding their use:

• The sheet stimulates equality among team members during the discussions, by the fact that all must be seated around a table (no one standing up and facilitating the discussions).
• The sheet rules demand at least some contribution to the process from each team member during the session, by reading out questions loud – and also decide for themselves what is needed to read (and not to read).
• The sheet is very physical and with few/no barriers for participants to express themselves on the sheet for everyone to see – even if it is only by drawing “stick men” on the edge (next time, maybe even the stick-man-painter will write some words on the sheet).
• The sheet and rules (when followed) prevent the Scrum Master from falling into a “team leaderish” role when the rest of the team gets lazy and wont’t bother to involve in the process – they all have to take their part of a common responsibility for getting through the questions and to the end of the “game”.

These characteristics make our retrospective sessions less bureaucratic and more inspiring than with our old technique. We have been using the more traditional technique for several years, with each team member preparing notes before the meeting, writing successes and suggested improvements (often as complaints…) on green and pink paper memos.

The notes were then collected on a whiteboard and discussed and voted on at the end – with the Scrum Master (me) as facilitator. This preparation of notes [was rushed] and no one really likes to do this. Going through each and every note was time-consuming duty with debatable value. [In the end] the retrospective meetings became quite uninspiring form for all of us.

But with the dialog sheet, we now have a better, more inclusive and more constructive climate in the meetings. We spend our time on issues of real value to the team instead of ceremony parts no one really likes, and more in line with the original intentions for this session.

The sheet can be put directly on a wall after the meeting, for everyone to see. I don’t have to make any kind of additional summaries anymore (as I did, even if core scrum doesn’t prescribe this). I can instead take a photo of the sheet for the record, if needed.”

I regularly hear that of teams who hang the completed sheet on the wall as a reminder of the discussion and conclusions. I have also heard of a team who hung a blank sheet on the wall at the start of an iteration and team members filled in the timeline as they did the work.

Finally, I recently discovered a blog posting from University College Dublin which used the Dialogue Sheets as part of student retrospective exercise. I don’t believe these are the first College to do so, University of Central Lancashire might have that honour.

Since I learned about the sheets from Cass Business School in London I like the idea that the sheets are going back to college!

In a couple of blog post, and on other occasions in other places I have talked about there being a Business Analyst working on the original Extreme Programming (XP) Chrysler C3 project.

I’m not sure where I picked this piece of information up but I was wrong. One, Chet Hendrickson of the original team read my post and the team actually had direct access to the payroll team to understand what was needed, agree acceptance criteria, etc.

The Wikipedia entry on C3 discusses a “customer representative” on C3 and indeed Extreme Programme suggests you have a onsite “customer”. Somewhere along the line I read, was told, or just got the impression that this person was, on the C3 project a Business Analyst. Now I see I was wrong.

Having set that, I would still suggest that a Business Analyst can fill the role of customer representative and often have experience and training in doing this. I will accept that sometimes a BA doing this might become a block and it would be better for the team to talk directly to the customers.

In my last post “Scrum doesn’t work for us; should we try Kanban?” I gave a warning about adopting Kanban because Scrum doesn’t seem to work. Having given advise on when not to use Kanban I feel I need to suggest when choosing Kanban is the right decision.

Of course list that follow is only broad guidance, each and every team needs to make their own decision based on many factors I cannot even guess at here. Nor is this an extensive list, I’m sure Karl Scotland, David Anderson, Benjamin Mitchell and others would add more to the list but its a good start.

Here goes….

Use Kanban for maintenance: teams who fix bugs, especially teams who fix bugs in live system. Such teams work respond rapidly to unpredictable work, bugs are difficult to estimate and can come up at any time.

Use Kanban when predicting future work is difficult: this is a generalisation of the previous case but expanded. It is not just bugs which are unpredictable, sometimes the work which needs to be done is unpredictable.

Note: some teams fall into this position not because the work they do is really difficult to predict but because there is no effort put into predicting the work, usually because nobody is tasked with looking ahead or the person who is asked to do so isn’t allow enough time to do so. The easy way to spot this is the absence of someone with a title like: Product Owner, Business Analyst, Product Manager or similar.

Use Kanban when the team find Scrum style routines stop them achieving flow: for effective teams who focus on rapidly turning new requirements into working software Scrum routines such as planning meetings can get in the way. Nor is there a lot of point to running a product backlog if items are being delivered rapidly or not done.

Use Kanban when the system is too complex to model with Scrum(XP): the plan-it, do-it, deliver-it model which underpins Scrum isn’t too helpful when a process has a lot of wait states or dependencies. The standard Scrum answer is probably to remove these but that isn’t always possible (e.g. you can’t force a customer to respond).

Use Kanban when learning is a higher priority than delivering: to be effective Kanban requires to learn from what the system is telling you and adjust. If you can’t put the learning into effect Kanban will not be effective. However, Scrum’s pre-packaged solutions means that many teams seem to adopt Scrum and forget about learning (e.g. retrospectives are forgotten.) Worse still, because Scrum (claims) to fix so many problems “out of the box” teams may develop a learn dependency.

Use Kanban when you need to introduce the Agile approach more gradually: strict Scrum mandates a big-bang approach, sometimes this isn’t possible. Kanban provides a foot in the door which becomes a lever for opening it more. (This point flows directly from the previous when you consider change to be the result of learning.) However this also comes with a warning: change can quickly stall if people do not act on what they see and learn.

In the past there has been debate about which style (Scrum or Kanban) a team should start with and which is the advanced style. Personally I find it easier to start with Kanban although many people feel the natural order is the opposite: start with Scrum, get good and advance to flow and Kanban. Although it is easier – in my mind – to start with Kanban it is also a lot, lot, easier to get it wrong.

There is a paradox there: Scrum mandates the role of Scrum Master, I don’t usually see the need for a Scrum Master, an occasional Agile Coach is helpful, but a full time Scrum Master No. Kanban doesn’t mandate any such role, but you probably need someone with past experience far far more with Kanban than you do with Scrum.

Two and a half years ago I published a blog entry entitled “10 things to know about Kanban software development” which has consistently been the most read piece on this blog. At first I thought “Well there isn’t much published on Kanban relative to Scrum” but then David Anderson published Kanban and that wasn’t true any more.

Others have written about Kanban too over the last two years but still there is a hunger out there, people want to know about Kanban. I see this too when I deliver my Agile training courses, the moment Kanban is mentioned people want to know more.

Although Kanban is conceptually simple you really need a day or two to discuss it properly. Still, I regularly find myself squeezing an hour, or just 10 minutes, into a Agile training course because the audience want it. I say “I really need a day” but I can’t avoid it – they are paying for my time so they get what they want.

One of the reasons people give for buying an Agile (Scrum/XP style) course and wanting Kanban is, they say, “we don’t think Scrum will work for us so we might try Kanban.” Then when I return to coach teams I’ve given training to I’m regularly asked “Scrum doesn’t seem to work for us, should we try Kanban?”. I reserve judgement and enquire before I give my advice, and what I find is….

They haven’t really tried Scrum(XP).

Or rather, they have tried a Scrum(XP) type approach and they hit problems. Despite my telling them this would happen they think its Scrum. The thing is, Scrum fixes some problems “out of the box” but it doesn’t fix them all, in fact it exposes old problems and highlights difficulties which you then have to fix. Thats the way it works, that is the way it is meant to work.

Let me repeat that: Scrum and XP do, in and of themselves, right out of the box fix a lot of problems software development teams typically have. But Scrum and XP do not (despite what some people will tell you) fix all problems right off: you have to continue the work and fix them yourself. Sometimes Scrum, as officially described, will just not work, you have to modify it to your environment.

What worries me when teams say “Scrum doesn’t work, we want to try Kanban” is: if a team can’t make Scrum(XP) work because they cannot fix the impediments or make their own modifications then Kanban will never work. In fact, Kanban will probably be dead on arrival.

Some years ago Karl Scotland said “there is a subtle difference between kanban and typical agile processes such as Scrum. Scrum focuses on being agile which may (and should) lead to improving. Kanban focuses on improving, which may lead to being agile. However, being agile itself is not important – it just happens to be the best way we (or at least I) know at the moment.”

Thus: If you want to try Kanban because Scrum doesn’t seem to work for you then the chances are Kanban is only going to be a diversion. Set about fixing your problems.

Now there are reasons why Scrum doesn’t work, and there are reasons you should try Kanban, that should be a separate blog. One common case is because the development team has some support or maintenance responsibilities. In these cases my XP-Kanban hybrid Xanpan works quite well.

(I keep taking about Xanpan and a few people have asked me to write about it but a) I don’t think the world needs yet another Agile method, and b) until recently I wasn’t convinced there was enough difference between Xanpan and either Kanban or Scrum/XP to make it worth while. On the second point I’m changing my mind. If you want to know more about Xanpan let me know.)

Back to topic, although a team might not need to move from Scrum/XP to Kanban or Xanpan there might still be advantages to doing so. However moving because you can’t overcome your own obstacles is not a good reason for changing. If you can’t make Scrum work because you can’t fix your own issues switching to Kanban is not the answer.

Despite being a bit of a mouthful to say “Minimal Viable Product” and the even more difficult to say “Minimally Marketable Feature” (also known as a “Quantum of Value” or “Business Value Increment”) are very useful concepts. What makes gives them killer power is that they speak to a secret belief held by many people (not just managers) that teams gold-plate development and create products with more than is needed.

The trouble is, while we all agree the we should develop Minimally Marketable Features (MMF from here on) and delivery Minimal Viable Products (MVP) it is actually quite hard to do this. Nobody seems to want to sacrifice their favourite feature or the styling they have set their hearts on.

In Business Patterns I have a side box entitled “Strategy means saying No” in it I say “One of my personal rules of thumb is that strategy is about saying “No”. Strategy is not so much in what you decide to do – saying “Yes” is easy – but in the hard decisions about what you choose not to do.” The same applies to product development: saying Yes to a feature is easy, saying No is hard, but unless you say No a lot more than Yes you won’t have a MVP.

(After completing Business Patterns I discovered that both Michael Porter and Tony Blair have made the same argument, that No is more important than Yes.)

I have come to believe that one of the reasons teams find it difficult to create MVPs made up of MMFs is that the teams are just too big. I would like to suggest that if you want to create a MVP then you need a Minimally Viable Team. i.e. a team which is only just big enough to create the product.

Indeed, I will go further and suggest that your Minimally Viable Team (MVT) should be slightly smaller than you think you need.

Basically my logic is: if you have more people you will create more product. If you constrain the amount of effort that can go into a product then you will constrain the thing that is produced.

Way back I worked on Railtrack privatisation in the UK. When I joined the team is was 120 people (although only about 12 actual coders). The project was massive. Out of that came by belief that inside every large project is a small one struggling to get out. I sometimes call this Kelly’s First Law of project complexity: Project scope will always increase in proportion to resources.

A few years later I found myself working on a data feed project at Reuters. In retrospect the team was overstaffed. We didn’t need COM based system with interchangeable components. We made work for idle hands.

I know one team I’ve been visiting for over a year now, MMF and MVP frequently come up in discussion but I see the product backlog getting larger and larger and larger. The team is quite large by today’s standard – over 30 depending on how you count it. And ever since people started talking of enlarging the team the backlog has grown faster.

So much for the observations, lets try logic.

If you think about this the need for a MVT to create a MVP is a direct result of Conway’s Law: organisations will create systems that are copies of the organisation. (Seven years ago Lise Hvatum and myself investigated Conway’s Law in a conference focus group, the result was “What do we think of Conway’s Law now?”).

This can also be stated as the Homomorphic force: the structure-preserving relationship between two sets of things.

If you create a team which is too big it will produce a product which is too big. Once you have created a team which is too big it will find work for itself to do and it will be very very difficult to reduce the team size.

So start with a small team: actively try to break Conway’s Law, break the homomorphic force.

Staff the team with a fewer people than you think you will need, staff it with a range of skills but avoid making architecture assumptions in your staffing (if you include a DBA and you will have a database in the system.) As and when the team demands to grown then grow the team grow it.

Use Conway’s Law to your advantage: create a Minimally Viable Team to create a Minimally Viable Product.

How small is a MVT? I would say two people.

Really you need three people for it to be a team but in the belief that you should start smaller than you think I say two. One of these people should be focused on the business side of things – requirements, need, problem domain call it what you will; the other on the technology or solution domain. Let them work the problem for a while and see what happens.

Here is an observation which I’ve been been playing back to clients for a year or so now:

• There are two types of company in the world, those who talk about automated testing and those who do automated testing.
• Those who talk about automated testing buy tools like Quick Test Pro, WinRunner and Quality Centre and Rational Test Workbench, Rational Quality Manager, i.e. expensive products from the likes of HP and IBM.
• Those who do automated testing use tools like Selenium, Fit & Fitnesse, Cucumber (inc. Gerkin, RSpec, etc.) and other Open Source products they don’t need to buy

• There are a few, very few, companies which don’t talk about automated testing but on the whole everyone thinks it is a good idea and those who don’t do it would like to
• There are a some companies who talk about automated testing and have no tools; this is a better position to be in than talking and spending money

What I would really like to know is: has anyone else seen this? Or, can anyone give a counter example?

I think there is even a logic here. The IBM and HP products are expensive, so expensive you have to ask the price (actually IBM does give the price of Test Workbench at $5,500 for a single user license). Consequently they need to be sold, it also means that they need to be bought at a high level in the corporation. The people who are sold these products are very disconnected from the day-to-day work of developers and testers. This means the products might not be suitable and even if they are then developers and testers need to adopt them: they aren’t part of the change decision.

In addition: I just don’t think these tools are any good. To be fair, I’m no expert on testing tools but I’ve seen Quality Centre in action. Quality Centre (QC) isn’t an automated testing tool, its a very expensive test tracker. Testers write their test scripts in natural language, e.g. English, into the tool, the tool runs on the side and as they execute the tests they click Success or Fail. At the end QC gives a report.

To my mind QC is a fancy version of Microsoft Word. English language test scripts, if they are any good, are so detailed that they take almost as long to create as automatic scripts but they are expensive to execute because they are manual.

QTP and similar products are often linked to the OS or browser. They result in fragile tests which break easily when a box moves a few pixels or the browser changes.

HP also follow a razor blades model, I’m told: once you’ve bought QTP you need to buy a plugin for every browser to OS you want to use it with. Every time a new version of the browser comes out you need to buy a new plugin – or so I am told, tell me if I’m wrong.

The net result is: these tools are high maintenance and easily fall into disuse if they are ever used.

On the contrary: Open Source tools are adopted by people who do the work because they see the benefit they bring and they don’t need budget or signatures to get the tools. People get them because they want to use them not because a Salesman comes around and convinces the boss that you need a tool.

And because many of the Open Source tools require developers to create glue code to interface the tool to the application they lead to a more collaborative style of working.

(Perhaps some companies who just talk about automated testing have downloaded some of the Open Source tools but never use them tool. Since they are free nobody notices.)

So there is my theory. Anyone else seen this? Anyone else explain it? Anyone got a counter example?

Last week I made the London to Cornwall train journey for the first time in a few months. I made the journey many times during the course of the Agile Cornwall programme. This time however I was on my way to the Agile on the Beach 2012 conference. The conference itself is a product of the Agile Programme and looks set to run again in 2013 (although the final decision has yet to be taken.)

With the release of a report last week which claimed the Agile Cornwall programme created 50 jobs I felt Agile on the Beach is something of a celebration. I’ve now had a chance to read the report in full and while the report is not available for public download I would like to share a few comments from it.

First I should say that the report itself was conducted by a third party company commissioned by Oxford Innovation. Oxford Innovation runs the Grow Cornwall programme on behalf of public bodies and it was as part of this programme that Agile Cornwall was bored.

The report surveyed the companies who participated in the Agile programme to find out about their opinions of the programme and the changes which had resulted. They spoke to multiple people in most of the companies so it was pretty well grounded although it probably wouldn’t stand up to rigorous academic analysis. (If any academic out there would like to do a rigorous study then please get in touch.

Here are some highlights from the report:

• The Agile programme has met expectations for all companies who participated in the review. (I suspect one which was disappointed did not participate.)
• Businesses are finding they are more flexible and responsive to customers
• Money and customers
  • None of the business reported a decrease in turnover, profitability or customers since adopting Agile.
  • 7 companies reported increased turnover or revenue; 3 reporting the increase was significant
  • 6 reported increased profitability, 3 saying the increase was “significant”
  • 6 reported an increase in customer and/or business opportunities with 3 of the six saying the increase was significant

• One company reported that it was now more difficult to hire because they could not find people with Agile skills.
• Small companies said it was difficult to find the time to get started on Agile

There are also some very positive comments on the quality of the consultants used in the project, as I reported in my last blog it wasn’t all me. But, if I may be permitted to blow my own trumpet, I was there a lot, I worked with more companies more of the time than any other consultant. So I’ll be giving myself a pat on the back!

The report has, unfortunately, not been made public – although a summary version was given to attendees at Agile on the Beach. So if you would like to see the full report I suggest you go and knock on the door at Grown Cornwall / Oxford Innovation.

Regular readers will now that over the last two years I’ve done a lot of work in Cornwall, I jokingly refer to “the Cornish Software Mines” (A case study and Light Touch Coaching to name two blog entries.) To date the most visible result of this work was the Agile on the Beach conference which is running again next week.

There is now a report out which has looked at the programme overall and concluded that the Agile Cornwall Programme created 50 jobs. That might not be a big deal for London but in Cornwall that is a big deal. Particularly since half the jobs were high paying.

So far I haven’t actually seen the report so I just have this report on the report to go on. I’m trying to get a copy as we speak.

I can’t take all the credit, I had help. The thanks need to go to:

• Oxford Innovation for creating and running the programme
• Michael Barritt who was the driving force while of Oxford Innovation and has since moved to Sullivan Cuff Software (one of the programme’s success stories)
• Jon Jagger who provided most of the technical coaching
• Benjamin Mitchell who coached several of the clients when I was fully stretched and gave intensive help to one of the more difficult clients
• Plus Kevllin Henney and Sebastian Bergmann who provided additional training, and Nancy Van Schooenderwoert who provided specialist embedded consulting

There is still time to book tickets for Agile on the Beach if you want to meet all these people and some of the people who benefitted.