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!

 

 

Advertisements
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!