Luis Gonçalves's Blog, page 9

Agile or Scrum don´t matter! What matters is software delivery!

Agile or Scrum don´t matter! What matters is software delivery!

My first official Scrum Master gig, about a decade ago, was in a large telecom. The team I was working with was updating the activation software that dealers used for on-boarding new mobile customers, changing price plans and add-ons, and such.

At the time, my mindset was firmly entrenched in Scrum dogma. As a relatively newly minted CSM, all I knew was Scrum.

I valued transparency, and courage so when it came time to start our agile project, I invited all outside stakeholder groups to our bi-weekly demos. That included marketing, various business units, trainers, directors, managers and more.

The reaction to the demo was mixed. Some thought it was a waste of their time and others thought it was ok. We noticed that over time, only the corporate trainers, and a couple of sponsors continued to attend. They were responsible for updating training documentation, and for training the in-store reps on the changes.

 Our team had clear marching orders:

– decrease the total activation time from X to Y (I can’t remember the exact numbers)

– decrease the total number of screens from 18 to 5 or something. (I can’t remember the exact number, but the existing flow was convoluted)

As I write this story, I imagine people who have the mindset I had a decade ago would say: “BUT YOU CAN’T DO THAT!!! TELLING THE TEAM TO REDUCE THE SCREENS FROM X TO Y IS GIVING THEM A SOLUTION!!!!!”

To which I say, relax will ya? It clarified the intent of what the business wanted, which was to make it easier, and faster, for reps to activate devices so they could make more money.

“BUT STILL….THEN SAY THAT INSTEAD OF GIVING THE TEAM THE SOLUTION!!!!” you may say.

Again, relax…which leads me to the point of this post.

 I always believe the role of the scrum master was a servant-leadership role which, to me, means that my opinion of how things should be, is irrelevant. I serve the team, the team serves the organization who serves their customers so we push-and-pull to figure out the best way to deliver solutions.

As I learned more about agile, I was still confused about why business folks would care about scrum or agile at all. Aren’t they interested in getting stuff done more effectively from idea to production versus wanting to know how agile they were?

I verbalized this confusion at an agile coach camp and generally speaking, I was met with a “you just don’t understand agile” attitude. Funny thing is, today business agility is all the rage so I guess I was right and those experienced coaches were wrong.

And yes, I’m poking fun at the community I love, so don’t take that seriously! That said, for a community that values inclusion, I see this at every conference I attend. Project managers come in with legitimate questions about scrum and agile, only to be made fun and chastised from the very people they’re wanting help from. I’ve been guilty of this as well.

Ok, rant over. Back to the story.

Our team had implemented some testing automation at the GUI level in order to capture before-and-after screenshots for the trainers after every sprint. This way, they could see what was different and they could incrementally create their training documentation.

We went live with zero known defects which was a first for this organization. Our product owner, who to this day is the best I’ve ever worked with, sent out an email on launch day to that effect. I wish I still had the email lying around as proof.

To this day, I’ve yet to work with such an amazing team. For some reason, the stars were aligned and things just clicked.

 These were some of our victories:

We wrestled deployment away from the deployment team and when it was time to release, we’d come in at 4 or 5 am and do the deploy ourselves.
After the first sprint, as usual, testing was crammed in on the last day so one of the developers, who was also our technical product owner said: “maybe we should help the testers next time?” That sparked a team agreement: testers will create the test cases and distribute them to the developers, the only rule is, you don’t test what you built.
Before mob-programming was a thing, we spent an afternoon once a month doing it. We were using Find Bugs ( http://findbugs.sourceforge.net/ ) and decided to bring one laptop into a conference room and smash all the red bugs. It just felt like a good way to learn and share technique, we didn’t know it was a thing.
Because we had a diverse team, in one retrospective we had each person write all the team members names in their native language like Urdu, Sandscript, and Mandarin. We didn’t intentionally do any team-building, we just liked each other and thought it would be fun.
When we had our first production problem, I was hauled into the Directors office for a beating, to which I told him to have the people who came down on him come and talk to the team because it wasn’t fair to him. By the way, that never happened, but we made the offer.
We used Rally and not sticky notes, but we all sat in cubes in the same area so daily collaboration was easy.
We continued to involve downstream groups in our demos, and sometimes our planning if we thought there would be an impact.
I sent out a half-page report telling all interested parties what our sprint commitment was, what the output of our retrospective was (only the stuff that was relevant to people outside the team), and again at the end of the sprint with a summary of what happened.
We had a PM who managed all the budget and other stuff. He never poked his way into the team and to this day is one of the best PMs I’ve ever worked with.

Everything our team did felt like the right thing to do. Never did we use scrum, or agile, as a stick. We knew our purpose, we had a clear objective, and we had a great team.

I feel fortunate to have started my scrum master career in a large organization because it helped shape my view that scrum and agile don’t matter, and people outside the team care about software delivery, not dogma.

These people might have the dreaded fixed-mindset, and there’s nothing wrong with that. As a community, we need to stop clunking people over the head with the dogma stick, and instead, empathize with what’s important for them.

Yes, reporting status to the scrum master might sound stupid for some people, but do you know if that scrum master has people who expect some type of report? Do those people have other people higher up that are expecting some type of report?

There are some simple questions you can ask yourself when it comes to interfacing with the rest of the organization:

What are they wanting to accomplish with Scrum?
What is the organization’s tolerance for disruption?
How intentional should you be about disrupting the status quo?
Who stands to win, and lose, when the organization is disrupted?
What up and downstream teams, processes, and departments are affected by what your Scrum team is doing?
When should you swim with the organizational current and power structures, and when should you swim against them?

I find it helpful to map this out to understand the organizational ecosystem so I can figure out which constraints are real, and which ones are artificial:

Source: Jason Little

 As a homework exercise, if you’re working in a multi-team environment, or an organization with more than 100 people, map this out on a wall.

There is no magic to scaling agile, there is only a conversation with those who are impacted by what your team is doing. You don’t need a big framework or method to understand how to deliver solutions, simply visualize your system, involved the people affected, and come to an agreement about what you’ll change, and what you’ll keep the same.

Use a diagram like this to figure out what you might be disrupting so you can make a choice about how disruptive you should be.

Above all else, get curious, not furious.

The post Agile or Scrum don´t matter! What matters is software delivery! appeared first on Luís Gonçalves.

Planning Poker And Scrum Poker Everything You Need To Know

PLANNING POKER OR SCRUM POKER EVERYTHING THAT YOU NEED TO KNOW

Hi, this week I will be discussing Planning Poker or Scrum Poker; strategies that use consensus-based estimating. Agile teams from around the world use the planning poker technique to estimate their product backlogs. Scrum Poker can be used with story points, ideal days, or any other estimating unit.

Planning Poker in Scrum brings together multiple expert opinions for the agile estimation of a project. This type of agile planning includes everyone: programmers, testers, database engineers, analysts, user interaction designers, and all other personnel involved in the project. Because these team members represent all disciplines on a software project, they are best suited for the estimation task.

How Does Poker Planning Work

A poker planning, or scrum poker session involves product owners or customers and editors. The session begins with each estimator holding a deck of value-based cards ranging in sequence. We recommend the following: 0, 1, 2, 3, 5, 8, 13, 20, 40 and 100. These values represent the number of story points, ideal days, or other units in which the team will estimate.

The product owner or customer will either read an agile user story or describe a feature to the estimators.

The estimators discuss the feature and, if needed, ask the product owner questions. When the estimators have finished their discussion, they each select one card privately to represent his or her estimate. The cards are then revealed simultaneously.

If the estimators select the same value, that number becomes the estimate. If their values differ, the estimators discuss their rational. Those who chose the highest or lowest value should share their reasoning with the group before each estimator selects another estimate card, repeating the process.

The estimators continue the poker planning process until a consensus on the value is achieved. If they cannot agree, the estimators may opt to defer the agile estimating and planning of a particular item, pending additional information.

When should we engage in Planning Poker (Or Scrum Poker)

Most teams will hold a poker planning session shortly after an initial product backlog is written. These sessions, which can take several days, are used to create initial estimates which are useful in scoping or sizing the project.

Because product backlog items – often in user stories form – will continue to be added throughout the project, most teams find it helpful to conduct subsequent agile estimating and planning sessions once per iteration.

They are typically held a few days before the end of the iteration and immediately following a daily standup because the whole team is still together.

Tips for Planning Poker in Scrum

The following tips help teams deal with common challenges in poker planning in Scrum:

Keep discussions productive: A two-minute sand timer is a helpful tool used to teach teams how to estimate more rapidly. To use the timer, the timer is set when someone in the group starts a round. When the sand runs out, the next round of planning poker cards is played.


Break out into smaller sessions: It is ideal, whenever possible, to break a larger group down into smaller sub-teams. This is a good option for running sessions when there are many stories to be estimated; often occurring at the start of a new project.


When to play:  Typically, estimating teams need to play planning poker on two different occasions: during the first iterations before the project begins and when new stories are identified during an ongoing iteration.

Top 3 Reasons Why Planning Poker is Great

It fosters collaboration by engaging the entire team.
It uses consensus estimates rather than single person estimates.
Through discussion of each user story, it exposes issues early in the project.

Watching successful teams during poker planning sessions will clearly demonstrate the three top reasons listed. Poker Planning is a great tool with many benefits, but there are other ways to help improve the process even more.

Small steps that most people miss, can be done to improve the process.  Knowing these tips will enable the successful coach or trusted team member, to help their team improve. So what are these nuggets of wisdom?

Those who do the work should vote.  

Too often, agile teams have everyone vote, regardless of their role in the project. Only those actively involved in the story should vote.

Managers don’t vote.

Managers usually want the work to take less time, so they often vote very low.  However, they have more experience than the average team member. By giving a manager veto power over the team consensus in one specific circumstance, they can then ask the team to consider something that may INCREASE the size.

Never allow managers to give low sizes or persuade the team to decrease its size because their opinion carries too much weight. A manager’s views will act as an anchor and drag the size down as they vigorously defend their position.

When there is a tie in the voting between two sizes which are consecutive, just pick the larger size and move on.

Consecutive sizes might be 5 and eight8 if you are using the Fibonacci sequence for sizing (1, 2, 3, 5, 8, 13).  An equal split usually takes a long time to resolve, therefore, use the higher number. In my experience, no one ever agrees to a middle ground number and usually choose the top size at the end of the discussion.  Using these facts is advantageous and will speed up the process.

Stop implementation discussions before they go too deep.

Teams commonly get very technical with details when discussing a user story.  While this is fine to a certain extent, it should be severely limited. Discussions should not take too long.  The people involved in the sizing should already have an idea for the simplest, plausible solution and pick a size based on that scenario.

While many believe that more discussion will make the size more accurate, the reality is that is not true.  It is done in part, to encourage teams to just make their best guess and move on. However, there a distinct lack of precision so the scale is not granular.

Use an “I need a break” card.

Teams often become so involved in their poker planning sessions that they do not realize when some team members need a break.  Having an “I need a break” card can be used by someone on the team to draw everyone’s attention to the need for a break.

Use a timer of some sort to limit discussion.

Using a timer to limit discussions is self-explanatory.  Discussions should be restricted to no more than one minute.

If consensus cannot be reached by the end of the third round of voting, pick the largest size and move on.

After two rounds of discussion, further attempts will not yield greater results and wastes time.  By choosing the largest size, the team has room to improve and will not be in any danger of running out of time.  The biggest problem teams try to avoid is running out of time, so this shortcut should resolve that issue.

Have the person creating the user stories meet with QA and Development leads before playing Planning Poker

User stories should have the answers to the most obvious questions ready.  Having answers ready, the team can focus on the size, not gathering information.

Remember the baseline.

Whatever the team picks as a baseline, it needs to be consistent from iteration to iteration.  If an ideal day is size one, then all iterations need to use that reference point.  If a user story is size one or three, then that needs to remain consistent across iterations.

Sometimes, it is helpful to re-address the baseline and discuss with the team what they believe the sizes truly are.  Failure to do this could eventually lead to “size creeping” a term I use when the team mentally changes their baseline over a larger or smaller size over time. This usually happens when the team cannot meet their commitment for several iterations, even though everything looks more or less the same.

Have fun!

Playing Planning Poker should be a fun, collaborative exercise.  Too many teams try to grind it out for an hour or two and forget to enjoy their work.  There are many ways fun can be injected into the process.  I like to play real poker with the sizes to add fun.

To play, every sized story counts as a poker card, and every five stories make a poker hand.  Before starting, everyone tries to pick which hand will be the best. This encourages the team to look at the user stories ahead of time, and then try to guess which set will make a straight or four of a kind.  Winners can even get a small prize.

Test Your Skills As Scrum Master

ARE YOU WONDERING IF YOU ARE DOING A GOOD JOB AS SCRUM MASTER?DOWNLOAD MY ASSESSMENT THAT WILL PROVIDE YOU A GREAT INSIGHT ON YOUR DAILY ACTIVITIES AS A SCRUM MASTER

Get My Assessment Now!



Planning Poker (Or Scrum Poker) for Distributed Teams 

“How can you play Planning Poker with teams that are geographically distributed”? There are likely many options to achieve this. These are a few common options:

Option-1: Chat Window (Tried, but leaves loopholes for biased points selection)

Communication mediums like GoTo or WebEx are used when teams are geographically distant. Once the requirements are clear, the product owner can signal via an utter to give points, and every member can use chat window tools to enter their number.

Option-2: Webcam (I’m using this one in the current project – Not great fun, But works!)

When using video conferencing to meet with multiple people (Google+ video a free and popular one), one person runs the meeting. That person says “1-2-3-Go”; after “Go” is said, each team member shows their card on the webcam.

Because the tools were supporting multiple people video chat display the users in a mosaic/tiles based form,  it is easy to see all the figures at once. However, on a funny note, people tend to show up cards after watching others. To prevent this, ask every member to hold up their card with the backside facing the webcam. Once host instructs the team to show their card, everyone simultaneously flips their card over.

Option-3: Planning Poker.com (Good. But you can’t change cards)

This website is designed by Mountain Goat Software, the same organization that pioneered poker planning cards. It is a free site that allows the moderator to create the project, add stories and invite people via email to participate in the process.

Any user who clicks on this link sees the story and standard scrum cards. The user does not need the authorization to click on any Scrum or post their thoughts on the story’s complexity.

Option-4: Google Docs

This idea is simple: create a spreadsheet in Google Docs and allow people to type their numbers.

Option-5: OneNote

The idea is similar to Google Docs, but MS Office documents also offer live synchronizing and platforms. While usage is limited to the desktop browser, but people also can post their opinions from their smartphones. Users new to OneNote will benefit from this video to learn the program.



Option-6: JIRA plugin

JIRA for Scrum management has a plugin to integrate poker planning within a JIRA UI. More details are available here.

Option-7: Scrummy

Scrummy is a story point estimation game for scrum teams, developed by the Web Chefs at Four Kitchens to allow easier participation by remote team members and to experiment with some new technologies.

Hope you enjoyed this blog post.

References:

MountainGoatSoftware

MontainGoatSoftware

Dzone

DiscussCode

The post Planning Poker And Scrum Poker Everything You Need To Know appeared first on Luís Gonçalves.

Legal Requirements – an excuse to impose Performance Appraisals

Hi guys, in this blog post I want to explain why we do not need to have Performance Appraisals in our companies for the sake of having “official written prof” about people´s performance. Every time I speak at a conference about this topic (Abolishing Performance Appraisals) there are always a couple of voices pointing out to the fact that we cannot ... Read More

The post Legal Requirements – an excuse to impose Performance Appraisals appeared first on Luis Gonçalves - Agile Coach.

How to create a safe environment in Agile Retrospectives

Hi guys, this week I want to help you with a topic that pops up quite often: “How do we create a safe environment in Agile Retrospectives” A lot of people come to me and ask me how can we help team members to say whatever they feel? Sometimes people do not feel comfortable to share everything… one possibility to ... Read More

The post How to create a safe environment in Agile Retrospectives appeared first on Luis Gonçalves - Agile Coach.

5 Great Reasons To Ask Questions

Hi guys, this week I am writing about the importance of asking questions. This blog post is inspired by a fantastic book that I read some time ago: “Coaching Questions“. The benefit of coaching opposed to advising is that asking coaching questions allow people to think, produce believable answers that can motivate them to act based on their ideas. Asking ... Read More

The post 5 Great Reasons To Ask Questions appeared first on Luis Gonçalves - Agile Coach.

The Instant Retrospective

The Instant Retrospective helps agile teams to tackle problems instantly. It’s a useful way to fix critical topics without further delay. The strength of this technique is the strong focus and solution orientated approach! It gives you the chance to fight against problems that prevents the team to perform. What you can expect to get out of this exercise Normally at the end of an ... Read More

The post The Instant Retrospective appeared first on Luis Gonçalves - Agile Coach.

How to drive Organizational Change

Hi guys, at this moment I am in Amsterdam taking a course on System Coaching and the module that I am taking right now is about Change Management. This is my first day but I already got fantastic ideas to share with you. The company that I am currently work with is trying to increase the code quality and move ... Read More

The post How to drive Organizational Change appeared first on Luis Gonçalves - Agile Coach.

How solution heroes can harm your team…

This blog post explain how solution heroes can harm our teams,It explains how these people can easily become bottle necks in our teams reducing productivity

The post How solution heroes can harm your team… appeared first on Luis Gonçalves - Agile Coach.

How cost reduction activities can destroy your company!!!

Herman is back. For the ones that follow my work for some years know that Herman is an Agile Coach in Supersoft. Herman is a person with whom I discuss several topics, mainly organisational subjects. Also, you should know that Herman is a fictitious character, so any kind of similarity with reality is a pure coincidence. I had an opportunity ... Read More

The post How cost reduction activities can destroy your company!!! appeared first on Luis Gonçalves - Agile Coach.

How cost reduction activites can destroy your company!!!

Herman is back. For the ones that follow my work for some years know that Herman is an Agile Coach in Supersoft. Herman is a person with whom I discuss several topics, mainly organisational subjects. Also, you should know that Herman is a fictitious character, so any kind of similarity with reality is a pure coincidence. I had an opportunity ... Read More

The post How cost reduction activites can destroy your company!!! appeared first on Luis Gonçalves - Agile Coach.