Posted in agile, scrum

I had scrum once. It was… fantastic!

National Sunglasses Day Sale

Hey People!

Why sunglasses at the beginning? It is 34 C degrees in Poland at the moment. Really hot – so sunny kisses for those of you –  who have milder weather conditions:)

Reason No 2 – it will be my last post before well deserved holidays (you can be jealous). Some major changes are coming just after the holidays, but let’s keep it in secret for now;)

Why Scrum again?

After my previous post I was asked if I had an example of nicely done retrospective meetings. Can I recommend some approaches?

I decided to leave theory and books aside for today and focus on practice. This is a unique opportunity of real-life project retrospective memoirs.

KingaWitko_QualityExcites

Step one – Communication

There is no Scrum, no Agile, no retrospective when people don’t talk. How to obtain it when not working at one spot? The other day I’ve heard of great approach “Pretend you are all remote”, even if some of you is sitting next to each other.

What’s the benefit? We are all at the same page. We are able to talk with the whole team  and at the same time, no one is excluded from important sessions or decisions. From tester’s point of view it is highly valuable.

My experiences with remote work and remote retrospective meetings used to be bad, very bad, actually. When people were sitting in two or more locations – the knowledge, skills and social life were divided as well. Retrospectives were rather rare and ALSO divided. People gathered in some conference rooms, were not able to hear well, some of them were excluded. Do you have such experiences as well?

BUT

The change has come.

Unique approach

I had a chance to work in a scrum project once. The real scrum project – with a scrum master, great mindsets and whole bunch of good  Agile treats 🙂
It was not a long-term, but definitely outstanding one.

We were located in three cities, but it was not important. Development team was at the same page all the time. However, great communication and demanding tasks were not the only features that make me think of this project as of the good one – retrospective made it remarkable.

What was so unique? Does remote retrospective really work? Sure it does! All you need is approach, sense of humor and the purpose.

The meeting

b1e3c46ef8f1cf9f45d808c9a0bf934e--secret-meeting-picture-cat

Nah, not that kind of meeting 🙂

I’m rather talking about such level of curiosity :

FUNNY-CATS-we-can-haz-council-meeting-meme
First of all, meetings were recurrent – same day, same time each sprint.
As I wrote before, the need of ritual is essential when talking about retrospective. Next – it was fun!

The scrum master took us by surprise each time. He provided awesome and delicious boards (online boards, of course), on which EACH OF US were welcome to “stick” their notes.

It was virtual – but it worked perfectly well. Going this direction, we had:
doughnuts retrospective, candy retrospective, pink fairy retrospective and so on…

Some of us complained that it is not “serious”, “somebody bought Creative Retrospectives book” or so. We played each time a bit like kids, but at the end of the day everyone benefit from it.

I also would like to highlight, that the funny form and elements of joy were not that important as the method, that made everyone speak and look for both:

  • fields for improvements
  • good things to honor.

Examples

650fa4f6d721280122a5f518122cef3a
How were we able to obtain that? By ‘talking’ or ‘thinking’ for somebody else. What do I mean by that?

Let’s try to rephrase a standard question:

What you are particularly proud of after this sprint?

or

What was not correct in this sprint?

INTO

What a person, who sits on your right thinks about it?
What he is proud of?
What did he achieved?
What was his blocker?

This little magic trick enables your mind to completely different behavior. It helps you to become a team, to acknowledge someone else’s needs and before the next meeting – you’ll ask first:)

As i said, each time we had surprise. Games were different, surrounding was different, but eventually it made a team – and this is all about in Agile, isn’t it?

Catch me on Twitter, I’ll keep you posted (and make you angry) from sunny beach 🙂 Cheers!

 

Advertisements
Posted in agile, scrum

Retrospective – it matters the most

Is it me only, who thinks that this blog becomes more and more Agile than testing? 🙂

Anyway.

retro

The other day I was trying to describe myself in front of big audience – and I thought that the best sentence would be : a software tester, who fell in love with … agile methodology! 🙂 A friend of mine asked me if I am more a tester or more an Agile creature. As everyone is Agile now – I’d rather  stay with tester’s mindset but Agile way of work. Does it make sense?

Speaking of which – what is the most important meeting for you (if you work in Scrum, of course)?

For me, when thinking about Agile, the most important and valuable meeting that comes to my mind is RETROSPECTIVE. You may agree or not, stating who we are without daily? BUT in my opinion, a retrospective meeting is unique portion of time, when the whole team sits together and tries to improve.

Team as a choir

hqdefault

Let’s imagine that a Scrum team is a choir.

It has to practice, sing and perform together, exchange ideas, spend a lot of time with one another. They do work.
On the other hand, each of choir members practices alone. Each of them knows his notes by heart and can perfectly sing solo parts, but at the end of the day – they have to perform in front of the audience. The performance of a choir is not a bunch of gathered solo parts – it has to sound as one! All voices complement each other and act like human orchestra. Can you imagine your team acting as one organism?

When thinking about this kind of approach – it may become obvious that scrum team has to seat together and have a common goal. For me, a retrospective meeting is that period of time, when a choir meets, has a rehearsal, spends time to improve and acts together.
I do believe that as  voice rehearsals are the most important times of choir work – as daily meetings and retrospectives have the same roles in scrum team lives.
It is all about acting together in order to improve.

The need for ritual

shareimage

In one of my favorite books about retrospective meetings – Agile Retrospectives: Making Good Teams Great (you can find it on Safari or Amazon) – retro meeting stretches across the whole sprint.
It is not just a meeting, of which everyone would not remember the next day. It lasts. The need for ritual is essential in preparation, conducting and improving. It is always about those three factors. That’s why everyone is welcome to come with his own opinion, problems and successes to the meeting. It is not supposed to be a one-man-show but a choir performance (or just a rehearsal 😉 Everyone is involved!

Leave your negative energy behind

How to act as a choir during retro? How many retrospective meetings, on which one person was a dominant do you have behind you?
Most of us have plenty of negative experiences connected with retrospective meetings (especially in Poland, when everyone is more tend to complain that to cheer up 😉 – please watch this YouTube video by Mark Walters to acknowledge what does the Polish Face mean 🙂 ). BUT complaining should not hijack the retro spirit !!!

Negative packaging is the first things the listeners see. Complain energy is tricky to handle. That’s why each of you should come to the meeting with your own mind. That’s why scrum masters use “stupid” games, “ridiculous” colorful sticky-notes and act (sometimes) like children :). Simply, in order to avoid a situation when only one person, one point of view and one problem matters. Everyone should be influential and benefit from the meeting.

A developer

banana-minion-wallpaper-despicable-me-movie

A development team consists of… DEVELOPERS! Brilliant, isn’t it? And as we all know – developers are the most open, cheerful and ready-to-speak up people in the whole universe!
83ae4322dff2116546d025b11f793523

So… sorry, Scrum Maters, Product Owners and all business-related people – it is not an easy task for you to make them speak during  retrospective meeting:)
How can you encourage a technical person to do so?

Honor the heroes!

Bring sweets!

Hear success stories!

Don’t push!

Capture and analyze metrics  (technical people feel more comfortable with numbers)

Bring more sweets!

Always look on the bright side of life

leadership-lessons-from-minions-550x336

Exactly. Speaking, complaining and honoring mean nothing if you don’t benefit from it. Sooooooooooooo – get it done!

Collect ideas in order to improve. As a choir during rehearsals:

practice, improve, repeat

Summarize your thoughts in an email, wiki or any other source of common project knowledge. Make your ideas and improvements visible.

Buy yourself a whiteboard, prepare a virtual Jira board. Do at least one thing to emphasize your conclusions, enable each team member to have an access to it.
The more you know – the more you are able to improve.
And remember – your conclusions from Reareo No1 might be a great beginning of Retro No2 and so on. It is a circle and a teamwork.

Good luck! May the retro-force be with you.

In case of any ideas – don’t hesitate to stalk me on Twitter or comment down below. Cheers!

 

 

Posted in agile, conferences, scrum

How to become Jedi Master

24890461356_1f932371bb_b

Lady Vader strikes again

My previous post was about Quality Excites conference in Gliwice. This time I would like to say something more about vivid conversation that took place during my discussion panel.

I had a chance to meet wonderful people and share inspiring ideas. It was an unique opportunity to hear about personal experiences and best practices worth to share.
As I wrote many times before:

womens-rights

How to become Jedi Master?

I do believe that every software tester is a kind of Jedi Knight. He fights for quality and the Quality is his light saber.
Who is a Jedi Master though? A person, who understands agility, quality and has a need for working together.

My best example of Jedi Master, who should lead all Jedi Testers, is Master Yoda. The same one, who talks about Agile:

“You must unlearn what you have learned”

803e86052f46b83569a8942c976057b9

Going further, I’ve asked people 3 – in my opinion important – questions about cooperation in an Agile team:

  1. How to communicate?
  2. How to introduce new people?
  3. How to share knowledge?

How to communicate

Nowadays, it is in job advertisements, small and large companies, everyone works in Agile.

mus9e8

When scrum team sits together – it is a perfect situation.

My concern was if a spread team (team located in several cities or countries) is still an Agile one.

I – Kinga Witko – claimed that spread team is not a real scrum team.

No one agreed with me 😦 Fine. (Misa no wise)

smutna_zaba

On the other hand, I need to underline here the one and only truth, that emerged as a discussion result:
Spread Agile team MUST use CAMERAS. And talk. Talk. Talk. All the time.

UNIX (1)

This is the fact, which everyone put their attention on. I do agree with that. When we don’t sit together – we talk, ask questions, get angry and happy together. However, when we work together, but there is no day-today interaction between us, we need to stay as close as possible to one another. Talking, laughing (even swearing) are the team-building features.
We are all humans, we have better and worse days. All of us need attention and understating. It is not possible to be achieved via Skype chat or other Slack-ish tool only. Conversation is the key to success within a team.
There is no team without little chats or coffee breaks, sorry!

The other important thing in agile approach is a mindset. If a team member is not eager to cooperate, denies flexibility or talking – it is maybe not the right place for him (or her).

I do agree that agile approach to software making is not suitable for everyone and is not fitted to every project. It is fine.
It is also OK if you are more comfortable with working on legacy code, together with a waterfall approach. You don’t need to force yourself do be AGILE. There is a lot of space within software industry for every style and every tester or developer. Chill!

New team members

help-me-obi-wan-cat-meme-637x412

In every Jedi Master’s life this day comes – he has to train young ‘Padawans’. Either a new team member, company member or a trainee.

Some time ago I was asked if there is a good way to introduce people into the project? The next question is – how will you know that the new team member IS READY to perform on his own.

Surprise! Surprise! (there is none)

People are not robots, it is not possible to predict what will happen. Going this direction – there is as many ways as Masters. The way you teach usually depends on your skills, empathy and understanding. And good will, of course!
There are such things as company values or project – related directions, but – AGAIN – conversation is the key.

People on my discussion panel suggested clever solutions, such as:

  • never imprison new testers with boundaries – let them explore your software
  • teach through example
  • less talking – more doing
  • provide documentation and lot of freedom.

Again, it depends on your skills and new-joiner’s abilities, what is possible to be achieved. Another point in this discussion is a recruitment process. If a correct person is selected, he’ll perform good testing in a short period of time.

People spotted also, that a new team member is fantastic benefit and opportunity for ourselves. In the position of trainer we are able to:

  • learn how much do we know
  • acknowledge our limitations (Context Driven Testing)
  • explore with a fresh look (Exploratory testing)
  • find unknown bugs
  • fix old bugs (for example those, that everyone got used to)
  • avoid knowledge silos.

Knowledge sharing

e598eed939471cf7223948c283b3fd15

Modern companies have lot of ideas to share knowledge. Most of the times, employees are able to run or attend cross-team / cross-technology workshops or presentations, take part in training or read books.

As I love to collect clever knowledge-sharing ideas – I’ve asked people “How do you share knowledge in your teams/organizations”.

Some of you may already know Michał Buczko – he encourages developers and testers to work in pairs (Pair people!) – it is a convenient way of broadening your horizons and extending knowledge.

In order to share knowledge, you may also “rent time”.
It may be an hour / day of a developer, tester or other team or company member.
How to do that? Just book a time with the person and take part in his / her day. You can exchange afterwards – it’s up to you.
I know that there are companies, which even “swap” jobs among completely different departments to FEEL the other person’s real working environment (I’m talking about you – Ocado:). All of those brilliant ideas may seem tiny, but they really work and empower people to do ingenious things.

Maybe some of those practices shall be a software company standard at some point?
I wish it to all of my test-buddies and to myself as well.

Should you have any comments, ideas, things that work fine at your company and you would like to share – comment down below or stalk me on Twitter.

I hope you’ve enjoyed the summary – see you all on my next discussion panel 🙂

Cheers!

 

 

Posted in agile, scrum

What is scrum?

I’m going to be an Agile-pedia today. Maybe it will be useful for some of you.

What is Scrum-

It will be a long post today, so grab some sandwiches, sit down and relax 🙂

What is it all about

People are mistaken sometimes. In some cases, they lack of knowledge, but copy what they hear and pass it on and repeat it. What is more, they are even eager to argue about it.

Kim Knup noticed some time ago in her 99 sec talk, that nowadays everybody claim that they work in Agile. Everything is agile now.

We have agile dev teams and agile testers, agile projects – which sounds reasonable. There are Agile organizations. But agile recruitment process? Agile bank account?
I believe that even my dentist would call himself agile, to be honest.

Agile is the new black

The word ‘Agile’ became so trendy that people can’t live without is anymore. Each work advertisements says that an agile organization is looking for an agile tester for an agile project. Being not agile means not to keep up. Old school. Losers. Dinosaurs.

Unfortunately, ‘Agile’ became a convenient replacement for: lack of requirements, lack of documentation,  or, just basically,  a pure mess.

Where are you, Waterfall, my old friend? Nobody likes you anymore.

We have that one, so what about scrum?

Let me state it clear:

What is Scrum- (1)

AGILE DOES NOT EQUAL SCRUM

These are not equivalent words replacing each other. They mean different things.

Scrum is very goo in managing agile projects.
Unfortunately, people (PMs, Business, HR) tend to use those terms alternatively.
It makes me sad:(

In the picture below you can see the diversity of Agile methodologies and implementations. They all base on common concept, but allow people to adjust way of work to their needs. As you can see – scrum is just one of the options.

koncepts

In simple words – SCRUM is a lightweight, adaptive framework for managing complex projects.

Look at those yummy donuts (I couldn’t help myself!).

What is Scrum- (2)

There are three obligatory elements of scrum:

  • Roles
  • Artifacts
  • Events

Let me briefly describe each of them for you.

ROLES

There are defined roles in scrum project:

  1. Product Owner
  • Makes a value for the project
  • Manages project backlog
  • Represents the user
  • Is equal to the other team members

Product owner has to be a single person, not a group of people, however this person has to have a large skill set. He is THE ONE who is able to make go / no-go decisions – so – choose wisely. Product owner has to listen and keep up.

      2. Scrum Master

There is often misunderstanding.
However, this short sentence is really worth to remember :
Scrum master is not a project manager.

I can remind you enormous number of ‘inspiring’ (oh, please) LinkedIn’s pictures – Boss vs. Leader. Like this one, for instance:

boss-vs-leader-1024x1024

This is the basic difference between a Project Manager and a Scrum Master.

The Scrum Master has to be technical and social at the same time. He takes care of the project, but he also maintains team member’s requests on daily basis. It is also a Scrum Master, who resolves conflicts within the team, because (surprise, surprise!) – we’re just people.
We do fight at some point. 🙂

3. Development Team

Is a scrum team everyone is a developer. It doesn’t matter what’s your hire key – in the team everyone is equal in the area of responsibilities, activities and knowledge.

A scrum team has to have cross-functional members, who decide about the direction together. No roles. No guidance. Pure collaboration.

That’s why a scrum team consists of 5 – 9 people. Not less not more. And when I hear – ‘Oh, we work in Scrum – our team has 25 people‘ – I’m like:

-WTF-meme-7298

ARTIFACTS

Second group of elements in scrum methodology are Artifacts. Not all of them are considered as obligatory by Scrum Alliance, but is is good to keep all of them in mind when setting up a scrum project.

  1. Product vision

At first – we want to know what we would like to achieve within our project, what our vision is, where do we aim. A scrum team usually states the vision at the beginning of the project and adjusts it during the time.

      2. Product backlog

I believe that most of you heave heard about product backlog.
This is the concept that majority of tools used in agile projects originated from. When we’re talking about project backlog, we usually think of Jira, Rally, Yodiz or other open-source helpers – that’s correct. A scrum team has to keep product backlog in mind, but it is a good idea to visualize it in a convenient form,

Product backlog is a key artifact.
It must be unique, single and constantly updated.

It consist of all tasks that are under development at the moment and all of remaining ones.

All items are ordered by their value to the project and – what is the most important – all of them are estimated by the development team.
Not the Product Owner. Not the business. THE TEAM. 

        3. Release plan

It bases on empirical data – how we did in the past – what to expect. It is a good idea to update the release plan after every sprint or more often – each time we have more information and more data.

Release plan derives directly from the product backlog. It has to be highly visible for everyone in the project and, of course, up to date.

           4. Burn-down chart

A visual artifact that reflects the progress and sprint backlog at the same time. It may be done in Jira, on the full HD super shiny screen in the middle of the room, on paper, whiteboard and so on. It just must be visible and accessible for everyone.

It may look like this:

scrumburn1

or can be more complex. It is absolutely up to you.

5. Impediment list

This is basically a list of every obstacle which blocks the team.

Remember – all artifacts have to be visible and up to date!!!

EVENTS

Apart from roles and Artifacts we have also Events and this is probably the most known and doable element of agile development. How many of you have heard: ‘We work in scrum, because we have daily meetings’?

orly

  1. Sprint Planning

You should obviously have to do a regular sprint planning sessions in scrum projects. You may start from sprint zero, but it is not obligatory. During sprint planning the whole team:

  • decides what will be delivered
  • creates backlog
  • decides about the scope of the sprint

And what sprint is all about – it has to be timeboxed and once you decide about the frequency (from one week to one month) – stick to that. Eventually you’ll learn how fast is your team able to perform, how does the project go and so on. Take your time.

     2. Daily scrum = Stand-up meeting

* no longer than 15 minutes
* daily
* what did we do yesterday?
* what id the plan for today?
* do we have any blockers

        3. Grooming/ Refinement sessions

It used to be called grooming – now the name of this meeting is refinement and it should be used for re-estimating new requirements. Agile, scrum – it is all about the adjustments. During the meeting the whole team should review higher priority items and estimate again, if necessary.

What is essential – you should plan 10% of each sprint for those meetings. You don’t have to use them, but find time for them when you find them useful.

        4. Demo

You’ve probably demoed your development in front of the customer at least once in your career. It may be stressful, but is is necessary to complete definition of done in the scrum project.

The most important thing: Present just those pieces of functionalities that are ready. Basically, it should not be allowed to demo features that are not ready for production. Very simple rule – very useful.

Demo is also an opportunity – you are able to meet your business – gather feedback – think of adjustments. It is beneficial for both sides.

           5. Sprint retrospective

Last but not least – there is no sprint without a proper retrospective meeting. We’ve started sprint during planning session, kept it up during entire development and we would like to close it with some conclusions.

Tiny tip for Product Owners and Scrum Masters – BRING COOKIES 🙂

Retrospective meeting should fulfill our desire to improve our work:

  • what gone well
  • what didn’t go well during the sprint
  • make an improvement plan – ACTION PLAN
  • lessons learned

… and that’s it!

ISTQB DEFINITIONS

As I am a certified Agile tester, I shall probably quote ISTQB syllabus from exam materials:

crVtQK

Scrum is an Agile management framework which contains the following constituent instruments and practices :

* Sprint: Scrum divides a project into iterations (called sprints) of fixed length (usually two to four
weeks).
* Product Increment: Each sprint results in a potentially releasable product
* Product Backlog: The product owner manages a prioritized list of planned product items (called the product backlog). The product backlog evolves from sprint to sprint (called backlog refinement).
* Sprint Backlog: At the start of each sprint, the Scrum team selects a set of highest priority items (called the sprint backlog) from the product backlog. Since the Scrum team, not the product owner, selects the items to be realized within the sprint, the selection is referred to as being on the pull principle rather than the push principle.
* Definition of Done: To make sure that there is a potentially releasable product at each sprint’s end, the Scrum team discusses and defines appropriate criteria for sprint completion. The discussion deepens the team’s understanding of the backlog items and the product requirements.
* Timeboxing: Only those tasks, requirements, or features that the team expects to finish within the sprint are part of the sprint backlog. If the development team cannot finish a task within a sprint, the associated product features are removed from the sprint and the task is moved back into the product backlog.
* Transparency: The development team reports and updates sprint status on a daily basis at a meeting called the daily scrum. This makes the content and progress of the current sprint, including test results, visible to the team, management, and all interested parties.

I hope my summary about scrum was valuable for you.
There is a lot of information about scrum around the web, several good pieces of literature, there is scrum.org as well, so keep on searching.

Any comments? – Don’t hesitate to write down below or on Twitter.

Cheers!