Scrum - Agile Doctor

15 August, 2016

Understanding The Agile Manifesto: A Brief & Bold Guide to Agile – Podcast Now Available

Understanding The Agile Manifesto: A Brief & Bold Guide to Agile by [Apke, Larry] Those of you who may follow this blog may have noticed it has been some time since the last post. It was an eventful summer and it was good to spend some time to catch my breath. Now that the kids are heading back to school, it is time for me to renew my posting. In addition to posting the podcasts, please check back for new Agile posts.

I am pleased to announce that my first book, Understanding the Agile Manifesto: A Brief & Bold Guide to Agile is now available as a podcast. Over the next few days / weeks I will be releasing the book, chapter by chapter, on this website and through the iTunes store under my “Agile Doctor” podcast. Since the book was a series of blogs, the podcasts will also be made available under the original posts.

This project is very dear to my heart as the podcasts were recorded by my son, Vadim Kim, who assisted me over the summer as my intern. I think he did a fantastic job of recording my “little” Agile book and I am sure you will enjoy.

The most recent version of the book includes an Introduction which was never part of any individual post. I have included the podcast of the Introduction below.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

10 March, 201624 August, 2016

Maybe It’s Time to Stop Using the Word “Sprint”

Any agilest worth their salt will tell you that culture matters, especially when you are trying to transition to an Agile methodology. Since culture is merely a reflection of an organization’s values and values come from ideas and words are how ideas are expressed, the words we use can often be critical. There is one word used Agile and Scrum that has bothered me for some time, “sprint”, and I propose eliminating the word from Scrum. In fact, I hope Ken Schwaber and Jeff Sutherland agree to incorporate this change in the next version of The Scrum Guide.

The Scrum Guide states, “the heart of Scrum is a Sprint”. This is one reason why I haven’t written this blog sooner. I believe in Scrum as an excellent way for teams to embody the Agile philosophy so I am hesitant to criticize. Who am I to criticize and will my criticism be misinterpreted? It took a long time for me to have the confidence to propose something that others may view as heretical (I know how strident some can be about Agile and Scrum), but I truly believe it is the right thing to do.

I acknowledge that I might not be the first to propose such a change. In fact, I had one gig where the company decided to refer to “sprints” as “iterations”. They insisted I do the same and I found it difficult to make the change. I thought this was just another example of “scrum but” (which in this case may have been true), but even though I do so begrudgingly, I now believe this company was on to something worthwhile. I also acknowledge that my opinion might not carry the requisite weight, but I feel it is necessary to add whatever weight it might hold to this effort.

And why would I propose something as radical as changing the very word referred to as the heartbeat of scrum? Simply this. The word itself carries a connotation that I find at odds with the values and principles of the Agile Manifesto. Therefore, I need to make this proposal in order to preserve my integrity. As a coach I often say, “The philosophy behind Agile provides a basis for making decisions when there is doubt on which option to pursue. The Scrum framework contains ceremonies that make the philosophy come alive in our daily practice. If you cannot trace something you are doing to the original philosophy then you probably should not be doing it.” It is for this reason that I no longer can use the word “sprint” and instead choose to use the word “iteration.” Of course, until the Scrum Guide is changed to reflect the more accurate term, I often say “iteration or sprint”.

There is an Agile principle which states, “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”. It has become obvious to me, the word “sprint”, which, although it may have a specific meaning in scrum, generally is understood to mean “an act or short spell of running at full speed.” I jog to stay in shape. As I have stated previously it is obvious that sprinting is something that cannot be sustained over a long period of time. Therefore, I prefer the word “iterating” and hope that someday the Scrum Guide, as the official word of what constitutes Scrum, will agree with me and change the word.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

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

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

4 January, 20167 January, 2016

The Most Important (and Least Understood) Software Development Fact

Facts and Fallacies of Software Development Book

I love the holidays – the family, friends, food, drink, and, of course, the gift cards. I love to read and time off plus Amazon Gift Cards means the opportunity to indulge my passion. As the New Year begins, I find myself knee deep in two wonderful books about software development and the workplace. One of these, Facts and Fallacies of Software Engineering by Robert L. Glass, I found fascinating even though it was published over ten years ago. While some of the material is dated, I found that most of the facts and fallacies are as valid today as they would have been decades ago. This alone is disconcerting. You would have expected that, by now, most of these facts and fallacies would be well understood and to some extent corrected. If anything, my experience is that there is less understanding of the true nature of software development now than ever. It should be required reading for anyone in the business of managing software development because it would certainly save many a great deal of frustration by learning vicariously from one of luminaries of software development.

It was just about midway into the 55 facts (Fact 21 in fact), that I stumbled onto what could easily be construed as the most important (and least understood) software development fact in Glass’ book. The fact is titled “Complexity” and states:

For every 25 percent increase in problem complexity, there is a 100 percent increase in complexity of the software solution. That’s not a condition to try to change (even though reducing complexity is always a desirable thing t0 do); that’s just the way it is.

Glass, Robert L.; Facts and Fallacies of Software Engineering

Glass goes on to state, “If you remember nothing else from reading this book, remember this.” He closes his statement of fact with “And remember, also, that there are no silver bullets for overcoming this problem. Software solutions are complex because that’s the nature of this particular beast.“

What struck me most about this particular fact and Glass’ treatment of it is how closely it aligns with my experience and things I have written and spoken about in the past. Software development is knowledge work and is generally complex, but a majority of people in software development are unaware of this fact and continue to treat software development as if it were physical (mechanistic) work and either simplistic or merely complicated.

It is by understanding this fact that software development will improve. Why? The things that we employ to combat the Complex are much different than the things that work against the Complicated. The Agile movement was a response against using complicated tactics in the complex world. The Agile philosophy engendered a whole host of frameworks, methodologies and development techniques all of which address the need to address complexity. Why do large teams not work so well in software development? Why does scrum talk about small teams? Because small teams are better at attacking complexity. Large teams are adequate for attacking the complicated. The same holds true about co-location, dedication, stability, and cross-functionality. These are all things that work well for complexity.

If we want to create better software we would be well to head Glass’ fact. We need to stop treating software development like we are building a house or assembling a car. Software is much too complex to be built using the tired old mechanistic means. Remember that as complexity of the problem increases, the complexity of the solution increases at a much higher rate, along with the risks attendant on increased complexity. If you want to mitigate your risk, it is essential that you learn how to properly deal with complexity. You might want to learn how to become Agile.

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

23 November, 201517 December, 2015

Five Impactful Interview Questions for Prospective Scrum Masters

A friend of mine who happens to read my blogs contacted me the other day with a question – could you write a blog about “the five most important questions to ask a scrum master in an interview?” It seems that his company had interviewed a bunch of scrum masters and was not able to find a fit. In his words, “a lot of people think they want to be scrum masters but have only taken the one week training and don’t really get how to truly be successful in an enterprise workforce.” Having run into the same issue many times, I hope that I can provide some direction to help my friend and others faced with the same situation.

In the past, I have written about the problem of scrum certifications, specifically the Certified Scrum Master (CSM) certification. The issue is that people hiring scrum masters have mistakenly believed that a certification means more than it really does. Prior to interviewing a scrum master candidate it is essential to know that the CSM can be obtained by anyone who can sit still for two days and take an easy test. I am not sure how many people have failed the certification test but in over seven years of being intimately involved with Agile and Scrum I have never heard of a single one. If people cannot fail a test how good can the test be. Given this fact I am not even certain that a CSM should be part of the job description. A few months of “boots on the ground” scrum is better than the two-day training.

I have also written in the past about my favorite question to ask prospective scrum masters, namely,

“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?”.

This question would certainly be on the list of five because it shows the desire of the candidates to better themselves outside of the normal workday. Agile and scrum are brief in words but very complex in practice. It is difficult to be a true “master” without looking past the Manifesto and two day training to what the experts are writing about. Bonus points to someone who replies with a book not written specifically about Agile or Scrum and having the ability to apply something from another discipline to their practice.

A big challenge in being a scrum master is understanding what makes for a good team. In my practice I have boiled it down to five aspects of a successful team. A good question would be to ask them

“what would you consider to be the five traits of a good Agile scrum team and why are these traits important?”

An experienced scrum master knows more than just theory. While a certification course can show us the happy path of scrum, the real world application is a lot messier. Like I don’t recall anyone ever failing the certification test, I don’t recall any seasoned scrum master not having to make adjustments or compromises when applying scrum. Of course these things are not optimal, but sometimes trade offs must be made in the short run in order to make things successful in the long run. The next question I would ask,

“Give me an example of when you have had to compromise or make a trade off in a Agile scrum implementation and why?”

A scrum master’s primary responsibility, in addition to the facilitation of scrum ceremonies, is to assist the team in removing impediments. A scrum master with experience should have multiple examples of how they were able to play the role of servant leader and remove impediments so my next question would be

“in your past please provide an example of a time when you successfully removed an impediment (or impediments) and what was the result?”

Most inexperienced scrum masters are able to speak to the scrum framework and the scrum ceremonies, but have not yet gained enough of an understanding of why Agile and scrum works. My last question (assuming I only have five) would be

“please explain why, when properly implemented, Agile and scrum are successful ways to create high quality software?”

I believe the questions above should aid anyone in assessing the true ability of a scrum master. I am also certain that there are many folks out there who might have similar or better questions that have been successful in the past. Please feel free to comment. In the spirit of open collaboration and helping others, like my friend, hire appropriately, what questions do you ask that have been effective

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS