Solve THEIR problems, don’t push your own agenda

if you go to people and tell them agile is the key, they won’t listen to you. instead, go to people and listen to their problems. propose and implement solutions to their biggest and worst one or two. check back with them and make sure they are happy (or at least happier) rinse and repeat. if something in the “agile” toolset doesn’t scratch an itch they have, then you shouldn’t be using it. be flexible in everything except your values. be compromising. if they see you give in to what they suggest, they will be more willing to give in to what you suggest.

obviously a retrospective is a great vehicle for this. if you can get the team as a group to admit to problems that they NOT YOU are worried about, then the solutions you come to will also be owned by the team.

Start with individuals, not the “team”

as an outsider, which we are as consultants, it’s very, very hard to convert an entire team to our way of thinking. it’s hard to know what they all think, and the more you push, the more it becomes YOU vs THEM. not good. it’s much better if you can identify the change agents in the team, find the connectors, the mavens, and the salespeople (see The Tipping Point ) and talk to them. it’s much easier to convince one person, one on one that you have some good ideas, and that you might be able to solve some of their problems. do this first, and instead of 1 vs 10 it becomes 2 vs 9 or even 3 vs 7, MUCH better odds. if you can do this with the most influential people, then convincing the rest of the team almost takes care of itself.

this of course works the other way around, too. the most influential people on the team can easily turn the entire team against you, so you have to make sure that you are listening to them. addressing their problems and concerns, and making them feel heard. this is of course good advice for the whole team, but it’s so much easier when it’s one person at a time, you might as well start there.

Ask for help, and dish out the credit

it’s a funny thing, but when you ask someone for help, you usually get it. and believe me, if you’re trying to introduce agile, you’ll need all the help you can get. the easiest help to get is advice that is asked for one on one. ask your boss what the social makeup of the team is. ask those teammates for advice on what the team needs. ask someone to give a part of a presentation to management.

from their perspective, it’s a great thing to be asked for help. it means the person asking respects your opinion about something. it also means that they now owe you something and you’re less likely to hesitate if you need help from them. it means that you take ownership of the thing that you helped create.

if you can manage to make people look good in exchange for your efforts, not only will you spread out the work, but you’ll win yourself friends.

Read the Secrets of Consulting

‘Nuff said.

I’m actually not a big fan of the traditional yesterday – today – issues format. I find that too often it becomes a status meeting – this is what I did yesterday, doing more of the same today, and no issues.

Instead of a status meeting, I like to treat it as a planning meeting. I prefer to think of a stand up like a huddle in American football. The point is to focus on today, and figure out a game plan that makes the most sense. Who needs to pair with whom? Who’s tackling what stories?

I find the signal to noise ratio is much higher in the latter format as is the energy. It’s fine to mention anything from yesterday that is especially pertinent or interesting to the team, but I think the focus should be on today.

Walking around the TW chicago office, I noticed a very cool trend. The teams that had offshore parts had pictures of their offshore teamates on the wall with names. It’s a small simple thing that I think would have made a difference on my last project, at least to me.

I’m a very visual person, and I relate a lot better to someone if I have a picture of them in my head.

So go…take pictures of people and stick them up on walls!

I was talking to a fellow ThoughtWorker about a TDD workshop I might be doing next week. We talked about the project, expectations (theirs and the client’s), the history of the project, etc.

What I did that I haven’t done before is I started asking about who the influencers on the team were. Taking my cue from the default.TheTippingPoint, who are the experts that everyone trusts (mavens)? Who are the people who sway people’s opinions (salesmen)? In a workshop (and ideally the day before) those are the people that I need to concentrate on, because they’ll make my job a lot easier or harder.

A situation where it’s 1 person addressing 12 is a lot harder than where it’s 3 people addressing 10. Spend a couple hours w/ people individually, and you have a good chance of changing the former situation to the latter – at the same time showing those individuals that you respect them and need their help. Pick the mavens and the salesmen to be those 2 people and you’re set.

“Agile with no refactoring == waterfall with no design phase” – John Perkins, default.ThoughtWorks

As Dan says, TDD is a tactical thing. When you’re in the middle of coding, it helps keep you from adding unnecessary complexity, and it let’s you see how your code is going to be used even before it is.

However, that’s only part of the story. The other pieces are enough design (up front or otherwise), and merciless refactoring later.

If you don’t continuously think about where you’re going and how things fit together, and if you don’t keep your code clean by refactoring constantly, all the testing in the world is not going to give you a good architecture. To come up with a good overall system architecture, especially on large projects, you do have to think at least a little about what direction you’re going to go in ahead of time. The beauty of good unit testing is that it’s not a big deal when you’re wrong (because you will be, even if you’re right today, you’ll be wrong when you get those new requirements.)

TDD helps you design the detailed stuff right the first time, and enables you to fix the bigger stuff later.

In a system with very low duplication and high automated test coverage, you don’t have to get it right the first time, because changing your mind later is about as expensive as changing it earlier. If you haven’t worked on such a system, you should, it’s such a different experience. No matter how dramatic a change you make, in a few seconds you know if you broke anything.

Only unit testing can give you a system like this, because any other testing introduces duplication. Say you have 500 automated end to end tests with 95% test coverage. Let’s forget the fact that it takes you an hour to run them all. Suddenly there are changes to the code that you can no longer make, because they would break so many of the tests that the team couldn’t afford the time to fix them all. So crud in the code builds up, or the tests get thrown away. Either way, BAD.

Unit tests on the other hand can be and should be as fine grained as possible so that most changes no matter how radical don’t affect many tests. You can use techniques like mocking to help in this. Ideally, a test should test exactly one method/class/small chunk of functionality, and it shouldn’t break if anything else changes.

And TDD does scale. I’ve seen teams of 30 developers with suites of 1000’s of unit tests that run in less than a minute. And their code stays maleable. When people think of a way to make it better, they can. In fact I wouldn’t work on a team that size if people weren’t writing tests, because the code would deteriorate into spaghetti.

For the record, I also am a huge advocate of having testers and other types of testing: acceptance, integration, end-to-end, functional, exploratory, etc. These all can come in very handy and find holes in your product, unit tests and requirements.

A team without buy-in

I’m currently coaching a project along w/ fellow ThoughtWorker, Zak Tamsen.
It’s still pretty early, just a couple week long iterations into it. The
problem that we were having was lack of buy in from the team. It’s probably
our own fault for not setting stuff up at the start of the project, but it
felt very much like we were telling a team of 8 people what to do (write tests,
pair, do this, do that), and they were saying back, ‘No, we don’t wanna’.
The harder we tried to fix it, the more it felt like we were playing Mommy to
the team.

Then we left for a few days which included our IPM.

The tipping point

When we came back it was fixed. In our absence, the leaders of the team had stepped
up to lead the team. They had run the IPM, they had had meetings about how to
get the team on board, they had started taking what had been our responsibility
on themselves. Now instead of 2 outside !ThoughtWorkers trying to “convert” 8
people, we now have an increasingly cohesive team where 5 people have bought in
and assumed leadership roles.

Now we had talked to the leaders of the team to try to make this happen before,
but with us there, they had been perfectly comfortable to sit back and let us drive.
It was the act of us getting out of the way that made them step up. If
a system CAN heal itself, it’s important to let it heal itself – TheSecretsOfConsulting.

As a coach, I should be trying to teach my team how to
fish, not treating them to the fish that I can catch.

Testing 101——In a very late night testing 101 discussion with Cem and James, we learned about several “missions” of testing :
Missions

• valueable bug finding
• change detection
• ship decision support
• contract fulfillment verification
• …

and according to Cem, there are 11 different “styles” of testing
Styles

• claims based testing
• regression
• exploratory/heuristic
• scenario
• user
• state model based
• high volume
• risk-focused
• domain
• stress
• function

A couple of the more interesting styles were exploratory and scenario testing.

Exploratory testing is a systematic directed way of approaching a program to find VALUEABLE bugs. It’s not easy, and it does find bugs that are not found by automated tests. This isn’t new, and someone, tester, developer, or analyst always does occasional exploratory tests on projects I’ve been on. Why? Because it finds bugs. What’s interesting is that we try to fool ourselves into thinking this these tests not necessary just because they are not automated. Some tests are actually better as occasional exploratory tests, like bringing a user in to see what they do. Like thinking about the riskiest bugs, then seeing if the existing tests would catch them. Like directed testing at new areas of the app where automated tests probably have holes. Like scenario testing (below)

Scenario testing questions the spec that you are writing against. It’s one more way of helping a customer to accurately represent all the stake holders of a project. This is really cool, and is a check that would probably have gone a long way toward making several projects I’ve been on more successful

A very interesting thing I heard from these testers was that they thought many function and domain tests belonged in developer unit tests, as a more appropriate place for them. This makes sense to me, if a tester wants a domain test for X why not pair with a developer on it?

How do acceptance tests fit into all of this?——Acceptance testing’s primary missions are communication & bug prevention. When they are automated, their secondary goal is change detection. The primary style of acceptance testing is claims based testing, because in XP not only do they test against the spec, but they ARE the spec They may also be function tests.

This leaves a LOT of ground uncovered. For instance, bug finding. Acceptance tests will (hopefully) prevent entire categories of bugs, most noteable those that involve developers not understanding customer requirements. But once that happens, what about other bugs? I’ve never had a project yet where we trusted our acceptance tests completely, and I would think it foolish to do so.

I have always used all my old acceptance tests as my regression test suite, but the problem with this is that it doesn’t scale. No matter how well you factor your tests, once you pass a certain point, test times start growing uncontrollably, and certain categories of changes start to break hundreds of tests. What if your regression tests didn’t HAVE to be your acceptance tests? What if they were a more carefully selected smaller subset?

BUT

Acceptance tests are good. By straddling the fence between customer and developer, they bring the two worlds together, They provide an executable spec.

More later…