Posts Tagged with agile

Names Are Important

Posted on

This article on the resulting change in a development shop after they adopted Agile popped up on Reddit today and the comments there got me to thinking again about the ramifications of changing the meaning of a term or phrase while still using the term or phrase to describe it.

Last week, we had an internal conversation regarding this Ron Jeffries’ post where he talks about the essence of Agile Software Development as he and others defined in the Agile Manifesto. Leaving aside the idea that the Agile Manifesto is a set of values and not dictates, one of my colleagues made a good point regarding how it was too late to discuss what Agile meant because the term Agile had been bastardized in so many ways as to be irrelevant, poetically paraphrased. A comment on the Reddit thread above made the same point, that in our industry, once you put a name on something, you have essentially relegated it to the dustbin of history because once something has a name, people can latch onto the name while changing the underlying structure of what the name stands for. Many people say that the beauty in agile is its flexibility but when something is so flexible as to have completely different meanings depending on how it is implemented, naming it loses all meaning.

The term agile should be be viewed as a descriptor of a philosophy of programming and not as a concrete implementation of how you develop software. Even Agile Software Development is philosophical in nature and aside from the main tenet of delivering usable, valuable software regularly, it is a term that should be used to light but not build your path. If your team writes a detailed specification at the beginning of a project and then iterates over that specification regularly delivering working, usable software, you are using agile philosophy even if very few agile coaches would teach that way. Having a philosophy guides your decisions but does not dictate your decisions. The failure to not clearly state this is one of the larger failings of the agile community.

Of course, by plastering a name onto something, you practically guarantee that someone will try to make money off of it, especially if it becomes a part of the software culture. However, it would be hard to make money being an agile coach if your coaching totally consisted of Yoda-like platitudes. “Deliver working software sprint 1 you will.” So the term agile became a description of directives and that’s when it started to significantly lose meaning. Saying you do agile software development now means you’re doing something that superficially looks like Scrum or Lean or XP but is so drastically different under the covers that the term “agile software development” has no meaning.

The best agile coaches understand this. They look at a process in a development cycle and try to decide if it fits into the philosophy of agile as opposed to the particular pragmatic implementation of agile that the team is working under. If it does, the process can be kept. If it does not, the process needs to be revamped or eliminated in favor of one that helps the team deliver software. Anything else violates the philosophy of agile software development.

Trust And Process

Posted on

Jay Fields explains how his team uses an extremely low ceremony requirements tracking plan. Their requirement tracking is basically three stacks of cards and the stakeholder is perfectly happy with it. Of course, the team can do this because of the trust the stakeholder has in the team and the trust the team has in each other to follow up and have conversations about the minimum requirements collected. This trust is something that advocates of a “Take what ever parts of agile you want” approach often ignore or fail to understand.

Several of my colleagues and/or readers feel that I must be terribly inexperienced or flat goofy when I advocate for a team new to agile to follow Scrum exactly to the letter. They often talk about teams that they have been on that have just done pieces of agile and they have succeeded. Of course, I’ve never said that ALL teams should ALWAYS follow Scrum exactly. I advocate for those new to agile, especially coming from a high process or high dysfunction environment, follow the process completely because they will not have the experience to understand what does and does not work for them and they will rarely have a coach to help out in that far more difficult endeavor than many people remember.

787Would you trust a Cessna pilot to get into the cockpit of a Dreamliner 787 and taker her on up? Of course not. The thing is, writing software well is only marginally less difficult than flying a jumbo jet. There are hundreds of little things that go into doing the job right and teams that are new to agile have no idea what is important and what is just part of the ceremony.

One thing Jay doesn’t mention but that I have written about before and that I feel is critical to successful software production is that trust doesn’t appear on a team that has been together for a long time. Trust comes directly from commitment and discipline. If the team has a track record of disciplined feature releases with requirements met, trust starts to form between the stakeholder and the team. With trust comes the ability (but not the necessity!) to choose pieces of the process that work best for the team and drop out pieces that have become mere ceremony. Doing this in reverse order is almost always counterproductive on anything less than an elite team.

People are often derisive when I mention “scrumbut” as a problem but the reality of the situation is that teams that can successfully modify the agile process to fit their needs are the exception, not the rule. Consultants often forget this because they come into situations where they are the coach and the leader and because they are being paid the big bucks, they have essentially bought the trust from the stakeholder. But in the normal day-to-day world of writing software, teams that adopt agile need the discipline that comes from a strict process to build that trust before they begin to modify their system.

Breaking Up The Team

Posted on

What would happen if midway through the the NFL season last year, the Pittsburgh Steelers, standing at 6 and 2 and leading the AFC North, had decided that their football season was over and disbanded the team? Or what if they decided to move Big Ben to the training squad because he was a prime performer and the training squad wasn’t really performing very well? What, you say? This would never happen?

No of course this would never happen for a variety of reasons not the least of which is that a team doesn’t just disband. A team doesn’t take their best performers and move them onto another project because that project is sucking wind. A team may lose a player here and there due to injury or trade or retirement but there is a sense of continuity to a team that exists above and beyond the sum of the team’s parts. A team has common, long-term goals like “winning tonight’s game”, “winning the division” and “keeping our superstars with the team”. Successful teams of all types typically have a common culture and no divas. Or at least the divas are under something resembling control. Even on NBA teams, where there are often divas of extraordinary divahood, winning rarely comes consistently unless the rest of the team buys into both the system and the superstar. Conversely, on bad teams, you may have one of the greatest players ever (see: Kevin Garnett pre-Boston Celtics) and still lose all the time.

This is true of all kinds of teams. Without some semblance of stability, culture, direction and goal, teams fail. In fact, they often implode. And yet, we in the software industry continue to call groups of people “teams” when they are at best, loosely grouped collections of individuals with similar skillsets working temporarily on a common project and at worst, highly dysfunctional trapeze artists who would like nothing better than to cut down the safety net and install 2 ounces of extra weight in the left side of their fellow coders balance bar. Project teams are not teams.

This is one of the gorillas in the room of current software methodology. We talk about software teams as if they want nothing more than to succeed when in fact, oftentimes, they could care less and may even have motives to foster failure. Of course, you could argue that we come up with methodologies to standardize these poor teams. But then someone might call you a cynic.

Granted, there are teams like this in the sports world but they don’t typically stay teams very long. They are broken up, sent away and rebuilt with the goal of having a real team. But in software, dysfunctional teams may stay together for office political reasons and completely successful teams may be disbanded in an effort to spread the success around, ignoring the fact that the team may have been successful because they were a team. We continue to treat software teams as if they are completely different from any other type of team we have ever encountered in reality.

As long as we keep trying to treat the symptoms of the disease instead of the actual disease, we’ll continue to have an industry that languishes. Stability is the critical component of the long term success of a software development team. Doing anything that undermines that stability contributes to the continued failures in software development that we keep trying to cure with a new methodology. A solid, stable, professional team can write software using any methodology. It’s only because we refuse that stability that we have to have silver bullet methodologies to try to cure so many of the symptoms of the disease.

Is Agile The New Waterfall

Posted on

I ran across this presentation claiming that agile is the new waterfall, that by following some method of agile dogmatically, you are merely substituting one dogma for another and you have failed to gain any learning or understanding. While this may very well be true in certain cases, it reminds me of the opening line to Anna Karenina: All happy families are alike. Every unhappy family is unhappy in its own way. Many people say that you should take the pieces of agile that work for you, use them and discard the rest. If you’re dealing with a team that is already functional, this works. Teams that are already highly functional can take any process piecemeal and work it out because they are already functional. Teams that are dysfunctional are dysfunctional in hundreds of different ways and allowing these teams to choose what parts of any methodology they implement leads them to reinforce their dysfunctions instead of fixing them.

For teams that are highly dysfunctional, picking and choosing pieces of any methodology will undoubtedly result in failure, not because they chose pieces of waterfall or pieces of Six Sigma or pieces of agile. It will fail because they are already dysfunctional and the best way a methodology can help dysfunctional teams is by applying the entire methodology, sorting out later what pieces do and do not work once understanding has been achieved. We, as proponents of whatever methodology we prefer, do these teams a disservice when we allow them believe that doing pieces that “fit” will lead them to greater function.

Dogmas aren’t created to immediately impart understanding. That only comes wisdom and experience. Music students play all scales over and over, dogmatically. They do that because eventually, that dogmatic approach will lead to higher understanding about their craft. If a music student looks at scales and says “I’m only going to play the C Scale”, they will never gain the ability to understand how knowing all scales makes them a better player. The student must play all scales to gain the most benefit and understanding. In fact, music students should play their weakest scales more in order to improve more. In the same way, I believe applying any methodology in whole to dysfunctional teams has the potential to do the same thing, more quickly than doing it piecemeal.

Methodologies aren’t designed for functional teams. They don’t NEED them. Methodologies are designed for dysfunctional teams, ones that need help not because of their methodology but because of underlying issues with the team or the environment. Taking the pieces “that work for you” from any process results in only focusing on your strengths and avoiding your weaknesses. Do that will never lead to success will never lead to a stronger team, only a more unbalanced team.

Continuous Deployment

Posted on

When Continuous Integration just isn’t hardcore enough. What an amazing and fascinating place that must be to work, an environment where discipline to their process enables them to deploy code to production up to 50 times a day.

The scripts that monitor statistics and perform analysis on the result of the partial rollout are ingenious. But all of this is made possible by human discipline to a process that make the impossible easy. I’d guess it’s probably a joy to work in that kind of environment, one where each team member has responsibility to all other team members to make sure the environment stays clean.

Team Rooms Aren’t That Agile

Posted on

One of the tenets that agile proponents often tout as the best of the best is the team room. A team room is a centralized location where the entire team works. Typically, there are tons of whiteboards around, a big space and the concept of personal space is thrown out the window if there happens to be one nearby. The supposed benefits come from the high bandwidth communication that a situation like this fosters. No more does a team member have to wait to have his question answered via email or IM. He can just tap anyone on the shoulder (or just stand up and announce his problem) and presto, problem solved by whoever knows the answer.

There are about 40 things wrong with this scenario that seem to be typically glossed over by the proponents of team rooms. The first, but certainly not the worst, is that it seems to be a myth that this is an agile tenet. It’s not found in Scrum. It’s not on the XP Rules page. I don’t see it in the Agile Manifesto. Pretty sure it’s not in Lean anywhere. This site says powerful communication is one of the seven core principles of agile management and makes a huge generalization that “The single most effective means to communicate powerfully, is to put all the team in a room together where they can do their work, every day for the majority of the work time” but provides no links or studies to back up this rather extreme assertion. Overall, having the team in a team room is at best, according to the links to the variants of agile above, a minor bonus, not even important enough to write into the rules.

The second way that a team room is just wrong is the effect that noise and interruption have on task completion, specifically cognitive tasks like programming. Google “Effects of noise on task completion” or “Effects of interruptions on task completion” and take your pick of psychological and sociological studies of this on human performance. They are so prevalent that you can even find free ones which is saying something in the field of psychological research. Even when you find one that supports crazy ideas like “radical colocation” which I wrote about here, you find that the study involved quiet places where programmers could go to actually do, you know, REAL work. There just isn’t any evidence out there that team rooms actually improve the code. There is anecdotal evidence that they improve the process that leads to the code but there is a MOUNTAIN of evidence that when the code has to be written, noise and interruptions lead to longer task completion, greater numbers of errors/bugs and higher frustration/annoyance by the subjects.

The third and final reason why team rooms suck is the fact that 50% of the time teams spend in the room involve non-work related issues ranging from discussions of the hot chick in HR with the short skirt, discussions about guns/football/basketball/your mother and who to blame for the awful stench after the team went to Abuelo’s for lunch. Put 5 people in a room together and you don’t get 8 hours of work out of them. You get about 4 if you’re lucky because the other four are spent doing non-work related things. It’s just human nature. It’s also the nature of the beast because when it is easy to interrupt someone, it is difficult to not be interrupted.

All of this is brought on by this post (I’m sorry to keep picking on Ken but he and I seem to have VASTLY different ideas of how agile works. He’s far more experienced than I am so I’m probably wrong on every count but until I get some hard evidence of it, I’m going to keep spouting off). In it, he examines the noise effect on teams and what that means for task completion. His numbers are

    Normal Project

  • 90 hours spent in lag time (based on an unlinked study)
  • 10 hours spent on real work
    Project with a team room

  • 15 hours spent on real work (the real work takes 50% more time in a noisy environment)
  • 20 hours of lag time
  • 65 hours talking about porn (ok I made that up but where else are the 65 hours going to go?)

One thing this analysis leaves aside is the fact that it took you 50% more time to do work that now contains a probable factor of 5 more bugs. Which means someone has to find the bugs and fix the bugs. You took more time to write crappier code which surely can’t be looked favorably upon by agile proponents. On top of that, there is some evidence that you spend more time modifying existing code than you do on new code by a factor of 10. Even if you believe that you wrote the same quality of code in the 15 hours interrupted that you did in the 10 uninterrupted, you’re going to spend 50 more hours modifying it and debugging it. Like everything in life, you can’t just look at the pro side of things.

I don’t doubt that team rooms can work. The problem is, they fail far more often than they succeed for the same reason teams doing scrum fail far more than they succeed. If you don’t implement a team room or scrum perfectly, they fail to deliver on the goods. If they aren’t implemented with a chance for quiet concentration separate from the team, if they don’t involve meta-XP rules like code standards, pair programming, or continuous integration, they just aren’t going to do what you think they do. Just throwing a bunch of people in the same room together doesn’t do what you think it does. Like putting lipstick on a pig, it’s a not a prettier picture and you only stand to annoy the pig.

Further reading (as if you made it this far):
Holding A Program In One’s Head
Attention and Sex
Human Task Switches Considered Harmful

Is Agile Gestalt?

Posted on

Ken argues that Agile (big A or little, your choice) is Gestalt. From this conclusion, he says that it’s a mistake to dogmatically follow a given process or proscribe particular tools when we’re trying to implement Agile and that instead, we should “. . .help remove organizational and sociological blocks that prevent teams from employing them.” While I think he may be right that Agile done correctly is Gestalt, I don’t think that his conclusion naturally follows.

For those of us who haven’t been in cognitive psych too recently, the Gestalt basically boils down to “the whole is greater than the sum of its parts” and is holistic in nature. Max Wetheimer, commonly considered one of the three founders of the Gestalt school, said this about Gestalt:

I stand at the window and see a house, trees, sky. Now on theoretical grounds I could try to count and say: “here they are. . .327 brightnesses and hues.” Do I have “327”? No, I see sky, house, trees; and no one can really have these “327” as such. Furthermore, if in this strange calculation the house should have, say 120 and the trees 90 and the sky 117, I have in any event this combination, this segregation, and not, say 127 and 100 and 100; or 150 and 177. I see it in this particular combination, this particular segregation; and the sort of combination or segregation in which I see it is not simply up to my choice: it is almost impossible for me to see it in any desired combination that I may happen to choose. When I succeed in seeing some unusual combination, what a strange process it is. What surprise results, when, after looking at it a long time, after many attempts, I discover-under the influence of a very unrealistic set-that over there parts of the window frame make an N with a smooth branch. . .

(Emphasis mine)

So is Agile greater than the sum of its parts? I agree that it probably is. But here’s the kick in the pants: so is waterfall or RUP or whatever methodology of the week that you follow to write good software. The key word there is “parts” I think. As in, without ALL the parts, you don’t get the emergent factor of Gestalt. Waterfall can be Gestalt, just ask the people who write the software that runs the space shuttle. It becomes a matter of discipline in following a process precisely.

In my limited experience, what I find happens if you don’t prescribe a practice in a shop that’s trying to implement agile is that shop picks and chooses the pieces that it likes (typically short sprints and planning at the beginning of each sprint) and leaves aside all the pieces that they don’t like which are typically the parts more likely to engender success with Agile like producing deployable code after each sprint or having access to real users, not managerial standins. When this process fails to produce the expected results, it’s the methodologie’s fault even though in reality, the methodology was hardly implemented at all. There’s a reason why we call them methodologies and not suggestologies. There is a method involved and when you short cut it, you get short cut results.

I don’t think Ken Schwaber would ever suggest that leaving out pieces of Scrum would result in a better process. In fact, his book is full of case studies where teams were trying to implement Scrum by skipping important parts of the process.

Eric Gunnerson wrote about what he called “scrumbut”, that is, the practice of saying you are doing Scrum but you’re doing it differently. I’ve written in the past how Scrum is analogous with a jazz musician. When you are a beginner, you don’t have any business going off on your own and riffing some jazz chords because you don’t have the fundamentals necessary to do that. Scrum and Agile are the same in that as a beginner, you can’t decide what pieces of the methodology are good and bad for your team because you don’t have the fundamentals necessary to make that decision without having implemented the process precisely. I don’t think a mentor should ever advocate or facilitate such behavior either. Instead, he should explain why all of the pieces of a particular methodology are necessary.

A process without ALL of its most important parts becomes anti-Gestalt because then the process not only doesn’t produce the emergent behavior expected, it can also be blamed for the failures that inevitably follow. Comparing the picture in Ken’s post with the picture above, it becomes obvious that without the critical parts, the cross in the middle never emerges.

Agile has the potential to make writing software more successful. But that doesn’t mean that it will ever be easy or that you can skip parts you don’t like. Implementing agile correctly involves prescribing and then following an oftentimes difficult process. Only by doing that can agile become Gestalt.