Test Retreat

Welcome to the homepage of Kris Corbus

Archive for the tag “agile”

ScanAgile

I realised that I did not write a blog post about a conference where I spoke in March, 2019. I am talking about amazing ScanAgile. I had great experience there and very interesting, thought provoking discussions. You know, that moment when you connect with someone on meta level, everything else leaves your thinking space and even all that travel trouble suddenly makes sense.

ScanAgile is community driven and the audience is everyone involved in work in progress. What said – it was unusual for me, that so many business people were there and I have the feeling that I met all of them. It changed my perspective and gave new ideas how to approach this group with my topics.

During the conference I gave my workshop “Questioning requirements: improving quality for everyone” and no matter that we had technical difficulties (abstract of the workshop was not visible on conference website), we had very good session and some participants staid much longer(1h+) and we had deep conversation about the topic.

So why I remembered about this great event? Because they just announced Call for proposals and if you are from Europe, I think you should submit!

“The theme of ScanAgile 2020 is “Everyone is a Change Agent” and event will be bigger than ever with 500 participants. Our special 2020 focus group is people from companies in transformation. ScanAgile 2020 conference will be held on 1st and 2nd of April 2020. A separate workshop day will be held on March 31, 2020. The venue is the same as this year, Clarion Hotel Helsinki, Finnland.”

ScanAgile

I plan to be there in 2020 as well. This photo was taken shortly after I won free ticket for 2020 :)

Trainer Notes

Agile Testing Quadrats

Weeks after Agile Testing Days were pretty intense. Every week another training. Business as usual? No. I do not know why… was something in the air or was it my students, or myself. We tackled agile and dig really deep. To experienced and guide it, made me very vulnerable.

To learn means to leave comfort zone and to realised that what we did so far was not OK. Learning can make you feel big discomfort. That feeling is not a good feeling, so sometimes to get it go, people turn the anger to the messenger. Trainers and coaches need to learn how to deal with it. Another thing next to anger is struggle. I see struggling people, who want to be really agile, not only on paper, but they have no idea how to do it in their environment. Sometimes I do not know which situations are harder – anger or struggle, but definitely since I attended Agile Couch Camp this summer it is easier to deal with situations like those.

Week before Christmas I had a group of people who had especially big emotional debt. No matter which topic we were discussing, it went back to the old stories about orders, ignorance (from managers) and silence (from employees because it does not matter if they say something). This group was special with another thing – there was one of managers sitting with them. She is one of the new managers, who joined the company not so long ago, but still – a manager. First day she was all about denial. Everything, what group said about bad practices, missing communication or management, was not true. On second day she started to listen and at the end of the day she said: “now I see that we have communication problem”. She realised that to talk or to share ideas is not enough with people, who were misused for a very long time. They do not believe you and they listen to something else. On third day the manager was missing for the first part of the day. I used the time and asked the group to reflect on training and how the manager reacted. It was interesting to observe that they collectively realised that maybe there is real change coming. The training they got, the manager, who listens when they complain and reacts when she realise something wrong. I felt very privileged to guide them through this moment. Felt like real transition to new level.

At the very end of the training group asked me for tips how to stick to ideas and how to keep agile spirit vivid. Maybe because of approaching Christmas or because of this something in the air, this time I chose to share story of my own vulnerability, my own struggle and my own insecurity and my tricks how I keep going and where they could look for tools what would help them to create a positive agile habit.

Sometimes giving a training can be exhaustive… but I still like it.

Communication Links

AgileCommunic

Few years ago Gojko Adzic tweeted following:

https://twitter.com/gojkoadzic/status/482506004102672384

 

Even today, several year after the tweet, people do not understand why agile team has to be small. The answer is communication links! Take a look on picture above. The dots are symbol of person in the team, and lines shows communication links in team. Example on the left is for team of five (10 communication links), example on the right for team of nine (36 links). Formula is very simple:

Connection Links=n (n-1) /2n , where n=Number of Team Members

In a team of 15 you will have 105 communication links(15*14/2=105).

Agile is about team, not about isolated knowledge of some individuals.

In trainings I still hear team members complaining about management, who placed timers on each desc, that people time their conversations and do not talk too much. But that is not about communication anymore. It is about company culture. There is a reason why they talk too much, find out what it is, instead of to forbid to talk.

Quality is the Responsibility of the Whole Team

Originally this article was posted on trendig.com English & Deutsch

Since 2001 we have the agile manifesto in place and since then the whole industry is learning to use agile principles and values in their daily work of software development.

 

agile manifesto

The Agile Manifesto guides teams through agile transition and in their daily work of software development.

One of the problems I see, is that many who claim to be working in an agile environment have never read or really understood the agile values. While consulting teams or giving trainings, I’ve heard countless times that the Agile Manifesto says everything that is on the right side is what we should not do, e.g. in agile we have no plans, no contracts, no documentation or processes. I got to know a team who lost their software architect in agile transition because architects are not mentioned in the Agile Manifesto. Now they struggle with huge technical issues and there is no one who can help them… But it is not meant to be like this! The Agile Manifesto states that value is in items on both sides, but if we have to choose, we are choosing items on the left over the ones on the right. Logic says we have to have all items of the Agile Manifesto if we want to deliver sustainable software and improve our delivery cycle. The aspect that agile methods wants to highlight is, that documentation, plans or contracts are not the aim of the project, but are supporting tools. The aim of agile projects is always to deliver working software, have valued team members, and promote collaboration with customers and value responding to change.

 

the whole team approach

The way in which we achieve the values and the principles described in the Agile Manifesto is using the whole team approach. Since it changes fundamentally how we work together in a project, you can say it is a new style of project management in which everyone on the team is held equally responsible for the quality and success of the product.

The Whole Team Approach supports the 5th principle behind the Agile Manifesto.

Professionals in software development know that each development decision is a quality decision as well. The Agile Manifesto sets it as a top priority. Software quality does not depend on the software development model that we use, but on the method how we all together as a team structure the whole software development process. Together, we use tools and activities which support the achievement of high software quality. One of these activities is testing.

 

what does testing mean?

Everyone around the world knows or can imagine what “software development” or “project management” are, but very few can say what software testing is, how do you do it and, most importantly, why?

10 years ago when I started my career in testing, there was the statement: “everybody can test” with the meaning that you do not need special skills to test. Today I often state myself: “everyone can test software”, – meaning everyone: developers, software architects, product owners, support people and operations – everyone, who can analyse information and build a mental model of it, to discover invisible strings and deviations between software and requirements, business regulations, standards, norms and legal regulations. Testing is an intellectual sport. But we are more used to say: Testing is the process of how we collect information about our product with the aim that, based on this information, the team is able to decide what to do next.

Two types of testing are very important in an agile context: automated regression and exploratory testing. With regression tests we collect information about software features which are already in use by users, and with exploratory tests we are learning about software features that we are currently developing.

If you run tests and your team cannot make decisions based on information your tests collected, your tests are not adding value. If you write weekly reports and nobody on your team reads those, your reports are not adding value. If there are 12,000 automated tests and no one can articulate what they cover, the automated tests are not adding value.

You may still have a tester on your agile team that acts as a coach for testing techniques and does some of the testing, but on an agile team, everyone should be able to collect information about the current state of the software. Remember: quality is the team’s responsibility.

the challenge of change

The essence of the whole team approach lies in the testers, developers, and the business representatives working closely together at every step of the development process. Because the whole team is responsible for success and quality, the whole team or at a minimum, representatives from each specialty – see three amigos  – is involved in every consultation or meeting in which product features are presented, analyzed, or estimated. For many organisations and individuals, it can be a struggle.

The first attempt to switch to an agile software development, in my experience, in 90% of cases looks like a 2-week-waterfall development. It is hard to change a person’s way of thinking or collaborating, a company culture or processes already in place. People and companies have to break deep-rooted processes, e.g. working in silos or not listening to junior members. Give it time and recognize people’s fears – it is scary to change! Some fears that people have expressed to me are:

  • “How exactly should I support my team members?”,
  • “If everyone should be able to test, what should I, the tester, do?”
  • “If the whole team decides on issues, what should I, the project manager, do? Is there still a job for me?”,
  • “According to our HR guidelines and my job title, I am a senior developer, but I never really understood testing. What will happen if others find out?”

All of those are valid questions and should be addressed.

Janet Gregory and Lisa Crispin were two of the pioneers in agile testing. Many agile testers call their book “Agile Testing” the Bible, because it was the first comprehensive book about testing in an agile context. Today they have the extension “More Agile Testing” and the 3-day hands-on training “The Whole Team Approach to Agile Testing and Quality”, for whole software development teams, with games and exercises on collaboration, planning and agile testing quadrants. I train this course myself because I am convinced that I can give many team members valuable knowledge for the implementation in their daily work. But whether it’s a book or training or reading blog posts or just trying things out for yourself: I encourage everyone to take a look at the whole team approach, because it is an important step forward when the entire team feels responsible for success and quality.

More Agile Testing > Testing Business Value

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction, Learning For Better Testing, Planning. Comming soon: Investigative Testing, Test Automation, What Is Your Context?, Agile Testing in Practice.

Part IV: Testing Business Value

Books

Articles, Blog Posts, Slide Decks, and Websites

More Agile Testing > Planning

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction, Learning For Better Testing. Comming soon: Testing Business Value, Investigative Testing, Test Automation, What Is Your Context?, Agile Testing in Practice.

Part III: Planning—So You Don’t Forget the Big Picture

Books

Freeman, Steve, and Nat Pryce, Growing Object-Oriented Software, Guided by Tests, Addison-Wesley, 2009.
Galen, Robert, Software Endgames: Eliminating Defects, Controlling Change, and the Countdown to On-Time Delivery, Dorset House, 2005.
Gottesdiener, Ellen, and Mary Gorman, Discover to Deliver: Agile Product Planning and Analysis, 2012.
Hendrickson, Elisabeth, Explore It! Reduce Risk and Increase Confidence with Exploratory Testing, Pragmatic Programmer, 2013.
Hüttermann, Michael, Agile ALM: Lightweight Tools and Agile Strategies, Manning Publications, 2011.
Whittaker, James A., Jason Arbon, and Jeff Carollo, How Google Tests Software, Addison- Wesley, 2012.

Articles, Blog Posts, Slide Decks

More Agile Testing > Learning For Better Testing

This is digitalised collection of testing resources created and published by Lisa Crispin and Janet Gregory in their book More Agile Testing: Learning Journeys for the Whole Team“. For more details on their work, visit http://agiletester.ca.

Already digitalised and checked parts: Introduction. Comming soon: Planning—So You Don’t Forget the Big Picture, Testing Business Value, Investigative Testing, Test Automation, What Is Your Context?, Agile Testing in Practice.

Part II: Learning for Better Testing

Books

Blog Posts and Online Articles

Courses, Conferences, Online Communities, Podcasts

More Agile Testing > Introduction

Two weeks ago on Slack, we talked about collections of good resources and Lisa wrote that she and Janet created a good one, but it is not available online. I volunteered to digitalise it and she agreed. Since then I am checking links and reading articles. What can I say – it is an AMAZING collection! Thank you, Lisa, for your kind allowance to publish the list online.

This is the bibliography list created and published by Lisa Crispin and Janet Gregory, More Agile Testing: Learning Journeys for the Whole TeamFor more details on their work, visit http://agiletester.ca.

Part I: Introduction

Books

Websites, Blogs, Articles, Slide Decks

 

Women In Agile

atd_womenleancoffee

Agile testing days organized this year something new: “Women in Agile Summit”. Great idea, difficult subject, wrong conference day – night after the conference has been closed. Not enough public information that without men, discussions are meaningless. And in fact, the person, who closed the conference, forgot to mention the upcoming event!

I arrived late but brought seven men with me. They had a hard time between choosing to drink a beer and guiding me to something-with-women-thingy. All of them chose to be brave and face the difficult topic. Bravo! But it is getting better – as we started our lean coffee session we got another member. We collected our topics, voted and as we just started our discussions, time was suddenly up and all teams were asked to present their results. So we did not really have a chance to discuss our topics as a team, but to our surprise, we got unexpected feedback to our presentation:

  • first of all because of men: women ratio in the team
  • gender of the person, who presented the team results
  • discussion topic “beer bet”
  • usage of the word “female”

No matter that the conference was extremely friendly and Maaret as Women-In-Agile facilitator was very inviting, the atmosphere was intense and spiky. Yes, we were late and yes, we did not have a lot of time, but as I talked to Garreth afterwards, we both had a feeling that no matter what would our team present, we would do it “wrong”. Even during open discussion about women role in tech, we still try to mould participants in old stereotypes.

Before I continue to share my personal views about this difficult topic, I need to share some background facts:

  • I am a woman
  • companies where I worked and work, male are a majority. In two companies I was the only woman with ratio 1:15 and 1:50.
  • the most terrible thing what can happen to a woman in tech, that she is invited/promoted because of her gender, not because of ideas she present

For example, my personal aim for this year was to become a testing conference speaker. I accomplished it with the talks at Belgium Testing days and Agile testing days – both are women friendly conferences. I am very proud of myself, but in the same time, because I know about women-in-tech-promotions I cannot be sure that I got my chances because of my stories or because of my gender. My hope is that time will show what is what. But for now, for 2017 I set another aim – to talk in non-testing conferences. Till now – only rejections.

The thing about diversity is the same with excess weight, you close the eyes and hope that one day it will disappear just like that, without any effort. But deep inside you know that if you want a real change, you will have to work hard and disciplined. And it will take some time until first results become visible.

Conferences are mostly organized by men and mostly men are invited to present. They speak in one language and have a similar set of values. But men are not only one to blame. Women need to lean in more and not get scared by the first decline. I know what I am talking, I heard a lot of NO’s. But the only way how to keep going is to keep going.

This is my pattern how I do it:

  1. do not wait for permission
  2. do not think what others will think of you/your work
  3. do not give up

Some of the companies, where I worked, had no-feedback-is-good-feedback policy, in other rules of procedures. In both of the cases you can get old while waiting for permission to work on something. So I started the following pattern: inform the manager about solutions or ideas and if there is no immediate feedback, like “NO, DO NOT DO IT!”, then I proceed with implementation. With a time I learned that that was exactly what was expected from me after informal part. No feedback is approval!

Other two things mostly are supporting the first one. To imagine what others will think about my actions takes too much time and energy. Time and energy which I need to proceed with my aims. Reduce the waste, get rid of everything what is holding you back. And just keep doing what you love to do.

At the end, dear men, do some fact checking from your past and present and recall when did you last time thank or praise your women colleagues for a good job?

Found On Internet

Excellent read about developers and some paradoxes Agile Methodology Breast Feeding

 

Post Navigation