Why Scrum Works and How This Tells Us When It Won’t

This was originally posted in August 2012

Abstract

We hear that Scrum works because it allows teams to self-organize. I believe, however, that Scrum works because it mandates a method that manages queues implicitly. Self-organization may get you there, and will certainly be useful in sustaining improvements achieved with Scrum’s implicit queue management. But it is not the real reason Scrum works. Knowing why Scrum works at the team level provides insights into why it often doesn’t work well at the enterprise level.

Continue reading “Why Scrum Works and How This Tells Us When It Won’t”

The Five Whys of Lean as an Answer to the “But” of Scrum

This was originally published in October 2009

In this blog I discuss the need to get to the root cause of why so many teams are not having success with Scrum.  Merely saying management is not removing impediments or labeling it “Scrum but” does not give much indications as to what or where the problems are. The question is “why does this happen and what can we do about it?” I will suggest one of Lean’s problem solving tools – “5-whys” – may assist Scrum teams in moving forward.

In an Agile Collab interview, Ken Schwaber acknowledged that only 1 in 4 Scrum implementations achieve the success desired by the companies trying it. He attributes this to the organizations accommodating the impediments the team faces instead of solving them. This number has been generally accepted by the Scrum community as accurate (as discussed at Scrum gatherings and on user groups). What surprises me isn’t the low rate of success but rather the general lack of interest into why it occurs. I’ve looked at both sides of this (see Challenging Why (not if) Scrum Works and Challenging Why (not if) Scrum Fails). My own belief is that one has to take a scientific approach and do an inquiry into why things work or don’t work. The intent of both blogs was to spark a conversation about how to improve Scrum.  Unfortunately, neither blog achieved this.

In the past, the generally accepted reason simply seemed to be people were not disciplined, educated or motivated enough to do Scrum properly.  More recently, the belief that developers don’t properly understand what they need to do has resulted in much discussion about having Certified Scrum Developer courses to solve this problems.  But I am afraid both of these are superficial answers.

The issue of teams doing a pseudo Scrum by cherry picking their practices has reached epidemic proportions. One hears of this so much that there has become a name for it “Scrum but.” That is, “we do Scrum but for this”.  However, why do people do this?  This is an important question.   In some situations this is probably a good thing.  After all, Scrum is not a prescriptive methodology but rather a lightweight framework. One would suppose that would mean that there aren’t any absolutes in Scrum, but I’ve heard several CSTs say if you aren’t doing daily stand-ups or retrospectives then you aren’t doing Scrum. The reticence of many Scrum CSTs to present a model of why and how Scrum works (many claim such a thought process is actually counter-productive) only exacerbates this situation. In other words, if one doesn’t have a set of principles to work from, one is left with little understanding of why practices work or not.

So what’s supposed to be in Scrum and what’s not supposed to be in Scrum and who is to decide? If one believes that practices are context dependent and that teams need to be self-organizing then one would expect the teams to decide what they should be doing. Tailoring Scrum should therefore be left to the team and an outsider shouldn’t pass judgment on the team’s efforts. However, since teams don’t understand Scrum well at the beginning of their adoption of it the advice is to require teams to follow a starting set of rules and to only tailor them after you understand Scrum. But why should we believe the starting set works in all situations?

Ironically, many Scrum thought leaders believe software is so complex there is no causality you can understand. In other words, you need to just solve the problems as they show up. In other words, after you’ve tried things and learned them, then you should do things in a way that works for your situation. While this makes sense, it seems to have led to the current situation that if it works, we’ll call it “Scrum” but if it doesn’t, well, we’ll call that “Scrum but.”

The dilemma of Scrum becomes evident. While we don’t want to be prescriptive, when you learn Scrum there are rules you need to follow.  Then, as you get better, you can tailor it to your needs.  The unexamined assumption is that you can always do this.  I do not think it is as simple as this. I believe we need a real analysis of why teams accommodate their problems or why teams don’t follow certain Scrum practices. In other words, let’s get to the root cause of Scrum not working or teams doing “Scrum but.”  To do this, let’s use a Lean tool called “5-whys.”

Five Whys

When something goes wrong, we often jump to conclusions about what caused it. Even when correct, we often stop there – instead of asking ourselves, “well, what caused that?” In other words, we don’t get to the root cause.  Thus, even if we fix this problem, if the root cause is still present, it’ll likely cause another problem.  A popular Lean tool to get to root cause is called “Five whys.”  It basically is an a technique where one keeps asking “why something happened” until the root cause of the original incident which set off the query is uncovered. This may take anywhere from 2-9 levels of questioning – so “5” should not be taken as the exact correct number of “whys” to ask.

Let’s use Five Whys to determine root cause for accommodating impediments and “Scrum but”.

The root cause of accommodating impediments

One of the common impediments teams face in corporate-wide Scrum implementations is that team members are often assigned to work on several projects. It is easy to dismiss this on the lack of commitment of management. If it’s available for them to solve it, there is a kind of implication (and insult) that they’re not up to it – either in intelligence or in commitment. But the truth is somewhat different when one looks at the issue.  The question “why don’t they solve the impediments?” and “what do they need to know to remove the impediments the team is facing?” are questions that should be asked, but rarely are.

Teams often run into impediments whose cause are outside the team. The teams therefore can’t solve them. But why doesn’t management? For example, many Scrum teams are composed of members who work on other things besides their main project. This causes thrashing an delays.

Why does this happen? Because management believes that one of their jobs is to make sure that everyone has productive work to do.

Why? Because management tends to look at people’s productivity in making management decisions.

Why? Because productivity is what they have been taught and used.

Why haven’t they been taught more useful agile methods? Shouldn’t this change in Agile? Not necessarily.

Why? Because many Scrum thought leaders believe you shouldn’t teach much, just create a framework.

Implicit assumptions that may not be correct

Two (unexamined) tenets of Scrum are impediments that slow the team down will be recognized as impediments and that the team is capable of removing them. Besides my earlier statement that impeded teams may not have the capacity to remove the impediment I will go further and state that teams may not even recognize all of their impediments as just that. Many things that slow a team down are often just viewed as the way it is. There is no notion that it is an impediment. For example, I don’t consider the fact that I have to take planes when I want to travel long distances an impediment – it’s just the way it is. Now in this case, I think my perception of reality is correct (but it would be cool if one day I woke up and found out I could fly on my own!).

The whys of “Scrum But”

Let’s take another example of applying 5-whys to a common “Scrum but” – retrospectives.

Why is the team not doing retrospectives?
Because they don’t see the value of the retrospectives.

Why don’t they see the value of the retrospectives?
Because they think there is more value in doing their work.

Why do they think there is more value in doing their work?
Because the retrospectives haven’t really done anything for them.

Why haven’t the retrospectives done anything for them?
Because they often don’t get agreement on what to do.

Why don’t they get agreement on what to do?
Because they think software development is about intelligent people using their judgment – that is, there are no real rules to use or a scientific method to apply.

Why do they think this?
Because software is so complex and no one has presented them with a theory to explain it.

BTW: This is one reason I talk a lot about the theory of flow underneath Lean-thinking. I have seen that it can provide a thought process that helps unite the team.

The dilemma (faulty thinking?) of Scrum

Scrum is in a dilemma here. On the one hand, Scrum is based on being a light framework that doesn’t give a model to work from. On the other, without such a model many Scrum practitioners don’t realize the importance of the practices or how to manifest the affect of the practices in their own context. It seems that the reaction has been to insist that certain practices be done (at least at the start) – which is ironic because Scrum is not intended to be prescriptive. If there isn’t a model, then how can one tell if one is doing Scrum? The common thinking is that you’re doing Scrum if you are removing your impediments, but you’re not doing Scrum if you are accommodating them. This, of course, assumes that Scrum can always work – a dangerous assumption, in my mind. It also makes it very difficult for new teams to know how well they are doing.

Getting beyond “Scrum But”

To get beyond “Scrum But” one needs to be able to understand when the practices of Scrum work and when they don’t.  I believe this requires both an understanding of why Scrum works and a scientific approach in how to apply these rules.  Unfortunately, I have not seen the Scrum community embrace this approach.

 

Smart People, XP and Scrum – Is there a pattern?

This blog was originally written January 2010.There is a division in the agile community about whether one should rely on people or focus on people supported by systemic thinking (no one I know of suggests systems alone are enough). This debate is often the people over process vs. people and process (or as Don Reinertsen would say people times process). I’ve been in the agile community for some time and have seen some interesting things that I think shed some light on this debate. This long-time perspective has enabled me to see an interesting pattern. This blog will discuss the pattern of what happens when smart people do not have the proper understanding of what they are doing.

I’ll start with what I consider to be my most embarrassing moment in my career. It was in 1984, 14 years into my development career. I contracted to build what would be the software system to power the touch controlled information kiosks at Vancouver Expo ’86. At the time, this was very avant garde. I was essentially in charge of rewriting a Basic language prototype into C for both improved performance and features. Since I was experienced in both languages, I remember thinking it’ll be easy – it’s just a re-write.

There were two main components of the application. Mine was the user component that defined how the system should work. Basically you entered events on a timeline that the system would run when the screen was touch. The other was a run-time component that ran the pseudo code mine compiled. I sub-contracted someone else to do the executable program because mine looked to be the more complex beast. At the time, I had a reputation for functioning code extremely quickly (and yes, I intentionally did not use the word maintainable).

It only took me a few week to get the basics of the system up and running – everyone was pleased. I was confident of success because, given this was a rewrite I figured the customer would know what was needed and I would just be adding functionality. Unfortunately, after they started using the system for a while bad things started to happen. It seemed every time they wanted a new input feature (e.g., specifying when a new event, like touching the screen, or starting audio) I would put it in quickly and it would work, but a couple of days later I would find out that I broke something that had been functioning. The problem was that I had tightly coupled code and was not following Shalloway’s principle. Up to this time I had studied how I could code better (e.g., structured programming, etc.) but hadn’t done a study on what caused errors (e.g., tight coupling, lack of encapsulation). BTW – this is not the embarrassing part yet.

The next few weeks followed this pattern – 1) get a customer request, 2) get the request working, 3) be told by the customer the next day or two that something else was no longer working, 4) fix the new bug. This extra bug fixing work was taking a considerable amount of time. It was clear that we were in serious trouble. Now, with what I know today, I would have concerned myself with writing better code (stopping errors instead of fixing them). But what I did back then was recognize that I was causing bugs because I just wasn’t finding all the coupled cases (I was unaware of Shalloway’s Law at the time – in fact, it was this experience that inspired Shalloway’s law). I figured if there were just a way I could tell I was about to commit an error, I could continue programming fast. The problem of having to type something in several places didn’t bother me. At the time I could type about 100 wpm (not my highest speed, but still pretty fast).

I thought the answer to my problems was detecting errors quickly, and (mostly) effortlessly. So here’s what I did. I spent a day essentially writing the equivalent of a UI Test runner and sub-contracted someone to run the tests for me. While I could re-run the test cases automatically, I needed someone to set them up and check the results against good cases. I had basically instituted semi-automatic acceptance testing in 1984 (still not the embarrassing moment – this was actually pretty cool).

From this point on we zoomed along. My quick coding style was no longer holding us back. I’d make a change, give it to my tester and within 15 minutes he’d tell me what I unintentionally broke by forgetting to change something that was coupled to my fix.. I fixed it almost immediately because I knew it was something I just changed. Bottom line, we got our system out in very good time. We even became a real product whereas we were originally only supposed to be a tactical solution for the Expo. The strategic product was being built in parallel with a longer timeframe and 30 people (compared to our 4). However, our product ended up being better so they released both.

So what’s embarrassing about “inventing” automated acceptance testing in 1984 and building a product for my client within budget and time while exceeding functionality initially envisioned and with a high quality? It was that I didn’t do automated acceptance test again until 2000 when I read about XP.

This episode was one reason I knew XP would work the moment I heard about it. I had done an iterative, close customer, automated acceptance test, continuous build (there was only me! ) project 16 years earlier. Only now I had 16 years of experience in considering what made for good programming.

This was why I immediately questioned why XP worked (not if, I was clear that it did). I remember this not being very well received. At the time, Kent Beck and Ron Jeffries (two of the originators of XP) pretty much insisted that you had to do all of the twelve practices of XP or you’d lose its power. There was also little in the way of explaining how to code.

Yes, I know about the four rules of writing simple code:

  1. The system (code plus tests) clearly communicates everything that needs to be communicated at the current instant in its development. This means that it runs every existing test, and that the source code clearly reveals the intention behind it to anyone who reads it.
  2. The system contains no duplicate code, unless that would violate (1).
  3. The system contains the minimum number of classes possible without violating (1) or (2).
  4. The system contains the minimum number of methods possible, consistent with (1) (2) and (3).

The problem with this definition is that it is practiced based. It also is stated in a way that is understandable to someone who already understands these practices (that is, has intuited the principles underneath them) but will cause great misunderstanding for those that don’t have this intuitive sense.

Of course, Kent, Ron and Ward (the third originator of XP) are all brilliant developers and had the necessary intuition. Unfortunately, most of the people getting excited about XP didn’t. I remember talking to several of my associates about XP and said that without the proper understanding of what was underneath XP (something no one wanted to talk about at the time) there would be serious problems for any undertaking it. I even gave a time frame – 6 months. Now be clear, I though XP was brilliant. I just said it was dangerous without the key understanding of it. Sure enough, while many people had great success, many others had great problems with code poorly written (ironically, mostly in the test code).

Those of you who know me know I’ve said pretty much the same thing about Scrum. I’ve written on why it works and why it doesn’t. Ironically, here, as in the XP case, my comments/concerns were pretty much ignored by the Scrum community. Today we have many (most?) Scrum teams practicing what the Scrum community calls “Scrum-but” (that is, we do Scrum, but …”). I wrote a blog on this as well The 5-whys of Lean as the answer to the but of Scrum. Even Ken Schwaber, Scrum’s co-creator and biggest evangelist, has said, I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.

So what is the pattern of these three things?

  • My not doing automated acceptance testing for 16 years
  • XP teams running into code problems after a few months
  • The prevalence of Scrum-But and the general lack of success by many companies undertaking Scrum

I would suggest it is counting on smart people to find the right thing to do is not always a winning strategy. That giving people understanding of the principles and rules underneath programming and development will make them much better. I admit this begs the question that I am a “smart” person. But, I do think I qualify – summa cum laude, 2 masters degrees (one from MIT), successful author, have run a successful business for 11 years (and still going), … I’m not trying to toot my own horn here. In fact, I’m saying, how could someone as smart as me do something as stupid as not use automated acceptance testing for 16 years (isn’t that embarrassing?).

Well, my answer is that relying on practices even if you are smart is insufficient. You must learn why those practices work. Of course, this makes sense only if you believe there are rules underneath what we do. Many in the agile community don’t believe this (I’ll be writing a blog on this next week). Bottom line for me is, get the best people you possibly can. Then, make sure they study their methods, as explicitly as possible, so they can create solid, support systems and understanding of what they do. You will get a much greater return from their efforts if you do so.

In my case, the understanding would have had me look to see where I could apply automated acceptance testing effectively. Years later, I now understand that one key aspect of automated acceptance testing is to eliminate the added work that comes from the delay between code and test. I clearly knew this at some level in 1984. But not at a deep enough, or consciously high enough, level to take advantage of it on a regular basis.

XP has been around long enough that people have finally gotten to the why it works. In Scrum’s case I believe we find people doing Scrum But because their lack of understanding of the principles underneath Scrum prevents them from effectively changing the given practices. They often think they are doing the right thing, when in fact, it is not effective.

This is why, at Net Objectives, all of our training and consulting starts with why things work. If this makes sense to you, and you think you can use some help in doing this, please send me an email alshall AT netobjectives.com to see if we can help.

If you want more information on what we now consider to be useful principles and guidelines for coding better, check out these resources pages (you’ll have to register to get access to some of these):

Challenging Why (not if) Scrum Fails

This was originally published in May 2009

Virtually 2 years ago I wrote a blog called Challenging Why (not if) Scrum Works.  Basically, I was looking to see why Scrum worked so I would be able to best take advantage of Scrum. I believe Scrum works very much due to the structure of the team, the iterative nature of development and the proper context within which the team works.  In this prior blog, I reported my experience with teams that were co-located, had all team members work together and worked on only one project compared with those who were not co-located, had team members of different roles report to different managers so they were not always working together and these same people were typically on 3-5 projects at once. The co-located teams were three times more productive than the other ones – even though the people, domain and customers were virtually the same. I thought this was a great insight for two reasons.  First, it meant if you couldn’t deliver (or even build) in increments, there were things you could do to improve your development methods.  Second, if you could do incremental development, these practices were some of the first things to implement.

Continue reading “Challenging Why (not if) Scrum Fails”

Going Beyond Design Patterns

This was originally published August 2012

In our Design Patterns Thinking  course we quote Christopher Alexander’s Timeless Way of Building – the book that inspired the software development community to create design patterns. Most everyone familiar with design patterns is familiar with Alexander’s phrase “patterns are solutions to recurring problems in a context.” However, my favorite quote of Alexander is 4 pages from the end of his 549 page book –”At this final stage, the patterns are no longer important: the patterns have taught you to be receptive to what is real.”

For those new to patterns, these two quotes may seem contradictory, but to readers of his book and attendees at our course, the typical response is “yes, I already knew that.” Design patterns are solutions to a design problem in the way recipes are solutions to a “what do I want to eat?” problem. Learning design patterns as solutions to recurring problems in a context in order to be a great designer is like learning how to be a great chef by learning recipes. While useful to a degree, it is not very effective to become a master.

We need to remind ourselves that patterns are examples of solutions given a particular set of issues to be dealt with. The Gang of Four’s set of 23 patterns provides a meta-pattern that can teach us how to handle variations in a problem domain. Our Design Pattern Repository lists patterns by what they encapsulate. This is an extremely important insight. In both Agile and non-Agile teams, requirements will change – the biggest differences are: rate of change, size of change, and how we prepare our code for the change.

Most new requirements change in how a concept is to be implemented more as opposed to a totally new concept emerging. Code is often written as “this is the way it’ll work” and therefore is not well prepared for when a new, different way comes along. When we truly understand the thought process of patterns, they will provide us with a different way of looking at the world. I discussed this in my article Can Patterns Be Harmful? as well as my book Design Patterns Explained: A New Perspective on Object-Oriented Design. In other words, patterns don’t just provide us with good solutions, they can provide us with a thought process in which to achieve quality solutions to unique situations for which no current pattern exists.

The focus on patterns as solutions is unfortunate. The insistence that patterns are discovered, instead of created, obscures the fact that there is a thought process underneath these patterns. This thought process is worth discovering.  One aspect of this thought process is how to refactor code using the knowledge of patterns – something called “refactoring to patterns.” I introduced this concept in our first design patterns class in 1999 (as well as my aforementioned book). It provides a basis for refactoring quality code as needed using the thought process of patterns. You can learn more about this in the Refactor To The Open Closed chapter in our Essential Skills for the Agile Developer: A Guide to Better Programming and Design book. This is also discussed in the Avoid Over and Under Design chapter the same book. If you prefer webinars, watch Avoiding Over and Under Design in Agile Projects.

If you want to learn more, the best place is to take one of our Design Patterns classes. We currently have one scheduled in Seattle – Design Patterns for the Agile Developer, October 30- November 1. If you are in another city and have 4 or more folks interested, please contact Mike Shalloway (mike.shalloway@netobjectives.com) and we’ll see if we can schedule a course near you.

 

Complexity is Not What it Used to Be

This was originally published in May 2012.

Those who cannot remember the past are condemned to repeat it. George Santayana

The time was 1847. The place was the Vienna General Hospital. New mothers in the doctors’ wards had been dying of puerperal fever with an extremely high mortality rate – three times that in the midwives’ ward. It was a mystery. It could not be explained. But Ignaz Semmelweis had been observing this for years. Had studied the situation and made some interesting connections.

The situation was very puzzling. There were two clinics in the hospital Semmelweis oversaw. Clinic one was the teaching service for medical students; clinic two was where only midwives worked. Why was the presence of doctors apparently killing new mothers? Women were coming to the hospital’s maternity ward for the benefits of the child care they would receive. But the high mortality rates had them try to avoid coming on a day when they would be admitted to the first clinic. In fact, many preferred to have their births in the street, then come to the clinic for the benefits. Surprisingly, the mortality rate for those giving birth in the street was significantly lower than for those giving birth in the doctors’ clinic. It was a mystery, and nothing could explain it.

Until Semmelweis figured out the connection. And proved it – lowering the mortality rate from the 10-35% it had been to 1%. The connection was doctors working on cadavers (it was a teaching hospital) and then going to do their rounds with patients. The solution was Semmelweis instituting the practice of hand disinfection with a chlorinated lime solution he created. The results were dramatic. But his theory was incomplete. He could not explain why it worked. The existence of germs had not been postulated yet, let alone detected.

His theories were scorned. Administrators of hospitals thought the suggested disinfection process would take too much time. Doctors were not eager to admit that they had caused so many deaths. It was not until years after Semmelweis’ death that his theories were accepted – after Pasteur could demonstrate the existence of germs. For more on Semmelweis, see Wikipedia.

How does this relate to us? I would suggest the knowledge of germs to doctors is like the knowledge of flow to software developers. It is not all there is (other things cause disease than germs) but it is pretty important to know. Things that often appear complex and unknowable, are, in fact, complicated but unknown. BTW: I am not suggesting that software development as a whole is not complex, just that not all of it is complex.

I have been doing some form of agile consciously for over 20 years. I have been doing agile practices at one time or another for over 3 decades Unfortunately, that “one time or another” was hit or miss. I did it when I intuited a solution, but that was relatively rare. I am a big believer in understanding why what you are doing works – see an old blog of mine – Smart People, XP and Scrum – Is There a Pattern?

It seems the software industry has hit a crisis in the adoption of Agile. It is almost to be expected that when you hear about a large organization successfully adopting Scrum for several teams working individually, you learn they can’t quite get it to work well across teams. Why is this? Well, it’s a mystery for some. Not for others.

Since 2005 we (Net Objectives) have been helping clients who have been encountering cross-team challenges in their development methods (IT and products). Many of the insights we’ve had have come from looking at the theories of Flow and how they apply to software development. This is one reason I am so passionate about the need to understand that Scrum itself, is a manifestation of Flow and Lean thinking. By not being consciously aware of this, many Scrum practitioners can’t extend it as needed, or abandon it for better methods when available.

I have seen some development groups (75-150 folks) transform themselves almost overnight by attending to flow. I have also been somewhat mystified by much of the Agile consulting community’s resistance to many of these ideas – having once been thrown off a discussion group for insisting they were a better alternative than (still) popular methods of team collaboration.

Challenging why (not if) Scrum works

This was originally published in May 2007. Minor edits made. I have left the # of years the same to keep context.

I have repeatedly heard that “Scrum succeeds largely because the people doing the work define how to do the work” (see From The Top by Ken Schwaber for his full text). However, I do not think that is even a third of why Scrum works – and be clear, I am certainly not questioning that Scrum works – I just want to get at the why it works.

Continue reading “Challenging why (not if) Scrum works”

Shalloway’s Law and Shalloway’s Principle

This blog was first written in August 2007

A few years ago somebody came up to me in one of my classes and said, “you’re the CEO of a successful company, co-author of a successful book (Design Patterns Explained: A New Perspective on Object-Oriented Design), … you ought to have something named after yourself.” So I, of course, immediately like this guy and think – hmm, what should that be?  I came up with this:

Shalloway’s Law:

“When N things need to change and N>1, Shalloway will find at most N-1 of these things.”

Hey, I didn’t say it was complimentary. It’s a law! I have to follow it. That’s the problem. BTW: They didn’t ask me about gravity either when I was born! I really would like to break that law at times too!

Eventually I came up with Shalloway’s Principle:

“Avoid situations w

Hey, I didn’t say it was complimentary. It’s a law! I have to follow it. That’s the problem. BTW: They didn’t ask me about gravity either when I was born! I really would like to break that law at times too!

So I came up with Shalloway’s Principle:

“Avoid situations where Shalloway’s Law applies”

Shaloway’s law applied when “N > 1″ and Shalloway has to find all of the things involved. In other words, avoid redundancy (make N=1) or make it so Shalloway doesn’t have to find the things. For example, I may have redundancy in my interfaces. But I also have a cool “to do list generator” (some people call it a compiler) that when I change a method’s interface it tells me what I need to update. Better not to have redundancy at all, but if you do, make sure Shalloway’s law does not apply.

For an in depth view of this, see Shalloway’s Law and Shalloway’s Principle from Essential Skills for the Agile Developer: A Guide to Better Programming and Design.

Specifying Exceptions in TDD

Exceptions in software represent a mechanism for raising an alarm when something goes wrong. They are used when there is a potential problem that cannot be detected by the compiler, linker, or other automated aspect of the development process, and thus may potentially make it into the released product.

When an exception is declared in the code, it is basically a way of saying, “We hope this never happens, but if it does at least we’ll be made aware of it.” Getting the exception is bad news, but the problem that caused it is made visible so we can deal with it. Not getting the exception is good news. Everything is fine.

In TDD, however, this is logically reversed. Continue reading “Specifying Exceptions in TDD”

One important aspect of systems-thinking that has long been ignored by the Agile community is that a system is not its components. Rather, it must be recognized that these interact in a way that creates the behavior.

But the nature of these interactions are very complex – meaning that they can’t be predicted. Unforeseen events occur, unexpected interactions and sometimes small, even obscure events happen that cause huge side effects. This is a reflection that product development (creating the unknown) by a group of human beings (by nature unknowable) comprise what is known as a complex system.

Many people have gotten caught up in the theory of complexity going further than what I need is necessary for pragmatic effect. While it is true that complex systems can’t be predicted, there are many patterns of behavior exhibited by them. In the same way engineers were quite effective in building magnificent edifices (e.g., the Pyramids) without a full understanding of the science underneath the methods used, it is possible to adjust the behavior of complex systems without understanding the full nature of the principles involved.

We mostly need to know that 1) our changes may produce unexpected behavior and 2) we are embedded in a system where small errors can cause big, undesirable affects (the essence of Chaos Theory). However, instead of giving up and saying we can’t predict things, we can move forward with an knowing our understanding is always incomplete. We do, of course, need quick feedback, both of our actions in our work and in any actions we take towards its improvement.

Both agility of development and improvement of our methods is required.