Wanted: Software Development Leader

One thing led to another and there I was contemplating the job req for what I would look for in (and what I strive to be as) a software development leader.

Experience:
- Development experience - preferably within the last decade

Aptitude:
- Can tell a crappy architecture from a sound architecture
- Can tell a crappy implementation from a sound implementation
- Can tell the difference between someone who is busy and someone who is productive
- Can discern the difference between a good candidate for a position "on paper" and a good candidate for real
- Demonstrates a deep understanding of what quality means for a software product (including non-functional requirements like performance, supportability, and extensibility)
- Can tell when an architect, developer, QA, BA, or business partner is blowing smoke up his hind quarters
- Can speak the dialect of business - ROI, NPV, customer acquisition cost
- Can relate to business stakeholders and build collaborative relationships
- Can connect to team members on a personal level
- Has a good sense of humor
- Understands the difference between a prototype and a production application

Attitude:
- Will call out a crappy architecture and drive change
- Will call out a crappy implementation and drive change
- Will call out the busy-bees and the smoke-blowers
- Will demand demonstrable quality (including non-functional requirements)
- Will demand reasonable tests (unit tests, component tests, system tests)
- Does not suffer fools gladly
- Will not sit through a PowerPoint that depicts supposed progress without demanding demonstration of said progress
- Will not abide bubble gum and duct tape solutions to production (or development) defects
- Demands continuous improvement
- Demands root cause analysis (5 why's)
- Demands customer involvement in product development
- Continuously seeks to improve efficiency by asking "why" and "how can we do this more efficiently" (e.g. - PMO requirements for excessive documentation)
- Is willing to fight for the resources required by the team to deliver
- Cares deeply about the team
- Cares about the career development of team members
- Cares deeply about product quality
- Will celebrate true success with the team (no gratuitous applause please)
- Will always give credit to the team for success
- Will remove team members when necessary
- Has a coaching mentality
- Is willing to get hands dirty (writing code, writing/running/debugging tests, fetching pizza)
- Is always available to the team
- Exhibits patience, when appropriate
- Exhibits impatience, when appropriate

Integrity:
- Tells the truth - for instance about project status
- Is clear to team members on expectations and performance on a regular basis (not just at review time)
- Is willing to stand up and fight for the team

Ah... it's late. that's as far as I got. I felt like the integrity section was short, but many of the integrity issues bled into attitude. What did I miss? What do you disagree with?

Dysphemism and cross register synonyms

I love learning new words. During a conversation in our open-space collaborative software development team environment last week, I used the term euphemism incorrectly. Thanks to Steve Moyer for pointing out the error of my ways.

Apparently, the subtlety is that a euphemism substitutes a less harsh term for another term. I can't remember what I said, but it was akin to saying "The head" was a euphemism for a restroom. Since "The Head" is harsher, it was not a euphemism, but a dysphemism.

Had I said that "Powder Room" was a euphemism for "The Head", I would have been correct in my usage.

By the way, these two terms are considered cross-register synonyms. Cross-register synonyms vary across some orthogonal degree on their subject. For example - dysphemism and euphemism are cross-register synonyms that vary in their degree of harshness. I found a good description of this particular cross register synonym and cross register synonyms in general here: http://www.linguistics.ucsb.edu/faculty/cumming/ling50/euphemism+dysphemism.htm.

Agile Pants

I found these "Puma Agile Pants" when doing a search on Amazon for agile literature:



Agile Pants... don't pair without a pair.

Test Lookup

Kris Kemper has a nice blog entry on finding tests related to code you are changing that lines up well with a concept I've been pondering today.

I have a colleague who asked me to look over a rather large C# software system, made up of many (>20) .NET projects. In the best agile way, he is relying on his elegant structure and well-named/concise tests to serve as the documentation for anyone who might try to understand the code.

Being self-aware, my colleague understands that he is too close to the subject to be able to determine "understandability" of the code by others. So he asked me - an outsider - to take a look. I think he was also hoping that if I - as a supposedly post-technical project manager - could understand it then he could brag that his code was so understandable that "even a PM can understand it". (Reminds me of those old Life cereal commercial where Mikey, who never likes anything, likes the cereal and his siblings declare "Even Mikey likes it !")

So I picked a class at random. Nice short methods, but reading the code didn't give me as much insight as I hoped. Then I thought... ah the tests. I'll read the tests. So I right clicked, searched for usages, and navigated to the location that had "unittests" in the name. Then I thought - wouldn't it be nice if I could right click on a method name, or a class name, and - instead of asking for usages - I could ask for tests.

That got me to thinking - what would constitute a test? A unit test that simply invokes a method or instantiates a class may just be using it for setup or for supporting scaffolding. But then wouldn't that be a smell? Shouldn't that irrelevant setup junk be in a setup, or injected or...

Anyway, Kris gets to much of these points... my main extending thought is simply - wouldn't it be nice if the tools could help us navigate to tests and sniff out those smells (rather than force them by removing the method, as Kris's technique suggests)?

Halftime

In American football, the game is divided into four 15-minute quarters. There's a short break between the first/second quarters and then between the third/fourth quarters, but the middle transition is longer. It's called halftime.

During halftime, teams return to their locker rooms for respite, but more importantly, coaches use it as an opportunity to adjust the game plan and motivate the team.

Much is made of the halftime break in football. I think the concept is equally useful in ... agile software development.

I introduced halftime on a couple of agile software development teams to step back and look at iteration (or sprint) goals at the midpoint of the iteration, to see where we stand, and adjust our approach. It has been a good opportunity to refocus, adjust sprint content, and address issues.

In a recent halftime, I pointed out that the scope for the iteration was 63, and that we had burned up 20 points. I used the analogy that our opponents had 63 points and we had 20 and that we need to figure out how to make up the difference. We adjusted our approach, removed some scope and went on.

If you're stuck in a project where the iterations are too long (e.g. four weeks), suggest introducing a short halftime (30 minutes) to refocus the team and adjust. Even if you're in 2-week sprints, doing a checkpoint/halftime at mid-iteration can be useful. It's also a good segue into shorter iterations.

Is it ever NOT what it is?

The phrase "It is what it is" bugs me. It falls into the category that includes phrases/clauses like "Going forward..." (as if you could go backward) or "To be honest" (an admission that what you're about to say is a departure from the norm).

I just heard a new one in the concierge lounge at a Marriott: "It'll be what it'll be". I think it was related to sports.

So, here are some suggested enhancements to the dialect:

* It won't be what it won't be
* It will never be what it never could become
* What wasn't, wasn't
* To be or to be, that is the [rhetorical] question
* It probably wasn't meant to be because it wasn't meant to be

I'm sure there are more clever opportunities here.

Agile adoption by geography

I wonder if there is a geographical distribution to the adoption of agile philosophies. To find out, I used Dice's job listings as a proxy to determine percent of postings that matched the word "agile" by City.

Suprising to me, Salt Lake City seemed to take the honors @ 12%. Next tier: Richmond, Seattle, Portland, OR, San Fran, Denver, Austin, Raleigh, all between 5% and 9%. The remainder can be seen on the graph. It's probably a bit too small to see, but if you display it individually, you should be able to clearly see the list of cities and the rough placing of the cities within the distribution.

Results:

Open Command Window Here

I spend a great deal of time at a command prompt on my Windows system. I recently found a a nice little Windows XP PowerToy that allows you to right click on a folder within windows explorer and then click a menu item to open a command prompt with the directory set to the folder you right-clicked on. How did I live without this for so many years?

Go to http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx and download the "Open Command Window Here" power toy. (I actually did it by hacking the registry, but avoiding regedit is good practice).

Linked In Recommendations

To what extent do you think your Linked In recommendations of others, and others' recommendations of you reflects on you?

An old colleague requests a recommendation - you kind of know him/her, but not well. Or maybe you know him/her, but don't respect his/her work. Do you recommend? An incompetent ex-colleague offers a well-articulated recommendation for you. Do you accept?

NO !

Don't do it.

Maintain a high bar for your recommendations so that they mean something. Turn down requests for recommendations for anyone who you wouldn't hire yourself - into your own department, or, better, into your own company. I think the latter is a pretty good rule of thumb.

Don't accept recommendations from people who you would not recommend yourself. The volume of recommendations is not important; it's the quality - both from how well they are articulated and from the standards of the source of the recommendation.

I was thinking at one point of asking someone for a recommendation. This person has a title that would have made for an impressive recommendation. Then I saw that she recommended a person for whom I did not have high regard. I decided against asking. Why? My recommendation would have been devalued by the other recommendation. Granted - not many others would have known or understood... but... I would have known. And others' may have learned.

I want to be recommended only by people for whom I have the highest regard and who I would have no hesitation recommending.

And I want to be recommended by folks who have recommended others who have achieved a high bar of performance.

And I insist on only recommending those who I feel I can honestly promote - based on my interactions and experience.

You too, should maintain high standards in your approach to recommendations.

Interesting question on LinkedIn:

What is the difference between an approach and a methodology?

What is the difference between an approach and a methodology?
Is it true that approach is just an idea and is less proven while methodology would normally start as an approach but is eventually time tested and proven? What takes an approach to convert into a methodology?

Here was my response:

I think of an approach as the foundation, or underlying principles that guide you in how you get your work done. I'm an agile software development proponent, and I strongly support the approach/philosophy expressed in the agile manifesto (http://www.agilemanifesto.org).

Methodologies, to me, prescribe more detailed steps to take to accomplish goals. Scrum is, in essence, an agile approach (the mantra is "inspect and adapt"), but it gets applied in many instances as a methodology (Though shalt provide a burn-down chart).

Methodologies excuse people from thinking about underlying principles. If you follow the rules for making a burndown chart, your methodology has been followed, but if you are avoiding opportunities to gain greater insight by taking a different tack, you are avoiding the approach/principles.

An analogy to cooking - using a methodology is like following a recipe - with your measuring spoons/cups at hand, precise temperature measurements, etc. Using an approach/principle requires more understanding of the ideas... the fact that sauteeing onions releases liquid gives you some information that allows you to adjust to other aspects of your cooking (like don't try to brown your meat while sweating your onions, because the released liquid will cause your meat to steam instead of brown).

In sum, I would say an approach requires more thinking and adapting, while a methodology provides more training wheels to give you procedures that you may not be able to link to the underlying approach/principles. I think that beginners require methodologies (like beginning cooks require recipes) while experienced folks can apply fundamental principles based on sound judgment (like experienced cooks simply press down on the steak to assess doneness instead of measuring the time).

XP Game in Fort Lauderdale

I facilitated a lego XP game for the Agile SIG of the Florida .Net user group at the Microsoft campus in Fort Lauderdale tonight - great fun ! Thanks to two of my colleagues from Bayview for playing the customer roles: Howard Sims (project manager/iteration manager) and Samir Patel (development manager).

Dave Noderer blogged in real time and took a video.

It's fun to watch adults get so engaged with legos.

28nd of the month

Received from Linked In at 12:10 am EST on May 29 (9:10pm May 28 in PT terms)

LinkedIn is currently unavailable while we make upgrades to improve our service to you. We’ll return around 9:30pm (PT) May 28nd, 2008.

We apologize for the inconvenience and appreciate your patience. Thank you for using LinkedIn!

The 28nd?

9:30 PT update: new message:

We’ll return around 9:45pm (PT) May 28th, 2008.

I like the noncommittal "Around" as a qualifier...

A semi-clean, well-lit, open-place

These are a few pictures of my team room. I love this place - high ceilings (with plenty of space for information radiators), lots of card walls, lots of white boards, movable filing cabinets, and a few cubes for the stationary folks. This is really a retail space the size of which you could probably house a basketball court.

We had an open space in the front that isn't pictured with a couch, some beanbag chairs, a conference table, a projection screen with a projector. We almost never had to schedule meetings in the limited conference space in the main building again.

A good view of most of the card wall. This is fairly old - we now have flipcharts with our historic burnup charts posted over the card wall so we can see our trends.

This gives a good view of the dimensions of our space.

The little white box area in the back is a portable office - 10x10, with privacy for personal phone calls, personnel meetings, etc.

The continuum

Is your software development approach agile or not?

Are you pregnant?

These are different questions. The latter question can be answered in a straightforward fashion... either you are or you aren't.

Using an agile methodology is a different question. Or an agile approach. Or an agile philosophy. Are you agile... yes or no?

The answer is almost always somewhere in between. You can use agile techniques (pairing, continuous integration, TDD, refactoring, user stories (following the INVEST principle), standups, abstract estimation techniques (e.g. points), iterations, velocity measurement, etc... in any degree. But what combination makes you "agile" ?

I think the answer is never yes or no, but the degree to which you espouse, promote, and enact agile approaches.

I think the continuum concept applies much more broadly than folks presume. Is your team "self-directed"? That's not a yes or no answer either.

Is being agile a good thing? Yes. Consider any course of human activity... being agile is better than being less agile. Am open to contrasting opinions, but I can't imagine an argument espousing being less able to adapt to change as being preferable. The chunked-up question is ... how useful are agile techniques in getting software delivered? I argue that the answer is "very". Why? The first answer lies in the fact that you NEED to be able to adapt to changes in your environment. Guess I'll save the remainder of the argument for a follow-up.

Top Chef Leadership

I'm becoming addicted to Bravo Network's "Top Chef" show. OK, so I'm generally addicted to cooking shows, but have, heretofore, confined my addiction to the Food Network.

I feel the role of a chef is a melding of cooking and leadership. Top Chef seems to focus more on the cooking aspect, and the extent to which folks step up in the delivery of good food. I think this misses a large part of the role of a chef. It's not enough to be able to deliver high quality food. You have to be adept at inspiring the other cooks in your kitchen to deliver.

Nikki, one of the chefs who was eliminated recently, was canned mostly because the menu was Italian, and she didn't exert leadership in driving the menu; her forte' is Italian food. So her inability to exert leadership was pivotal for her. One of the guys who escaped elimination focused on one dish - vs. another who went to the mat for the team in doing almost everything else.

When the elimination was announced, other chefs shook their heads. They knew that the one-dish guy should have been the one to go...

An ex-colleague of mine regales me of similar stories from her company. Promotions that make mouths gape, people surviving layoffs when more capable people are released. She sees some of the same aspects from "Top Chef" in that company. One-dish wonders survive because they play the game better than others. I sometimes wonder why "Top Chef" doesn't ask the other cooks directly about who should be eliminated.I guess that's show business.

The "Z" Word

Zealot: A fanatically committed person.

Hmmm... good or bad?

It suggests an unfavorable hue to me. I've seen this word used before to describe folks' commitment to a particular technology platform. He's a .NET zealot, or a Ruby zealot, or Zope zealot.

In the case of technology (most cases?) zealots prefer their approach/solution to all(?) others. For instance, how could you turn back from having written significant code in Ruby to doing plain old Java? Those who aren't writing in Ruby have simply not yet been shown "the way".

I consider myself fairly pragmatic and reasoned, but I seem to have acquired the dreaded tag at work. My zealotry is in an agile approach to software development. (English zealots - note the use of the article "an" vs. the article "the" - it's an important distinction).

I'm measuring whether I should shrug the label off, welcome it with open arms, or fight it. Actually ... that's not quite accurate. I'm pretty sure shrugging it off will not be my chosen response.

At some level, I feel it's like being called a "rationality" zealot... or a "damned common sense practitioner". I'm a "Sunrise Zealot" damn it ! I find the agile manifesto chock full of common sense. (OK, here I see... manifesto => zealotry... maybe if Kaczynski and Marx hadn't also used the term manifesto we'd be in better shape).

Some software development professionals unabashedly promote a "waterfall" approach using a document-centric "SDLC" lifecycle. Templates are created to capture every known aspect of the project. Stakeholders are forced to "sign off" on documents, which form a contract-like agreement to what will be delivered. Of course, a change request process is included, which affords the opportunity to create change documents which are then signed-off.

Agile is not binary... agile is a continuum. There are agile development techniques and agile project management approaches. You can use any of them - or not. The use of one technique does not an agile project make.

Agile, chunked up, (to me anyway) is about focusing on the delivery of quality software over and above delivering service to a process. The customer is not a color-copier and a list of signatories to a spec. The customer is the user of the software; the organization that benefits from working, functional, valuable software. No organization prefers reams of documents over working software. And those that argue voluminous documentation better leads to working, functional, valuable software should start measuring the extent to which those documents are implemented as stated. After all, not many approaches refine their processes to eliminate waste (ala Lean).

One should question the value of accepted process (using the Five Whys, for example) in order to assess the usefulness of documents and other artifacts to ensure they stand the test of reason.

OK, my writing therapy is done. I hereby embrace the label "Agile Zealot". I also accept the following additional labels: "Fatherhood Fanatic", "Beer Lover", and "Education Enthusiast".

I do like the alliteration angle though... may I please be an "Agile Aficionado" instead? Ah, but perhaps that doesn't quite capture the intensity of my rapture.

Receiving Feedback

My last post on feedback was on giving constructive feedback. Here, I'll focus on receiving feedback.

In the question of feedback - what, where, when, why, and how - the receiver of the feedback may not have control over many of the elements. To some extent, your ability to receive feedback effectively is determined by how effectively the provider shares it. But you do have some control.

If you have a regularly scheduled one-on-one with someone, or performance review meetings, you should always be prepared for feedback. Prepare yourself for these meetings with an attitude adjustment that suggests "I am open and willing to receive feedback constructively so that I can improve". If you enter meetings with this mental preparation, you are way ahead of the game.

Another attitude adjustment that helps you to receive feedback openly is to consider the alternative. That is - what if the person providing this feedback just stayed quiet? I assert that you always gain information and knowledge (even if it's simply an impression of the regard that the giver of feedback holds for you). Treat it as an information gathering exercise. You will learn

1. What that person thinks about your behavior - or even you


2. By extension, if that person holds that view, then others may as well


3. Hopefully - examples of the behavior that the reviewer deems in need of improvement


4. Suggestions of how you can improve

First, let's cover the "when" and "where" of feedback. I've already mentioned naturally occurring events where feedback will be shared. But it sometimes occurs (and should more often occur) in an ad hoc manner. If you sense that you are not in a good mental or physical place to deal with feedback at that time, it is well within your control to request a postponement of the discussion. Try something like this: "Adrian, I am very interested in hearing your feedback, but would it be OK if we schedule some time to discuss this privately - perhaps tomorrow morning? I feel like I will be in a better place to listen and take your feedback constructively at that time".

"What" feedback provided is primarily - but not exclusively - determined by the person providing feedback. If I tell Jeff that the coffee he has been providing me is too hot, that is the primary message. But if Jeff probes on what the temperature should be, what I feel the temperature has been and such, he can steer the feedback towards the constructive content he needs in order to improve. In this way, he can control the "what". In addition, he can use it as an opportunity to probe for related (or unrelated) feedback.

"How" the feedback is provided can be steered by the recipient as well. I mentioned in the "giving feedback" post that one should focus on the behavior and not the person and should provide specific examples of where the behavior needed improvement. If the feedback giver is speaking in generalities, you can steer him by asking for specific examples. If he can't provide specific examples, ask him to keep an eye out for instances in the future. Something like: "I appreciate your feedback that I'm often late for standups without providing advance notice. I can't recall an instance when I failed to notify you in advance - though I do remember the one time that I overslept, which I understand is not a great excuse. I will make every effort to be on time and to notify you if extenuating circumstances arise. If you find examples when I fail to do so, could you please notify me right away, so I can determine the root cause at that time". OK, I'm going on and on for a silly example; you get the idea.

Take notes. Sometimes - particularly if feedback is negative - our emotions cloud our ability to retain the information being provided. It is helpful to take notes to revisit once the dust settles.

Always receive feedback in a positive manner. Always thank the person for taking the time to give you the feedback - even if you disagree. We need to reward people with thanks for taking the time, effort, and risk of conflict to provide feedback. "Thank you, Adrian, for the feedback on the temperature of the coffee. Though I think I've been rigorous about controlling the temperature, perhaps if I find a thermometer for you to measure, you can let me know the temperature you find when the heat is unbearable. In this way, I can improve my coffee provisioning". (I'm getting tired of this example... from now on, no more coffee... this analogy has run its course).

Don't be defensive! Again, treat the feedback as a gift, not as an attack. You're not perfect. We all strive towards perfection, and the more input and feedback we receive from others, the more adjustments we can make on the path.

Don't fight back with criticism. "Yeah? Well, I think your burnup charts should be done in crayon, Adrian, because they're like the work of a 3-year-old."

Consider returning to the person who gave you the feedback after you've had time to digest and perhaps implement some change. "Thank you again for the feedback you gave me last week. I've been thinking about it, and have adjusted a couple of things. Can I share with you the changes I've made?" This shows a healthy dose of maturity, willingness to improve, and respect for the person who took the time to give you feedback.

I'm open to receiving [meta?] feedback on this post.

Giving feedback

Giving and receiving feedback is difficult.

Umm... well. That's not exactly correct. Giving feedback is easy. Giving constructive feedback is difficult.

For now, let’s focus on giving feedback

In my team blog, I used the example of one of my team members getting me coffee. It was meant in jest, but I won't use his name here... Let’s use that as an example in giving/receiving feedback.

Adrian: Hey Jerry… I want to talk to you about something. The coffee thing isn’t working for me. You’re not satisfying my requirements. The coffee is frequently too hot, and you’re always late with it. I’m really annoyed with you.
Jerry: I don’t know what you’re talking about. I always get that seam thing right… well, most of the time. And I can’t control the heat of coffee. And I’m not late with it. You must be delirious. I’m doing the best I can. I’m better at getting coffee than David was.
Adrian: Come on, I know you can do better. Please, let’s get that coffee thing fixed.

What’s wrong with this dialog - everything?

No. There is something good here…. There is a bit of specificity in the feedback. There are three things brought up here… the heat of the coffee, delivery timing, and the seam facing the right way.

There are many things wrong with the dialog. Adrian is making several common mistakes.

Adrian should give positive as well as negative feedback. We tend to speak up when something is wrong and focus on what’s wrong. We should find opportunities to give positive feedback in relation to the negative feedback. So something like

Adrian: Hey Jerry… Thanks for getting me coffee. The other day when I got in, I was so rushed and needed to get off to a meeting; it was nice to have my coffee right here ready to go. It made a huge difference in my day that day. One thing I’ve been meaning to mention – it seems to be too hot sometimes. Last Thursday, it burned the roof of my mouth. Was there something specific you did that day that caused it to be hotter than usual? Is there some way that we can get the temperature down a bit?
Jerry: Gee, I don’t know. It may be that you got it that day right when I returned from the coffee shop. I can’t control the temperature of the coffee they serve, but perhaps I could get some ice cubes and have them available for you. Would that work? Or perhaps if you called when you are 10 minutes away from work, I can get the coffee then, so the coffee has some time to cool.
Adrian: Those are great suggestions. I hadn’t thought of ice cubes. Don’t worry about getting them for me; I’ll just get one and pop it in if it’s too hot.

Notice the difference in the tone of the conversation. Adrian and Jerry are collaborating in finding a way to get the heat of the coffee right. Also – Adrian is being much more specific.

It is critical in giving feedback to find instances where the results were not acceptable. “Last Thursday” provides a very specific example that Jerry can think back to. Last Thursday is also relatively timely. We’re not talking about last month.

The coffee being “always late” is clearly not accurate. Again, by providing specific examples and focusing on the behavior or results rather than the person, you are more apt to get the results you seek.

Here are some attributes of effective feedback:

• Specific – rather than general. With specific examples.
• Sharing impact. Why is the behavior a problem? What was the impact of the poor performance to the team, to the company, etc.?
• Timely – both in relation to the incident/behavior, and in terms of the recipient’s receptiveness (e.g. not when the person is on their way out the door or troubleshooting a high priority production issue).
• Focused on the behavior, not the person

There are more, but this is a start.

Next time, I'll address receiving feedback.

Polyglot Programmers

Neal Ford from Thoughtworks has a good blog post on polyglot programmers. His argument is that single-language programmers are becoming a remnant of the past. To thrive in the IT environment of today, we should be open to using the right language for the job.

Attitude, Aptitude and Integrity

This is the tag line for Thoughtworks: Attitude, Aptitude and Integrity. It's printed on the back of all business cards.

As I was saying goodbye to a colleague who is moving on to another position, I told her that I felt that she exhibited these traits. I think that's a high compliment. Good luck Grace.

What's in a blog? Facts? Or Insights?

I recently viewed the blog of a colleague who was detailing a vacation he took. Much of the content was around the facts of the journey - the cab picked me up, the plane was late, etc.

I get more out of blogs that reveal insight rather than sequences of events. We bloggers should seek to convey insights rather than facts... and relegate the details to a journal or something private (still not sure what value such a collection of facts would provide).

I promise to seek to avoid regurgitating facts in favor of sharing insight here.

Stanford Entrepreneurial Thought Leaders

Marcelo Olivas turned me on to these podcasts from Stanford (also available via iTunes). These are regular talks & interactive discussions with entrepreneurs and industry leaders who visit Stanford University. I learn something new from every episode. The lessons are applicable across industries and company maturity.

They also have videos available from their main page.

Highly recommended.

Sausage Making

Otto von Bismarck – the “Iron Chancellor of Germany” in the 1800’s is said to have made this observation:

"Laws are like sausages, it is better not to see them being made."

The comment suggests that the making of sausage is a messy business. It’s better if you just avoid thinking about what goes into making the sausage and simply enjoy the results. Similarly, the making of laws is a messy business that can be unappetizing.

I use this reference quite a bit on projects. The extension to this in the software development world is:

"Software Releases are like sausages; it is better not to see them being made."

Software development sausage making includes our development approach (e.g. points, burnups, self-directedness) and in some cases, our technology choices. I have, at times, made the mistake of opening up the “sausage making” process for stakeholders to assess, critique, and well…watch. Sometimes this is appropriate. For example when getting into detailed conversations about cost/benefit analysis on technology purchases, or to determine whether those choices are in line with the corporate IT strategy, it makes sense to discuss them. Too often, though, I think we make the mistake of getting caught up in discussing the sausage making with stakeholders in many cases where, frankly (sausagely?), they might be better off not knowing how the sausage is made.

This is a classic mistake that technologists make. We get so enamored of our technology and our process, that we think everyone else must be interested in how we do our work.

We should focus stakeholder reviews more on the array of sausages we produce, rather than how they are made. Don't show iteration burnups, or discuss the nature of a "point" in the estimation process. Apply an adapter/interface on the information to convey only that which is appropriate to the audience. Consider this a sausage casing, if you will, that abstracts the detailed content regarding the inside of the sausage. So, rather than discuss with them that

"This sausage is almost done – it needs some fennel, and a little more pork fat, and a touch of lard."

we should be saying something like

"This sausage is almost done; we are 85% confident that it will be available for consumption in the mid-April timeframe and 98% confident that it will be ready in time for the Memorial Day picnic in May. If you want to increase the probability that it is delivered in time for April, we can eliminate one of the ten sausages we have slated for April and refocus on this one."

It is in these conversations that we provide our stakeholders with information that is suited to their digestive profile.

Seeing how others see

I'm taking a Myers Briggs test right now. My whole team is taking the test this week. I learned alot from doing the test in grad school; it helped many of us adapt to our different approaches to working. But that's for another blog entry.

One of the questions: Are you more likely to
a) see how others are useful
b) see how others see

My answer is a), but I wish it were b). That's not to say I'm all about usefulness; I think I do probe on a deeper level more than most would consider typical of a manager. But I think there's something here to work on. The a) answer is more tactical I think; b) is more strategic. Are you seeking results? Or are you seeking to understand the people on the bus¹ to channel them effectively towards helping you to - not only answer questions and solve problems, but to - ask the right questions and identify the approach to solving the problem.

I blogged some time ago about this quote I like - "Managers use people to do work; Leaders use work to grow people." Related (same?) point.

¹Reference here to "Good to Great"... a book that suggests that one of the attributes of a company that bridges the gap from good to great is that it focuses less on the strategy than on the people you have defining the strategy... their metaphor is a bus, having the right people on the bus, and having the right people in the right seats on the bus.

Agile versus Discipline (sic)

I recently gave a presentation: "Introduction to Agile" at a .NET CodeCamp in South Florida. One of the attendees commented that Barry Boehm had written a book called something like "Agile vs. Discipline".

My first reaction was that this must be a mistake. No informed software expert could possibly posit agility against discipline. I looked it up after the conference. This attendee was indeed accurate. I found Boehm's article: "Rebalancing Your Organization's Agility and Discipline" here: http://www.agileprojectmgt.com/docs/Boehm20.pdf.

Wow.

Wow.

First paragraph of the abstract says: “we realize that ‘disciplined’ is not the opposite of ‘agile’ but it is our working label here for methods relying more on explicit documented knowledge than on tacit interpersonal knowledge”.

That’s like titling an article as “Rebalancing gun control and murder” and mentioning in a footnote that not all murders are caused by guns, but that “murder” is our working label for lack of gun control. However you fall on that topic, you can see the illusion being prepared.

Table 1 shows that the home grounds of “disciplined method” include “stable, low-change; project/organization focused”. How many of you, dear readers, work in such environments? Any?

Table 1 also conveys that “quantitative control” is the home ground of “disciplined” methodologies. Is this to mean that us agilists just shoot from the hip and decry measurement? Not in the least. What’s your unit test code coverage, Mr. Discipline? Do you measure it? I do.

Primary goals of the “disciplined” include “High Assurance”. Indeed. Excessive documentation, analysis paralysis, waiting to show users working code for long periods of time provides “high assurance”? That’s your “disciplined method” for you. Documents in lieu of working code? Is that what assures highly?

I would prefer Mr. Boehm’s table of “home grounds” to relabel the columns “Agile” and “Disciplined” with these terms: “Planning” vs. “Plans”. Here’s the trick. Agile relies on the act of planning and the discipline of responding to change. His so-called “disciplined” methods rely on plans that usually remain static and get modified by committee.

Mr. Boehm’s spider chart shows dimensions for attributes of a project to show whether it is more or less amenable to agile or “disciplined” methods. I’ll take them one at a time:

• Personnel. Essentially Mr. Boehm says you need smarter people to do agile. This is probably true. I would argue, however, that you’d rather pay one person $90K who can do the work of two people at $60K and that the diminishment of communication costs between people adds to the economies of scale beyond the numbers. This is true in any environment that you wish to consider. The best programmers, it is said, are 10 times more productive than the average. Why not pay twice the going rate for someone who’s only, say, five times as good?
  
• Dynamism. (%Requirements-change/month). If your requirements don’t change as much, agile is not right for you. What a silly statement. They probably meant to say that if your requirements don’t change as much, you can hire cheaper help who can’t adapt to change. Agile works well in dynamic (i.e. most) environments. You might be able to get by in the rare “stable” environment with excessive documentation, and delay between idea and working code.
  
• Culture (%thriving on chaos vs. order). I love this statement: “[disciplined devotee] thrives in a culture where people feel comfortable and empowered by having their roles defined by clear policies and procedures”. When’s the last time you heard someone say “I am particularly empowered when somebody tells me exactly what to do and when to do it”? I’d much rather have a team of thinking, adaptable, empowered developers than drones who simply follow the process. Am I way out there?
  
• Size. This is the big knock on agile… that it doesn’t scale. I’ve seen it scale… well… fail to scale. I’ve yet to see a successful large-scale agile project up close and in person. But this should not be interpreted to mean that I discount the possibility. I believe it can be done. I just think that it requires enlightened leadership. That’s where the dearth lies.
  
• Criticality. Really, this is plain stupid. Sorry Barry, but this dimension really irks me. When’s the last time you worked as a leaf-node part of a team on a project in either a waterfall… umm, I mean, disciplined… approach or an agile approach. This dimension alone conveys to me that you have lost touch with software development reality. Agile is not the antithesis of discipline. You probably think that agile means “no documentation” – like many ignorant folks out there. Fortunately they’re not writing about it; alas, you are.
  

One of the paragraphs urges readers to “assess the likely changes in your organization’s profile over the next 5 years”. Please. If anyone has visibility beyond the next year, my hat is definitely off to you. And write it down, revisit it in a year and see how wrong you were. 5 years? No freakin way. Your vision of possible organizational stability warrants an inclusion in the fantasy walk of fame.

Mr. Boehm has a bullet that implies that dependability is a hallmark of non-agile methods. It reads: “key future trends to consider include the increased concern with software dependability and need for discipline”. The authors have crossed a line here. They're no longer using “discipline” as a catch-all for waterfall methods, they’re now using discipline as an inarguable quality. Again, Agility is all about discipline. They are clearly out of touch.

Here’s a phrase that disgusts me: “Examples of potential anomalies are: Operating with agile, fix-it-later developers with a growing, increasingly enterprise-integrated and dependability-oriented user base”. Really. “Fix-it-later developers”… implies that agile developers are hackers who let bugs fester. And that somehow, agile development conflicts with a user base that values dependability.

Unbelievable. Really. Mr. Boehm (and coauthor): Poke your head up into the real world. Join an agile project. Don’t just read about it and regurgitate uninformed opinions.

In sum, I am disappointed, and amazed at the observations in this article, which seem to be informed mostly from uninformed, anti-agile pabulum.

MoSCoW Squared

Agile business analysts are well aware of the MoSCoW framework. That is - the classification of requirements as "Must Have", "Should Have", "Could Have" and "Won't Have". The beauty of this classification is that it clearly defines the stories in understandable terms of importance - rather than 1, 2, 3, 4.

A colleague of mine - David Smith - recently pondered the importance of several stories across two dimensions. There were features that had high importance to one party but not the other, and there were stories that appealed to both constituencies. He plotted the requirements on a two-dimensional grid, assigning their importance across the two dimensions representing those constituencies. It was so informing and illuminating that I thought other agilists would benefit from the idea. Here's an anesthetized version:



Ultimately, the value of the story stems from its radial proximity to the root. In other terms, you could probably draw an arc reflective of the relative importance of each axis (or constituent).

I hope you find it useful. I know that, for us, it provided an "aha" moment.