Monday, January 28, 2013

My booksprint experience

I spent two days this weekend to experience a booksprint to to write a book on agile in Finnish. Book version 1.0 - first release from the first sprint - was out 6.15 pm yesterday, just as we had scheduled. Scope ended up as 99 pages of varied experiences written with a variable quality. The book is called 376 years of agile experiences, that is, the summed number of years in the software industry for the writers that has influenced what we experience with agile.

I must admit I had my doubts on 20 egos in one place with a shared but really vague task. But towards the end, ended up being positively surprised that something actually was done to our definition of done "dares to show to a friend".

The work really started months ago, when I enrolled. I was quite active in the discussions, with the personal intent of reminding people we don't really agree on the topic we're about to write on and that it would be a loss if one decided and the others just executed the plan. As I understood, a booksprint could start with just an idea, and we could work towards making that idea real, together, as a facilitated group.

In preparation, three of us met up with a group of people who had created a book in Finland this way, but their topic was mathematics. They had actually started from an outline of what should be taught on the topic. And that was quite a different task than the one we had at hand.

On saturday 10 a.m. the booksprint session then finally started. We had about 20 people in the room, ready to write and learn. We had a facilitator to control the process, and went through a series of discussions: who are we writing for and why, what should we write about. All of these discussions, together with a lunch that had not been preplanned enough to stay for the kitchen to cope with our numbers, took until 3 p.m.

I feel the value of the group discussion was more towards getting to know the unknown people just a little, what they found relevant enough to talk about. But it wasn't actually taking the book forward, as planning is not yet doing, and doing teaches us much.

I ended up in a group of 6 people with a wide selection of topics to write about: doing things in agile. We had become a group since some of us wanted to write about product backlog -related stuff, but got a few other stickies to go with this from implementation to maintenance.

After all the discussion, I wanted to just try writing for a while, to sort out what kinds of experiences I personally could write about. With a little discussion, every one of us in the group started writing individual stories, without agreeing on what was our scope, our common goal or anything of that sort.

The facilitator came in to interrupts us with breaks on regular intervals, which made us realize how time was flying. After the first writing session, one of our team members started leading the effort. This particular team member was someone with a little less hands-on experience, and she started asking the others what they could write about, trying to agree a plan on who works with what so that we'd get something together. I found myself become irritated with this controlling of the work when I was not sure where I would start with my writing - I did not want to commit to anything yet, except that I will write and share my stories. I told the group that I probably will only write this one piece I was working on and change topic next day, and continued my writing - reading process.

To be a little less of a loner, I started talking about a picture we could have the graphics fellow do for us - that we would need to leverage the skills he has as he too was spending the whole weekend there, and pictures are relevant. So we drafted an idea on paper, and left him thinking about it. The paper draft was transformed to a powerpoint-style picture, and then replaced with a real one. 

At 6 p.m. large part of the group stopped working for the first day. A subgroup continued, with myself and a colleague. We read all the individual and dispersed stories people had contributed. We copy pasted text around, added intro text and structure. And by 11 p.m we had a structure that emerged from the stories we had written so far, reflected with the understanding of our area to write on, and our first picture in the chapter.

Next morning the team regrouped at 10 a.m. and by that time people who had left early had already realized that things were taken forward but nothing was removed. The structure inspired us into collaborating, and the complete silence from the first day talking about what people would want to contribute next. And we also identified a gaping hole in the theme of implementation that we wanted to work on.

With the good experience of reading and seeing the emerging structure, I went on to suggest I could help the other teams with similar stuff. I was denied with "we should do that together, 20 is better than 1" but eventually, we never did that. I feel that could have significantly helped make the book one book, whereas now you can more clearly see the team division in the styles. So, I gave up on the idea, and started writing more stories on our chapter, reading others writings and moving things around when it felt right.

On day 2 afternoon, we merged the work of another group on "teams" on our chapter, as they were nicely compatible as themes.  Also at this time groups were asked to contribute 15 minutes to commenting on some other groups stuff, and we go nice new ideas that ended up as completely new stories in the chapter.

We ended up with over 40 pages that I find has some structure (could be better), that had been proofread and commented on.

To contrast our process to another group: they worked out what they would want to write on with post-its, and were building a larger story. Their story will be in version 2 of the book. But some other stories from that group are available now. Just the drafts of what they were planning, missing that story is a loss - to be fixed soon enough.

My main takes from this were:
  • start doing but prepare to find the emergent structure
  • group helps remove my writers block as I can rely on people commenting
  • more of the process of how the book is done would be useful, I find that others comments contributed to our chapter because our writing enabled commenting; commenting on just misc notes that other groups had until 4 p.m was different
  • great people, great knowledge - and lots of failures in trying agile
Addition 30.1.2013: Another report can be found in

Friday, January 25, 2013

Fear-driven testing community?

I'm about to spend a weekend on writing a book with a crowd of about 20 people on Agile - in Finnish. Thus it seems appropriate that just today I've been watching long discussions about worries that some context-driven testing community members seem to be showing towards agile.

We're talking about our fears. Fear of dismissing testing narrowly as checking, fear of testing as something that will happen in the team without details or skills, and fear for losing our right to identify as testers - people who intentionally study testing and choose to invest so much time on that that it is not possible to invest as much on something else.

The fear for our identity may go as far as saying that programmers wouldn't study critical thinking or recognizing threats to value in the products they work on. Claiming that is the core of 'being a tester'. To me, they are just to examples of skills areas that help demystify testing in agile teams. I see development as process of transforming ideas to code. Ideas we build together with diversified skills are stronger. Code we evaluate together, seeking to check they are as we intended and to explore ways we never intended. And explain what we know and don't.

I realize agile can be scary. It can be scary that we're asked to stop owning things like critical thinking and recognizing threats to value, and allow everyone in the team do those. It can be scary that there just isn't as much of what we do now to do in the future. That we don't get to do all that by ourselves. And that we need to find rationales of what makes us special in depth of skills and concurrent actions instead of just labeling it all "testing".

To me, testing includes checking and exploring. Checking helps with being able to focus on other things than the ones we're capable of checking with automation. A lot of the stuff in rapid testing has had a twist of "emergency testing" to it. Agile may remove the emergency by making it continuous.

If an agile team does testing badly as a team effort and has their feedback loop of continuously delivering to real customers / end users in place, the team will learn to test the hard way. I've seen organizations retrain  a new generation of testers this way as their existing testers wouldn't fit in the teams, through a series of failed deliveries they could have avoided leveraging the existing tester's skills. This unfit was as much due to testers not making compromises on their role as it was on the idea of "everyone must code".

Some years back, in an organization transforming to agile, we were asked "would you go back". In groups that would, two stuck out: testers and project managers. The testers felt we were losing something. But instead of going back, we looked at what we feel we lost - respect for our skills, the feeling of being needed and important. And we addressed the fear instead of allowing that to drive us to something that wasn't right for the product business.


Sunday, January 20, 2013

From co-organizing to putting things together

This post is continuation of my previous post: Bringing communities together.

FAST is not the only community I feel I belong to. FAST is my home, though. It's the community I consider first and last. It's my people.

I also belong to Agile Finland, and have been a member since it started.  Agile Finland is a registered non-profit. I occasionally go to their annual meetings too, even though I hate the sense of bureaucracy the "must keep" meetings create with their official agenda. If I'd want to do some session for Agile Finland, as a member, I think I would be immediately welcomed. But, I want to so sessions for Agile Finland that simultaneously are also sessions for FAST. I've notice this works out great as long as there is someone on the Agile Finland Board that participates. I've been hinting that I'm a member too, and I could represent both, but that tends to not be how things go. However, I'm welcome to invite Agile Finland members who are not FAST members to the sessions organized. But the board participation creates this "sense of ownership".

Co-organizing works out nicely, with two members of the respective boards. For FAST, we've done that with a project-oriented interest group ("differences in being project vs. test manager"), with a Java special interest group ("unit testing") and with agile Finland ("what's agile testing").  I like doing things for many communities on one go if possible, since before this started, it was quite common to do the same things twice. And the time is limited. Sometimes the premises will only fit a certain number of people, and choosing the primary community is a way to make sure we don't need to say no to quite so many people.

Sytyke, the organizational "home" for FAST, would love to say all FAST sessions are their sessions. The trouble they're facing, I think, is that we tend to be moving by inspiration instead based on a set plan of dates and topics. And when we have still plenty of time to reach our members, their members may already be dropped out of the loop with the chains of how information should flow that are not direct. 

I'm also paying attention now to something Sytyke initiated and Agile Finland is participating in. We're writing a book on Agile next weekend, in form of a book sprint. We set the scope in the start of the weekend, 20 people writing and out should come a book in Finnish about Agile. Since Sytyke initiated it, it's their book. Except that the book wouldn't have as much people writing it without other communities joining in too. And I for one, feel I still somehow in this mix represent FAST - but FAST is not one of the co-organizers. 

ISTQB Finland (FiSTB) is its own non-profit. FAST collaborates with them, as they are the same people. Yet, when they organize a session, it's not a FAST session usually because you have to pay for it. We're just about to start talking if there's a difference in organizing "in collaboration" or being a "supporting organization". FAST isn't promoting ISTQB, but we're not hiding it either. It's presented as one option people may choose from and I personally just make sure the other options and my strong feelings for the need of those options get to be visible too.

Internationally, I'm AST member. That is the only non-profit I pay for. I joined Software Testing Club, but have no idea if I should feel I belong there. And I'm connected with the EuroSTAR community, as a program committee member. These are all international, but feel hugely different.

My main lesson has been that to build a community, one should de-emphasize the community leader / facilitator and the board,  and emphasize things the members of the community do. With a board approach, members (and the board) tend to assume the board is there to organize the action. I'd love to see boards setting trust on the members organizing the action. There's bound to be rules of what is appropriate for each, but we should work on providing the rules in such a way that activities could really emerge without approval.

But finding the ways to do things for many communities at once, I still wonder if that will be easily doable. Time will tell.

Saturday, January 19, 2013

Bringing communities together

I've spent significant hours since 2001 on a testing community: FAST - Finnish Association for Software Testing. The words we use in Finnish are not so much about association, but more about a special interest group. And we focus on bringing together testing - in Finland, for Finland, from Finland. Not just testers, but anyone who wants to know about testing.

We have people who identify as "members". They've given their email addresses on our annoucements-list. I checked just a few days back that there's 1037 emails. Inactive ones get automatically dropped after a couple of bounces, so that should be pretty accurate.

We started a group in LinkedIn (in Finnish) a year ago, and it has turned to occasionally active place to talk. With 722 people, most are still just lurking to see what comes up.

We renewed our web pages last autumn. We've had 4496 clicks since, and best ever day since then has had 523 clicks.

A week back we joined Facebook, with now 55 people liking us there.

And, as per the people I meet in our sessions, we have people who are not on any of these lists but will show up in our sessions when their contacts inform them about something good happening. Like the fellow who won EuroSTAR supporting organization free attendance some years back - he became listed as he had already won. 

We are a community of people, without an official structure. We're organized around a bunch of active people, some of which remain, and some of which change. I for one has been "one that remains". We're not an organized non-profit, but operate as a special interest group for a non-profit called Sytyke ry, which in its turn is a part of the Finnish Information Processing Association. Some of our members are members of FIPA and Sytyke, while others are not. We've agreed with Sytyke that we can also be a special interest group of some other non-profit - testing doesn't belong to one exclusively.

We have no membership fee. We've organized a lot of different things over the years, since 2001, and what we organize is free of cost, other than the time you put on the community. Without people, there is no community.

The idea is, that any member of the community can set up a FAST session without asking the board for permission within rules - it's a session about testing, and it's free, and it aims for inclusion rather than exclusion. Marketing sessions of tools or consulting organizations tend to not be considered these, as they don't allow for conflicting views and exclude some people ("just prospective customers, no competition).

We've managed to have an active community without any official budget and all-free activity by encouraging the companies to feel part of the community. They give us premises & coffee, and we have great sessions on various topics. I'm right now preparing one for 500+ people, where the premises come from Helsinki University of Technology and the coffee breaks are sponsored by a few companies, and we have a relatively large test lab track running on the side of two talk tracks of 300 + 300 seats. We do book circles, testing dinners, trial courses, peer conferences, 100+ conferences, test competitions, testing dojos and actively discuss in our native language online.

I feel the core of this activity is that we have no budget at all. People who speak don't need to go for a decent cut of the profits. Companies are a relevant part of the community letting us their premises for  the sessions and buying the coffees. Many companies have showed, with these actions, that they have people who care about our cause enough to keep the sessions running. Testing is important. That makes this possible, even relatively easy.

If we would have a membership fee, the dynamics would change. Members would expect service, instead of being the ones serving the community. And speakers would expect to get their share.

I'm an idealist. I've refused significant amounts of money in working for non-profits for fairness arguments as I would be eligible due to official position, and the others contributing wouldn't.  I don't need the free lunch, I need the invigorating conversation. I need the community.

So, I'm looking at how to integrate this community and these principles with other, more international communities. Reaching the people that can and want to be reached with the activities we're anyway doing for this community. And allowing this community to grow from looking inside Finland to real, internationally contributing hub it could be.

Tuesday, January 8, 2013

It's not bad to know of things not testing

I've been having a bit of a hard time with one of my development teams. Hard time comes from being a barometer-type-of-personality to notice changes in the moods, happiness and work satisfaction, and seeing the impact of that in the overall results as in the bugs I need to worry about and the overall throughput going down.

In many ways, this is work as usual. Sometimes things work out better than others. But with this particular case, the trouble is that a technical team beaten to corner enough times tends to stay in the corner, and needs significant changes to play openly again. However, we have a key stakeholder in the changes who thinks no change is needed, no problems are visible and the main problem actually is that the team might not be able to cope with any changes. I consider this a conflict of belief systems, and don't expect quick resolution - while I would never give up on the change.

With trying to explain this to people in twitter, I started thinking how much good as in thinking tools I have from all the years of reading a lot (business, people, agile and testing books are my thing) and sitting though various presentations picking a piece of information here and there, and putting together the stuff that makes sense to me. In the seemingly endless effort to try introduce changes, I realized that I've had a upper hand of engaging the others with three very specific things I was aware of:
  1. Code review approaches
    When the command is "review code this month", I helped the developer to see alternative interpretations to that. Instead of hearing "wait until all mistakes have been made and correct them", I suggested he would hear "let's pair up, and see what mistakes you could learn to avoid and how I might help you with that". It's actually not the activity of reviewing they want, it's the end result you could get if you reviewed. Pair programming is a modern view to continuous review, right?
  2. Documenting a task / issue in Jira
    When the discussion is dwelling about how the requirements are so inadequately documented in our Jira tasks and how we're so excluded from all relevant decision-making as it's all been done without us while thinking through the detailed enough spec somewhere in product management with limited technical knowledge, I pointed out that we should think of the 3 C's as they relate to every task / issue we have. The Card -part is just a placeholder. It doesn't need to be specific, actually, it's better if it wasn't too specific. The Conversation -part is really relevant - after we have enough detail for the Card which is not much, the Conversation should happen. And as a result of that, we could actually put down the Confirmation -part in whatever format that helps us remember what we agreed on and will be useful. And all of a sudden, it is ok to not have them all laid out at once, since what was one is now three.
  3. Specification by Example / Behavior Driven Development
    When I asked a new developer I'm working with as the tester if we knows what I mean when I talk about SBE, I learned that his exposure to this theme is from me alone and we have not talked much yet. So, I ask him to sit with me next to my computer, and we walk though a couple of examples of Gherkin-style specifications I've been collecting on the area we're working on, basically listening in about the things we talk of and writing them down as examples. He looks at the example point out he could use that in his development. And I finally understand that while I favor SBE in talking about the practice, I would have won him over already if I talked about BDD. 

With these changes, I shouldn't complain we don't introduce changes. I just wish I had the right words to speed up all the things we could accomplish, and did not always have to do this all through trial and error, finding the right words and the right route to handle all the various details that need working on.