scrum - 2/5 - Agile Doctor

18 January, 201618 January, 2016

You Have a Friend – Another Reason Scrum Works?

Scrum teams, when properly assembled and maintained, have been shown to increase developer productivity and satisfaction. Scrum teams that work are small, co-located, dedicated, stable and cross-functional. These elements are essential in working in the complex world of software development. Recently, I stumbled across another reason that may explain the gains found on proper scrum teams – friendships.

In his book, The Best Place to Work: The Art and Science of Creating an Extraordinary Workplace, Ron Friedman explains that there is a strong correlation between employee engagement and whether an employee has a best friend at work. It is important to note that employee engagement and employee happiness is directly tied to employee productivity. Additionally, engaged employees also exhibit increased focus, passion, loyalty, spend less time off the job being sick, suffer fewer job-related injuries and have less turnover. In other words, there is an excellent business case to be made for keeping employees engaged through facilitating friendships.

Of course, this begs the question of how companies can facilitate friendships. According to Friedman, there are three basic things that are necessary to foster friendships; physical proximity, familiarity and similarity. It is interesting that these are things that a properly assembled and maintained scrum team will nurture. Physical proximity is analogous to co-location. We find it difficult to bond with people who we are not physically close to. Familiarity can be gained with small teams that are kept together over time. Similarity is found in keeping the people dedicated to the effort over time. In fact, studies have shown that it takes about a year of occasionally working together to transition from acquaintance to friend, so I would recommend that it takes about four to six months of scrum team experience to achieve this friendship level.

There are two additional levels of friendship that have been studied, namely, the transition from friend to close friend and from close friend to best friend. According to Friedman, the cement that bonds friends even closer together is “a foundation of shared risk” and the ability to “reveal our vulnerabilities.”

And how is this related to Scrum? I think there are two things that could allow Scrum to facilitate these deeper bonds of friendship. The first is the retrospective. When this ceremony is done correctly, it challenges people to honestly confront issues that the team is having and the sessions can be intense, but the experience of frankly sharing can certainly increase the bonds between team members. The second thing I think could play an important role is the last aspect of a good scrum team, cross-functionality. While this may seem a stretch, my own experience with teams is that when individuals are encouraged to work in areas outside their primary focus, they increase their feeling of vulnerability. It also forges greater bonds because a person has more opportunities to support their friends and contribute to the team.

Scrum is a difficult challenge at many companies because they continue to have trouble creating scrum teams with characteristics shown to work optimally. These five characteristics are size (small), co-location, dedication, stability and cross-functionality. These are the things that are essential in combating complexity, but it appears they are also necessary to building lasting and close friendships. Perhaps one of the reasons that properly assembled scrum teams are so successful is that when you keep them together, close friendships are established and this has been shown to increase productivity and reduce turnover. I think that this needs to be taken into account when we assess our all too prevalent reliance on temporary workers and temporary project teams. Perhaps temporary teams do not function as well because we have not given people the time (and space) necessary to form friendships.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

14 September, 2015

One Effective Interview Question for a Scrum Master or Agile Coach

I have had the good fortune to be involved with Agile software development for close to a decade now. During that time I went from a somewhat skeptical Director of Software Development to someone who now makes his living helping others create great software by applying the Agile philosophy as an Agile Practice Director. One of the things I have noticed during this time is, as Agile (and especially Scrum) have become more mainstream, the quality of individuals calling themselves scrum masters and agile coaches has become more variable.

The problem is certainly not new or particular to Agile Scrum Masters and Coaches, However, I feel that that, given their centrality to software development teams, the fact that Agile is new to many organizations and in many cases these individuals are expected to aid in transformation, having an ineffective Scrum Master or Coach can lead to disproportionally negative effects. For example, a single inadequate developer can be a real drag to a team, an ineffective Scrum Master can be detrimental to multiple individuals and multiple teams and the same inadequacy at the Coach level can lead to wholesale bedlam for large parts (if not the entire) organization.

The problem is further exacerbated by, as I (and others) have pointed out in the past, by a weak and inadequate system of certification. It is good business to mint as many scrum masters as possible from a two-day training, but it does the outside world no service. This begs the question – in a world where every former project manager with a CSM calls themselves a scrum master and every scrum master with a few teams under their belt calls themselves a coach, how can I really assess those who have talent from those who do not?

Of course, one could use someone’s resume to assess the breadth of work. How many different teams has one worked with? How many years has one been involved with scrum? How many different organizations has one coached at? Unfortunately, individuals looking for work have a tendency to prevaricate at times so how is one to know if that time was really spent doing Agile or did I conveniently reclassify this work because it was not “entirely waterfall”?

A good deal of my current work is trying to make these kinds of judgments. If you too need to assess the ability of a scrum master or coach, let me share the question that I have found to be most effective:

What book have you read recently that has changed the way you think about Agile and the way you go about your job as a scrum master (or coach) and why?

If you are merely a paper candidate who has relied on the minimum set of qualifications (ie you have a good number of certifications) then this question is very difficult to answer. Being a scrum master or coach requires a level of passion that transcends merely implementing a small set of learned behaviors. It requires an active mind that is constantly seeking new ways of thinking,, new experiments to try, new behaviors to model – any and everything that one can do to truly be a servant leader. Passionate people always want to improve. There is no better indication than reading as a means of improving one’s ability.

The question not only shows ones ability to think critically, but it also indicates a higher level of maturity. To read something that changes ones view requires the ability to realize ones knowledge is never perfect or complete. I have to acknowledge that something I hold to be true today may not be true or that I have a true ignorance of certain things.

Agile and scrum are about continuous improvement. We should not expect our scrum masters and coaches to have all the answers any more than we can expect our teams to function perfectly. There is always room for improvement and it is the good scrum master and coach who is not only able to admit this, but also has taken the steps necessary to improve. One of the most accessible ways for this improvement is to read books and to apply this knowledge. So the next time you are asking yourself “Is this scrum master or coach any good?” perhaps you might want to ask them this simple question:

What book have you read recently that has changed the way you think about Agile and the way you go about your job as a scrum master (or coach) and why?

9 September, 20131 February, 2014

Two Time-Management Techniques to Aid Agility

Originally published on ScrumAlliance.org

With Agile as a philosophy and Scrum as a framework, ScrumMasters are sometimes on their own, left out in the cold when it comes to specific tactics. While I heartily recommend such practices as BDD (behavior-driven development), continuous delivery, and so on, there happen to be some simple time-management practices that I have found to be beneficial for almost all of my teams that have chosen to adopt them.

Team time facilitates collaboration

As every Agile practitioner knows, collaboration is essential to succeeding in Agile so that all parties can discuss the work that needs to be done. To increase collaboration, most of us facilitate grooming sessions with our teams to do things like pointing, writing acceptance criteria, and breaking down epics.

But there is one challenge many of us face: how to effectively schedule and ensure participation.

From my experience, one useful way is to establish “team time” every day right after the daily stand-up. Every day for my teams it takes the form of 45 minutes after the stand-up, which allows us appropriate time to sprint plan, sprint review, retrospect, backlog, story groom, and maybe tell a joke or two.

One of the major benefits is that every team member knows when they are going to meet in perpetuity, so they can more easily find productive time unburdened by a great number of ad hoc meetings. It also lends a very nice rhythm to their day! Since this (and my other technique, outlined below) is agreed to by the team and its efficacy discussed in retrospective, it’s a great example of how a team can maximize collaboration. I have had multiple teams use this technique over the past few years, and I honestly can’t recall one that did not feel it was beneficial.

“Office hours” allow team members to focus and find flow

Veteran ScrumMasters know that individual team members should not be scheduled for eight hours a day. In fact, most know that getting five good hours in a day would make for a productive day indeed! Besides, if you are using the team-time technique discussed above, then you’re starting an eight-hour day with only seven. But here’s the big question: How can I make sure I can get in those five productive hours a day?

In order to ensure that individuals get the needed focus needed to achieve a flow state, one that is necessary for good concentration and coding, most of my teams use “office hours.” These are time slots, decided upon by the team, when they are available for productive work only (e.g., tasks assigned during sprint planning). They will usually schedule a two-hour block in the morning and another three-hour afternoon block in Outlook (if you don’t use that, then you can use a real calendar! No, just kidding).

Not only does this eliminate disruptions but it is compatible with pair programming or other team interaction work when needed. As with team time, it is rare for a team to try this simple technique and then choose to go back to, as one team member put it, “scheduling chaos.”

Stronger together than apart

To summarize, using team time as discussed is an excellent way to facilitate engagement while also ensuring that the team’s rhythm is unbroken. As well, office hours provide a great, chaos-free environment for the team to buckle down, since the time blocks are clearly outlined. While each technique, in isolation, is beneficial for many users, I have found that team productivity soars when the two are fused together.

To see what this looks like in action, take a look at my example spreadsheet below. This will give you a starting point for your own implementation of these two techniques (and maybe jog some of your own inspiration!). I hope that this makes the Agile road easier to travel, because believe me, the journey is worth it.

For additional reading, here are two articles I recommend that touch on this subject:

If you have any questions, feel free to reach out with commenting below or with social media. Thanks for reading!

– Larry Apke

3 May, 20131 February, 2014

Philosophy Versus Practice

When trying to get waterfall teams and organizations to move to a more Agile development methodology there are two training strategies – philosophy and practice.

The philosophical approach relies on teaching the history of software development and the philosophy behind Agile – the manifesto and principles. This approach assumes that as long as one is equipped with the proper overriding principles then one will be able to make the correct decisions as challenges occur.

The practice strategy relies heavily on training the ceremonies, especially scrum ceremonies like standups, retrospectives, reviews, etc. This approach assumes that if you do the rights things that overtime the reasons for the practices will become apparent.

Continue reading “Philosophy Versus Practice”

8 February, 20131 February, 2014

Looking for Agile Success – All You Need is Love

Like any professional should I spend a great deal of my time attending user’s groups, reading professional articles, speaking with leaders in my field, etc in an attempt to find ways to do my job better. This morning I stumbled upon a couple of interesting articles, The Unintended Consequences Of A Leader’s Lack Of Trust (whose link has gone inactive) and Employees leave managers, not companies. While not exactly writing about the love, these got me to thinking about love and its place fostering Agility.

It is the nature of my job to bond tightly with the teams that I work with and also to have to leave these teams frequently, as they achieve a high level of self organization, to pursue opportunities to help other teams. I am currently faced with one of these moments and the feeling, as always, is bittersweet. I am excited about my new opportunity but will genuinely miss the teams I have worked with over the past few months.

Continue reading “Looking for Agile Success – All You Need is Love”

Tag: scrum