It was a large group this month at the SL-Agile roundtable. As my laziness continues, all you get again this month is my raw notes. I’ve bolded my main take-aways.

Agile 2009 Roundup

Kanban: the gap in inventory in the next station. Kanban pulls from the end, not push from the front. You would only code new features if QA has time to test it.
Costs: if costs are essentially linear, and software value is exponential, estimation becomes worthless. Value is the only thing that matters. Always deliver high value items, regardless of the cost.

Switching from command and control to a collaborative leadership style

Celebrate failures. If you haven’t had a failure in the last 6 months, you have a problem.

The appropriate amount of slack

Google does 1 day out of 5 for personal time
1/2 day every two weeks is not enough
Better to group up the time to have large blocks. 4 weeks on, 1 on.
You have to plan the slack in. Give a “gold” pass out to one person per iteration. Don’t hide it in padded estimates.

Dealing with trust issues on a team

Book: Crucial Confrontations: Tools for talking about broken promises, violated expectations, and bad behavior
Self organized teams would self disciplin and deal with the trust issues.

User story formats

Quit arguing about the format and do something.
Can your customer read, understand and see value in your stories.
Are they reading them?

What is the role of process in a growing company

New person wants to rollback some working agile processes. You’ve got to fight for it.

Jonathan’s show and tell

Big iceberg list from a project. 6 cards wide by 12 cars high. Each with a sentence.
Is it effective as an information radiator? the intended consumer has to judge.
Does not readiate very far.
Borderline overload.
You have to watch and review your tools to make sure they still have value.

Book Recommendation:

Maverick: The Success Story Behind the World’s Most Unusual Workplace

Every month I have great intentions to poor over my notes from the SL-Agile Roundtable and post the fantastic tidbits I collect. And most months it just doesn’t happen. So, in the spirit of my up-and-not-perfect-is-better-than-down-and-perfect philosophy, I’m just going to post my raw notes. If there is something in there that you want some context on, ping me.

Book: 4 steps to epiphany – Tdd a business idea

Automating Agile managers

Corporate America seems to be dumping middle management. Is that due to automation.
Is there a diffference between traditional and Agile management? Yes.
What is traditional management?
Agile manager is about continuous improvement.
Kent Beck said Agile management is an oximoron.

Cloud people – specialists

Multi-specialists – not the specialist and not the generalists.
Kay – your specialists should be in you core competency.

B players

Want to be told what to do each day. Where do they fit in Agile.
Kay: they keep the A players from tearing eachother apart.
Should fit great. Sign up for some stories and go.
Don’t make B’s act like A’s.
Player grades are context sensitive.

Confident or compotent people

Watch out for confident incompotent people.
Dunning Cruger effect – confidence leads to not recognizing their own incompotence.

Book: Flow

principles of product development Lean is so done.
Quantify the cost of delay

Information radiator overload

A person was being overloaded with info on the wall.
Less more efficient radiators
The point is to boil down the essence. If you have too much it is just mess of data again. The sun dominates all other radiators when it is in the sky.

Track budgets to sprints/iterations

Track money on the burn up chart. Budget utilization.
Have people give an estimate, within 10% accuracy, on time spent on each project.
Why isn’t it standard to track this stuff on visible public charts?

group refactor of a code sore spot

Substitute for traditional code review. More cooperative. Less confrontational.
Pnopricode from julias shaw uses heat maps to look at complexity.

Jeff: have customers organize your goals, not your implementation specifics.

Betaloft – shared work space

It was another great SL-Agile roundtable discussion this month. After the Agile Roots conference I wasn’t sure what to expect. This month we had the usual motley crew and few new faces. There were about 12-15 in total. As a bonus, Ron Holliday in town for a visit. Ron has been working with Fidelity for 15+ years and brings some great stories to the table.

Collaborative Culture

The first hour was devoted to a topic about team and company culture. There were references to Israel Gat’s keynote at Agile Roots. The core question was whether Agile presupposes a collaborative culture. I believe the consensus was that it does not.

My takeaway from that discussion was that Kay Johansen posits that the SL-Agile group mindset has been swayed against command and control cultures because of continued exposure to Alistair Cockburn. That may be true.

Estimating (part of a larger topic)

Zhon Johansen suggested that we only need to be as accurate in estimating as financial analysts are in predicting stock market behavior. He was talking about larger scale estimates.

Story Formats

There was an interesting report from one company about continued stress over the “correct” story card format. It seems they are deadlocked on making a selection. The group agreed that is doesn’t matter what the format is, just do it. Andrew Shafer commented that talk does not cook rice.

Agile Roots Conference Wrap Up

As most of the crowd attended the conference, we took some time to go around and have people mention their takeaways. Seems everyone got value out of the event.

Homework

Ron mentioned the OODA loop. This was a new concept to me and most of the group. So, your homework is to go read up on it at Wikipedia.

My parents were in town this weekend so that my Dad could attend the Agile Roots conference that I helped organize. During a break, while sitting at a table with some local developers I know, my father recounted a story from my childhood that I had forgotten. He was using the story to explain why he believed, that from an early age, I was destined to be in the computer programming field. On to the story.

One day in second grade I was being even more disruptive than usual, which my teacher didn’t appreciate too much. Being fed up with my insubordinate behavior, she sent me home with the task of writing the phrase “I will be quiet in class” (or something similar) 1000 times. That will teach me. A proven disciplinary method. Possibly if she would have had a more engaging discussion on the intricacies of basic math, I would have listened. I digress.

Once home, I explained the assignment to my parents. My father became outraged at the pure lunacy of the prescribed punishment. I agreed, of course. He ordered me to follow him to his home office. I no doubt thought I was in for a long lecture on the value of education and how I was wasting my opportunity. Instead, he sat me down in front of a marvel of technology called the TRS80 (pronounced by the in crowd as “trash 80″). He then walked me through creating my first BASIC program. It was short and sweet, but it efficiently printed out “I will be quiet in class” 1000 times. Now that’s working smarter not harder.

Needless to say, my teacher was not pleased. I think she wanted me to actually write the phase out by hand. She should have been more specific with her requirements and I continue to be a disruption in class. But I did learn to program.

I have reconstructed the full source code below (released under the Creative Commons License), so that if you ever have a need, and have a TRS80 lying around with a copy of BASIC, you too can teach your child to avoid punishment and skirt responsibility for their actions.

FOR I = 1 TO 1000
  PRINT “I will be quiet in class.”
NEXT I
END

Facilitated Planning Session

Christian described a recent meeting, facilitated by Alistair Cockburn, where they were able to bring together several disparate company divisions, create, and organize over 100 use case story names in half a day. Alistair led the group through facilitated brainstorming, affinity grouping, and dot voting.

Ethics

There was a great question about the apparent lack of specific literature on Agile ethics. The ACM Code of Ethics and Professional Conduct was discussed. The best comment from the discussion was something like, if a methodology forces me to question or change my ethics, I don’t want it.

It doesn’t seem like there is anything in the ACM Code of Ethics that conflicts with Agile values and principles, but there are pieces that can be construed to conflict.

Specifically, section 3.4 is called “Ensure that users and those who will be affected by a system have their needs clearly articulated during the assessment and design of requirements; later the system must be validated to meet requirements.”

I could certainly read this as a it not being ethical if big up front requirements document are not created. But, it doesn’t specify what form the requirements come in. Agile methodologies describe many great methods for documenting and validating requirements.

Remote/Distributed Agile

The essence of the discussion was, there is no us and them, the is only us. The suggestions centered around thickening the communication channels; video conferencing, chat, always on phone lines, full group daily stand-ups, and pair programming via remote desktop.

Agile testing

Kay asked the group what they would like in an Agile tester. A flurry of responses were given.

• Don’t devote all of our testing to the GUI.
• Be part of the iteration, not beside it.
• Have the tester check the fix on developer machine before it is checked in.
• Collaboration over tools – many bugs can be fixed in much less time than it would take to document it in the bug tracking tool. Just talk to the developers.

Consistent high-level reporting for multiple teams

The take away from this discussion was that it will be most effective if someone spends the time to inspect all of the team activities and craft a short executive summary by hand.

Other great topics

• UI refactoring war stories
• How to cram 2 years of Test-driven development (TDD) experience in 2 hours for a conference session
• Agile architecture
• Agile Roots Conference

Thanks for facilitating, Jonathan.

I use TweetDeck to manage my Twitterverse (it’s a small “verse”). One unique feature of TweetDeck is the ability create groups of followers. This allows you to funnel your steam down to something manageable. Missing though, is the ability to see the tweets for all people you follow that are not in a group.

So, what you are left with is a group of high priority tweets to read, and another with the tweets for all people you follow. Lots of duplications. Not cool.

The other day I stumbled on a neat trick for removing the duplicate tweets from the All Friends column in TweetDeck.

In the picture above, you can see that I have a group called “A list”. These are the tweets I read first. Once I finish scanning the list, I click the Mark all as seen button at the bottom of the column. Then I clear the tweets by clicking the Clear seen tweets button immediately to the right. That gives me an empty A list column.

But, my All Friends column still contains the tweets that I just read and cleared. To fix that, all you have to do is click the Clear seen tweets button at the bottom of the All Friends column. Poof! A clean list of unread tweets from the non A list followers.

First, a little background. The Sterling Scholar program is a competition of sorts among Utah high school students in key areas of study. Winners at all levels are almost certainly handed college scholarships. In high school I was much more into the “trades” than traditional topics; drafting, carpentry, and electronics. I was the nominee from all of these departments.

The competition came down to me and a female from the culinary arts (read: home economics) department. As you already guessed from the title of this post, I didn’t win. When I asked what I could have done better, I was told be one of my most trusted teachers that “she had better legs”. Ouch!

That combined with some issues in a state drafting competition, left me fairly bitter for the past 15 years. But, recently while reading Outliers by Malcolm Gladwell (see book report) I realized that if I had won the Sterling Scholar award, my life would have been very different. Gladwell talks about how the opportunities we are given and the experiences we have throughout our lives define us more than any other influence.

I would have certainly gone on to be an architect, spending at least 9 years in college. A respectable profession, yes. Something I would have been happy doing, no. Instead I was given the opportunity to see a bit how the real world works, and in turn evaluate whether I really wanted to spend 9 years in a politically charged college environment. It took me a while to come around, but after an eye opening discussion with a college professor, I realized that learning, and potential for success, has nothing to do with school and everything to do with our own internal desire to acquire knowledge and grow.

I quit college and have been learning ever since. Bucking the system at every turn.

What opportunities in your life have defined who you are?

I recently finished reading Outliers: The Story of Success by Malcolm Gladwell. Ok, to be honest, I listened to the audio book. This book is about those people in our world that stand way out from the crowd, the richest, smartest, and most successful, and how it is that they got that way. It turns out that it matters less what our IQ is or how hard we work, and more about what our heritage is and what lucky coincidences we have. Gladwell calls these coincidences opportunities.

Example: Bill Gates is a smart guy who worked his butt off to get where he is. But, he wouldn’t have achieved his current level of success if he weren’t born within a 1 year window that put him smack in the middle of the personal computer revolution at the age of 21. Furthermore, he had the fortune of having access to a state of the art computer terminal at his junior high school at the age of 13. Something Gates admits that possibly no other 13 year old had at the time. Only a handful of colleges had that equipment.

In short, this book is absolutely fascinating. If you enjoy reading about human nature and understanding what makes us all tick, get this book and read it.

Going through this book made me think a lot about the opportunities I had growing up. Made me questions what impact they had on who I am, and where I am today? In upcoming posts, I will detail some of those events that I feel changed the course of my life.

This month the roundtable was made up of about 8 people. Mostly old timers, with a few newer faces.

We spent quite a bit of time deconstructing Alistair Cockburn’s questioning style. Alistair, the founder of the SL-Agile group and Agile icon, was not at the meeting, so we talked about his behind his back. Alistair has a way of asking probing questions that is quite fascinating to watch. He allows people to come to their own conclusions by structuring the conversation in a clever way. My main take-away is that we should try to discover (or guess at) the other persons world view. In trying to learn enough to understand their world view we are able to look at the world from their point-of-view. Do this can be illuminating.

Andrew mentioned that he really enjoys Israel Gat’s blog The Agile Executive. I’ll have to check it out.

Somewhere along the way, I wrote in my notes “reflect first”. This is a great rule of thumb for anyone trying to affect change in there organization. Sit down with those involved and figure out what is working, what is not, and what the action plan is for making changes. Then rinse and repeat often.

There was mention again this month of the Cargo Cult effect. In Agile teams this seems to show up a lot in the form of team members grabbing onto a few practices, such as pair programming and iterations, and thinking that they will reap the same benefits as those who truly have an Agile culture.

All good stuff, and I always take something away from the meeting.

In the Agile software development world, there is a common practice among development teams called the daily standup. At a set time each day, everyone involved in the project gathers in a common area where they hold a mini meeting. It is called the standup because you are required to stand. This keeps the meeting short and focused. (more…)