Markus Gärtner's Blog, page 13

Beer Coaching

To avoid any upcoming confusions, beer coaching is not about coaching people to drink beer. It’s more coaching a larger organization by putting a crate of beer in the middle in the evening, and have chats with people. I didn’t invent this one. A few weeks ago, someone told me that he was bringing a crate of beer to a client to have an opportunity to talk to some folks, and reach a deeper relationship with the ones attending.

I wasn’t convinced.

Up until a colleague convinced me to try that out at a client we are both working right now. She actually had to push me. Here is what I think now about it.

Beer coaching is a style of organizational coaching that emphasizes the personal freedom and responsibility of the individual coachee to continually optimize the quality of his/her work be treating private chat, being-coached, and drinking beer as mutually supportive activities that run in parallel throughout the coaching.

On face value, the mechanics appear easy, but it may take years to apply it skillfully. Here are the ingredients: water, yeast, malt, and hops. Use these as a baseline. Fill the result in bottles, and put 20 of them somewhere, and let everyone in the organization know.

You will have chats with people that you usually won’t meet. You will have chats with people that show up, and don’t drink beer – and that’s ok. The purpose of the meeting lies in getting connected with folks in the larger organization, and to nurture the culture change.

A survey on several successful projects show that one key ingredient is repeating all over the place. 15 out of 10 people pointed out that getting seriously drunk with their colleagues was the most important factor to team building. As a coach you can find connections with folks in this manner, and connect people with each other in the organization that usually won’t talk to each other – since they might have forgotten about that chat the next day.

Some apply that coaching skill in an unstructured manner. Having studied beer drinking groups over the past 20 years, I must say that this is not always so. For example, Lean Beer is a structured conversation that you can have while drinking beer. I have ran several Lean Beer sessions, and formats, and the combination of Lean Coffee facilitation style with beer always ends up in something fruitful. If the energy goes low, you can of course always pull “Beer” as the next topic. But be alert that usually Lean Beer will end at that point.

The same goes with organizational coaching. We faced some challenges getting deeper connected with some employees at one organization. So, as a final experiment, we tried out Beer Coaching. We had 20 attendees that evening, each one of them drank a beer with us, and we had a chat about their situation. Thereby we could find out about particular need when it comes to (sober) coaching in their team.

Since we put beer in the middle, we also had a couple of by-passers that joined us for a beer. We talked about stuff, and found out about the great experiences they already had with the thing we were coaching on. We could then connect different beer drinkers with each others, so that a culture of exchange (words) was nurtured.

Depending on your particular company, you should find a suitable spot in the building. Outside the building might be good to catch people while they are heading home, but usually a terrible idea in the winter. Inside the building right at the door out could be a better place if there are no customers in the house. We found some coffee kitchen somewhere in the basement where not too many people would run into, since one larger customer was in the building. Experiment with different locations.

Oh, and afterwards, you may find some folks willing to go to dinner as well. Of course, you can continue discussions there.

So, I can only encourage you to try beer coaching once. I certainly will.

A final word of caution: maybe this practice is better suited for certain markets. We especially tried it in Bavaria and Cologne, Germany. Sweden, Belgium, and UK might work too. I don’t know about the US culture when it comes to combining beer with work. I don’t have too many experiences with other places.

Don’t treat this blog entry too serious as you might have read it while sober.

Why I am writing so many blog entries

Huib Schoots asked me the other day whether I was on a blogging spree. I provided him an answer. Well, I answered him over twitter. So, it was more than a shallow answer. I told him that he was only seeing side-effects of what I tried to do. Actually an example that he should focus on my outcomes rather than the outputs. Here is the longer answer.

Over the years, there is one thing that helps you improve your writing. I have read about this one crucial ingredient several times, in several books. Weinberg on Writing has it. The New Comedy Writing has it. It’s a similar thing that you need to become better at anything: experience. Experience in writing can only be gained by writing.

I noticed this years ago when I wrote ATDD by Example. Every night I was sitting down to get my head around the topic, and note down anything that came up. I pushed myself to write for an hour on the book every evening. Most of the times, I worked more than one hour on the book each night because the first hour only got me started.

In the past, I had cut down dramatically on my blog. I didn’t feel I had the energy. I didn’t feel I had something important to say. I felt that I had different priorities than maintaining my blog. Early in January this changed.

But what changed?

Over the past year I have read many books with Agile and Testing in the book title that made me sick. It seems Agile has become a large misconception. With more and more successes in the larger enterprise, it seems that more and more people sell their snake oil by putting in the term Agile.

That made me sad.

So, in the new year, I realized that I wanted to change that. I realized that I could change that. I realized that I probably have to change that.

So, what does that mean? First things first. My writing muscle was out of shape from exercising too few. So, in order to be able to write something, I needed to get myself back on writing. But how do you do that? Well, so far my tactic of fire-and-forget blog publishing stopped working. So, right now at this point in time, I have a backlog of scheduled blog entries for a full week. I get myself down daily, and write. That provides me enough relief and buffer if I don’t find the energy to sit down one evening, I can do that the next day, or so.

The outcome of this is that I can get back in shape for writing. I need to do that because I haven’t dealt too much with thinking through concepts. I actually need to write right now. Why? Ever since finishing Susan Caine’s book on introverts, I noticed that writing helps me to reflect over things. Also, over the day, I collect several things that are worth writing about, but lost the gift to really get my thoughts down. By forcing myself to sit down every weekday in the evening, and produce one blog entry, I went to re-built that ability. So far, there always has been at least one idea from the day that I could dive deeper into in order to reflect on my day. If there wasn’t, I also maintain a backlog of ideas because – you know – there are days where you can’t restrict yourself to a single idea for a blog entry.

When visiting the first few conferences, I remember that people approached me. “Hi, I read your blog, I love it.” I always joked that people shouldn’t tell me about it. I maintained my blog for my own. That helped me reflecting myself. If they told me, I would probably lose my energy for writing. It seems there is some truth in there.

Last week, a former colleague of mine approached me. He told me that he loved my blog entries, but people might become upset with the typos in it, indicating that I probably should pull in more proof-reading to get them out.

To say the least, I am not writing all this stuff for the outside world, but for me. I also never visit back my previous blog entries, and read them – most of them. I am grateful if you provide me specific hints about typos. But as these entries are a side-effect of what I really want to achieve, I really don’t care whether the number of my readers goes up or down. I keep an eye on it, and you can see me smile sometimes. But clearly: that’s not my key objective here. I am not writing this stuff down for you, dear reader, I am writing this stuff down for me. It helps me remain sane, and it helps me improve my writing skills in order to prepare myself for another step.

What’s that step? Glad you asked. Right now, I am preparing my brain for another book. Having received the Most Influential Agile Testing Professional Person award last year – thank you all for that, by the way – I think I can change the world of corporate enterprise shallow agile adoption to a better place. I really want to stop the suffering I see around when consulting with various clients by under-informed and mislead agile introductions.

That said, I plan for another book. As I get more and more older, I figured I also become more and more heretic. That said – and the context-driven community is probably going to hunt me down for that – the current working title of that book that I came up with yesterday morning while running is “Software Testing – A profession that shouldn’t”.

I find myself deeply rooted in three different communities. That’s sort of a pity, since it gives you at least thrice the opportunities to visit conferences and publish articles and books. These communities include the Agile community, the Software Craftsmanship community, and the software testing community. Since quite a while I came to realize that these are deeply connected to each other. I think it’s time to get my thoughts down on that. These blog entries are my exercise for that.

That said, over the next few weeks, you might or might not see me keeping this pace. I don’t know what the future holds. So, I might find that now’s the time to start this thing. I am currently heavily feeling overloaded with work on the other hand, and I don’t know yet what I will do to find a sustainable pace again. I am not committing to anything in this blog entry. That said, in some more days to come you might find that I produce less and less here. That might be an indicator for one of the following.

Maybe I started writing that book finally. I put my head around the topic, and was able to get an initial draft for a book down. At that point I might immediately stop blogging on a daily basis.

Maybe I just found myself between work, live, another expected newborn, and the other stuff that’s up my sleeve right now, and found that I should cut back seriously on some of that stuff that I really don’t need to do right now. Maybe then I will stop producing blog entries on a daily basis.

Or maybe I just lost interest in that topic, and moved on. I found my energy currently lies somewhere else. Then I will stop blogging on a daily basis.

The bottom line: I don’t care too much whether you are happy or unhappy with what I am writing. I have a different goal right now. I don’t care too much whether I now set high expectations for a book you want to read. I might or might not produce it. These days, I seem to be attracted to overload myself. Don’t count on anything right now. Still, I find it’s something I need to do right now, and I have fun doing it. Sorry for any inconveniences.

Continuous Acceptance

Over the past year I ran a couple of Scrum trainings. At first I found it sort of funny to notice that amount of misconceptions that seem to appear in these various classes. Recently I figured that it would be more helpful to clarify some of them. Among one of the larger, and probably more manifested misconceptions regarding Scrum lies in the Sprint Review meeting. Let’s examine that one today. I am quite sure that someone has written about this before. I found that it would be worth to throw in my point of view as well.

Objective of the Sprint Review

What’s the core objective for the Sprint Review meeting? It seems that most folks think that the ProductOwner accepts the results of the sprint, that is the potentially shippable product increment. So, the core objective of the Sprint Review meeting lies in the ProductOwner marking the particular items from the Sprint Backlog with a green check mark, and appreciate the development team for their work in the past two weeks. At least this point of view is congruent with the notion that we don’t need to invite stakeholders to this meeting.

Can you figure the situation the situation where a customer, the department lead, and the CEO attend the open Sprint Review. The development team demonstrates the product increment, and shows what they finished according to the Definition of Done. Now, there was a rather vague backlog item in the Sprint. The ProductOwner now finds out that the development team has a different understanding about the item, and implemented it another way.

Only for a moment dive into this situation as a team member on the development team. Probably the one that is currently sitting at the keyboard demonstrating the product. A moment ago, you were proud of your results. Now, you notice that the face of the ProductOwner becomes more and more frowning and unhappy. “I am sorry, that’s not what I meant. You need to do this over.” Silence.

Digest that situation for another moment.

How do you feel? Do you notice the elephant in the room? Do you notice the hidden thoughts of all the developers in the room?

Let me adhere to the retrospective prime directive and not dive into this situation any deeper.

To make a long story short: as a member of the development team you would lose face in front of the stakeholders that also attend the meeting. You probably think more about what the ProductOwner did wrong with his crappy item, and I certainly think that a couple of development team members will start to fight that sort of feedback more actively.

To say the least, if the key objective of the Sprint Review meeting was to have the items, then why should you invite stakeholders at all to this meeting? And isn’t the Sprint Review meeting the most terrible moment in time to find out that you didn’t deliver anything this Sprint? I certainly think so.

The core objective of the Sprint Review meeting lies in receiving feedback from the stakeholders regarding the product increment. The ProductOwner should use that feedback in order to derive unaddressed backlog items that she can prioritize in the list of already existing backlog items accordingly. At this point having stakeholders attend the Sprint Review meeting also makes more sense. They play a central role.

Receiving feedback

While this objective sounds easy enough – it is not. The agenda of the Review meeting are quite easy. Team demonstrates product increment, we collect feedback from the stakeholders – and move on to the retrospective after closing the meeting, and releasing the stakeholders again. Finished. That’s it. Really.

Yeah, maybe the team did prepare sloppily for the demonstration part, and so on. Over time they may or may not come up with preparing the demonstration in a engaging way. Fair enough. That’s still basic in comparison to collecting feedback. Why?

In some of the classes we came up with an exercise where we work through a whole Sprint in a short amount of time. Then the whole training class comes together, some of us play the role of the stakeholder, and provide feedback. What always happened, no matter how long the training class was, is that the development team starts to justify their decisions. Also oftentimes the ProductOwner joins in this justification. At that point we actually shut down our minds for any feedback. That’s poor.

I always refer to a rule that I read in Peter Block’s Flawless Consulting. I avoid taking anything personally that happens before 6pm. I found this a helpful rule when consulting. I also found the rule helpful when reading review feedback of my articles and chapters. The same applies for a development team and their ProductOwner. They provide you with the most relevant information in order to make the product more valuable to them.

So, STFU, and listen!

Oh, and you need to trust your ScrumMaster that he will be able to handle unfair feedback, and get the discussion back on an objective level, rather than a personal one. (And if your ScrumMaster is not able to handle such a situation, you need to help him by providing him that feedback.)

But when does the ProductOwner accept items from the Sprint backlog?

Oh, glad you asked. If the Sprint Review meeting is not the right point in time to accept backlog items, when does that one happen? Ideally, the development team and ProductOwner interact with each other regularly, hopefully every day during the Daily Scrum. The ProductOwner should attend that meeting. When the team says that they finished one item in their Sprint Backlog, we can have a discussion afterwards about when to meet in order for the ProductOwner to have a look at it – and hopefully accept it, or identify remaining tasks for this item.

I worked once with a team where the first item would be finished after about three to five days into the Sprint. The development team would then make an appointment during the day with the ProductOwner to have a look at it. The ProductOwner would sit down on the test system to inspect the updated product, and the item in particular. Since there were always things that he wanted to change, one team member always joined him, and noted down everything that came up. Afterwards they put these tasks on the taskboard, and fixed the remaining problems over the next day. Usually the ProductOwner was happy after that, and the development team could move on.

The focus should move from acceptance of Sprint Backlog items during the Sprint Review meeting towards a model of Continuous Acceptance during the Sprint. That helps the development team and the ProductOwner realizing their progress within the Sprint, and not only finding that one out when it’s too late to do anything about it. I think this is a more fair model of interaction between development team and ProductOwner. In the end, none of the team roles can produce anything valuable without the other.

Let’s work together, rather than against each other.

Principles of Scaled Agility: Global Optimization

Since the last global Scrum Gathering I worked together with a couple of Scrum trainers on principles to scale Agility in the enterprise (German, we are working on an English translation). We reached a point where we want to share our current results. In this blog entry I am going to take a closer look at our thoughts on global optimization.

One piece of caution: I translated the original German text on the fly without consulting back with the others. It’s likely that we will work on the English translation and continue the word-smithing.

When scaling agile a separation of the whole product into (hopefully loosely coupled) component is mandatory. Purely local optimization of the components leads normally to sub-optimization on the level of the whole value stream. Therefore you need to ensure that always take the whole value chain into consideration.

Agility in a larger company means that there exists more than one team. Teams either work in parallel on totally different products or – what the case more often than not – on the same product. These are part of the whole value stream in the company.

Theoretically every team could find local optimizations that improve the own team. Unfortunately in complex organizations that does not lead to optimizing the whole value stream.

Local optimizations can be found surprisingly – and scaring to me all the time – in large organizations all over the place. For example take a story that Cem Kaner shares in his videos for the BBST course series that he once worked for a company where the testers were rewarded for finding more bugs. At first this might not seem to be sub-optimization. But in the same company there existed a second sub-optimization that makes the case more prevalent: the developers were rewarded for fixing more bugs.

In the end in that company there was no longer software developed any further although both departments clearly produced optimal results – according to their individual measures.

What was missing was the consideration of the whole value stream. In a football game (football in the European sense, not the American one) my team won’t be any better if I demand to have all players running as fast as possible for the whole 90 minutes. In the end, the goal to score a goal with the ball has an important role to play whether Germany or Spain wins the World Championship.

In general this raises the question how to watch out for the whole value stream. We derived three sub-considerations on this:

transparency on all levels
prefer in-person interactions
create flow and rhythm

Transparency on all levels

All participants can inspect all information they need to make meaningful decisions for optimizing the overall situation. This includes especially objectives, facts, decisions and the current progress. To achieve that it’s not enough to collect this information and make it available statically. Dynamic exchange of relevant information is one of the key factors for continuous improvement.

For empirical process control to work transparency is important. Transparency is important so that self-organization can unfold and establish. Only when all employees have access to mandatory information on a daily basis are they enabled to make optimal decisions – and to speak to others if they don’t agree with their decisions.

You cannot create transparency only by providing all information for everyone. Depending on how effective that individuals filter out information that is meaningful for them, you might create an information overload. That is why dynamical exchange on the provided information is at least as important than the information itself. Through exchange with colleagues we find out whether we have a common view, and where hidden assumptions leak into our evaluation.

Transparency comes in two flavors: a comfortable flavor, and an uncomfortable one. The uncomfortable means that employees will notice clearly if they do harm to the organization. The comfortable flavor enables leaders and managers in the organization to accept more decentralized structures without risking the organization as a whole. Since all participants have access to all necessary information, they can also make good decisions that do not lead to local optimization, but instead improve the organization as a whole.

Prefer in-person interactions

Direct in-person interactions provides the highest information bandwidth to exchange knowledge, skills, objectives, needs, and concerns. Oftentimes implicit information and assumptions reveal themselves in direct interactions. In-person interactions are important within a single team, between several teams, and with the remainder of the organization as well.

In Tacit and Explicit Knowledge, Harry Collins describes the connection between tacit and explicit knowledge. He also identifies a set of ways to transfer knowledge. According to Collins knowledge can be transferred through writing, a translation of written words from one language into another, but also through coaching rules, for example as we use them when we learn to ride a bike. Beyond that a collection of knowledge is embedded in our cultural background. We cannot transfer knowledge about a dishwasher by dropping one down in the jungle. The jungle folk would need to invent the concepts of dish, electricity, and fluent water to make any meaning out of it.

In order to create transparency and good decisions, personal bilateral interactions are necessary. I remember a project I was part on a couple of years ago between an office in Germany and another one in Malaysia. We had an one-hour meeting on a daily basis in order to coordinate work between the two subsidiaries. Over time, though, we found out that something seemed to be wrong. During the teleconference we talked about things we wanted to do – and yet we were displeased by the other office (vice versa). Two weeks later the project managers in each office were able to switch from telephone to video conferencing for this meeting. We had a totally different meeting at once. We could see each other live. We could also see when someone didn’t get a particular sentence on the other side. Those meetings became dramatically more effective since we didn’t need to have long discussions about obvious things, and we could concentrate on the things that we disagreed with.

In the early years of this century, Alistair Cockburn published a lot more on the effectiveness of communication channels. In his work he raises the importance of in-person contact and bidirectional communication channels. Of course these principles apply to small as well as large teams, and their interactions internally, between each other, as well as within the whole organization.

Create flow and rhythm

Flow and rhythm across the whole value stream are an important pre-condition for hyperperforming teams. These teams flourish based upon clear objective, intensive synchronization, and fast (or eliminated) hand-offs.

Through the regularity of the Sprint a rhythm is created in Scrum. We meet daily to coordinate together. Every two weeks we sit together to plan the next two weeks and inspect the results of the past two weeks. These regularly appointments lead to regular synchronization.

In a scaled environment we need to extend this regularity to the whole value stream. The teams work in their own rhythms, but they have interfaces to the larger organization. That’s why they need to interact with other teams regularly.

In large organizations I can create flow and rhythm through regular retrospectives across multiple teams, maybe through a product release cadence, and exchanges within so called communities of practice. In practice releases with collective retrospectives create synchronization on product and process level. With exchanges among specialists, I can create a common view for example on the system architecture. This leads to fewer conflicts between multiple teams.

Why is global optimization so important?

For me, one of the key reasons that large organizations develop software slowly does not come from more complex or complicated products. Instead many local optimizations slow down the whole development, and therefore the whole value creation process. Since there are more potential local optimizations in larger organization, when introducing agility in these companies setting the focus on global optimization is very important. In the end, we don’t create more value faster when, for example, the test department finds many bugs quickly. The whole company can improve more if it finds ways to prevent as many of these bugs the next time to start with.

Global optimization helps us keep that common objective in mind that makes all of us faster. Transparency and direct interactions are the key drivers for this. We can make decisions more easily in a decentralized way. We also need to consider the role of the managers in agile organizations to achieve this. We also considered this important area. Christoph Mathis will be dealing with the topic of supportive leadership.

Professional testing organizations

There are a couple of professional organizations out there. I joined a few of them. How did I pick the ones that to join, you ask? This blog entry serves as an overview, and a decision aid for tester folks also looking forward to become more professional in their work life.

An overview

There are a coupe of professional testing organizations out there. For me living in Germany, there is the German Testing Board which spreads knowledge around ISTQB in Germany. My network never really consisted of people around that board. I never attended a class from them. I never felt addressed by their material.

Then there are the folks from the ASQF. These organize local user group like events. I attended a couple of these. I always found that these folks were quite open. They helped spread the word about a variety of topics. That is worthy content. However, I think you need to be connected to one of the organizers locally to get to know about these events. To attend a meeting, I joined their announcements. From that day on, I feel more connected to them through their announcements every 2-3 months. And I also get updates regarding the next upcoming events.

At some point the Association for Software Testing appeared on my networks. At first, I didn’t know what they were doing. Over time, I noticed that AST kept on coming up with an annual conference. And they ran online courses on software testing. At a certain point in my life, I decided it was worth the 80 bucks a year to join them, and support the work they did. They appeared to move forward the idea of context-driven testing. That was a fruitful thought. Also, they supported local peer conferences, and as organizer you could get some financial support if you organized a workshop on your own.

Back last year, I was contacted by the founders of the International Association for Software Testing. I knew all of the founders from the Let’s Test conferences, and knew whatever they started would have a good basis. I decided to support them from early on. While I don’t know yet, what they might deliver over time, I stay curious how I might contribute to that. But then, on the other hand, I seem to be pretty busy these days. Time will tell.

Picking the right one

First of all, be aware that most people working in professional organizations are putting in most of their work on their leisure time. The problem with good professionals and leisure time is that it’s hard to balance the daily job with the community work. Both are important, and ideally both should support each other. Sometimes they don’t.

That said, from the outside most of these organizations may appear that they hardly achieve anything. That makes picking the right one more difficult. Most of my picking had been by peer recognition. The folks I met at conferences that talked about something reasonable were also the ones that listened dearly to. From those folks I could grasp what they received from those organization, but also where the criticism in the others were.

My personal background consist of a giving attitude for most stuff. For example I joined three different swimming related clubs in my past after having received so much from one swimming club for ten years. I felt that I needed to pay some of that back. 16 years later, I decided to move on, still wondering whether I paid enough back myself. I still feel connected to these institutions, and look forward to every news entry from them. I am still a paying member for that swimming club that I joined when I was 6 years old.

The same applies to professional testing organizations. For example take the Association for Software Testing (AST). They helped Cem Kaner create a set of online classes, that they are now teaching in a peer fashion. Instructors are grown based upon attending and facilitating classes. When you attend a class, you can give some of that learning back to others. That attitude is pretty much in congruence with my underlying value system.

Help advance the craft

When it comes to professional testing organizations, one thing stood out for me: peer recognition. That comes with a chicken-and-egg problem. If you are not out there talking to other testers outside your company, you are unlikely to get one recommended. That’s a pity, since most of them provide learning content that can help you become a better tester on your own. I think some of these organizations might do well raising the outreach by visiting large companies, or providing online learning material like courses and webinars.

To get in touch, try to look for an event near you. Attend it, and ask people how they keep on learning about their profession. Over time you will not only be connected to several folks in the industry, but might also find people that make more sense for you. Listen to these folks with an open mind.

A final piece of advice: before pre-maturely joining one organization, first observe what potential value they bring to your craft. You want to avoid spending a tremendous amount of money before you know it’s worth giving to them.

Why should just the developers have all the fun?

Back in 2009 I attended my first coding dojo. It did not take long for me to realize that it was fun, and all the programmers in that setting learned a lot. Ever since I was convinced about what some call Deliberate Practice. It’s a practical exercise to help you learn a deeper understanding of a skill – most often accompanied with a mentor or coach that provides you feedback. Let’s take a look into various formats that are suited for testers.

Testing Dojos

Back then I started to investigate in an idea called a Testing Dojo. Initially the setting was basically the same as in a Coding Dojo. Someone prepared a problem for the audience, introduces it, and the group goes to do their thing. We started with paired testing, and testers changing back to the audience every 5-10 minutes. That worked quite well in smaller groups, but became sort of a pain while dealing with larger groups.

That’s when I experimented with changes to the environment. Nowadays I use multiple pairs on the same program together with debriefing sessions in between. I called these Testing with a Stranger. Eventually I also use the same format for my Exploratory Testing class, leaving a bit more time to provide the introductory concepts in the beginning. I am quite happy with that format.

Weekend Testing

Weekend Testing came up at the same time as my Testing Dojos idea. The idea is to meet online rather than in person. Tester receive a mission, test for an hour, and come back to a facilitated discussion after that. Most learning happens during the facilitated discussion.

I co-organized Weekend Testing in Europe for nearly a year. One guy, Mike Scott, started to organize Weeknight Testing in London. In early 2011 we organized a connected Weeknight Testing session spread across the globe at Hamburg, Germany, London, UK, and San Francisco, California, USA. We worked mostly among our local groups (we had 9 in Hamburg, if I recall correctly), and did the facilitated debriefing together through video chat. That was awesome – but took a lot of energy. Maybe that’s why it didn’t happen again, yet.

Testathon

Earlier last week I was contacted by who is organizing a Testathon in London. The idea is pretty simple: test stuff with other folks, learn from them, and maybe win a prize. A Testathon is a Hackathon for testers. I was surprised to hear about that idea – and I look forward to the results and reports. Unfortunately I can’t make the date, but I would like to organize one in Germany at some point. So, if you are interested – have an app, a prize, or willing to co-organize – drop me a line.

Exploratory Testing Retreat

Since some time, I am thinking through a concept that brings together the format of a Code Retreat with Exploratory Testing. I think I have some ideas that would work well. The biggest challenge though will be to find something similar as the “delete your code” statement from the Code Retreat format.

The idea would be to work with 6 different pair partners over the course of the full day. The facilitator would throw in different constraints for every session, and help the pairs during the testing. For sure, we would run the testing in sessions. I hope to run one or two of these within this year.

Moving forward

Of course there are other formats like the Test Lab found at regular conferences, testing challenges given out during evening events at conferences, and so on. Testers should have fun, and ideally would be coming by their intrinsic motivation to these events. Some swag does no harm, though. Some money can also raise the attention of new testers to put their best efforts in. Though, that shouldn’t be the primary goal to attend such events.

Since a few years, I set up a website in order to collect some of the missions and products to test at such events. You can find the website at testing-challenges.org. I think a growing knowledge base for such challenges can nurture the larger community that appears to grow around the topic of deliberate practice. If you are willing to help me maintain testing-challenges.org drop me a line, and I might provide you writing and editing rights to that wiki.

Overall, I think these initiatives help move forward our craft. It will eventually also lead to more developers becoming more interested in testing. I consider that a good thing, and look forward to that brighter future.

ScrumMaster in need, part-time

The other day, I received a mail from one participants of an introductory class on Scrum:

I am working as a development team member. We are looking for a ScrumMaster, and I want to take on this role. I agreed with my boss that I still need to contribute as a team member, and therefore will work 50% as ScrumMaster, and 50% as development team member.

While thinking this through, I got some concerns. I think it’s not a wise idea to become the ScrumMaster for the team that I am also developing in. What are your thoughts?

As an alternative we have a closely related team. I could work as a ScrumMaster there, and their ScrumMaster joins our development team. What do you think about such a solution?

Since I run into this type of question often, I found I should publish my thoughts on it for future reference.

The ideal

Some folks will complain. “The ScrumMaster job clearly is a fill-time dedicated role.” I agree to that. Unfortunately not all companies are willing to invest that. A former colleague of mine blogged about 42 tasks for a ScrumMaster that could help as an indicator how much work a good ScrumMaster puts into his job.

The ScrumMaster should seek opportunities to improve the Scrum team to deliver better products faster. He needs to talk to development team for that. He needs to coach the ProductOwner. He needs to facilitate meetings, mentor team members, coach the team and individuals. He also needs to collaborate with the larger organization about organizational impediments (such as part-time ScrumMasters). He needs to help the development team remove impediments. If a ScrumMaster cannot dedicate 100% of her time to fill the role, the Scrum implementation is likely to fail providing the benefits of competitive companies.

The bottom line: if you can’t dedicate 100% of your time for the role of the ScrumMaster, don’t do it. You are likely to do a terrible job, and not fill in the role. You will be challenged between development team work and the role of the ScrumMaster. You will be part of two parties, and it will drag you down.

ScrumMaster for own team

However, corporate reality at times is terrible. So, let’s dive into the pros and cons of either of the proposed solutions for the part time ScrumMaster.

When the ScrumMaster s ScrumMastering at the same team she is also developing with, then the ScrumMaster is co-located with the team, and knows many details about what works, and can trigger the “right” difficult-to-answer questions, and coach the team to become better every Sprint based upon those insights. Since she is working with the development, she knows the elephants in the room, and she knows when the team needs team building. She is interacting with the team colleagues on a daily basis, and probably applies pair programming with everyone of them.

On the downside, facilitating the meetings can be a drag if you are involved in the contents of the meetings. Especially in the retrospective you might lose the role of the facilitator, either on purpose, or just as seen from the outside. At that point you will be ineffective as facilitator. Also, personal coaching may or may not work with team members that you interact with on a programming basis every day. For some people it’s difficult to open up in front of people they will work on the same level in the code. Be aware of that as well.

Bottom line: I would recommend to get some help (mentoring, coaching, training, …. whatever suits you) for the role as facilitator. Especially since you fill a two roles on your team, your colleagues will have a hard time to differentiate in which role you are saying what, and are likely to misinterpret it. There are some facilitation tricks that can mitigate that risk. Whatever learning suits you most, can help you become a clear facilitator, and a clear team member for your team.

ScrumMaster on another team

You are not involved in the Sprint details, and can maintain your outside perspective, providing feedback to the team members. Facilitating will be easier. If your work is similar than the work of the team you are developing for, then you can also bring up and address common problems more easily.

On the downside, you won’t be able to attend the retrospective meetings of your own team if it’s scheduled at the same time. It also depends where you consider you should sit to get the right insights. If you sit with the team where you are developer in, then you will have greater identification with the work of that team, and might oversee details regarding team building in the team you are ScrumMastering. If you sit with the team that you are ScrumMastering, you will have greater insights into their team building, but might not feel as part of the team where you are developing for.

Try to sit with both teams if your office allows that. You also need to find a buddy for meetings like the retrospective where your buddy can provide your input to that meeting as well. It will be less than optimal, since you are not in the room to help drive insights, and you will not agree on actions in those meetings, and will therefore have a lesser identification with the results. Be aware of that.

Sometimes you have to…

Actually, I can’t really answer the initial question for you. The bottom line is: don’t do anything fewer than 100%. If you cannot avoid that, then you have to pick your battles. The consultant’s answer there is “it depends”. I hope I helped you identify on what it depends, and where your strengths and weaknesses may contribute to a possible solution for you.

Lessons Learned from the “Danger Zone” in Hamburg, early 2014

When I went back to work in the first week of January 2014, I was surprised. Right before Christmas some rallies started in Hamburg. For whatever reasons, some folks started to make fun out of the high demand of police that was present in certain areas of Hamburg – the so called danger zone. Let’s see what I learned from the news about those folks.

(Image credits: http://www.berliner-zeitung.de/politik/rote-flora-gefahrengebiet-hamburg,10808018,25818092.html)

Artists

(Image credits: http://zapp.blog.ndr.de/klobuerste-hamburg-gefahrengebiet-tagesschau/2014/01/09/)

The folks who went on the streets were protesting against arbitrariness of police forces. For up to three weeks parts of Hamburg were put under special rights. Police forces were allowed to check every person – and so they did.

The gamification on the internet though became very creative. “You get one constitutional law for 100 checks by the police.” Folks attended those games started to put toilet brushes in their trousers and cloths to make the impression they were wearing more serious weapons – thus being checked more frequently.

I think these folks were really artists. They were creative in their minds, and didn’t let the felt oppression kick in. Instead they took the courage to make some obvious fun out of it. Their acts were artisanal.

Next time I feel oppressed I will free all my jiggling skills, start being creative, and become an artist.

Futurism

(Image credits: http://revolution-news.com/day-3-of-dangerzone-protests-in-hamburg-police-lies-exposed/)

The crowds in Hamburg at the beginning of 2014 were driven by a vision of a future. On one hand they were afraid of a future where the police – the executive force – can act arbitrarily against anyone. They were afraid of a police state where the executive force became judge and politics. An imbalanced view.

On the other hand these crowds were motivated by their future, a future of freedom, where everyone could express their thoughts freely without risking to be put into prison. These folks were driven by the vision they had in their minds. They knew they had a better vision of the future in mind. They knew it was worth fighting for. They knew they needed to pick their battles.

The danger zone soon became a vision of a future that no one wanted, and everyone fought against. Mothers with children, tourists like me, yet everyone on the streets were confused about that. Even politics outside Germany took notice. The US warned about traveling to Hamburg in that period. The crowds fought that outside picture of Hamburg, Germany as well.

The next time, I feel something’s deeply going into the wrong direction, I will fight passionately for a better future.

Teams

(Image credits: http://www.sueddeutsche.de/politik/reaktionen-auf-scholz-interview-gewalt-ist-liebe-und-das-gefahrengebiet-ist-demokratie-1.1861403)

These folks also knew that they had a higher impact if they joined forces. That did not only happen through the internet in online forums, but they also met in person to march through the danger zone. People joined forces because they knew that only made them stronger. They knew that would make their message stronger.

While walking through Sternschanze and St. Pauli in those days, you could hear the voices of those crowds. They were forming teams. They had a clear goal in mind. They had a shared vision. They knew where they were heading.

The next time I will pick a fight, I will find people who share my vision. I will find people that I can convince about my vision. I will know that I need to find other folks that can support me.

Anarchy

(Image credits: http://www.stern.de/panorama/reaktionen-auf-hamburger-polizeimassnahme-wo-gibt-es-einreiseantraege-fuers-gefahrengebiet-2081626.html)

The shouts of the crowds were scary to me as someone who just wanted to work for a week in Hamburg. It was frightening, and it felt sort of like anarchy. I remember on Sunday I left the train in the danger zone, and didn’t notice much at first. When I left the train station, I was confronted with some folks. Folks on the street ran into my way to provoke me.

From a distance I didn’t always realize it, but it was anarchy. People on the streets did everything in order to expose the police state that was in place in those districts under the danger zone.

The Romans considered anarchy to be democracy turned bad. In hindsight, I think the anarchy in place wasn’t bad after all. These folks were fighting for something they believed in. These folks convinced me about their goals. They convinced me enough that I would have felt oppressed when being checked by police guards. These folks knew it was easier to ask for forgiveness rather than allowance.

The next time I am finding myself oppressed, I will get rid of this feeling, and take action. I will call out anarchy, and move forward. Maybe I will never have to ask for forgiveness.

ARxTA

(Image credits: http://www.nwz-inside.de/News/Deine-Welt/Spotlight/Leben-im-Gefahrengebiet,58849)

In 2009, Brian Marick talked about Artisanal Retro-Futurism ⊗ Team-Scale Anarcho-Syndicalism. He was referring back to early days of Agile in the software world where people would tear down cubicle walls on the weekend. He was talking about information radiators put on office walls that were protected by the furniture police (state). He talked about joined forces rather than sole people fighting for their rights while others watch.

The situation in Hamburg in early 2014 reminded me about that talk. Next time at work, I will apply artisanal retro-futurism crossed with team-scale anarcho-syncdicalism when I truly believe it will be necessary. Would you join me?

What if…

What if you found out that you were living in a matrix? That the world before your eyes has been blurred. That a lot of the things that are dear to you actually are counter-productive to your goals. How would you recognize this?

Some years ago, with Systems Thinking, I started to realize some problems with my own thought processes. Ever since then my realizations went worse. I am too frank to face you with the full truth. Still here are some stories worth thinking about.

Speeding cameras

This first story is a story I heard last year that I could resonate well with. Some years ago, in the UK, there were some examinations regarding traffic accidents. For high-risk areas politicians declared they wanted to put speeding cameras in place in order to have drivers adhere to the speeding limits. The proposal was concluded, and the speeding cameras installed.

Skip forward a few months. Another study considers the effectiveness of speeding cameras. Researchers dive into the numbers, and come up with the following conclusion: ever since the speeding cameras were installed, the number of traffic accidents in that area went up – not down.

Now, the logical conclusion would be to get rid of speeding cameras at all. Unfortunately us humans make more political rather than logical decisions. Since the speeding cameras created another income for the city or county – an additional income that was already planned for – the speeding cameras were not removed.

What happened? While the rational argument when it comes to traffic accidents pro-claims to remove the cameras, the political decision prevailed.

Group leader

Your boss asks you whether you want to take over the leadership for a group of people. You feel honored, and want to please your boss. But you have personal doubts, and express that you would need guidance because you never did something like that. Your boss tells you that you can get the mentoring and training necessary to fit into that role. You feel satisfied, and agree to step up into that position.

You start working with your colleagues. You consider yourself part of the group, and try to make decisions as equal among equals. You try to ping back and forth ideas, but progress seems to be slowing done, and you don’t know why.

Surprisingly for you, one of your colleagues expresses a thought in a discussion that is new to you. You start to realize that he sees you in a different role than you see yourself. Immediately you realize that you have a different influence – and outside perception – just because you replied ‘yet’ to accept that role. You notice you are received as “the bad boss” in front of your colleagues, although you try to lead reasonable arguments. You realize that with your position in the way you cannot have reasonable discussions to move forward anymore. And you also don’t want to lose your face by stepping back from your position. What do you do?

Manager

You are hired as a manager for a department. You work with your group leaders and other managers to provide the best value possible. You are busy working on improvements, making decisions based upon the best of your knowledge, and the support of all your staff.

One day you notice that your competitors are delivering similar product with one third of the staff size in one tenth of the time than you do. You are not sure how they are doing other than that they are working harder.

You find out, that the department you lead actually harms the progress and revenue of the company. You notice that the existence of your role as a manager of that department leads to sub-optimization, extra work, and more costs for your employer. You notice that the things that keep you busy are actually causing you to become even more busy, and hire more staff. One hand you like being responsible for more people, and love to take care for them. On the other hand, you notice that you are hurting the very company that is paying your paycheck each month. What would you do? Risk your employer run out of business because it cannot deliver similar products at comparable speed and price? Or do you try to convince your bosses and your colleagues that you are causing more harm with your work?

What if…

Life is more political than you think. At times, life can be as political as a senat discussion without you noticing that. The stories above are drawn from real situations – only the names have been changed to protect the guilty.

What if you were too bling to see the light? What if your current perception of the world keeps you from seeing the reality? What if your current desires like money, position and salary, and status keep you from seeing the trouble you are creating? How would you like to wake up? At once like getting up from a nightmare? Or slowly fading out of that dream? Waking up by someone else or by yourself?

I have tried to wake up some of these folks, and I have tried to wake up myself in comparable situations. All of them involved unpleasant news, foreign elements in Virginia Satir’s terms, and mostly the persons involved to accept the situation. It’s hard to live in the real world at times – but transparency can help us improve. Don’t turn your eyes away from it.

Focus on outcomes, not outputs

When it comes to focus, I am deeply convinced that you should focus on the right things. That raises the question what the right things would be. In the Lean community there is a saying that we should not focus on outputs, but rather on outcomes. Let’s try to turn this argument around, and wonder how we can focus on outcomes rather than outputs.

Daily Standup Meeting

The main objective int he daily standup meeting – whatever process model you follow – does not lie in the output – the updated sprint backlog in Scrum, the updated Kanban board when using Kanban, or whatever you. The updated board is an output from the discussions that should arise. So, what is the main objective in this meeting?

It’s that the team should coordinate itself in order to provide the best value possible up until the next time we get together. The main objective lies in coordinating the team’s work. The updated board is a result of that, and should be a means to that end.

User Stories

The key value of a user story does not lie in the adherence to some kind of user story template.

As a user

I want business functionality

so that I earn more money.

This would be a user story that is completely adhering to the template. But is it helpful? Or guiding? Well, I don’t think so.

That is, it is focusing on the output, the phrases in the user story, rather then the outcome. As Ron Jeffries put it, a user story consists of three Cs:

Card
Conversation
Confirmation

Ideally the team should spend 90% of their time on the outcome, the second C, conversation. The outcome of user stories lies in the shared understanding. You can generate a shared understanding of a feature to be built in the most efficient way by talking face-to-face about it. That’s the outcome of a user story. Focus on that – not so much on the template.

Acceptance tests

When working with acceptance tests, you can focus on expressing the acceptance criteria quite perfectly in the tool that you picked. That’s focusing on the outputs, rather than the outcomes.

As with user stories, the biggest value of acceptance tests lies in… the discussion. The outcome is a shared understanding of the feature to built, and the constraints that you need to fulfill. The constraints are expressed in some manner using a language of the tool that you picked. But the bigger value comes from the shared understanding.

Also consider that automated regression tests is rather an output from the acceptance tests rather than an outcome. It’s perfectly fine if you throw away your acceptance tests – before or after automating them. The shared understanding is the bigger value.

Planning

When dealing with planning, be it Sprint Planning, Release Planning, or traditional style project planning, the value lies in the planning activity, and reaching consensus about it, rather than the output, the plan. No plan survives the first contact with the enemy. Having a release plan really means that you have a notion of the upcoming release cycle, and guess that based upon your guesses in estimations and your past progress you are able to deliver this piece of functionality. Sounds like too much vagueness for me to be real. The outcome of the planning activity though lies in the shared understanding about what we are going to focus on for the next timeframe. That’s the higher value proposition.

Now what?

Next time you boss asks you to do something, and you have the impression that he’s asking you for a deliverable, ask for the reason for that deliverable. Most of the time there should be both, a consumer behind the deliverable or artifact, and an outcome that is a side-effect of producing that deliverable. Try to understand what’s more crucial for your situation right now, the deliverable, or the outcome. In the long run it will serve you better to understand those forces at play.