Change your Organization: it’s about trust.

May 2, 2013 Leave a comment

Some days ago a colleague suggested me an interesting blog of James Shore about changing the organization. How an organization can become more agile? How an organization can improve their processes?
Successful organizational changes cannot be fully top-down or bottom-up, but is there really a difference between the two? James Shore thinks they are essentially the same thing: “Both are extremely difficult. Both require that people want to change.” So how can you introduce new ideas and help the change to happen? The central point is trust. James says “It’s as simple as that. When people trust me, I’ve been successful. It hasn’t even been hard. And when people don’t trust me, no amount of cajoling, persuading, beating with sticks, etc., will make a difference.” The way to change something in the organization is no-change. The approach is more to show people ideas, seeing what they think, talking about alternatives, listening to experiences, etc.

“#1: the Way to Change is No-Change. I’ve seen how hard organizational change can be, and so I no longer attempt it. I just share ideas, lead by example, and have fun doing it. If things change, great! It’s a much easier approach to life… and you know what? I think it’s made me more effective as a consultant, and as a change agent, too.”

I like this thought and I think James is right: at the end change is about trust and respect to earn this trust.

“We must be the change we wish to see.” – Ghandi.

Filed under Becoming Agile Tagged with , ,

Rotating the ScrumMaster Role. I let the team decide.

March 26, 2013 2 Comments

Recently I have been asked by some stakeholders why it is always me in the role of ScrumMaster instead of just rotating it periodically inside the team. The motivations following this remark have been:

- It is recommended by agile.
- It has been done by another Scrum team inside the company and it worked well.

Is it really true that the SM role should rotate inside a team?

I don’t agree with the idea of having a permanent rule to rotate the SM role specially when it comes from outside the team and those motivations seemed to me not really valid ones. I also clearly remembered what is written in “Succeding with Agile” by Mike Cohn about rotating the SM role. What he says is that the habit of rotating the job of SM is not recommended and it could be done in some occasions and for specific reasons but not as a permanent practice. The risk to rotate systematically the role is that the stakeholders don’t really understand the duties of the ScrumMaster and they can start thinking that everybody can do it. We know instead that to be a good ScrumMaster we need particular skills.

Furthermore in companies that haven’t fully transitioned to agile and are mainly organized in a different way (ex: waterfall development) I find that there isn’t always a clear understanding of what a ScrumMaster really is. In such organizations the role of ScrumMaster can be a little different from team to team and it can depend on the context. Sometimes when these companies need a ScrumMaster they need also other skills and other responsibilities and in this case I think rotating the role is even more complicated and risky.

Why it worked well for one team inside the company? Why the rotation cannot be applied on every team?

The asnwer is simple: every team is different. It’s a mistake to think that what worked well for one team should work well for another and in my particular case between the two teams there were some differences: my team was a cross-functional team with no manager inside and working on different functionalities of the application (from UI to DB),  the second team was a UI team working in a dedicated UI project with a manager be also part of the team. The context was different and the role of the ScrumMaster in the two team was a little different too. As we told earlier, the context is important.

I didn’t think the motivations were really valid and I didn’t think it was a good idea too to put in place a permanent rotation. I clearly expressed my position to stakeholders but I didn’t want to defend this position alone… I was there to represent the team, I was the servant leader for the team so what the team thought about this? Did they feel the need of this rotation of SM role?

What I did as ScrumMaster

I decided to schedule a retrospective meeting with the team, dedicated to the subject of rotating the SM role, to know what the team thought about it and what they wanted to do.
The results of the Retrospective have been that the team didn’t feel the need to rotate the ScrumMaster role and they didn’t want to have a predefined rule to rotate it.  It should have been a team choice when someone in the team wanted to try the ScrumMaster role. One team member told in the retrospective that he would have been interested to try the role temporarly in view of taking then a CSM certification, but not immediatly. The team agreed also to put in place something to improve the situation when the ScrumMaster wasn’t available (back-up).

As a result of the retrospective we added  in the team wiki a section dedicated to the role of the ScrumMaster with all the responsibilities and the tasks to do.  This guide is actually used as a reference for the back-up ScrumMaster and to give also visibility outside the team on the duties of the role.

What I learnt

As ScrumMaster I tried to express my position to stakeholders giving the reasons why the habit of rotating the role wasn’t really a good idea but sometimes is not easy to convince people. In these situations you can do a step back remembering that as ScrumMaster you are a servant leader for the team and you can let the team decide. It’s much more easier if all the team agrees on a position to defend and legitimate it.

Filed under ScrumMaster Tagged with ,

Gather data in the Agile Retrospective

March 23, 2013 Leave a comment

At the end of every Scrum sprint there is the retrospective meeting, where the team gathers after completing an increment of work to inspect and adapt their way of working and teamwork. The agile retrospective can follow a precise structure as described in [1]:

  • Set the stage – to prepare the team for the work they’ll do in the retrospective
  • Gather data – to create a shared picture of what happened during the iteration
  • Generate Insights – to indentify and analyse the causes that contributed to the team success or that need improvement
  • Decide What to do – to create actions for the next iteration
  • Close the retrospective – to express appreciation and have feedback on the retrospective

As ScrumMaster and facilitator of the retrospective I dind’t always follow the full structure suggested in [1]. Sometimes the step to gather the data was skipped and the retrospective just started to generate insights identifying what went well and what we needed to improve. It was a mistake. Since some retrospectives I reintroduced again this step and I found that it really helps the team to remember what happened during the sprint: impediments, difficulties, positive moments, feelings. It’s not only important for the team to create a shared vision on what happens but it’s also a way to check how people inside the team consider the same event (positive or negative) and generate discussions.

Timeline

Timeline – Agile Retrospective

The activity I use to gather the data is mainly the “Timeline”. It’s a very simple but powerful activity to stimulate memories of what happened during the sprint and the aspect that I found really interesting is when the timeline is used to collect not only the facts but facts and feelings.
To do this after having collected all the facts in chronological order I ask each team member to put a colored dot to show if they consider the event positive or negative or if their energy was high or low. This part can be considered as another activity called: “Color Code Dots” [1]. Once the facts are associated with feelings we have interesting data to start discussions.
I ask why an event is considered positive or negative, I look if all the people put the same feelings or there is someone that consider the event in a different way and in this case I ask why we have this different perspective. Sometimes I ask to draw a graph for the ongoing emotional ups and downs during the iteration. It’s interesting to see again that no all the team has the same emotional status.
I found the part that add feelings to the facts really effective because it helps the team focus not only on technical issues related to the development process but on the team and team issues, as it should be for a good retrospective.

In conclusion after having seen the difference of agile retrospectives with a step to gather data and without it, I suggest to always find time and do this step. As said by Aristotele: “Well begun is half done”.

[1] “Agile Retrospective – Making Good Teams Great” – Ester Derby, Diana Larsen.

Filed under retrospective Tagged with , , , ,

Managing Future Bugs (Known Unknowns) in the Sprint

January 20, 2013 Leave a comment

This article has been firstly published on the Scrum Alliance site.

As ScrumMaster, there are different situations we have to deal with. Here I’d like to address the following topic: how to deal with future bugs that can arrive at highest-level priority during the sprint (in other words, we must treat them).

This is a common situation if the Scrum team is not only responsible for developing new functionalities but also for solving bugs found in the production environment, linked to user stories or not. In companies that haven’t fully moved to Agile, where Scrum can have a Waterfall-at-end interaction, these bugs can be opened during the quality assurance phase (after the Scrum process) — but we don’t know how many there are.

When bugs are already known, they can be put in the product backlog during the sprint planning; they can be estimated and considered user stories. Sometimes, however, all we know after the sprint is started is that we will have some bugs to treat during the sprint. These future bugs can arrive later, with a high priority compared to the user stories in the sprint. It’s an example of the more general problem of how to manage the “known unknowns” in a project. We know that we will potentially have some bugs to treat, but we don’t know how many or what they are.

We have to plan the sprint content, and we have to deal with these “known unknowns” bugs. How can we estimate the bugs in the sprint? How will these bugs affect the team sprint velocity?

Future bugs estimation: Story points versus capacity days

The first option could be to replace the bugs (not present at the time the sprint starts) by so-called “placeholder stories.” Estimating such stories can be difficult because we don’t know their complexity. The range can be from a reassignment of the bug to another functional team (if it was wrongly assigned to the Scrum team) to a complex fix done by the Scrum team itself. We could assume that these “placeholder stories” are of a small to medium size, adding some of them into the sprint.

An alternative approach is to have just one “placeholder story” for all the bugs, with a percentage of the sprint velocity associated with it.

The main point for the first option is that the “known unknowns” are managed, estimated in story points; and these story points are considered in the sprint commitment. In this case the velocity of the team will be not impacted by this “extra” work, because the work is visible and estimated in story points.

The second option could be to leave a buffer in the number of days in the sprint needed to treat these bugs. The time reserved to manage the “known unknowns” could be considered as less capacity for the team during the sprint. This brings a lower commitment in story points (just as when team members take vacations during the sprint). This option affects the team velocity because some capacity is reserved to do “extra” work in the sprint that is not visible and that hasn’t been estimated in story points. As ScrumMaster, you’ll have to pay attention to keep track of the team velocity in association with team capacity (available working days in the sprint), which in this case can vary more.

Summary for managing future bugs (known unknowns) in the sprint

ESTIMATION OF PLACEHOLDER STORIES

Pros:
- Work is visible in sprint backlog
- Team velocity is less impacted

Cons:
- Estimation in points for something of unknown difficulty

USE CAPACITY DAYS

Pros:
- Easier if we know that some days must be reserved for this (for example, associated to another budget line)

Cons: 
- Work is hidden in the sprint (bug fixing considered as “vacations,” no story points or user stories associated)
- More fluctuations in team velocity

Filed under planning Tagged with , , ,

A happy day

August 1, 2012 Leave a comment

Today I’ve received the book “User Stories Applied” from Mike Cohn with his personal inscription inside. Being his fan this gift made my day instantly happier.

Mike Cohn book inscription

Filed under books Tagged with

Software engineers shouldn’t be like “cogs in the machinery”

July 30, 2012 Leave a comment

Even with the agile “revolution” taking place in these few last years in the software development industry it’s still common to find companies developing software where the importance is more focused on the processes than on people working every day to develop the software. Even when companies declare that people are important they don’t really perceive the situation in which many software engineers work today. This situation is however well described in the literature and used also as motivation for a transition to agile.

Unfortunately I find the metaphor of software engineers like “cogs in the machinery” of Mike Cohn in “Agile Estimating and Planning” well describing the reality here:

“Agile teams value individuals and interactions over processes and tools because they know that a well-functioning team of great individuals with mediocre tools will always outperform a dysfunctional team of mediocre individuals with great tools and processes. Great software is made by great individuals, and as an industry we have tried too long with too little success to define a development process that relegates individuals to replaceable cogs in the machinery. Agile processes acknowledge the unique strengths (and weaknesses) of individuals and capitalize on these rather than attempting to make everyone homogeneous.”

I agree also when David J.Anderson in “Kanban. Successful Evolutionary Change for Your Technology Business” tells that “like Ford assembly-line workers in the second decade of the twentieth century no one cared about the monotony of the work or the well-being of the workers”. Again “It’s hard to imagine the emergence of organized labor in knowledge-work fields like software development, mainly because it’s hard to imagine anyone addressing the root causes of the physical and psychological ills developers routinely experience”

A further step in considering individuals and interactions over processes and tools is to have people acting as a team. This is a completely different thing than having a group of people together for administrative convenience.  As Douglas McGregor told:  “Most teams aren’t teams at all but merely collection of individual relationships with the boss.  Each individual vying with the others for power, prestige and position”.

For a software engineer the feeling to be part of a real team is exactly the opposite as feeling to be a “cog in the machinery”, this is what software engineers should search to feel more motivation and appeasement in their daily work. Managers should consider the problem.

Hope this can help reflection…

Filed under Team Tagged with ,

Testing in Scrum with a Waterfall Interaction

March 24, 2012 Leave a comment

This article has been firstly published on Scrum Alliance site .

Sometimes, when testing user stories in Scrum, there’s a final Waterfall interaction to deal with. The scenario I present here is based on this situation: a Scrum process with an interaction of sequential phases at the end of the process to (re)test the whole developed functionality. These sequential phases are mandatory for our organization, which follows a Waterfall process for the releases of the product. So, for the moment at least, we have to deal with this — and my experience is that we aren’t alone. We call this scenario of interaction with Scrum the “Waterfall-at-end” (see Michele Sliger, Bridging the gap: Agile projects in the Waterfall enterprise. Better Software, July/August 2006, 26-31). I think this scenario is frequent because the adoption of Scrum often is incremental inside an organization, and both approaches can coexist for a while.

Below is a graphic depiction of this scenario:

I’d like to discuss how the testing has been integrated into our process, then analyze the objections that are sometimes raised on the testing choice made. I hope this can help people in the same situation we’re in, and that it can start a discussion about best testing approaches in this situation.

Scenario

The functionalities we develop are constituted of many user stories. For each user story, at the beginning of the process, all team members together identify what we call “test ideas.” Test ideas can be seen as test acceptance criteria for the user stories. Generally, every test idea is translated into a manual test, with different steps to follow to finish the test scenario. These manual tests are written and run for every user story.

The problem compared to a full Scrum approach is that, given the Waterfall-at-end interaction, we are obliged to rerun the tests for the whole functionality to qualify the product before going to production.

Objections

There are several valid objections to the scenario, and they are interrelated:

  1. Creating and running tests for every user story is inefficient because we have to rerun them for the whole functionality. It’s better to create tests on the whole functionality at the end of the Scrum process.
  2. We spend a great deal of time creating tests for every user story when, instead, we could create one single test grouping more user stories.
  3. We spend too much time running the same tests: We run tests for each user story (during Scrum), then for the whole functionality once delivered (during Waterfall-at-end), and then once in the QA phase (during Waterfall-at-end).

First Analysis

Testing each user story separately is, for me, the basis of the Agile process, even in an interaction with a Waterfall-at-end scenario like the one described. Integrating testing into the process itself is something we should do for any software development process, not only in Agile or Scrum. This approach respects one of the fundamental principles of modern quality management: “Quality is built in, not inspected in.”

The reason to respect this principle even when Scrum interacts with a Waterfall process is because testing later in the process brings well-known problems (see Mike Cohn, Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2011, 308-309). It’s also crucial because the team shouldn’t think that quality is something different than development, something to assign to only one person in the team (the QA specialist). It’s important to keep a whole-team approach (Lisa Crispin and Janet Gregory, Agile Testing: A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009).

Let’s analyze the objections more in detail:

1) Creating and running tests for every user story is inefficient because we have to rerun them for the whole functionality. It’s better to create tests on the whole functionality at the end of the Scrum process.

It’s true that it can take more time to create tests for every user story than to create the tests for the whole functionality. But what I’ve noticed is that when tests are created per user story, we tend to test more. I think that’s a logical consequence of splitting the functionality in more manageable parts (user stories): Test ideas come more naturally and in more quantity when we’re dealing with user stories rather than considering the whole functionality.

So even if it’s possible that we spend more time with this approach, we test more (with more tests resulting at the end). To me this is not a waste of time but proof that integrating testing from the beginning of the process can cultivate more thorough testing. The development is done with all these test ideas in mind, and this helps produce better quality, because in order to finish a story all the tests have to be passed.

2) We spend a great deal of time creating tests for every user story when, instead, we could create one single test grouping more user stories.

It’s true that sometimes, especially with small user stories, it seems like a waste of time writing a test when we know that two user stories later, we’ll have to test another part of the functionality. Why not just create a single test? In any case, the test for the Waterfall-at-end phase could have a single test (perhaps grouping two or three user stories).

I think that this mind-set may sometimes reflect the fact that we have user stories that aren’t well created, or tests with a bad design. Even if a test is done for a small user story and we have to modify it when another story arrives, the impact shouldn’t be high if the story has been created in the right way and the test was well done.

And what if, instead, we create a single test (grouping more user stories) and then for some reason the functionality isn’t fully developed? Isn’t it always better to have a set of tests reflecting the functionality developed so far?

3) We spend too much time running the same tests: We run tests for each user story (during Scrum), then for the whole functionality once delivered (during Waterfall-at-end), and then once in the QA phase (during Waterfall-at-end).

This is the easiest objection to respond to because the answer is: Yes, it’s true!

I simply agree, and I don’t see a better solution other than introducing test automation. But sometimes you have to deal with the organizational culture and barriers to successful adoption of automated tests. I see this as a technical debt. Our team has to deal with it, introducing the change and showing that it’s possible to use Agile testing principles. And I can say that it’s not easy.

I hope other readers have ideas about how to deal with this testing issue. I’d enjoy an online discussion.

Filed under testing Tagged with , , ,

Follow

Get every new post delivered to your Inbox.