Every year VersionOne performs a worldwide survey about the state of agile development. Today we are going to talk about this.

For comparison purposes, I've done a post like this depicting data from previous research. You can access this post through this link and check out the subtle changes occurred during one year period. But do not worry, I will highlight it here.

To elaborate this study 3,501 IT professionals were interviewed. Of these, about 88% have knowledge of agile practices, reflecting an increase of 7% in previous survey. Most of respondents states they use agile techniques for approximately 2 to 5 years. The one using agile for over 5 years corresponded to 19% of respondents. Comparing to survey two years before, it is an increase of 9%.

Respondents were most commonly project managers, scrum masters and team leads, followed by software development team members. The following chart shows these profiles.

Let’s take a look into other interesting charts!

Below we can see the percentage of organization's projects that adopt agile methods. This measure allows us to see how companies already using agility are trying to apply agile techniques in all of their projects.

The range of 0% – 25% was 31% in previous survey. Currently, this number dropped to 27%. This is a small change, but in the desired direction. 

Scrum are still the most popular agile methodology being used, followed by Scrum/XP Hybrid with similar percentages. The scenario remains unchanged.

The chart above represents the amount of respondents who said they use or not each of the agile techniques. Compared to the previous survey, most of the techniques had improved slightly. Few of them had a small decrease. The highlight is Kanban (from 32% to 39%) and Digital Taskboard (from 39% to 45%). This increase of people using Digital Tawskboard is probably related to the drop from 24% to 22% in use of Analog Taskboard.

The number of people using tools to support agility is growing up. For us, it is an encouragement to carry on with the good work and keep improving Scrumhalf.

Finally, each respondent answered the main reasons to adopt agile methodologies in your team or organization. The numbers are similar to previous survey. There are no important changes. The bottom 3 answers in the chart were considered more important. We can see most responses centered on better customer focus.

The complete research is available on the VersionOne website. You can access directly through this link.

Till next post!

The post State of Agile Development appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

End of the year is coming. I believe many people may already be reviewing how their year was, if the goal made last year were fulfilled, what goals have achieved. Therefore, today we’ll talk about retrospective.

Over time we have presented in this blog some posts about retrospective. Here are some useful links:

• Agile Retrospective
• Retrospectiva Fim de ano
• Technique to make a retrospective meeting in Scrum

I present below a compiled tips of what to do, and what not to do, to help in the success of the sprint retrospective meeting.

LIKE 

Make all participants quite comfortable to express problems that may be happening. We also know in every group there are the shyer and introverted ones. It is worth to “give a hand” so they can get loose and contribute to retrospective. If these people do not manifest, saying “Joe, what do you thing? Do you agree?” will already put them into discussion.

Do not intimidate when ask a question. For example: Asking “What else?” is more friendly and less intimidating than asking “Is there anything else?”. These small actions contribute to participation.

Bring games, after all everyone likes games! On internet is possible to find different ways of how to carry out a retrospective. Research, try out, experience, surely there is some little game will fit the moment of your project.

To show the positive results and achievements of previous retrospective meetings is always a good way to make the team realize the importance of retrospective and, therefore, enhance motivation.

DISLIKE 

Demotivating sentences as “We are wasting time” does not add value. Change the focus/target if the time is really being wasted. Try to straightly introduce a new subject, loke “Let’s talk about ___________________.”

Lose focus. Although retrospective is going well and relaxed, with everyone participating, we have to stay alert. Keep the focus to maintain all energy and effort direct to what will really bring value.

To blame is bad. There is no gain in that. If happened some problem, or something did not go as expected, not a single person is guilty, but all team is. Instead of looking for the guilty, team should discuss and create solutions to prevent new problems.

I hope these tips help you to make a successfully retrospective. As one of presented tips, do not feel shy and comment if you liked the post. Also, tell us what tips would you add.

See you next post.

References:

• https://www.scrumalliance.org/community/articles/2014/july/dos-and-don-ts-of-agile-retrospectives
• http://intland.com/blog/project-management-en/tips-and-tricks-to-make-the-most-of-your-retrospectives/

The post Tips for Retrospective appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Today I comment and give some tips about what we can do when Scrum Master (SM) is on vacation. Feel free to comment and contribute with news ideas and points of views.

Last year, Ester posted about some cares to take when accumulate roles in Scrum. In this other post she presents us some tips to the SM who is about to go on vacation. In today’s post we will see some tips from development team's point of view.

Scrum Master is a role, not a specific person. When SM goes on vacation it is a good opportunity to improve team's self-organization. If the vacation period is not too big (greater than two Sprints) I believe the SM role could be temporarily played by one or two different people from team.

My team recently passed by such situation. SM’s vacation period was only two Sprints, and during that time only one person took the role.

Other approach would be the development team invites a SM from outside of project. However, we noticed some possible failures at this approach. Let’s see.

Why not to call temporarily a SM from outside of project?

The new SM…

– … does not have project context nor present situation;

– … does not know problems and obstacles;

– … does not know team as well as the team itself.

Therefore, its actions would probably limit to become familiar with project status, be present at meetings, and solve some impediments, but with no project context.

In my opinion, when team is mature it is ideal that one team member takes the SM role in its absence. However stay tuned for role accumulation. Below are some tips.

Tips when accumulate Developer and Scrum Master roles

Here are some tips I believe may contribute:

A) Team and PO should be aware that, during these Sprints, team velocity will probably decrease. Of course, after all one of developers will also play the SM role.

B) During the planning poker, the team must be careful to not overestimate the points of backlog items for fear that Sprint will be "arduous" to have a person working less time in development. The items must continue to be estimated in the same way.

C) Scrum Master may need to solve some impediment, and because of that, it can end up leaving in progress for a long time a task it was developing. To prevent it, is necessary to inform the rest of team that the impediment may take longer than expected and then some other developer should continue the task where it stopped. That scenarios emphasizes the importance of daily meeting, once it is the moment the team know what each one is developing and can plan the strategy for the workday.

Conclusion

In my opinion, if SM went on vacation and your team is small/have experience with Scrum, give the team a chance to fill in this gap!!!

If team is in such conditions, its members will probably not need the SM role all the time. In this case, depending on the context, one person, or perhaps anyone, can meet the demands of SM as they arise.

Let us remember that Scrum is inspection and adaptation. Here is a great opportunity to put this into practice.

Till next post!

The post What to do when Scrum Master is on vacation? appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

Hi,

Today’s post is adapted from the original "Five Things a Product Owner Needs to Know", available on this link.

For many times the importance of the Product Owner (PO) may be overlooked in relation to other actions os Scrum project. If it happens, it is certain that the project will not have the expected success. So, this role is as important as the others and requires a professional able to perform it.

The text of this post is directed to the PO and brings five tips to contribute to the successful performance of its role in Scrum projects. Let’s get right to these tips!

1. Trust is key

The PO has the knowledge of business rules of backlog items. However, since the PO has no development experience, maybe here are backlog items with technical knowledge difficult to understand. The tip here is to have the support of development team to explain the technical details of such stories, so that the PO can prioritize them correctly.

Also, if development team (from here I will only call "team") suggest changes, probably they will bring benefits that can accelerate development, make the code more reliable, and increase product performance. In other words, listen to the feedback of your team, as it can be a valuable complement to the product.

2. PO’s job is to serve the team

The ultimate goal of development is to launch, in time, an excellent product. The PO should try to be available as soon as possible and answer question from team.

If the team is working with Sprint of 2 weeks (10 working days), imagine if there is an impediment to paralyze the work for 1 day, it means that 10% of available work time was thrown away.

3. User insights are essential

It is essential PO understand the people who will use the product. The better understanding of end user, better will be direction of the product, its features and business rules. Nothing is more important than spending time understanding the end user.

Although it seems difficult, the goal is to achieve the best balance between what you know the product needs and what is value to users.

4. The team often fails

Even the team is very productive in a Sprint, it does not necessarily mean that the next will also be a success. The ups and downs of the development process are normal, unpredictable and can occur due to various internal and external factors.

The truth is that success or failure of Sprint is not as important as the team capacity to deliver value. Thus, there is no reason to despair if one or two backlog items are not approved at end of Sprint.

Scrum teams are always trying to improve at every Sprint. The PO should trust the team and know that, eventually, failures may occur because team decided to test new techniques, or defined a very ambitious goal.

5. PO is not project manager

This tip is for PO not try to embrace the world with their arms. This is impossible!

The PO does not need and should not worry about team schedule, how they allocate their work, or how they plan Sprints. PO job is only to set priorities and provide valuable feedback to team.

Only developers fully understand details of their work. If the PO tries to control aspects of development past these levels, then the project may be fated to frustration and unhappiness.

To let the team be self-organizing and rely on their way to work will save time and make life and work easier for everyone.

Did you like the tips? Disagree? Got any more tip to add? You are invited to comment and share your thoughts and ideas with us.

Till next post!

The post What Product Owner needs to know appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.

today I want to discuss some details about the moment we are planning the next Sprint, more precisely at the stage of the Scrum known as Sprint Planning Meeting.

In this post here I've talked about planning for Sprint and tried to answer the question "How many items my team is able to develop?". In it, I talk about the use of the team velocity as a measure to assist with this selection.

In today's post I want to show that this measure is continually changing, and so it is important to be watchful and updating the team's velocity each sprint.

We can notice that by checking the amount of points did it at the end of successive Sprints. That amount is always changing and thus also the speed. The reasons for this change can be many:

• Absence of any team member
• Holidays over the Sprint
• Underestimation / Overestimation of backlog items
• Urgent and unforeseen items entering Sprint
• Others

In the project I work, we use the Planning Poker to estimate the points of backlog items (more info on how to do this here, here and here), but we also take note the amount of time (in hours) each item took to complete. Thus we can take, for example, the items we point with 3 points, check the total hours consumed, then divide by the number of items and we will finally have a relationship of how long, on average, the team leads to finish a 3 points item.

In the following table we can see that there has recently been a change in the amount of hours we took to complete items of 3, 5 and 8 points. The latter two had a subtle change, but the item of 3 points happened to be completed in 75% of the previous time. We should not understand that this reduction in the time necessarily mean that the team has become more efficient, but we must face as a natural change, since the points are based on estimates.

Still analyzing the table, we can talk about points vs hours, which was discussed in this post right here.

Looking at the data in the table we realize that hours do not form a linear function. In other words, it takes 2h to finish the 1 point item, but it does not mean that the 2 point items should takes 4h and so on. It's not quite there, after all we are dealing with uncertainty and our points of estimation are fuzzy (more about fuzzy here).

And you, dear reader, have you been measuring the speed of your team? Doing like this or any other way? Feel invited to share with us some of your experience.

Till the next post!

The post Sprint Planning: Velocity and estimate appeared first on ScrumHalf Blog - Agile and Scrum Software - Brazil.