Posted on

Agile Principles: How to Maintain a Sustainable Pace

larry apke, agile, scrum, indiegogo, agile development, agile doctor

larry apke, agile, scrum, indiegogo, agile development, agile doctor

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

When I think on this principle I cannot help but think about the potential “dark side” of agile and how it can be misunderstood and implemented incorrectly. It also reminds me of an interesting story I was told by one of my coaching colleagues recently.

Once upon a time a company hired a very talented vice president of software development. Unfortunately, when this brave soul entered employment the amount of technical debt in the code was enormous. This was a situation that needed to be fixed because this pasta code was very expensive to maintain and made it difficult to deliver software quickly and with quality.

The company’s leadership heard about agile and decided that this was the answer to all their problems so they set about sprinting. Since the concepts are so easy they felt they could forge ahead without expert agile scrum help. In their quest for agility they found that they could indeed write code faster, but without proper guidance they forgot about the concept of sustainability and did nothing more than create technical debt faster. Unfortunately for our VP, the pleas to adopt sustainable agility went unheeded and six months was all the VP could take before moving on.

The bottom line is that many companies misuse agile because they think by being agile they can cheat the iron triangle of development. What too few people realize is that you don’t choose two of three sides because it is actually an iron square where you choose three of four sides (scope, resources, schedule and quality or, as Jeff Atwood refers to it, an Iron Stool). You misuse agile when you choose everything but quality because the code becomes unmaintainable over time and agility becomes mired in the big ball of mud you have created.  I refer you to my article about refactoring in the Agile Record for the problems with unnecessarily complex and technical debt laden code.

The misguided desire to emphasize speed over quality leads to the accumulation of technical debt and is a symptom of project (and not product) centric thinking. Like I refer to in an earlier blog post, there are reasons why no one washes a rental car.  Overtime you will no longer get speed or quality and your ability to sustain agile over long periods of time is compromised.

I try to run at least a few miles everyday, but I do not sprint the entire run. If I did, I would barely make it more than about a quarter of a mile. This is why I have begun to prefer the term iteration over sprint. Sprinting goes against this principle because sprinting is, almost by definition, unsustainable. It certainly is not “constant pace  indefinitely”.

I argue that in order to maintain constant pace indefinitely there are two things an team must do and an organization must support, acceptance test driven development (ATDD) and continuous integration / delivery (CI/CD). I believe currently that BDD is the best means of accessing ATDD (and TDD) so I have taught that to my clients with spectacular success.

Without ATDD and CI/CD all teams are doing is what I call feature chasing. The question is not one of sustainability but how many and how quickly can I deliver new features. While this might be important for startups, most are not involved in such high competition that chasing features at the expense of quality and long term sustainability is ludicrous. Even those who must feature chase to remain competitive must recognize that they are creating technical debt that must be paid, and paid quickly, before servicing the “interest” on the debt is all that can be afforded.

Interestingly enough, though many people believe that employing ATDD, TDD and CI/CD slows the progress of software delivery, my experience is that, with very little training and a healthy dose of discipline, the gains far outweigh the investment. This is obvious if we look at the product and not just the project, but my experience shows that even within the misguided and arbitrary project the payoff is realized.

I have a number of teams that I have coached that delivered high quality software into production in short project time frames precisely because, and not in spite of, BDD. As Bob Martin states, “The only way to go fast is to go well,” and no one is more recognized as an expert on quality code than him.

My last point is related to the above in that one of the greatest dangers of feature chasing is not just that we tend to accumulate technical debt faster, but it (and the sprinting as fast as we can mentality) generally pressures us to not take advantage of training opportunities like learning TDD, BDD and the like. With technology changing so quickly it is critical that our people make certain to invest their time not just chasing features but building the skills necessary for sustainable development so they can maintain a constant pace indefinitely.

– Larry Apke

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Android | RSS

Posted on

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

sprinting

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.

rugby scrumThe 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.

sprintingAnd 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

Posted on

What to Expect from a New Agile Team

Whenever I work with a new Agile team I have some stock “speeches” that I tend to give. One of my favorites “speeches” covers my expectations are for a newly formed Agile team, namely increased transparency and predictability.  Notice that I did not say increased velocity. That may or may not come with time, but the first two hurdles are getting to a point where one can understand what is going on at any time – transparency – and what can be expected to be delivered over time – predictability.

One of the biggest hurdles to getting any software development completed is endless interruptions. Transparency provides a safe haven where anyone associated with a project can see where the team is at anytime so that constant status and interruptions can be calmed.

Continue reading “What to Expect from a New Agile Team”

Posted on

Why I Don’t Like Whiteboards, the Last Sacred Cow and Why I Will Burn in Scrum Hell

I doubt there are many people in this world who have the passion or spend more time researching about Agile than I do. Over the years I have seen many sacred Agile/Scrum cows questioned. Usually when one has the guts to do so there are scores of Agilistas ready to denounce anything that goes against their indoctrinated Agile/Scrum education. It seems that many fail to understand that in order to prove the value of something, it must always be questioned. Hell, the whole damn thing started because a few folks decided they would question orthodoxy and find better ways to do things.

And now I think I have found the very last sacred cow remaining. Over the past few weeks, whenever I have some spare moments, I have googled, binged and read blog after blog. My search – is there anyone else out there who really doesn’t care for Agile/Scrum whiteboards. I can say from experience that it appears unanimous. Every person talking about Agile or doing Agile absolutely, positively, without question loves Agile whiteboards to track iterations. All that is except me. Yet I cannot hold my tongue any longer. I know I will go to Scrum hell, but I have always had a strong distaste for Agile boards.

Continue reading “Why I Don’t Like Whiteboards, the Last Sacred Cow and Why I Will Burn in Scrum Hell”

Posted on

Using Individual Burndowns

I have my very own Scrum team right at home. There are seven of us in the family. I love each and every one of my family members equally, but that does not mean that each one of my family members is the same nor would I treat each one exactly the same. Of my three boys, each has their own wants, needs and desires that I need to help fulfill on a regular basis. One needs extra help for their homework, one needs extra time to help them with their driving lessons and my youngest just needs me to spend as much time as possible with him even if we don’t do much of anything (though we always seem to have something). In other words, in order to have a highly functioning family (team) I have to treat each family member (team member) a little differently. I don’t hand the car keys over to my five year old nor do I hold hands when I walk down the street with my twenty year old.

I have two second families right now, the two scrum teams that I have the pleasure of being acting scrum master for. Like my own family at home, both of these teams is comprised of individuals with different levels of Agile maturity. One team is close to highly functioning while the other is just now taking the first tentative steps into Agile. One team can handle nearly all their sprint planning while the other needs a great deal of time. One has tasks assigned to the team (and chooses tasks based on availability during the sprint) while the other goes through the effort of making sure that tasks are chosen during planning to ensure that they don’t over-commit.

Continue reading “Using Individual Burndowns”