scrum master - Agile Doctor

11 January, 201612 January, 2016

Project Manager/Scrum Master: A Cry for Agile Help

Over my time as an Agile Coach I cannot even begin to count the number of times I have been approached by recruiters for a position as a Project Manager/Scrum Master. My coaching colleagues and myself often joke about this particular job title saying, “we like the title Project Manager/Scrum Master because it helps us know which jobs and companies to avoid.” Why would we avoid such positions? For better or worse, by using the title Project Manager/Scrum Master we are able to quickly infer a great deal about the company and their experience with Agile – most of it not positive.

The first thing we notice about a company using this title is that they usually have little or no understanding of Agile and Scrum. The duties of a Project Manager and Scrum Master are quite different. Not only do the two roles perform different functions, but they represent a fundamental different in the way they view the world. Project managers in Waterfall try to control projects. Scrum Masters work with Agile Scrum teams to facilitate. In Waterfall, Project Managers have responsibility. Scrum Masters, on the other hand, do not have direct responsibility as the responsibility for success shifts to the development team and Product Owner. Since the Product Owner decides the sequence of the work, a Product Owner is the closest thing to a Project Manager in Scrum. A simple Google search of “project manager versus scrum master” can provide more information on this for those who are curious.

This particular problem manifests when a company desires the potential benefits of Scrum without really understanding Scrum. Without a good understanding, people attempt to map their existing roles with those of Scrum. Let me make one thing perfectly clear. The role of Scrum Master is unique to Scrum and any attempt to map it to existing roles will only result in confusion, frustration and less than optimal outcomes. As coaches, if given the choice of coaching a complete novice as scrum master or “retrofitting” a project manager as a scrum master, we chose the former. It is not that project managers cannot become good scrum masters because many have, but in order to properly train one as a scrum master there is a great deal of work in “unlearning” much of what has been previously trained. With novices the time spent “unlearning” is non-existent.

This is why I believe that companies recruiting for Project Managers/Scrum Masters are actually making a very public plea for help. If a company truly wants the benefits of Agile, it is essential that they actually take the time to truly understand that becoming Agile through the use of the Scrum framework is a serious commitment. People must gain a better understanding of software development and how knowledge workers differ, change their fundamental thinking around projects and products, pursue organizational change and realign people around properly configured scrum teams, work with recruiters who understand the difference between project managers and scrum masters and work as partners to recommend better solutions to underlying organizational needs.

For those seeking Project Managers/Scrum Masters, I hear your cries for help. As an Agile Practice Director I would love to help you to better understand your real Agile needs, to help you reorganize your work and people to take advantage of Scrum (other Agile frameworks, methodologies and development techniques), to optimize your organization so that you can deliver high quality software in a shorter time. I am available anytime to provide the help you need. If not me, please reach out to another Agile professional so we can rid the world of Project Manager/Scrum Master for good.

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?

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”

15 January, 20131 February, 2014

Thoughts on Agile Coaching

When I tell people I am an Agile Coach, unless they are in IT, I tend to get a lot of strange looks. Most of the time they will say something like, “I get the coaching part, but what the heck is Agile?” It is at this part of the conversation that they experience immediate regret as I launch into an endless barrage of commentary on Agile development.

Lately, however, I have begun to re-examine my own assumptions about what it the Coaching aspect of an Agile Coach is, especially now that there are so many professional coaches looking for work after the end of the regular NFL season.

Continue reading “Thoughts on Agile Coaching”

26 December, 20121 February, 2014

Larry’s Top Ten Agile and Scrum Myths

I gave the Larry’s Top Ten Agile and Scrum Myths talk to the Java Users’ Group in Phoenix recently and people have asked me what the top 10 myths are. I have posted a copy of the powerpoint, but for quick reference, I have listed below.

Myth #1 – Agile is a Framework/Methodology
Myth#2 – Agile Means No Documentation
Myth#3 – Agile is Less Disciplined / Easy
Myth#4 – You Can Achieve Agility Without Organizational Change
Myth#5 – Agile is Scrum
Myth#6 – Scrum Will Lead to “Hyperperforming” Teams
Myth #7 – You Must Get 100% of all Stories Complete or You’ve Failed
Myth #8 – Scrum Master = Project Manager
Myth #9 – We Can Do Scrum Without a Product Owner or Many P.O.s
Myth #10 – With Scrum We Can Make Changes Whenever We Feel Like It

Now feel free to rip into these as you wish!

– Larry Apke

20 December, 20121 February, 2014

Drive: The Surprising Truth About What Motivates Us and Why Agile Works

In Daniel Pink’s bestseller Drive: The Surprising Truth About What Motivates Us, the author persuasively argues that what motivates people in the knowledge economy (of which software development is squarely seated) “is the deeply human need to direct our own lives, to learn and create new things, and to do better by ourselves and our world. ”

People are no longer motivated by the carrot and stick approach of past Tayloristic, manufacturing, assembly line business. What motivates new workers, and what has been supported by a wide range of scientific studies, can be summarized by the acronym AMP which stands for Autonomy, Mastery and Purpose.

As an Agilist, I am always curious why in one company an Agile implementation succeeds and in another it does not. While there are many reasons for Agile implementations to fail, one thing that many have in common is that they fail to take into account the three factors Pink describes in his book.

Continue reading “Drive: The Surprising Truth About What Motivates Us and Why Agile Works”