Agile Planet

Every now and then I take a stroll down memory lane and read some old blog posts, both mine and colleagues’.

After I stop cringing at how naive and earnest we all were I try and contrast my current opinions with those of my younger self and his young friends.

Some thoughts from tonight’s history lesson:

• Be aware of your biases, preconceptions and beliefs. Consider how they might colour your interpretation of events.
• Throwing away an acceptance test suite representing ten person-years of work because you want to use a different test tool is almost always a shockingly irresponsible thing to do.
• A major high street bank based in Poole could have had an award-winning business banking website if they hadn’t (ostensibly) cancelled the project because it was going to deliver 3 months late. That was 5 years ago. It’s still not finished.
• Technical excellence is meaningless without effective governance.
• High performing teams are messy, loud, exhausting, chaotic fun and will still be discussed fondly whenever 3 or more members get together, even 5 years later.

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

For sometime I’ve been publishing Agile Quick Links. Links to articles that Agile folk will be interested in. Now I’m starting NeuroAgile Quick Links, these will references to articles or summaries of papers that I think are of interest to members of the Agile community.

The Conversation is Over. Long Live the Conversation – reacting to an article about the use of twitter like tools in high school, David Rock examines the affects our interactions through facebook, twitter etc. are reducing our empathy and damaging the art of conversation. David talks about the silence in cubicle mazes as people ignore each other and fail to collaborate. Talk your teammates don’t IM or Skype them, real collaboration happens through face-to-face conversation and not over a computer

When We’re Cowed by the Crowd and The Web and the Wisdom of Crowds – we’re all familiar with the Wisdom of Crowds (James Surowiecki) and the idea how a diverse group of people can make some very accurate estimates/guess. In these articles, Jonah Lehrer describes:

The scientists then gave their subjects access to the guesses of the other members of the group. As a result, they were able to adjust their subsequent estimates based on the feedback of the crowd. The results were depressing. All of a sudden, the range of guesses dramatically narrowed; people were mindlessly imitating each other. Instead of cancelling out their errors, they ended up magnifying their biases, which is why each round led to worse guesses. Although these subjects were far more confident that they were right—it’s reassuring to know what other people think—this confidence was misplaced.

I wonder what affect this has in planning poker where we get more information than just the raw numbers, also the ideas behind the numbers.

“That’s the Way We (Used to) Do Things Around Here” (strategy+business – free reg required) a long article on understanding how change works and the brains involvement. If you’re helping to organize change (i.e. coaches) this article is well worth reading.

Happiness on the Job is tied to Autonomy (see: Happiness: The Neglected Role of Job Design). In addition the study notes:

The study also shows that performance-related pay, one widely-used management tenet of high performance work systems, makes no difference to satisfaction or stress. Performance-related pay includes bonuses given to City workers and other employees

In the same vein Its all about control – you either need power or choice (i.e. autonomy). This is a recurring theme autonomy is very important to us.

Here’s another video interview recorded by Yvette Francino of SearchSoftwareQuality.com at the ADP/West 2011 Confierence.

NeuroAgile – the intersection of neuroscience, cognitive science, psychology and agile/lean software development. For some time now I’ve had an interest in understanding how and why Agile works (see: Does Scrum Work? Hell Yes!!! Why and Why Scrum Works??) while poorly written it was my first attempt at articulating a deeper why.

For sometime now I’ve been reading about Neuroscience (Norman Doidge “The Brain That Changes Itself”, John Medina “Brain Rules: 12 Principles for Surviving and Thriving”, James Zull “The Art of Changing the Brain.”,  Torkel Klingberg “The Overflowing Brain: Information Overload and the Limits of Working Memory” and David Rock “Your Brain at Work”), cognitive science and psychology (mostly via well researched blogs). What I’m learning that these fields have a lot to tell us about people, their motivations and how they work together. I think  that these things are at the heart of making successful projects.

So why am I coming up with a new term? I think we need a label to help us categorize some of these great ideas and to provoke us into finding more. In my case I’m pushing it further. In the past few years between Roger and myself we’ve written several articles that look at applications of neuroscience: The Science of Learning: Best Approaches for Your Brain and Multitasking Gets You There Later. Now we’re crawling our way towards at least a mini-book. In the next few weeks I will start publishing a series of interesting links and sometime early in the fall we will publish a paper on Creativity.

I’m live blogging from the uk government IT meeting on agile at the SPA conference. Nothing beats a blogpost fired off in anger

Here are some tweets I would like to elaborate on:

Me: “Offshoring government it is stupid”

Eric Lefevre (@elefevre): “why? on paper, if there is any way to commoditize software for government, it would sound like a win, wouldn’t it?”

Me: “Software is executable knowledge. Offshoring software is giving a potential enemy exclusive posession of that knowledge.”

Imagine, if you will, the UK code breakers in the 1920’s outsourcing some of their work to Germany, because labour there in the crisis after the first world war was cheap. Manual computations, but nevertheless. What would have happened by 1938?

This is a bit of a straw man of course. However, the problem with outsourcing and/or offshoring is that you put executable knowledge, plus the expertise to grow that knowledge and build knew software from it in the hands of one party. That leads to a dependency on that party. As long as things go fine, that is swell. When things go bad, not so much.

If you think that documentation is going to help. It might, if you are lucky. Most of the knowledge that goes into software is tacit, and very difficult and costly to transfer.

So if you are a government agency (or a company for that matter), don’t be stupid. Keep some good technical people on permanent staff, who know how your crucial systems work, and can make modifications. If you add some external staff to that to be flexible in capacity or bring in specialist knowledge, great!

Just don’t forget to let them work side by side with your permanent staff on a daily basis, so your organisation does not leak knowledge that it can’t recover on its own.

Just remember, knowledge is power. If you’re not careful, you will learn that lesson the hard way.

At the SQE Agile Development Practices (ADP/West) Conference last week in Las Vegas, Yvette Francino interviewed me on the topic of cultural change.  Here is the video of that interview.

In my previous post, Avoiding Iteration Zero, I suggested starting with “the one obvious thing that needs to be done? (Hint: it’s not ‘login.’)” As Jon Kern has recently mentioned, this same topic has come up elsewhere. I was also in that list discussion.

Jon is, of course, right in a narrow sense. You can start with login, if you want. You can also start with an Iteration Zero. (Or, an Iteration Minus One, as I’ve seen one organization do when their list of pre-planning outgrew one iteration.) I’ve observed that you can generally get better software, faster if you start somewhere else.

There are some very good reasons for this. For one thing, it’s unlikely that you’ll find much business value in delivering a system that allows people to login, but do nothing else. Unless you’re writing a login package for others to integrate into their code, something else is the central idea of the system. Surely there are some things about that central idea that we don’t yet know in detail. By contrast, “login” is fairly widely known and understood (even if sometimes implemented poorly). Even if we decide we can’t deliver the system without “login,” we can learn important things earlier if we work on the central idea first. (And I can imagine, in a pinch, having a usable system where access was controlled by putting the computer in a secure room where only those with authority could touch it.)

Learning important information sooner is one of the subtle but powerful benefits of working in an Agile fashion. It can help the business make better decisions about priority, or even about the direction of the effort. That’s one of the tenets of the Lean Startup focus, but it works for established organizations, too. There’s almost always something new about what we’re doing, or we wouldn’t be spending money doing it.

This pattern of accelerating learning is powerful for businesses that use it. But it’s also powerful for programmers working on the code. As we build our application, we can learn about better ways to structure the code, and we can use that information when we’re writing further code. I’ve found this to allow me to do a better job when developing code in an iterative-incremental fashion than when creating an up-front design and then following it.

Let’s look in more detail at Jon’s suggested beginning:

For example, to start, you can simply check that the response has “Login Succeeded” ( or “Login Failed” for testing that a bogus login attempt does indeed fail). …simply:

Scenario: Successful Login
    When I login as admin
    Then I should be logged in
Scenario: Failed Login
    When I login as asdf56ghasdkfh
    Then I should be not logged in

And your steps would hide the logic for filling in the login form and checking for success:

Given /^I login as "([^"]*)"$/ do |login|
  @login_name = login
  visit login_path
  fill_in "login", :with => login
  fill_in "password", :with => "password"
  click_button "login_button"
end
Then /^I should be logged in$/ do
  response.should contain "Login Succeeded"
end
Then /^I should not be logged in$/ do
  response.should contain "Login Failed. Please try again."
end

Given this simple start, where will we put our access control logic? Most likely in our Controller of MVC or Presenter of MVP. Then we’ll decide to which page we direct the user. In effect, we’re protecting the “Login Succeeded” page from the unauthenticated. Is that page the asset whose access we want to control?

I once worked with a client who had an application that allowed authorized users to access the documents to which they were authorized. It was not an Agile shop, and they were not working in short iterations using small stories. They had, however, been delivering new functionality in each release for a number of years. And they were very thorough programmers, carefully checking that they were not delivering bugs. Having started with the idea of access control, they had ended up with their authorization check in the Action class of their Struts app. Over time, there was a need for further authorization concerning some documents. Only an authorized user could see any document, but some documents were only available to a subset of users. The Action class checked that the user was logged in, retrieved the list of documents, and then filtered out the ones that particular user was not allowed to see.

Do you see any problem with this scheme?

It works well enough, but it causes some maintenance headaches. Even though there was not a link to the unauthorized documents, there’s nothing to stop a savvy user from guessing the URL and retrieving it anyway–so there had to be an authorization check there, too. And there were multiple lists of documents, so each one had to make this check. Sometimes when the authorization logic changed, one of the Action classes would be overlooked. Extracting this authorization filtering code to a method would reduce much of this duplication and make that particular mistake less likely, but some lists had different filtering rules. Also, the Action classes would retain the duplication of the order of steps that each one had to apply in order to properly protect the assets. (That’s a more subtle flavor of duplication that many overlook.) And there was a requirement to show some documents in the list to people who were not yet authorized to retrieve them.

It was pretty complicated and error-prone. Enforcing the security at the outer layer, instead of directly around the protected assets, resulted in more places and more variability in the implementation. I’m sure that you and I and Jon Kern would not end up with such an error-prone design. Jon is an excellent software designer–much better than I am. He can explain why you’d want to design in a particular way and describe the reasons why. I, on the other hand, have trained myself to be sensitive to duplication. Test-driving code with an aversion to duplication would lead me to a different design.

I helped these programmers implement a new feature–one that provided government-mandated access to certain documents even if the user wasn’t logged in at all. Since this required a change to all of these access controls, it provided the impetus to change the design. While adding this new requirement using Test Driven Design, I also refactored code to remove the duplication. As I did so, I pushed the access check lower in the code, passing along a “AuthenticationToken” object that could be treated as a black box by intervening layers. Ultimately the access check was made in the database queries themselves, insuring by simple inspection that no path in the user interface could lead to a condition that allowed unauthorized access.

You’re probably a good programmer, too. I’m sure you wouldn’t make a mistake. Linda Rising recently told me that 80% of people think they’re above average, so you must be good. As it happens, the programmers who built this system were pretty good, but they weren’t experienced in the technology. This J2EE system was the first Java code they’d ever written. These programmers generally succeeded by being very careful to check all the paths. Only very occasionally did they miss one and allow a bug to escape to User Integration Testing.

It’s my contention that by implementing the primary functionality first, in this case the listing and retrieval of documents, then we’ll be more likely to naturally put the access control directly around the assets that matter. In other situations, there may be other considerations for the access control that would be different from the application I described. In any case, if our primary story is

When I do whatever my application does
Then I get the result of doing so

in all of the varieties of “do,” then the proper place for access control will be obvious for more than 80% of us when we get to the story

Given I am not an authorized user
When I do whatever my application does
Then I am denied the result of doing so

While it is certainly true that we can get to the desired design anyway, as both Jon’s blog and my story above illustrate, it’s easier, more direct, and more likely that we’ll do so if we start with our primary business functionality before the LOGIN story.

It’s not a law of the universe, but it’s a good heuristic: The Login story is not the place to begin.

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

Have you ever thought about the Maximum Marketable Featureset for your product? You may be familiar with a Minimum Marketable Featureset, which is the minimal set of features where someone wants to buy your product.

The underlying assumption is that adding more features after the minimal set will make your product more valuable.

At some point adding features makes a product less valuable to users. Less features are easier to understand for users and for developers, which in turn can help improve the value of each feature.

So next time you build a product, think about it. When will more features diminish the value of your product to its users? Why not on your current one? Are you there yet? How far still to go? Past the point already? Could I make this post more valuable by asking less questions or using fewer words?

I just got an email from Allison Randal, Technical Architect of Ubuntu. They're looking for people to build automated tests for Ubuntu:

At Canonical, we're ramping up a team for automated testing across the entire OS. I'm wondering if you have contacts in Portland or elsewhere who might have recommendations, or be able to point a few qualified people our way?

Allison went on to say that they're specifically looking for people who can write automated tests, not just manual testing skills.

If you're interested, apply here. Although Allison mentioned the Portland area, I'm pretty sure any location is fine.

Comments

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

In my Certified ScrumMaster Training I ask students not use their laptops and CrackBerry’s. Why?

Some people want to take notes using their laptops. Unfortunately my experience shows that laptops do more harm than good. They put up a barrier between people at a table and reduce collaboration. They send a signal that this person isn’t open. They even reduce interaction with the trainer. Finally with tools like outlook even if you don’t have web access they’re often a source of distraction. For these reasons I ask that you not use a laptop.

Crackberries, IPhones, etc. don’t put up the same barrier because the screen doesn’t get in the way but they present a different problem. If you’re looking at your device, worse actively using it you’re telling people around you that the distraction is more important than the class. You’re saying its more important to interact with the device than your classmates.

Breaks are the perfect time to use your electronic devices, but the rest of the time honour us with your presence.

Come Join us for Certified ScrumMaster Training in Ottawa

For several years I’ve been trying I’ve been trying to find a Neuro-Linguistic Programming (NLP) book that provided a simple and clear explanation of what it is and how it works. With “Relationships Made Easy for the Business Professional” – Dr David Fraser scores well on the first and not as well on the second.

The book’s strength comes from David’s practical business background which he uses to ground his writing and examples. The book fails when its attempting to explain how NLP works.

David describes a 12 step process to help

1. Attention to others
2. Attitude
3. Self-control
4. Wavelength
5. Filters
6. Connection
7. Values
8. Language
9. Self-awareness
10. Attention to yourself
11. Balance
12. Love

Most of the steps David describes make perfect sense and I’m trying to apply them. The book falls down when David attempts to explain why these ideas work:

Whenever you feel you have run out of mental flexibility, try some physical flexibility, such as a stretching exercise or moving around. Going for a walk when you have a problem to think about gets the left and right sides of your brain communicating. (location 1054)

While going for a walk is a great tactic when you’re blocked it has nothing to do with getting the left and right sides of brain to communicate. They’re going to do that not matter what. From David Rock’s, “Your Brain at Work”:

Stellan Ohisson, at the University of Illinois at Chicago. explains how when facing a new problem, people apply strategies that worked in prior experiences. This works well if a new problem is similar to an old problem. However, in many situations this is not the case, and the solution from the past gets in the way, stopping better solutions from arising. The incorrect state becomes the source of the impasse.

Handing the problem off to your unconscious by taking a walk or starting another activity is an effective approach. There are left/right brain distinctions but they have nothing to do with “blockages”. See, Elkhonon Goldberg “The New Executive Brain: Frontal Lobes in a Complex World” where he makes the claim that the left hemisphere deals with routine situations and right with novel. The details of what’s happens and the evidence to support the claim is several chapters long, so I won’t summarize it here.

David Fraser says:

If a meeting becomes strained, try having everyone move around. Use flexibility in the physical dimension to unblock the mental processes. A time-out” can actually speed up a meeting.

Again this might be a good idea but I’ve not seen any example of “blocked mental” processes in my reading nor a study that explains why movement might be effective when people are interacting in a meeting. The best discussion I’ve seen for our interactions comes from Rock’s, “Your Brain at Work” see Act III Collaborate with Others.

Finally Fraser says

Develop physical flexibility to increase your mental flexibility. Learning T’ai Chi, even at a very simple level, is one effective way of doing this.

I’ve not found any evidence yet about a relationship between physical and mental flexibility. In fact I’m not sure we really know how to characterize mental flexibility. The closest I can find is John Medina and Brain rules: “Rule #1: Exercise boosts brain power.” (brainrules.net). David Rock also has more on exercise and the effects on neurogenesis (grow new neurons). Finally there is some interesting evidence around meditation and its benefits (a quiet mind), but nothing to support the claims Fraser makes.

In a nutshell, an interesting book with many good ideas. However the flaws in the science make it difficult for me to read. I suspect I wasn’t the intended audience for the book. If you don’t mind these issues then you will find the book valuable.

On Tuesday, Alistair Cockburn and I debated the merits and limitations of certification in a webcast hosted by the PMI. We had an interesting and cordial discussion and the PMI has graciously put up their recording for anyone to hear.

Listen to the debate here.

Comments

Teams new to Agile often realize that they have a lot to do before they get their new development process at full speed. Looking at this big and unknown hill in front of them, many Agile teams choose to do an Iteration Zero (or Sprint Zero) to prepare before they start delivering regular increments of functionality. During this time, they may try to get their ducks in a row with

• A list of features to be built
• A release plan or timeline for those features
• Setting up development infrastructure such as version control or continuous integration servers
• Studying or practicing skills in new technologies they expect to use
• … and other management, infrastructure, and technical endeavors.

They try to get all the preliminaries out of the way so they can hit the ground running full speed in Iteration One. In my experience, they’re still not ready to go full speed. These things are rarely as complete as expected after one iteration, and often aren’t quite in tune with the actual needs of the project.  The list of features will likely not be complete, but the attempt to approach completeness will dump in lots of ideas that have been given little thought. Any attempt to project into the future still has no data about how fast things can be accomplished. The infrastructure may or may not be the best for supporting the project, but it is likely that the project will now conform to the infrastructure rather than the other way around. The choice of technologies will be made speculatively rather than driven by the needs of the project. While we may do OK, we’ll have made a lot of decisions with the least amount of information we’ll have in the project lifecycle.

And we’ll have burned an iteration without producing any working software that tests our decisions.

My advice is to borrow an idea from Lean and look at the situation from the output point of view.  Ask yourself, “what would it take to start delivering?”

The initial backlog really only needs to be one item in order to start delivering.  If you’ve got too many unknowns, then just start with one item.  Get the business stakeholders, the programmers, the testers, and anyone else who needs to be in on the discussion (User Experience? Ops?) to talks about it.  (I call this a meeting of the Three Amigos.)  What is the one obvious thing that needs to be done? (Hint: it’s not “login.” Start with the main purpose of the system.) I can’t imagine a situation where a project is started without any ideas at all.

Take that one thing, and slice it into thinner slices.  Decide on the examples that represent acceptance of those slices.  Some of the slices will have questions that can’t be answered.  Put those aside for the moment.  Choose the most central slice that travels through the entire concept from end to end, or as close to that as possible.  Estimate that as one team-iteration.  (Estimates don’t have to be “right.” They’re just estimates.)  Start building it.

Learn the necessary skills in the technology while accomplishing real work. Learn the parts that aid building the system, rather than developing the system according to some framework. When you don’t know how to accomplish something, or you think multiple approaches might work, do minimalistic spikes to give the information needed to make a decision.

Along the way, start slowly building your development infrastructure. Set up a local code repository. You can always migrate the code to an “official corporate” repository later.  Right now, there’s not much code. Set up a simple build-and-test script so that everyone builds in the same fashion. You can always add other build targets later. If you’ve got time, you can set up a Continuous Integration server. Otherwise, just do it manually. Checkout & build into a clean workspace. Do what’s needed to run the code so that you can show it working.

If you can’t accomplish this slice in one iteration, it’s probably not thin enough. Or, maybe you haven’t yet solved an essential technical problem. Or the goal isn’t yet clear enough. Figure out what impediment is most in your way, address that, and try again.

More likely, you’ll get this slice done in less than a iteration length. If you get this slice done before the end of the iteration, then pull in another slice.  Estimate this as “the rest of the iteration.”  Repeat as needed.  As long as you’ve gotten one slice done, you’ve got a potentially deliverable product increment.

Yes, there will still be development infrastructure to be developed. There’s no particular rush to get that done. Just keep improving it, so that it helps you get more done. Yes, there will still be technical skills to be developed. That should always be the case. Just keep experimenting and pushing your limits.

Yes, there will still be features to be added to the backlog, refined, prioritized, split into stories, and prioritized again. This should continue throughout the project. It’s part of the “steering” process. Yes, there will still be a need for projections to estimate when functionality can be released, or how much functionality can be released by a certain date. When you think you’ve got enough information about what needs to be done, then consider the initial release plan.  By then you’ll also have accumulated a little information about how fast things get done.

There will still be a lot of holes in your knowledge of what needs to be done and how fast things get done.  Don’t trust your initial release plan to be “right.”  It’s just a stick in the sand to help you judge how things are going.  Keep planning, and move the stick as needed. And as time passes, you’ll have a better and better indication of how fast the system gets developed. Even when you think the Release Plan is complete, it needs to be continually reviewed and adjusted. Since it’s never done until the release, there’s no particular hurry for a certain level of completeness.

This sort of beginning is very like the Hudson Bay Start that Johanna Rothman describes in her book, Manage It (pp. 52-53).

The Hudson Bay Start approach was originated by the Hudson Bay Company in the 1600-1700s in northeastern Canada. The Hudson Bay Company outfitted fur traders. To make sure the traders hadn’t forgotten anything they needed, they left Hudson Bay and camped just a few miles away. By making camp just a few miles away, the traders ensured they hadn’t forgotten any tools or supplies–before they abandoned civilization. With just a short start to their journey, they had a better idea about their ability to endure the winter.

There’s really no reason (other than “that’s not the way we do things around here”) that this can’t work for the start of any team/project. It’s a great way of learning the right stuff for the current situation while also making a bit of progress. I use this technique in my Agile in Six Months transition plan.

Brian Marick has written a tantilizing post The Stance of Reaction. In it he says

At this point, Sr. Naveira has at least four reasonable choices. He can step forward, thereby “asking” Srta. Muzzopappa to move backwards. He can step backwards (typically reversing the sweep). He can turn toward her so that they’re facing, causing her to “collect” (bring her feet together). He can take no step at all, but turn his chest to the left, causing her to begin moving counterclockwise around him.

The important thing about Argentine tango (danced recreationally, though perhaps not in a performance like this) is that she does not know which choice he’ll make. She must be balanced in a stance—physical and mental—that allows her to react gracefully to any legitimate move.

I truly hope he’ll expand on this, and how he applies it to the business of software development. I have great admiration for Brian’s intellect and inventiveness. I suspect what he says will help me work on some half-baked ideas I have about effective TDD keeping the code in a state in which it’s prepared to go in any direction, and about Pair Programming being most effective when we work to increase the possibilities open to our partner (a la Improv acting).

So far, Brian seems to be describing the concept of Reaction by saying what it is not–that it is not a reduction to a model. His description of this dichotomy does not match my understanding of how we use models. Online conversation has not clarified my understanding of his description. I suspect that the difficulty stems from us looking at the situation using different models. The appropriate next step seems (to me) to clarify my own model of how models work and are useful to me.

I wholeheartedly agree with Brian’s assertion that we have “a readiness to reduce (abstract away, simplify, generalize) the world’s complexity into something simpler that you can work with and think about.” This is not just true of knowledge workers, but of people in general. The assault of the universe on our senses is far too much to observe without doing so. As Brian says, “By default, we mostly act unconsciously, with the unconscious mind forwarding only anomalies to the rational part of the mind.” In other words, when the world around us is appearing to conform to the models that are most ingrained within us, we can react according to those models without making a conscious choice.

Other models are less ingrained, and we apply them more consciously.  Brian’s examples of the “homo economicus” and the “V-model of the Systems Engineering Process” models are good illustrations of models we’ve built particularly to help us with situations that our subconscious doesn’t handle.

Is there a fundamental difference between our unconscious and conscious models? As far as I can tell, it’s only in our awareness of them.  The study Brian uses to illustrate the power of the unconscious mind describes a detectable awareness between a cookie sheet and a chess board.  The unconscious model accounts for putting a cookie sheet into the oven, but does not account for putting a chess board into the oven.  Certainly both cookie sheets and chess boards are too modern to be innate to the species. Instead, the pattern of putting a cookie sheet is one to which we’ve become accustomed by familiarity. Or, at least, most of us have. Trying the same experiment with people unfamiliar with ovens, cookie sheets, and chess board would assuredly give different results.

Reductionist models are the way that both the conscious and unconscious mind deals with the sensory overload.  But the models we use can lead us astray.  As Brian says,

So sticky is the “homo economicus” reduction that economists face the occupational hazard of treating it as the only model of human behavior, which can make them say awfully silly things. Similarly, elegant and simple software development models like the V-model are so elegant, so simple, so pleasingly linear that their failure to work with real human behavior and limitations is commonly seen as the fault of the people, not the model.

H.L. Mencken put it this way, “For every complex problem, there is a solution that is simple, neat, and wrong.”  We are more likely to jump to an easy answer when we only know one model that fits the situation, or when we fit a model that’s so deep in our unconscious that we don’t notice it’s there.

If we are to avoid the trap of being limited by an inappropriate model, then we need to know more than one model.  And for the unconscious models, we need to find ways to rethink the situation according to conscious models.

In fact, this latter use is the value I find in the Myers Briggs Type Indicator model that so irks Brian. Brian would like for people to discard MBTI because it’s not “true” and doesn’t predict peoples’ behavior well. I, on the other hand, don’t expect either of these things from MBTI. It only aspires to be a model of preference, not behavior. While it often gets misapplied for things such as predicting what career path a person should take, that’s not, as far as I know, an intended use. And I don’t believe it’s “true” in the sense of corresponding to entities in the human psyche. Instead, it’s “true” in the sense that it corresponds to human observations, much as putting a cookie sheet in the oven does. I’m not even convinced that the preferences indicated by the MBTI are constant. I wonder if my preferences change slowly over time, and if they sometimes change rapidly and suddenly in response to the situation.

Whatever the faults of the MBTI as a model for people, it helps me to rethink the application of my unconscious models. As an introvert, my unconscious model might label an extravert as pushy and self-absorbed. Re-evaluating the situation in the light of MBTI, however, may suggest to me that they’re merely thinking out loud. As an NT (iNtuitive-Thinker), it’s easy for me to jump to the conclusion that the solution in my head is both correct and obvious. Realizing my preferences helps me to realize that it is unlikely to be obvious to others, and that I should test its correctness with some data.

We would do best if we always beware our implicit trust in our models, especially our deepest and most closely held ones. These are the models that allow us to act immediately and “instinctively.” But it is the model we don’t question that will most likely get us into trouble. From time to time, especially when things are not playing out to our liking, we can view the same situation in light of multiple models and see if they give us different insights.

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

Michael Feathers has just written a post on The Carrying-Cost of Code: Taking Lean Seriously.  He says,

No, to me, code is inventory.  It is stuff lying around and it has substantial cost of ownership. It might do us good to consider what we can do to minimize it.

I’m not sure I can see the analogy of code that’s in production to inventory.  Code that hasn’t shipped, yes.

But all code is a liability, I think.  When code is in production, then it’s offset by the asset that is the functionality.  Whether or not the net is positive is another question.

There’s no doubt to me that code, whether in production or not, has carrying costs that are larger than generally realized.  Perhaps it’s a depreciating capital expense?

Carrying costs are larger than we think. There’s competitive advantage for companies that recognize this.

It’s something that takes up space.  It takes maintenance.  It takes attention.  It does have a substantial cost of ownership–larger than we think.

The analogies may be failing me, but I think Michael’s sentiment is correct.

The source code for this episode is available here. Visit the Let's Play archive for more episodes!

Many thanks to Danny Jones for figuring out the HD Youtube embed code.

Comments

On May 24th, I'll be participating in a PMI-sponsored debate with Alistair Cockburn about the merits and limits of certification. Alistair is someone I have great respect for--he's responsible for introducing me to the Agile community--and we fall on opposite sides of the certification debate. Alistair is heading up the ICAgile certification program and I... well, I've had strong words to say about certifications.

I want to enter this discussion with a clear understanding of the plusses and minuses of certification, so I'd love to hear your arguments--and particularly experiences--for and against certification. Let me know what you think!

PS: I haven't been able to find a link to the PMI event, but it's on May 24th and you can see it on the Agile Community of Practice calendar.

Comments

In the past few months I’ve seen the following question several times: “Who’re the Agile/Scrum Guru’s or Thought Leaders?” The urge to ask the question is good but misplaced. I assume it comes from people who’re new to Agile and want to know where to get good ideas. Inevitably people reply with long lists of people.

There is just one problem, the whole concept of thought leaders is alien to Agile thinking. We promote the value of cross functional teams and always assume that even the least experienced person has a contribution to make even if its asking a question.

I learn from people inspite of their names. I’ve learned things from Ron, Alistair and other well known people, but I’ve also learned from lesser known people. When you start paying attention to names your narrow your thinking. Radical suggestion tell us which non-guru you’ve learned something from in the last week? (in my case Charles, Heather and Steve). Read widely and ask if the ideas fit with your understanding of Scrum and Agile. When you encounter a new idea go back to the Agile Manifesto and its accompanying Principles. Ask yourself will this new idea help you deliver high quality software and delight your customer sooner.

Frankly I focus most of my reading and thinking about outside the Agile community now. My personal energy is focused on understanding people through the lens of Psychology, Cognitive Psychology and Neuroscience.

Lets stop gazing at our navels.

If you must have a guru look up Brian Marick (see: Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism) he will be happy to have a few followers :-)

Everything should be made as simple as possible, but no simpler. — Albert Einstein

Dave Rooney recently bemoaned on Twitter about how complicated people make things, pointing in particular to a thread on the scrumdevelopment yahoogroup.  It’s a thread that started with a question about a team wanting to adjust the Sprint Backlog in-sprint when something changed about their capacity to complete the work.  From there it spawned a long discussion about various ways to estimate the work and commit to it.

To me, most of these approaches to estimation are more complicated than is necessary.  Some go into detailed calculations that are far more complicated than what most teams do.  I could tell you a really simple technique, but I suspect most teams aren’t ready for extreme simplicity, yet.

That’s OK with me.  If they spend a bit more time and effort figuring out what they can do in the next sprint, that’s probably not a big deal.  And as they notice they’re not getting much value from the time they spend estimating, they’ll want to do something about it.  At that time, it will be important enough to be the next issue to tackle.

One of the proponents of an especially involved calculation said

The other thing I many have not mentioned previously is that in this company, this senior guy (an American) does not like it when people disagree with him and is known for having got people fired for not agreeing with him…This the reason why everyone is careful when they are in planning poker, which, for this reason, does not work as intended as an open discussion opportunity…

Oh, dear! This estimation calculation is a technical solution to a people problem.  While it may get them through the planning meeting with a selection of stories to be implemented, it doesn’t deal with any of the myriad of problems caused by such a bully.

When one prima donna throws his weight around intimidates others, you’ll never have a Real Team.  People can’t rely on each other.  They can’t share their thoughts, ideas, and misgivings.  Agile development is a team sport and such behavior is the death of teamwork.

Let’s face it, if you’ve got fundamental problems like this, then the estimation strategy doesn’t amount to a hill of beans.

Let's start with a fairly common question:

"Ouch, we're so behind with the project, what on earth shall we do?"

A response that is just as common is:

"Add more resources! Increase head count as much, and as fast, as possible!"

Honestly, how many people have responded so spontaneously?

Over 35 years ago Frederick Brooks wrote the book "The Mythical Man-Month", where he shows a formula for how to calculate how much the delay increases in a delayed project if you add one more person. How is it, then, that so many think it'll help?

What is even worse, apart from the delay being likely to increase, is that projects with too many people involved have a tendency to lead to a large code base. It is to be expected as a law of nature. It can of course be too large a code base for many other reasons too, but this is one important factor.

Each developer would naturally like to be productive and, just like the others, add X number of lines a day. So the growth of the code base size is directly related to the number of developers.

Even if I am allergic to projects that become overcrowded over time, there's something I dislike even more. That is projects that start to be overpopulated on day one. On top of the problem with too large code base there is an additional problem with X amount of people that are waiting for something to do, which costs a lot to no avail. Pretty soon everyone starts to create their own architecture. Similarly, requirements are created wildly on speculation. The project is simply in a very bad position from the outset.

Why does this happen? I think one reason could be that many people see software development as a keyboard intensive task. Sure, it never hurts to be fast on the keyboard, but it is mostly because the keying should not distract the thinking and the mental models.

If you are twice as fast at the keyboard as your colleague is, are you twice as good as your colleague?

Perhaps, but if you believe a quote from Bill Gates where he should have said that a super programmer is worth 10 000 times higher salary than a mediocre one, your double speed keyboard skills should be a very small advantage. Probably other stuff is way more important.

When I think about it, we have a saying for this phenomenon; the adage is probably much older than Brooks's book and it goes: "too many chefs spoil the broth." So, avoid adding loads more head count on the problem at all costs.

(First published in Swedish here.)

We use models to help us simplify the situations we’re viewing, so we can reason about them more easily.  I’ve often found this to be enormously helpful.  It’s important, though, to remember that this is only a model.  We can use a model for understanding, and even for making predictions.

We cannot substitute the model for the thing that it is modeling, though.  The map is not the territory.  When we use a model in contexts where it doesn’t apply, it’s likely to lead us astray.  Similarly, when we mistake an illustration of the model for the model itself, we may make inferences that the model doesn’t support.

For example, a couple of my friends have recently tweeted complaints about the Satir Change Model in response to such misuses.  I find the Virginia Satir’s model extremely useful, and would like to disassociate it from these misuses.

Bas Vodde said,

“I come to dislike the Satir change curve, it seems to include the assumption that every change is good.”

In what approximates discussion on Twitter, it seems that the root of his problem is that diagrams illustrating the Satir Change Model commonly show a new status quo with “higher performance” than the old status quo.  Such an illustration makes sense if you’re talking about trying to introduce a change to an organization.  Few people introduce change intended to decrease performance.

If the Foreign Element is, instead of a new business process, the loss of an arm, you might well expect a person’s performance to go through the same plummeting chaos before they find a Transforming Idea that allows them to reach a New Status Quo.  You might also expect that the performance level of the New Status Quo will be less than that of the Old Status Quo.  There are things you can do with two arms that you can’t do with one.  And it’s unlikely that someone would choose losing an arm as a strategy to increase performance.  Bas is right that not all change is good–even when it’s well-intentioned.

There’s also the question as to what is being measured as “performance.” This is usually a conceptual illustration rather than some particular measure or estimate of performance.

Brian Marick said,

“Dammit, some people change because it’s fun. Not everyone changing can be modeled by a dysfunctional family! #satir #rant #overabstraction”

This statement was apparently a reaction to another tweet which said,

“Change cannot occur until the pain of the status quo is greater than fear of change. In work and in life.”

I’m not sure what connected this to the Satir Change Model for Brian, other than it has the words “change” and “status quo.”  I suppose the statement might even be generally true, but I agree with Brian that it mis-characterizes many situations.  For the vast majority of changes that we freely choose, there may be no fear at all, and the “pain” might be better termed “boredom.”  This would still technically fit the statement above. Somehow it sounds very different when you say “Change cannot occur until the boredom of the status quo is greater than zero.”

In general, the Satir Change Model applies to change resulting from destabilizing external events.  That’s not the entire universe of change.  I agree with Brian that, if you’re talking about voluntary, joyful change, then the Satir Change Model is probably of little use.  I would look to models about learning rather than about change.

For one of the examples that Brian mentioned, that of changing to programming in Clojure, you could probably fit the model to the events. Even though this change is a self-induced Foreign Element, I suspect that Brian’s programming productivity plummeted for a time.  Then, as he began to understand Clojure and internalize how to use it, he got progressively, but inconsistently better, until he finally reached a level of competence in the new language.  (Note: I’m envisioning this based on my experiences at switching programming languages.)

But while you could apply the model, I’m not sure what benefit it will provide.  Remember, It’s Only A Model.

Thanks, Bas and Brian for the impetus to write this article. I hope that I haven’t misrepresented your views. I realize that Twitter is a difficult place for nuanced conversations.

Brian Marick challenged me for an expression of joyful change, especially related to software development, based on the teachings of Virginia Satir.  As discussed in my previous post, he’s come to associate the combination of “Virginia Satir” and “change” with pain and the following:

…blaming… …placating… …anger… …guilt… …stress… …resistance… …denying… …avoiding… …blocking… …deny… …avoid… …anxiousness… …vulnerability… …fear…

This post is, in part, to demonstrate to him that the work of Virginia Satir is not focused on the negative.  Mostly it’s to share, and rejoice in, the freedom we have to reach our goals.

The Five Freedoms

The freedom to see and hear what is here instead of what should be, was, or will be.

The freedom to say what one feels and thinks, instead of what one should.

The freedom to feel what one feels, instead of what one ought.

The freedom to ask for what one wants, instead of always waiting for permission.

The freedom to take risks in one’s own behalf, instead of choosing to be only “secure” and not rocking the boat.

This passage comes from Virginia Satir’s book, Making Contact.

It is the fifth freedom on which I want to focus, for this is the freedom of joyful change.  I can try new things, taking the risk that they might fail.  If they do, then I own that failure. But that risk of my failure is balanced by the likelihood of my success.  I weigh the balance and make my own choice.

I do not need the protection of others.  I do not need someone else to make the decision and force a change on me, or deny a change from me.  The choice is mine alone.

As long as failure is only a risk and not a sure thing, then there is also a chance of success.  That success is also mine.

Success often does not come with the first attempt.  Often we must fail a little.  We may try small experiments, so as not to bet the farm on a single roll of the dice.  We risk that which we can afford to lose.  If we lose, we learn from it and try with this new knowledge.  This is a strategy almost sure to produce success in time.

And what a sweet success that is.  Success not handed to us by someone else’s choice.  Success not borne of attempting the sure thing.  But success achieved by our own efforts and intellect.  Success that teaches us far more than any instant success.

And this success, and new knowledge, is all ours.  Isn’t that a joyful thing!

How long does it take to take a team from where they are to becoming an Agile team?  Of course, that depends on many things, including where they are and how badly they want to succeed at Agile.  It’s reasonable to think they can make a transition in six short months.

If you’d like your team to become Agile, give me a call to find out how I can coach the team to do that for about the same cost as contracting a senior developer.  If your team has already made a transition, but you find that you’re not as effective with Agile as you’d like to be, I can coach using the same framework to help you reach that effectiveness.

Shopping in our local Grocery Store (Farm Boy) on a recent Saturday made me realize what a good job they do Limiting Work in Progress (WIP) and Self Organizing. Driving into the parking lot with my 4yr old, I was dreading the busyness of the store. When I got in the place was packed, trying to manoeuvre even a small cart with a 4yr old driving was quite the experience. I had expected to the checkout experience to be easily 10 minutes long, an eternity even with the best behaved child.

When I entered the store there were only a few people on cash and the lines seemed to be building, by the time we were ready to checkout half an hour later all 9 cashes were open and we waited less than two minutes.

What happened? A couple of conversations with cashiers have helped me piece together the key points:

• They all recognize that Farm Boy doesn’t make money until you’ve paid – a Customer with unpaid groceries is Work In Progress. After all if you only have a few items and see a 10 minute line up you might just leave. Especially if the 1-8 items queue is also deep.
• If there is a line up they just start cashiers just start opening lanes until the bottle neck is cleared
• Many of the staff can work the cash so you’re rarely stuck waiting for another cashier
• Staff don’t wait to be told to open cashes they just do it
• When demand ebbs the cashiers start to close and return to other work

So effectively they’ve seemed to discovered the Theory of Constraints (TOC) and they Self Organize to eliminate the bottleneck. Their system is informal, but even without sophisticated measurements you can still observe and eliminate bottlenecks. Compare this to another large Canadian grocery chain where I often line up for 10+ minutes, just waiting to get to the front of the line. Guess which store gets more of my business?

In the software world QA, especially when all the tests are run manually. is often the constraint we find. So we need to take steps to eliminate the bottleneck:

• Automate your Regression Tests, so that you have a minimal (if any) manual regression work to do
• Train everyone on the team in the basic of QA.
• When work builds up in QA cease writing new code until the existing code has been tested and the tests automated.
• Start write your application using Acceptance Test Driven Development

Eventually QA stops being the bottleneck, at which point we re-examine the system to see if the bottleneck has moved again. When that happens take similar steps all over again to eliminate the next bottleneck.

What Bottlenecks have you observed in your grocery store? Your development process?

Another Theory of Constraints post: “Theory of Constraints in Software Development”

That’s the Way We (Used to) Do Things Around Here – Jeffrey Schwartz, Pablo Gaito, and Doug Lennick team up to write about understanding the mechanics of change through the lens of neuroscience. As many of you will know this is topic near to my heart.

A brilliant brainstorming technique – Edward Boches – explains how to improve brainstorming through silent listing. I’ve used this and related approach of working in pairs on a number of occasions. Both approaches are faster and seem to generate better results than traditional approaches.

People Know When First Impressions Are Accurate – apparently we know when we’re right.

The Whole Team Approach in Practice – Lisa Crispin visits Energized Work and talks about the great team and their focus on Continual Improvement and the focus on Quality.

Advantages of Limiting your WIP – Matt Wynne – from the archives, a story about the problems his team was having and how Limiting WIP held smooth out delivery.

Basic Story Testing Styles – Charles Bradley, examines a number of different ways of expressing Acceptance Criteria. He mentions five approaches: “Bullet Points; Test with…; Test that…; Given/When/Then; Specification By Example” giving pros and cons for each. Which style(s) do you use and why?

A day in the life of an acceptance tester – Cheezy of LeanDog fame helps see how he moved from acceptance criteria to code. A great place to start when you’re trying to get your head wrapped around ATDD.

At the last London XpDay, some teams talked about their “post-XP” approach. In particular, they don’t do much Test-Driven Development because they find it’s not worth the effort. I visited one of them, Forward, and saw how they’d partitioned their system into composable actors, each of which was small enough to fit into a couple of screens of Ruby. They release new code to a single server in their farm, watching the traffic statistics that result. If it’s successful, they carefully propagate it out to the rest of the farm. If not, they pull it and try something else. In their world, the improvement in traffic statistics, the end benefit of the feature, is what they look for, not the implemented functionality.

I think this fits into Dave Snowden’s Cynefin framework, where he distinguishes between the ordered and unordered domains. In the ordered domain, causes lead to effects. This might be difficult to see and require an expert to interpret, but essentially we expect to see the same results when we repeat an action. In the complex, unordered domain, there is no such promise. For example, we know that flocking birds are driven by three simple rules but we can’t predict exactly where a flock will go next. Groups of people are even more complex, as conscious individuals can change the structure of a system whilst being part of it. We need different techniques for working with ordered and unordered systems, as anyone who’s tried to impose order on a gang of unruly programmers will know.

Loosely, we use rules and expert knowledge for ordered systems, the appropriate actions can be decided from outside the system. Much of the software we’re commissioned to build is about lowering the cost of expertise by encoding human decision-making. This works for, say ticket processing, but is problematic for complex domains where the result of an action is literally unknowable. There, the best we can do to influence a system is to try probing it and be prepared to respond quickly to whatever happens. Joseph Pelrine uses the example of a house party—a good host knows when to introduce people, when to top up the drinks, and when to rescue someone from that awful bore from IT. A party where everyone is instructed to re-enact all the moves from last time is unlikely to be equally successful¹. Online start-ups are another example of operating in a complex environment: the Internet. Nobody really knows what all those people will do, so the best option is to act, to ship something, and then respond as the behaviour becomes clearer.

Snowden distinguishes between “fail-safe” and “safe-fail” initiatives. We use use fail-safe techniques for ordered systems because we know what’s supposed to happen and it’s more effective to get things right—we want a build system that just works. We use safe-fail techniques for unordered systems because the best we can do is to try different actions, none of which is large enough to damage the system, until we find something that takes us in the right direction—with a room full of excitable children we might try playing a video to see if it calms them down.

At the technical level, Test-Driven Development is largely fail-safe. It allows us, amongst other benefits, to develop code that just works (for multiple meanings of “work”). We take a little extra time around the writing of the code, which more than pays back within the larger development cycle. At higher levels, TDD can support safe-fail development because it lowers the cost of changing our mind later. This allows us to take an interim decision now about which small feature to implement next or which design to choose. We can afford to revisit it later when we’ve seen the result without crashing the whole project.

Continuous deployment environments such as at Forward², on the other hand, emphasize “safe-fail”. The system is partitioned up so that no individual change can damage it, and the feedback loop is tight enough that the team can detect and respond to changes very quickly. That said, even the niftiest lean start-up will have fail-safe elements too, a sustained network failure or a data breach could be the end of the company. Start-ups that fail to understand this end up teetering on the edge of disaster.

We’ve learned a lot over the last ten years about how to tune our development practices. Test-Driven Development is no more “over” than Object-Orientation is, it’s just that we understand better how to apply it. I think our early understanding was coloured by the fact that the original eXtreme Programming project, C3, was payroll, an ordered system; I don’t want my pay cheque worked out by trying some numbers and seeing who complains³. We learned to Embrace Change, that it’s a sign of a healthy development environment rather than a problem. As we’ve expanded into less predictable domains, we’re also learning to Embrace Failure.

I'm presenting two sessions at the Norwegian Developer Conference in Oslo. This first one is "Evolutionary Design Illustrated," a detailed discussion of evolutionary design, with code samples and visualizations of how projects I've worked on have changed over time. It's on June 8th from 17:40 to 18:40.

My second session is "We Deliver Business Value," a focused session on the planning techniques required to deliver business value on a regular basis. Techniques I'll discuss include iteration planning, being "done done," velocity, slack, minimum marketable features, working on one thing at a time, and risk-adjusted burn-up charts. This session is on June 9th from 10:20 to 11:20.

Comments

I've been writing the developer chronicle for Computer Sweden (in Swedish) for a couple of months. I'm going to republish the articles as blog posts. The first one is called "Lasagna is not a good role model".