Agile Testing Day Netherlands 2014

/by

Agile Testing Day Netherlands 2014The well-established Agile Testing Days will reach Den Haag on February 13, 2014 for a one-day conference and we’re very happy to be sponsor of this great meeting of Agile-minded software testers. Our founder and strategic coach Andrea Tomasini will deliver a keynote presentation controversially titled Agile Testing is nonsense, because Agile is Testing.

The friends at Agile Testing Day Netherlands 2014 have prepared a Christmas special until December 23rd, you can get the ticket for 375 € instead of 500 €. Seats and tickets are limited to 150 people. As a passionate software craftsman make yourself a merry little Christmas and grab a ticket for you or a friend or employee who was not naughty, but nice during the whole year to send them your season’s greetings! For further details please visit www.agiletestingday.nl.

AgilePalooza Conference in Austin

/by

Last week saw me try out a short talk on the art of agile portfolio management for the first time. Sharing the stage with a very strong line up, including Mike McLaughlin (), Jan Thomas, @DavidHussman, Russ Fletcher (@davisbase) and @DamonPoole. With two tracks – a planning and a practicing track – the talks were entertaining and informative. It was a pleasure to sit in on a number of speakers and catch some interesting and thought-provoking talks.

We started with a warm-up at Dell, which to be fair was much more than a warm-up. Over 250 people on site, and a further 150+ people worldwide plugging in remotely, the day was busy with full rooms, plenty of insightful questions, and lots of feedback. 
Creating Powerful Teams
I started with my Building Powerful Teams talk (http://www.slideshare.net/davesharrock/great-agile-teams-sdec13-winnipeg) which was followed by some great questions. The premise of the talk is really about revisiting the Scrum definition of the Development Team. We first considered three characteristics of great agile teams: cross-functionality, size and collocation. A brief overview of the difference between self-organization and cross-functionality; only great sports teams show self-organization, while every sports team has a cross-functional teams with loosely transferable skills. A more in-depth discussion on size – including sharing the Ringelmann Effect which maps the impact of coordination losses and, a significant concern many people are hesitant to draw attention to, the impact of social loafing. While I suggest in the talk that there is a perfect team-size (6), at least according to several studies, the critical piece is testing the impact of different team sizes on the outcomes the teams produce. 
Finally, I ended the talk with a review of the Harvard Business Review Six Common Misperceptions about Teamwork: article http://blogs.hbr.org/2011/06/six-common-misperceptions-abou/. A favourite article with a number of very salient points.
In closing, there were some excellent questions around tools used for enabling better communication and collaboration between distributed teams. While anything but an exhaustive list, the following are a number of tools several clients we work with have found to be useful. Note they are generally free (at least to start with) with all that that implies for corporate usage. And I’m not talking about the agile project management tools, but rather tools that enable better collaboration and communication between team members
  • www.linoit.com: a great sticky note tool used very successfully for any sticky note exercise requiring input from a virtual team (e.g. Retrospectives)
  • www.cardboardit.com: great for story mapping or any sort of product visualization exercise. As the marketing says, if Google Docs and Post-it Notes had a kid, it would look like cardboardit.com
  • www.planningpoker.com: the free tool for handling relative estimation using the classic Planning Poker approach across distributed teams
  • Skype, Google Hangouts – for keeping everyone in touch, having a permanent chat window open for the team, or even better, a permanent video call open, allows for much higher bandwidth communication
  • Yammer – a tool for those conversations that require a little more permanence than those conversations offered by Skype or other IM tools
Agile Portfolio Management
On to the main event – while there are plenty of conversations around building teams and standing up agile teams to solve immediate problems, the challenge of coordinating activities across multiple projects, products or programs is fraught with opinion, advice and ‘best’ practices. This is a difficult problem, and not one that can be simply addressed through the mindless application of someone else’s successful practices. Like the American auto manufacturer executives trying to replicate the success seen at a Toyota manufacturing plant by copying process, agile at scale is a principle driven change, not a practice driven change. (For those who aren’t aware, the American auto manufacturers were never successful in achieving the same productivity and quality gains Toyota was famous for by replicating practices alone. They had to dig in and understand the culture, which was a much tougher problem to solve.)
The challenges the scale of an enterprise inflict on an agile organization can be summarized as difficulties in creating transparency, maintaining focus, and increasing communication. All three are simple on a small scale, but quickly become difficult and are negatively reinforcing (getting harder and harder to address, the larger an organization gets) as we scale an organization.
I gave examples of three principles taken directly from the Lean and Agile principles underlying any Agile change. While they are not the only ones that have an influence, they certainly help address the three costs of scale, communication, focus and transparency.
#1: Focus On The Whole
#2: Deliver As Fast As Possible
#3: Make Progress Visible

Finally, in closing, I touched on the influence of the PMO. Although definitely passing remarks, an interesting metaphor I uncovered was that of a pilot. While we definitely want a pilot to get us out of trouble when things go wrong, our expectation is that the pilot will rely on the autopilot for most of the time, letting the plane literally fly itself. While doing so there is plenty to do: Watching that the plane is on course, acting within its design parameters, and heading in the right direction, at the right speed, while avoiding any turbulence on the journey. However, the pilot only takes the controls in extreme circumstances, leaving the autopilot to do its job most of the time. A great metaphor for the PMO – rather than a process policing or controlling function, the PMO is there to monitor progress and add their expertise in extreme circumstances.

For more thoughts, notes and commentary, check out my Storify report from the day.

The truth about collective responsibility

/by

A statement I hear regularly about collective responsibility, is; “When everyone is responsible, no one is responsible”. These statements usually come from managers, who prefer to have a single person who takes the full responsibility so they can hold one person accountable.

The Gallop organization performed a meta-study of employee engagement and found that high employee engagement results in measurably better profitability, productivity, customer loyalty and quality.

So let’s look at what motivates people in their professional environment, as described by author Dan Pink:

  • Autonomy
  • Purpose
  • Mastery

Autonomy

Boss or Leader

Autonomy is the desire of people to be self-directed. Traditional ways of management leave little room for autonomy. Managing people means directing them, giving instructions and assigning units of work to individuals. This is great if you want compliance, but if you want engagement, self-direction is better. 

To create an autonomous environment where people can self-direct, you need to inspire people, and help them to discover their talents, sometimes talents they were not aware they had. To do this you need leaders, not just managers, who will lead by example and show them the way first, but with the goal of allowing to think about the best way they can do their job. 

Purpose

Purpose means being part of something that serves something larger than ourselves. When profit motives exceed purpose motives, things can go downhill fast. Dan Pink describes this is his book Drive: The Surprising Truth About What Motivates Us that rewarding activities can extinguish motivation, diminish performance, crush creativity, crowd out good behavior, encourage cheating, shortcuts and unethical behavior, become addictive, and foster short-term thinking.

When people have a purpose, it inspires them to take action. When people are really feeling they are part of the bigger goal, they are more likely to be creative and come up with innovative solutions. Leaders should inspire people to achieve long term goals, not financial ones, but by painting a vision of a goal to work towards, a greater goal of which they want to be part of.

Mastery

Mastery is the urge to get better at things that matter. Whether it’s learning a new language or being part of a project that challenges or inspires, people want to get better at what they do. Leaders should inspire and encourage people to learn and provide an environment where they can learn.

A side effect of learning is that it stimulates your intelligence and creativity. There are studies that show that taxi drivers in London have more developed brains than ordinary Londoners. Having to learn new routes and react to unforeseen situations is stimulating their brain to develop.

It seems to make a lot of sense for organisations to have people working for them who are willing to learn and get more intelligent by doing so, doesn’t it? 

But how does this fit in Scrum?

There’s a lot of talk about self-organising teams in Scrum. To properly understand how that works, we need to involve the team in the larger picture. A good user story defines a problem in such a way that the solution can be implemented end-to-end, cutting through all layers of the architectural cake. This requires that different team members can bring different experiences and expertise. In Scrum we give teams autonomy, by enabling teams to self-organise. People who are closer to the problem are more likely to make the right decisions, and cross-functional Scrum teams (should) have all the knowledge they need to come up with solutions together.

We define the boundaries to the problem definition by defining acceptance criteria to User Stories. The team can then come up with the most optimal solution within these boundaries, sometimes referred to as thinking inside the box.

But setting these restrictions on User Stories alone is not enough. How can we expect people to come up with the best possible solution when they don’t have a clear understanding of the long term product direction? By defining a engaging Product Vision which sets this clear direction, teams can understand the User Story priority in the Product Backlog and see how each User Story contributes to achieve the vision. Better yet, they can use their combined technical expertise to suggest alternatives which are easier to implement and deliver almost the same value, resulting in a higher return on investment. They can even suggest to add User Stories to the Product Backlog which are quick win from a technical perspective.

When I worked with a mobile messaging provider, the company wanted to add a feature to show the people with whom you exchanged messages most, at the top of your contact list. The team immediately saw all kinds of technical complexities: during what period? should this be stored on the server? is the length of the conversation a factor, etc. They then realised that listing the last five people you exchanged messages with would bring almost the same user value at 1/10th of the cost. The team was able to propose this idea because they understood the user needs and felt that they were also responsible for the return on investment. 

When people are trusted to come up with solutions autonomously, they will begin to feel more responsible for their work, inspiring them to be creative, do research, and have a need to master the skills needed to do their job. When teams are really taking ownership to achieve their Sprint goal and product vision together, this will mean that they will put the team’s purpose before their individual targets. This requires them to look outside of their own areas of expertise and see where they can contribute best, and will, step by step, acquire mastery in other fields beside their own expertise.

To get back to the original statement; “When everyone is responsible, no one is responsible”. I want to turn this around; “When only one person is responsible, everyone else is not responsible!”

Change… what is change?

/by

Almost exactly one year ago I stood in the kitchen waiting for the coffee water to come to the boil. Watching water coming to the boil is somewhat boring and my idle eyes dropped onto a towel someone had brought in, which said “Happiness is not a goal, it’s a way of life.” Still waiting for the hot water I digested this piece of information, and it dawned on me that, although I myself of course have no misconceptions about agility whatsoever, so many people have got agile wrong. They think agility is a goal, but it’s really a way of life. Hmm, I thought, I must write this down! As if waiting for this moment the boiler clicked off, and my insight was pushed aside by the imperative of making coffee.

What you are reading now is the first part of a series of blog posts on change, long in the making. I am writing this from the perspective of agile software development. Change is the core of agility, and you can’t be agile if you are not prepared to change and benefit from change. Being agile is to live with change, for change, and to be able to continuously create change. Not only change in the product, but in the processes and work agreements, and in the organization itself. Change needs to be embedded in the organizational culture — yes, even organizational change, even though it may sound like an oxymoron.

Naturally then, understanding change is very important if you want to work effectively as a servant leader, perhaps a ScrumMaster. Leadership is much about paying attention, observing and listening, making sense of situations and helping others understand what is going on, then letting people try out their own solutions. Through positive experiences the new methods will eventually stick and become culture.

I haven’t planned out the rest of the blog posts in detail yet, but the idea is to gradually progress from understanding change in theory and in practice towards understanding how to introduce change, apply change and perhaps guide it when it happens. We will also look at a number of larger agile frameworks from the perspective of change. There is enough material here for at least three semilong posts, so bear with me.

By the way, the models and ideas that I describe here are not my own. I have picked up a number of concepts from various sources over the years and retained those that I feel are useful. They help me make sense of what change is, how it propagates and how you even might be able to gently guide it sometimes.

Buy-in: Internal vs. external change

When the millenium was still pretty new, I worked as a process engineer in a medium-sized software consulting and subcontracting company. Starting from a very slim ISO 9000 -certified process, we worked in a group of three to develop our subcontracting processes towards CMMI level 3 (and also achieved the target in 16 process areas, but that is a different story). We worked on a small number of elements at a time and tried to finish each process element and deploy the results as quickly as possible.

Predictably, our project managers were not too thrilled by the changes. On the other side of the corridor sat a couple of trusted go-to guys that I knew would help me out in a pinch, but piloting the new changes with them was always a hard sell. It took months to talk them around to the new ways of doing things. But sometimes they would surprise me by developing their own tools and templates. Why was that?

One way to describe this is through buy-in. If a person doesn’t understand the new methods or think that they are better than the old ones, nothing will change. However if the person can participate in exploring and generating ideas, it is easier for him or her to buy into the idea, and the threshold to picking it up is much lower. And sometimes you find that somebody gets all excited over a new method, and wants to deploy it directly.

In general local knowledge is seen as more reliable than remote knowledge, and opinions more reliable than empirical data (Rainer et al., 2003). In plain language, the work done by the Process Development Unit and knowledge presented in academic research reports is perceived as less credible than the opinions and experiences of a teammate. Internally driven change meets less resistance than externally driven change. (If you don’t trust the article by Rainer et al., just take my word for it!)

In my case I was able to impose myself as a teammate to the project managers. But because I did not do the same work as they did, I was not really a project manager. My experiences and opinions did not carry enough weight and I resorted to the less credible and thereby slower method of presenting theories and models, many times using actual live project data to exemplify the concept.

How do you internalize change? We’ll discuss that later in this blog post, and will return to the topic in future posts. But for now, lets look at… FEAR!

Reactions to change: the lizard brain

The second lesson I want to bring up here is that all humans have a hard-wired notion that change is dangerous. In the jungle or on the veldt, those who spot telltale changes and avoid them are the ones who survive.

It pays off to over-react, to have a slightly lower panic threshold than one would think necessary. This is because those who scram off immediately use up more energy, but may live to see another day. But those who hang around to check that the waving grass really conceals a man-eating saber-tooth tiger don’t always get the chance to scram off. And so we have evolved an instinct for getting out of dangerous situations. Change and fear are connected on a quite deep level in our brains.

Some years ago I picked up a concept from a marketing guy named Peter Schneider. It’s simply called “the lizard brain”, and like all models it is wrong: it’s a simplification of reality and thereby full of holes and errors. However, I have found it very useful. It explains some of the reasons why people fear change, and also helps make sense of why people react as they do in the face of change.

The main concept of the lizard brain model is quite simple. When subjected to a threat of some kind — a threat to your habits, your territory, or your existence — people go into panic mode and will either fight, flee or freeze.

The name “lizard brain” comes from fact that panic reactions are handled (mostly) by the amygdala, which can be found just above the brainstem in all invertebrates. We share this with all mammals, birds and, indeed, with lizards.

When an invertebrate animal — a homo sapiens for instance — is subjected to a strong threat, the amygdala causes an immediate primal reaction. This is not a simple reflexive action: reflexes typically only yank a couple of muscles. But the primal reaction is still well below rational thought. In a dangerous situation, standing around considering your options is not a good, uh, option. In fact, one could say that the upper brain functions are simply subverted, disconnected by the amygdala. People suffering from primal fear are not only unreceptive to rational arguments but incapable of rational thought.

Perhaps an example would be in order here. My own strongest experience of primal fear happened at around the age of ten, when I walked on a sandy road and saw a large slavering dog running towards me. I was so scared that I just screamed at it, ready to fight for my life. (In terms of the lizard brain model, this is a fight-for-existence reaction.) Luckily the dog was as scared as I was. It did a somersault, turned on the spot and ran away. Immediately afterwards, my heart pumping adrenaline at 180 bpm, I felt ashamed of losing control, but also the deep satisfaction of winning a fight.

Interestingly enough the lizard brain is also activated in prolonged situations of fear or anxiety, as is the case in e.g. agile deployments. Case in point: “We will pilot Scrum in the organization and your team is the best candidate!” In other words: “We say you Scrum.” Ouch! How do people interpret this?

  • To some people agility is a threat to their habits. Many are accustomed to working in the warm fuzzy zone of “there are some last-minute problems but I think I can possibly get it done by next week Thursday”, also known as “90% done”. Others like to work alone and keep information to themselves, and see the increased transparency as a threat. Yet others feel that the daily standups are stupid — it takes weeks to implement this feature, why should I report every day?

  • Some people see Scrum as a threat to their territory. Many of them are former project managers that are now relabeled ScrumMasters or Product Owners and find that they have lost a large portion of their power. Or perhaps they are software architects irritated by the fact that teams are doing unapproved changes directly into the code base?

  • Some people see agile methods as a threat to their existence in the organization. These include line managers whose teams are suddenly self-organizing, or testers who learn that all testing will soon be automated, or specialists that have carved out their own narrow niche.

To the 95% who are not directly involved in driving the agile transition, Scrum is a cause of anxiety or outright fear. How do they respond?

  • Fight! Direct and indirect attacks. Badmouthing. Fear, uncertainty and doubt. Passive-aggressive behavior in the Scrum meetings. Appearing to play along for a while, then a sudden explosion of this-will-never-work. And so on — the examples are countless.

  • Flee! Some people grab the opportunity and move to other teams or escape the company altogether. The decision to flee is often made early, after enduring perhaps two or three weeks of Scrum, although it can take months for the fallout to appear. By that time people have made new commitments, signed new contracts, and the decision is very hard to reverse.

  • Freeze! A surprisingly large number of people seem to lose their drive and become unable to produce anything of value for months on end. They are moving the mouse and tapping on the keyboard but nothing real comes out.

In almost every team I work with, I can find examples of fighting and freezing. Sometimes, but luckily very seldom, also of fleeing. This model has helped me make sense of why people behave irrationally during an agile deployment.

As a manager or ScrumMaster of a piloting team, it’s your job to navigate them past this stage of anxiety. The main problem is how to do that when people are not thinking rationally. Let’s take a look at a third model.

Cultural change: the pyramid of results

Traditional management methods are focused on guiding and synchronizing the actions people do. The thinking goes that actions produce results, and if we want to get better results or more consistent results, we need to improve the actions people do. We can do this sometimes by standardizing, perhaps by measuring, perhaps by modeling and planning, maybe by setting up KPIs and targets.

We could also introduce the Project Manager role to plan and synchronize the actions of several people, and the role of Quality Manager to measure the results and improve the tools and processes. What if we want to make a more revolutionary change? Why, we set up a change program.

Unfortunately change initiatives are unlikely to succeed. According to Towers Watson, 75% of change initiatives fail to have any sustained long-term effects. I used to think that the 70% level of failure in software projects was astonishingly high, but this is even worse! Thoughtfully Towers Watson provides a list of causes; predictably it includes things like unrealistic goals, uncommitted CEOs, insincere senior managers, and the scourge of short-term thinking.

Needless to say, these symptoms are all likely to appear in a failed change initiative, but if you want to make the initiative succeed then attacking the symptoms is futile. According to the abovementioned study, 87% of the respondents train managers to manage change, but only 22% say that the training had an effect. You need to dig deeper. And so, let me introduce the “pyramid of change”.

The driving idea behind the pyramid of change is that what people do and how they do it is strongly influenced by their beliefs and value systems. If the actions and expected results are in line with their values and beliefs, they will happily and voluntarily do what it takes to get the results done. If not, they see little point in the exercise and will grudgingly carry out the task.

Where do people get their values and beliefs then? Well, from experience. From trying out things themselves, from observing other people, and from talking to other people about their experiences.

The Results Pyramid is © Partners in Leadership LLC.

The upper half is about “hard skills”: guiding and scheduling actions, measuring the results, managing risk. The lower part of the pyramid consists of the company culture, which requires “soft skills”: leadership, politics, managing expectations, shaping beliefs and making sense of experiences. Managers are well trained to work in the upper half of the pyramid, but as a leader in a change situation you need to shift your focus.

If you want your organization to change, you must create new experiences. You must show people that the new methods work in practice, tell them fairy tales and horror stories about how other teams have succeeded or failed, and use new thinking models to help people understand what is happening. As they gain experience from working with the new methods, they will start trusting the new ways of working: in other words, they will start changing their belief system.

Summary

In this post I presented three models of change. There are more to come, and I will bring them up in future posts. However, let me first tie up the three models by returning to my first example of developing processes towards CMMI level 3.

As a process developer I saw that people were reluctant to take new methods into use. I tried to repeat my rational arguments over and over again, and I felt that people were slowly, slowly becoming more receptive over time. Back then, I thought that it was a question of understanding the new method, and that this could be achieved by teaching and demonstrating.

In hindsight I’ve understood that things work differently. Project Managers were afraid of the changes I were proposing, and felt anxious about taking them into use. They did not necessarily respond well to my preaching: they became more receptive because they were getting practical experience from using the new methods, learning that the threat is really smaller than they thought. In other words, regardless of how much you tell them that the saber-tooth tiger won’t bite, they need to see by themselves that the tiger is continuously NOT attacking them before they can stop thinking of it as a “foe”… and perhaps someday start thinking of it as “friend” or “ally”.

References

A. Rainer, T. Hall, and N. Baddoo. Persuading developers to ’buy into’ software process improvement: Local opinion and empirical evidence. In Proceedings of the 2003 International Symposium on Empirical Software Engineering (ISESE’03), 2003.


 

 

The bitterness of poor quality

/by

Recently I came across a picture online and posted it on twitter. I thought the quote made a lot of sense in an agile context, since in agile product development, quality should be considered in all stages, from early feedback from your customer to continuous integration on software teams. 

The bitterness of poor quality remains long after the sweetness of low price is forgotten.I am not a very active twitter user, so I was quite amazed it was retweeted over 200 times! Apparently the quote on the picture resonated with a lot of people, which inspired me to write this post. I also did some further research on the origins of the quote. It’s not clear who was the original author, but some sources attribute it to Benjamin Franklin. In the picture the quote seems to be hanging in an old saw-mill, but it turns out that around 1930 many companies had this statement as their motto, to emphasise they were building products to last.

Product Quality

The statement still holds true today, maybe even more in the current age of globalisation, where customers have easy access to social media and online reviews. Although good quality is no guarantee for success, products and services with poor quality won’t stand a chance.

One of the Lean Principles states “Build Quality In”, meaning quality should be considered and validated in all stages of the process. Unfortunately many organisations still consider quality something which is only required at the end of the product development process. There are different aspects to quality to be considered during the product development cycle. Quality is more than just preventing defects. A product with no or few defects will not automatically be considered a quality product by your end users.

When using an agile approach, the result of each iteration should be a ‘shippable product increment’, which we can inspect and validate against acceptance criteria and non-functional requirements on a User Story level. But we are also able to assess how the product holds up against the Product Vision we are trying to realise.

There is a good reason product backlog items are defined as User Stories in agile approaches, it emphasises the need to focus on User Value. Yet many organisation do not involve actual end users at all in their product development process, or if they do it’s only at the end. So try to involve users in early stages of the process, and focus on shipping minimal viable releases of your product to end users to validate it in the market.

Technical Quality

Next to validating product quality, we need to assess if our product conforms to our internal quality standards. For example browser or device compatibility, load and stress the product should be able to handle, connection and session handling, etc. When these aspects are validated only at a late stage of product development, the consequences can be quite severe.

Imagine you have delivered 10 iterations of functionality, if you discover some components added in the first few Sprints are not able to handle a certain load, you will have to go back and rethink the approach you took months ago. At the same time the functionality which was added later, may have been dependent on these components and thus will also be affected, introducing a lot of unexpected rework.

Regression

Regression in software is considered to be the introduction of defects by changes in code, configuration or libraries. When you are only focussing on validating the new functionality added in an iteration, you will not discover regression defects in existing functionality.

This is one of the biggest challenges when teams move to an agile approach. In a waterfall project you had a big test phase at the end where all the integrated code was manually tested. But when you are delivering integrated code every iteration, you can’t really afford to run all manual tests every time. The only real option you have is to automate your tests, so you can run them continuously without much manual effort.

When your code is well covered by unit tests and integration tests there is another advantage, in stead of finding the bugs at the end, you can discover them quickly, it’s a good practice to run unit tests often from your IDE, allowing you to quickly see if the few lines you changed are breaking any tests. And when they do it’s usually obvious how to fix it.

Effort required to fix vs. Time of discoveryQuality is Free

Another quote I love is one from Philip B. Crosby: “Quality is Free”. This quote is from the sixties, and wasn’t really intended for Software projects back then, but it actually does apply there too. What he meant with the quote was that any investment you make to prevent defects will pay itself back.

When you consider the cost of resolving defects and the time of discovery, you will find it is quite worthwhile to invest in unit test and integration tests.

How to get started

When you are dealing with a legacy code base without unit tests, it’s usually not an option to stop adding value and write unit tests for months. To get started you can start small, for example, agree to add one unit test this Sprint, the next Sprint cover a full story, until the team is ready to cover all new functionality with unit tests. Integration tests can be started the same way. Your velocity will be lower in the beginning, but you will soon see the amount of time teams spend on fixing defects drop, thereby increasing and surpassing your initial velocity.

Teams can also consider to write unit tests for defects found after the Sprint is complete. The reason these are found is usually because parts of the code are not covered by tests. You can start by adding tests for blocker and critical bugs, thereby making sure these particular situations will be covered by unit tests from now on. Next to unit tests, teams can also add automated integration tests in the same way.

Developers should get used to the habit of running unit test suites often from their IDE or command line. But it is also quite useful to have a continuous integration server, which monitors your version control system and validates all tests pass and build are successful.

No time to waste, start investing in your quality and productivity now! Your customers will love you for it.

Agile Testing Days 2013: Agile Testing is nonsense, because Agile is testing…

/by

Some impressions

The Agile Testing Days has definitely been an experience for me. I wasn’t sure what type of people I would have met at such supposedly very “vertical” and specific conference, focusing on testing in the Agile world. It’s definitely one of a kind, and I was positively surprised about the amount of people who are actually getting closer to Agile through the testing experience.

The quality of the speakers has been very high, I have attended almost all of the keynotes, and were all very well followed, and engaging too. I have learned that there are still a lot of people calling themselves tester, who are clearly willing to part themselves from the “developers”, which I find particularly strange in an Agile environment. Shouldn’t it be all about the team? Shouldn’t the team be a peer to peer team, with no hierarchy and no roles? Developing a product in Agile means making it shippable at every iteration, and that requires all the skills needed to make it happen! Which ones? It depends on the context… every product is different, and requires different skills and people to be developed.

I have met a lot of people and I have also rejoiced with some old acquaintances that I helped starting the journey toward Agile in 2009… and now they had quite some stories to tell, great! Overall it seemed a very well organized event, with fun in the evening, the right mixture of talks, workshops and also Open Space. One thing I would definitely change if I were one of the organizers, would be to cut the talk length to 45m maximum, so there would be more talks, and probably some would be more focused, I include myself in the category.

My opening keynote writeup in some way…


How it all started

It all started about a year ago, when I was asked to prepare a keynote for the Agile Testing Days, after having presented at the Agile Dev Practices in the same year. I was pleased to be asked to have the opening keynote, and on the other side also a bit puzzled, as I am no testing expert, as many of you may have noticed. I have been developing software for a very long time, and I still do it for fun, but now my main focus is on an overall organizational perspective, and definitely a mixture of Agile, System and Professional coaching (who doesn’t after all).

Still I am pretty much involved in supporting teams, and I can still teach ATDD, BDD and TDD to pretty much any programming language (well it is not about the language after all). So I had to think about what should I talk about, for 1h, one year ahead of time? How agile is that? Then I thought, maybe I should ask what sort of keynote were they expecting from me, considering that a keynote should maybe open a lot of doors to more specific and vertical talks, I was still unsure about the focus.

At the end it went a bit on the provocative side, well you can’t really argue that testing isn’t needed, or is a waste (as someone likes to say, and with whom I disagree). Testing is one of the activities required to create a product (software or not, doesn’t really make a difference), and it is not just about the compliance of what has been done with the expectations, but is about creating confidence in the team developing the product, that they are pursuing the right objectives, that what they are building is going in the right direction. Still some people tried to convince me that their job as tester is to find defects, which are a sort of trophy, a demonstration that they have been able to break the product (or even more explicitly the work those “others” developers did).

Why? As far as discovering things which do not behave as expected, or even discovering new things that nobody had thought about, testing is a discipline which helps a team refining its targets, and learning. Once it becomes a self-fulfilling prophecy, it looses pretty much its purpose and also introduces various dysfunctions. One of these, is the one I have exposed in my keynote as the “Show me the money!” dysfunction. If you are Agile, you know what I am talking about probably, such behavior is resulting from a fundamental distrust in the team and in what the team is doing. If there is no trust, then there is no Agile, but trust needs to be gained, it is not something we can “expect” as a precondition (sounds like testing a bit). And here is where I wanted to emphasize that being Agile requires to develop a certain mindset, which in particular is reinforcing the attitude to trust results based on the fact that we can validate them.

 

Testing as an attitude

This might seems natural to many, but if you have been in enough messed projects in your career, you probably will remember at least one time, in which people didn’t know exactly why they were doing what they were doing. And this is where the Agile mindset, strongly focused on results and goals, and allowing individuals to commit to achieve a goal, by allowing them to pull the work from a list of defined objectives (normally called backlog).

People start thinking about how would they know when they will be done, before starting to do anything. This attitude is required especially when working in complex contexts, where often isn’t clear what is the end results you are trying to achieve, or even it is a set of options and you need to understand if you are moving within the expected range. To strengthen the attitude, you need to practice, but before you can practice effectively, you need to try some approaches and understand what works and what doesn’t.

 

Testing as an approach

So let’s think at testing as an approach to experiment different ways in which a problem could be solved. If you think this is reflected in any sounding Agile thing you might be doing already since quite some time, you want to know what are the “Acceptance Criteria” of a User Story before committing to do any work on it. And once you have it in your hands, the first thing you start doing, in order to focus, is to identify what are the possible acceptance tests that you can derive from those agreed “Acceptance Criteria”.

Good teams at this point are already looking into automating, to be sure they are not wasting time in doing the wrong things, and to make sure there is a safety net, which will remind them to refocus on the goal of that story. As you may know it is all about shorting feedback loops, and the most valuable ones are the one you can shorten through the conversations with the Product Owner and the stakeholders, while defining what to test and how to test. Agile people do all possible things to visualize anything, because by visualizing, conversation can be more structured, and focused. This is a great approach too. Now the practices come into place, testing is full of practices.

Dan North (@tastapod) pointed out in his keynote, that there are at least 120 different testing practices that he was able to count in his experience, and decided to categorize in four quadrants (how comes are always four…) based on two dimensions: deterministic towards “random”, and manual towards automated (you can read more about this in his keynote Accelerating Agile Testing). Practices are useless if they aren’t supportive of the approach you are willing to adopt. Many people just adopt practices, such as TDD, because someone told them they are good, and they do not really think about the value nor the economical impact of doing TDD. Maybe they will eventually end up stopping doing it, because they won’t see any benefit (just another cool practice isn’t it?). Well, if more people would understand that TDD is about design of the software, and not testing.

 

Testing as a practice

This is exactly the approach that I was trying to highlight in my keynote, by explaining that Agile people might decide to approach the solution of a complex problem, by defining a set of tests which a possible solution should be able to successfully pass. This approach – writing tests first – is a well known principle of eXtreme Programming, and it is embedded with very fast feedback loops into the TDD practice.

So TDD is not about writing automated tests (that’s the output) but is about discovering the solution to a complex problem, by means of limiting the solution space through the definition of tests, which the solution has to fulfill. This leads to a more clean and focused design of the software, aiming at solving the “problem” and happens much faster (this is the outcome), than if you would sit and think at the solution from the inside out.

Finally I have made some back references to System Thinking and the Theory of Constraints, to highlight the importance of the behavior that a particular system is producing. I have presented as an example the behavior a push system is producing: focused on individual, competition, and compliance, while a pull system is normally producing a behavior focused on team, collaboration and value (as outcome). So if you really have complex problems to solve, you need people who can work in the most creative, safe-to-fail environment possible. This will require discipline, will require courage, and commitment, all of which is based on transparency, respect and trust.

With this in mind, invest in building great teams, and lead by example, coaching them developing the right attitude toward Agile. After a while, and some failed approaches, they will eventually find out practices which are supportive of their intentions, and will become more productive over time. Also don’t think you can sit on a bench and enjoy the ride, because the Agile mindset is rooted on continuous improvement, and that means, your bench will change shape, and move… probably every couple of weeks :-)

My Storify of the session.

The State of Scrum 2013: a Report from the Scrum Alliance

/by

At agile42 we practise Scrum each day and we’ve been very pleased to see earlier this year the publication of the 2013 State of Scrum Report by the Scrum Alliance. The work is now available for free download and includes a PDF report, a webinar to watch online and a webinar presentation deck.

State of Scrum 2013Scrum Alliance is a nonprofit professional membership organization providing Advocacy, Community and Education to encourage and support the widespread adoption and effective practice of Scrum. This industry report is based on input from almost 500 business professionals in more than 70 countries. Participants represented various industries from IT to education, finance, government, healthcare, telecommunications, and more. Key findings from the report include the observation that Scrum is growing rapidly, not only in software development, but in industries far beyond. The report also reveals the leading reasons organizations are adopting Scrum and contains three recommendations for successfully practicing Scrum.

We are happy to collaborate with the Scrum Alliance worldwide, not only participating at various Scrum Gatherings and Coaches Retreats but also providing coaching services to the organization through our North American coaches Brad Swanson and David Sharrock since last summer.

agile42 is a Registered Education Provider (SA REP℠) and offers training courses leading to Scrum Alliance certifications like the CSM (Certified ScrumMaster), CSPO (Certified Scrum Product Owner) and CSD (Certified Scrum Developer). Check our offering of trainings or contact us with your team needs.

The Dark Champions of Agile: Hark… Who goes there?

/by

Click here to read “Part 1: Know Thy Enemy”, which identifies the resistors to change and how to defeat them and “Part 2: Gathering Allies for Change” which explains how to show leadership through action.

In part one of The Dark Champions of Agile we discussed the struggles of an agile transition and the forces and people, who will align against you to protect their status quo. The Dark Champion of Mediocrity and the Baron are personas we discussed with strategies on turning resistance into momentum. Part two discussed more personas and some perspectives on turning enemies into friends and ambassadors of agile. The values of Respect and Transparency dictate this proclamation; portions of this list were developed at the Coaches Retreat in Boulder, CO, Dec 2011, kudos to all whom contributed.

Knight

How to defeat the Dark Champions in your agile battles…

Anchor/Foot dragger:  This persona is openly resistant and will not accept change, even if you showed him the invention of fire, the wheel or sliced bread.  The Anchor professes allegiance to the old ways and will not accept agile.  This persona is usually banished with logic and results, the small wins you create in your agile transition.  The data and metrics collected to validate improvement to the team or product decreases the power associated with the Anchor’s voice.  Results win in any arena, so create your performance metrics to show that teams cannot afford, or tolerate, decreased work efforts.  Over time, the team will decide how best to onboard or drop the Anchor; inclusion is always preferred.  If the agile coach needs to intercede,  it is to facilitate a discussion between the Anchor and management on where best the Anchor can serve the organization.

Beware the Foot dragger, twisted cousin of the Anchor.  Foot dragger will use an ‘easy going’ attitude,  to hiding in plain sight.  Do not be fooled by the complacency that hides beneath the surface.  The Foot dragger does not impede progress but does not advance it, adding inertia to the system.  This persona is easily defeated by employing coordination tactics; have the Foot dragger run the next retrospective or lead a backlog grooming session.  Action defeats complacency.

Saboteur:  The Saboteur loves agile in public and loathes it in private.  It will conspire with others to resist agile in secret, opposite the Anchor.  It operates with non-value adding activities such as committing to work items and not finishing, derailing meetings with useless questions, hijacking demos with needless commentary.  The Saboteur is best dealt with in a two prong approach.  A particular behavior such as being late to every meeting is discussed in a one on one session.  Once the behavior is shown again, you can address the Saboteur with a “Sir, we previously discussed this issue…”. Now the power of the team can be brought to bear on the Saboteur.  Two such outings will reveal a pattern of behavior which the team will be more adept in finding sooner, as the team progresses.  Challenge the Saboteur to show deep knowledge of agile, by asking for book reviews, blog post updates, new ideas from the web, chapter reviews from books owned by the team.  Failure to produce knowledge for the team will not go unnoticed.

Dead Fish:  Go with the flow, don’t rock the boat, don’t whine, just do whatever, apathy…
The Dead Fish can be tricky if dealing with cultural diversity, gender or seniority.  My usual approach to the Dead Fish is to reinforce the authority of the agile transition.  This reassertion of management’s desire to work in a different methodology, will give you the perceived authority when establishing working agreements with this persona.  Dead Fish are first offered the gift of inclusion, ‘Please be one of us, join the team, be open minded’. If this persuasion is ineffective, then the message of discipline is delivered, “If you will not join us, do not resist or sabotage our efforts. Follow the team, the process and do as instructed.”  Although this is not the preferred way, it’s a way forward.  This tactic will help the Dead Fish participate while keeping a safe buffer between themselves and fully committing to the change.  They are usually converted over time, with some successes and hard fought changes.

Dead Fish and Foot dragger are almost the same, I see indifference in the Dead Fish and a half hearted commitment in the Foot dragger.  Perhaps its just nuance, opinion, word smithing or splitting hairs, but I see two personas.

Diva/rock star:  This persona is very prevalent, equivalent to the architect in the ‘ivory tower’ lording over us mere mortals.  The Diva has the technical expertise or seniority to hold sway over those in the lower courts, but you must not give way…You have been hired by his boss, so this conversation becomes
very focused.  I invite the Diva to meet with their manager and between the three of us, we come up with a plan to include/exclude the Diva.  When confronted with a manager or an Agile Champion farther up the food chain, the Diva is repelled but not defeated.  Beware the morphing into the Foot Dragger or Saboteur.  The more subtle approach to including/defeating the Diva is to schedule open debate sessions where attendance is optional and team issues can be discussed.  I propose a different forum than the retro, which has a higher purpose.  These battle sessions are perfect for giving the Diva the room to voice opinions, and for you to establish/demystify fact from fiction and handle/corral/gently instruct the Diva into what are the agile principles and who really holds authority in that arena.  A small, gentle display of authority, enough to show the other team members that a Diva can be managed, respectfully. Inclusion in decisions is the way to win over anyone, even those whom fight inclusion will break under team pressure to contribute.

Church Mouse:  The quiet, intelligent, introvert whom does not seem engaged.  This persona is perplexing but can be drawn out into a contributing member of a team.  The Church Mouse must be approached directly, usually with a buffering team member along for the conversation.  Space and respect are given in abundance and under no circumstance are you to interrupt when they speak.  Constant support is given in team discussions, even when disagreeing perspectives are presented.  Extroverts on the team are approached individually before meetings and silent signals are established for when discussions go long.  The usual exertion of force, see Diva, cannot be used.  One method to use is the cover of Critical Mass.  This technique involves gathering the team members that see the value in agile and have them proactively include the Church Mouse in pairing activities, demo prep activities, keeping the project board tidy and updated, lead a daily standup for the more adventurous.  The inclusion by the crowd, instead of the coach, provides the message of “It’s ok to change. Contribute to the conversation and help us grow”. 

Your Mission

Retrospectives that Rock

/by

The Team Retrospective may be the most critical activity of an Agile or Scrum team. Building the habit of learning from retrospectives is an important skill. Especially as a strong influencer (whether as a manager, team lead or simply through force of personality), there is a delicate balance between directing the outcome and allowing the outcome to emerge from the team. Ideally the team will take ownership of the learning, drive identification and collation of issues and their root causes, and brainstorm, discuss and decide on best possible actions. However, many times we see the impact of strong personalities on a team leading the retrospective in a particular direction, looking to prove a point, get the next obvious bottleneck dealt with, or otherwise guide the team’s behavior through assumptions rather than building up the mental muscles of self-awareness and self-directed learning.

Retrospectives are a delicate time for a team, in which we ask them to trust one another, follow the prime directive of retrospectives (“Regardless of what we discover, we understand and accept that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”) and challenge the status quo. In order for the team to feel safe to do this we need to manage the environment with care.

Here, we touch a little on attributes of effective retrospectives. If your retrospectives are timely, targeted and without undue influence, the tendency to skip retrospectives, or direct the outcome of the retrospective is diminished.

Respect People’s Time

Respecting people’s time is a critical aspect of this – this has less to do with preparation, though preparation is important, and more to do with respectful use of the time the team takes out of their daily work. First, the retrospective (like any meeting) should start on time, be timeboxed, and reach a real, actionable conclusion on one or perhaps two key issues. Second, the decisions made during the retrospective should be acted on in the next sprint and when impediments extend beyond what the team can own themselves, impediments should be visible and given management attention. The highest priority should be given to following through with the changes suggested by the team and quickly addressing impediments raised.

Without this commitment to resolution, the team will soon see that the retrospective is not given the priority outside the team, and stop challenging the status quo and looking for genuine improvements. Recommendations become perfunctory – simple changes that have little impact on the real barriers to high performance – rather than challenging the current product delivery paradigm and stepping into the realm of true innovation and ownership of delivery outcomes.

Provide Intent

Retrospectives on general improvement of the iteration soon reach an impasse. The team has made all the obvious changes they can and probably avoided the few critical changes they could make, assuming some things simply cannot change. At this point, the retrospective may lose impact without a change to the format of the retrospective process.

To revitalize the retrospectives, we can use different retrospective patterns, such as timeline retrospectives or sailboat retrospectives, for example (see How to Hold a Sailboat Retrospective). However, the simplest way to inject another level of energy into the retrospective is simply to provide intent by setting a clear question at the beginning around which to retrospect.

Most retrospectives revolve around an implicit (or sometimes explicit) question about how the most recent sprint can be improved. Framing an alternative question for the retrospective is a powerful way of guiding the team to discuss points of interest on the periphery of the sprint itself.

To be valuable, the intent should be clear to all, relevant and definitely not self-serving. These could be focussed on uncovering specific issues tangential to the success of the sprint itself (e.g. what would have to change for the team to deliver twice as many stories in the same amount of time?) or targeted on organizational issues being ignored by the team (e.g. how can we reduce or eliminate the wait for regulatory compliance sign-offs for new features?)

Beware of Implicit Influence

In many teams, key individuals may carry implicit authority and influence, whether through experience (e.g. the senior architect), longevity (e.g. employee #4) or previous or current position (e.g. the project manager turned scrum master). This means that one statement made by the team carries a different weight to the same statement made by a key influencer.

For example, if the team comes up with a statement like “the team should critically review the suitability of the existing software design for any new stories” this will be discussed in the context of the root cause being addressed, and whether or not this solution will cause the required behavior or outcomes. The same suggestion made by a key influencer, even in their role as a Scrum Master, Product Owner or Team Member, may be interpreted as prolonging the status quo, or defending a strongly held personal opinion by the team. This can cause the team to immediately abdicate responsibility both for the outcome (e.g. by not following through and committing to make the required changes in a timely fashion) and the resolution of the original impediment. The team as a whole loses.

In almost all cases, the most valuable behavior of any influential role model is to listen and perhaps ask clarifying questions. Any other observations or inputs can be made through the brainstorming and collation process, or through providing intent, as described above.

What other hints and tips do you recommend for maximizing the learning opportunity of a retrospective? Let us know…

The first Italian Certified Scrum Product Owner training

/by

One of the main activities of agile42 team between coaching assignments is to train new Scrum professionals and prepare them for Scrum Alliance certifications. Trainings are usually done in English but local communities can often enjoy a local-language course thanks to the network of coaches from different countries. It’s therefore been a thrill to witness the first Certified Scrum Product Owner training completely in Italian, run by Andrea Tomasini and Roberto Bettazzoni in Bologna at the end of July.

The training offered the full agile42 treatment consisting of background information about Lean, Agile and Scrum, teamwork games, interactive sessions with questions and answers and a full “startup” vibe for a class of 24 participants – coming from places as diverse as Florence and Canton Ticino. Thanks to everyone who took part, here’s a photo gallery of the two days.

The next official Italian CSPO will be held on September 9, again in Bologna. Please check our training list for more dates, cities and language options for all certification courses by the coaches of agile42!