Geekus Con Livus

Malcolm Anderson's home for Geeks With Lives
posts - 57, comments - 42, trackbacks - 59

My Links

News

We now have "news"

Archives

Post Categories

Friday, August 08, 2008

Once again, my favorite agile book

Corps Business CoverI’ve been talking with a lot of people about the book “Corps Business:  The 30 Management Principles of the U.S. Marines, and I just found a list of the principles from that book.  http://www.vincehuston.org/books/marines_30.html

 

I know that this book has been passed around in the Scrum Master community for the last 3 years, and probably the general agile development community before that.

 

What does a book about the Marine Corps have to do with agile software development?

 

You may be surprised.

 

My personal favorite is

13. Manage by end state and intent. [p98]

Tell people what needs to be accomplished and why, and leave details to them.

 

What is yours?

posted @ Friday, August 08, 2008 1:22 PM | Feedback (1) | Filed Under [ Agile Development Leadership Scrum ]

Thursday, July 17, 2008

Design and Agile Development

A quick shout out to Chad Sturtz for passing this video my way.


Video:  http://www.viddler.com/explore/Agileaustin/videos/2/

Length: 82 minutes

Date: 1 July 2008

Location: Austin Texas

Presenter: Jeremy D. Miller

Blog: http://codebetter.com/blogs/jeremy.miller/default.aspx 

 

One of the things that I really liked about this video is that it shows the biggest value (IMHO) of a good users group is being able to be in the room when high level conversations are happening. 

 

“How do you get junior developers engaged?”

“How do insure profitability while maintaining technical excellence?”

 

This is all in addition to the main focus of the talk “How does design get done on an Agile project?”

 

Some concepts that I found interesting.

 

“What is the difference between a spike and a prototype?”

“What is on your design backlog?”

“What is on your refactor backlog?”

“How reversible is your design?”

“Think ahead; don’t act ahead”

 

 

 

Here is the original post I received from Chad Sturtz

 

This is a video of a presentation last week at Agile Austin 2008.  It’s titled “How does design get done on an Agile project?”  It’s 1h 22m long, but hits on very many topics; everything from how TDD/BDD comes into play, to Reversibility, to the Open Closed principle.  And, a saying that will stick with me for a very long time, “Think ahead; don’t act ahead”.

 

The presenter is Jeremy D. Miller (http://codebetter.com/blogs/jeremy.miller/default.aspx).  If there’s any topic covered in the video that you’d like to hear more of his opinion on, check his blog.  Most likely he’s written about it (and written a lot, his posts are long).

posted @ Thursday, July 17, 2008 3:09 PM | Feedback (9) | Filed Under [ Agile Development Leadership ]

Monday, June 02, 2008

Microsoft Robotics Studio - What?

Once more, Microsoft is handing out free tools, and doing cool stuff, and putting the fun back into programming. 

 

Are you up for the challenge?

This is not a game, it's a full fledged robotics language, and simulator.  Ever wanted to show how easy it would be to have robot navigate a maze or program a rescue robot, or a soccor droid?  Well now you can.  Currently the only one available is the maze navigation (complete with traps), but more will be released over the course of the year.

It looks like you can upload your program, and the winners will have their programs loaded on to real bots that will go head to head at the PDC.  The be all, end all winner, gets a robot of their own.

Click here to download the MS Robotics Developer Studio 2008 (CTP April)

Click here to go to the Microsoft Robotics Developer Center

 I've really got nothing more than, "This is cool"

posted @ Monday, June 02, 2008 4:03 PM | Feedback (0) |

Thursday, May 29, 2008

"The Reading List Game" and "The Agile Evangelist Reading List"

There's a project and it needs your input.

There doesn't seem to be a "Geekus Con Livus, Agile Evangelist Reading List" and there needs to be.

Also, about a year ago I had a thought for a way for a group of people to quickly and easily generate a reading list.  I call it "The Reading List Game"(tm) [Tell your friends you heard it from Malcolm]

Hmmmm, maybe these 2 ideas could be put together and I wouldn't have to do any real work, while at the same time, letting a ton of people show everyone else how bright and well read they are.

Also, I've been wanting to try an idea I'm calling "The Reading List Game(tm)"

Both Jeff Atwood and Scott Hanselman have both got developer book list recommendations, but no one has asked the Agile Community what they thing an Agile Evangelist should be reading.


Here's how you play The Reading List Game(tm)
you get 10 votes and you can submit between 1 and 10 books. 
Distribute the 10 points any way you want to.
You have until Friday, June 13th 2008 to get your votes it
At which point I'll total the points and print the results


Here's my voting.



"Corps Business: The 30 Management Principles of the U.S. Marines" by David H. Freedman
(If I had to put only one book on a list about Agile Development, this would be it.  5 used copies are available for $1.25 (+ $3.99 shipping and handling) over at amazon right now, get them while they're hot)




2 "Agile and Iterative Development: A Manager's Guide" by Craig Larman
(chalk full of hard data for that bottom line manager in your life, this one is a close second to Corps Business)





1 "Agile Project Management with Scrum"  by Ken Schwaber
(I'm a Certified Scrum Professional, you knew it was going to be on the list.






1 "Lean Software Development: An Agile Toolkit" by Mary and Tom Poppendieck
(Why does Toyota keep eating Ford's lunch?)






1 "Implementing Lean Software Development: From Concept to Cash" by Mary and Tom Poppendieck
(I had to put a couple in to answer the "how do you do it?" question)






1 "Practices of an Agile Developer: Working in the Real World" by Venkat Subramaniam and Andy Hunt
(Don't bother trying to explain to developers that programming is really applied philosophy, have someone else do that)





1 "Agile Retrospectives: Making Good Teams Great" by Esther Derby and Diana Larsen
(Saying that you should do retrospectives is much easier than facilitating retrospectives)






ps

Don't forget to tell your friends you heard about "The Reading List Game" from Malcolm at Geekus Con Livus

posted @ Thursday, May 29, 2008 8:46 PM | Feedback (2) |

Friday, May 09, 2008

Continuous Intgration and your car's dash board

I've found that there are some analogies that are useful for describing agile principles.



Continuous Integration (CI) can be likened to the temperature gauge on your car.

For the most part, if your temperature gauge goes into the red, it's advised that the driver stop immediately and fix the problem with the car.  Otherwise the car may overheat and do serious damage to the engine, while bringing the car to an stop FOR the driver.  The cost of waiting is significantly higher, and the benefit gained by waiting is marginal at best.

In general, if your CI instance fails you should do 2 things. 
1) Assign someone to find out what went wrong (here's a hint, it's probably the person who just checked in code)
2) Chop off the hand of anyone who checks in code on top of a broken build.

Now lets go back to that car.  There may be times when you have someone that needs to get to the hospital NOW. 

At that point, you may not care how much damage you do to your engine in the process of getting you to your destination.  You know that you will pay a heavy price to bring your car back into good shape, but that doesn't compare to getting your deliverable where it HAS to go.

Likewise, if you absolutely positively have to get a particular feature to your customer in the next week, and in the process of this you break your build.  An argument could be made to ignore the breakage, and go on.

Personally I don't think it would be a good argument, and exercising that option would be a sign that your engineering practices probably need more work, but the argument could be made.

posted @ Friday, May 09, 2008 11:31 AM | Feedback (0) |

Monday, October 15, 2007

Selling Scrum - Scrum "Endorcement" in SD Times, October 15, 2007

http://www.sdtimes.com/static/retrieve/pdfissue.html

A friend sent me the above link to this months Software Development
Times where one of the front page stories was about the decline of RAD
and the rise of Agile.

I have little use for SD Times because it's I see it as basically
being a giant advertisement for various tool developers aimed at CIOs.
 In fact the entire "Rapid Application Decline?" article was
completely tools focused.

However, as I was going through the issue, I found an interesting
article on page 41, "Spreading the Agile Practice" that dealt with
doing agile development using distributed teams.

What really stood out for me was this (admittedly out-of-context line)
that just screamed, "take this endorsement to your CIO"

"... agile development is most effective when Scrum is used in tandem
with Extreme Programming, or XP."

The full paragraph is here.

"The core principles remain the same regardless of
the specific agile process in use; although at the recent
Agile 2007 conference, a number of consultants and
developers mentioned that distributed agile development
is most effective when Scrum is used in tandem
with Extreme Programming, or XP. Scrum provides the
overarching management structure, while XP is in place
at the developer level where the coding is actually done."

That being said, can someone give me a really good argument, or
article,  for the concept that in order to do distributed teams, you
had better be really good with the practices that you are intending to
distribute?

Thanks
 
Malcolm

posted @ Monday, October 15, 2007 5:51 PM | Feedback (9) |

Tuesday, October 09, 2007

The myth of the part time Scrum Master

Recently a job posting came through the ScrumDevelopment list reflects an all too common misunderstanding about Scrum.
"An exciting new [industry removed] company located in Bethesda, MD is looking for a ScrumMaster and Technical Lead to join their team. This is a key employee position responsible for leading the construction and enhancement of the company’s web-based e-commerce and portal software, and its interfaces with various content and service provider systems."
My reply to this person pretty well sums up my feelings on this misunderstanding.
Hi
 
I'm not sure if your company or your CxO's are aware of this, but the role of Scrum Master is a full time position in and of itself.
 
You might be better served by hiring a Scrum Coach and putting your entire team, plus their manager, and their manager's manager through the CSM course.  We had a lot of success using that approach at the Washington Attorney Generals office.  Even with that thrown into the mix, there were challenges to adopting the agile philosophies.
 
A good starting place to get a Scrum Training reality check is this post over at Implementing Scrum dot Com
ImplementingScrum.com is a great resource for bringing setting your expectations in implementing Scrum into your organization.
 
Also a list of up coming Scrum course can be found at the Scrum Alliance dot Org site
 
Best of luck.
 
Malcolm Anderson
Certified Scrum Practitioner

posted @ Tuesday, October 09, 2007 5:52 PM | Feedback (2) |

Monday, October 08, 2007

Using Scrum on a multi project development team

Recently a question came up on the ScrumDevelopment list asking about using Scrum an a team doing multiple projects in parallel.  Since being involved on a team doing just that, I've been wanting to take the time to document our approach but have never taken the time to do it.  Now I have an excuse and I thought i would share it with everyone.

> I wonder how would you approach to planning and tracking when there is
> a small (<15) team involved in several projects at the same time (not
> necessary maintaining few product flavours, but still working on one
> product). Usually a project could be completed by few (2-3) developers
> within a dozen iterations.

We did this in our department of a large federal agency.

We had had a team of 6 or 7 developers, working on 5 - 9 projects per sprint.

We had one daily scrum meeting, and a common project board covered in index cards, one story per card, one row per project.  When stories got completed, they were moved over to a corresponding "done" board in our common war room, which also functioned as our meeting room.

We were using 2.5 hours per developer per day as an ideal day, and our pool of "hour points" was distributed to our various customers by our manager.

We aggregated all of the "hour points" into a single burn down chart, but had separate demos and planning meetings for each project.

We worked on 3 week sprints with a 1 week "demo and planing" week between them, which also worked as a opportunity to get things done with infrastructure that no one wanted to pay for.

It's not textbook, but it worked pretty well, and our customers were overjoyed to be getting visible progress each and every month.  Our customers also got to see what other projects we were working on at any given time.

Lastly we used a customer report card to gauge customer satisfaction, which gave us feed back on how our customers were feeling about our progress, and also reinforced to them how much and how well we were taking care of their needs, by having them assess our progress.

posted @ Monday, October 08, 2007 3:50 PM | Feedback (5) |

Thursday, October 04, 2007

My Life - A Modern Parable

This came across the ScrumDevelopment list today, and I had to share it.  Once more, it's not mine, but it's my life and one of the reasons that I am so passionate about Scrum (leveraging Lean principles, and XP practices).

From http://talk.ocregister.com/showthread.php?t=28235

Modern Parable

A Japanese company ( Toyota ) and an American company (General
Motors) decided to have a canoe race on the Missouri River . Both teams
practiced long and hard to reach their peak performance before the
race.

On the big day, the Japanese won by a mile.

The Americans, very discouraged and depressed, decided to
investigate the reason for the crushing defeat. A management team made
up of senior management was formed to investigate and recommend appropriate
action. Their conclusion was the Japanese had 8 people rowing and 1
person steering, while the American team had 8 people steering and 1 person
rowing.

Feeling a deeper study was in order, American management hired
a consulting company and paid them a large amount of money for a
second opinion. They advised, of course, that too many people were steering
the boat, while not enough people were rowing.

Not sure of how to utilize that information, but wanting to prevent
another loss to the Japanese, the rowing team's management structure
was totally reorganized to 4 steering supervisors, 3 area steering
superintendents and 1 assistant superintendent steering manager.

They also implemented a new performance system that would give the 1 person
rowing the boat greater incentive to work harder. It was called the
'Rowing Team Quality First Program,' with meetings, dinners and free
pens for the rower. There was discussion of getting new paddles,
canoes and other equipment, extra vacation days for practices and
bonuses.

The next year the Japanese won by two miles.

Humiliated, the American management laid off the rower for
poor performance, halted development of a new canoe, sold the paddles,
and canceled all capital investments for new equipment. The money saved
was distributed to the Senior Executives as bonuses and the next year's
racing team was out-sourced to India ... Sadly, the End.

Something else to think about:
Ford has spent the last thirty years moving all its factories out of
the US, claiming they can't make money paying American wages. Toyota has spent
the last thirty years building more than a dozen plants inside the US .

The last quarter's results:
Toyota makes 4 billion in profits while Ford racked up 9 billion in
losses. Ford folks are still scratching their heads.

posted @ Thursday, October 04, 2007 2:59 PM | Feedback (3) |

Thursday, September 27, 2007

Mike Cohn - Planning and Tracking on Agile Projects

Mike Cohn has posted a link to the presentation he did back in March this year on Planning and Tracking Agile Projects.

There's an hour and a half of video plus the slides.

Well worth the watch if you are doing story points, or if you think story points are stupid.

http://www.mountaingoatsoftware.com/news/view/14

posted @ Thursday, September 27, 2007 5:08 PM | Feedback (1) |

Thursday, August 16, 2007

Some of the biggest advantages to using Scrum in your organization

There is a lot of talk about "Agile Development" these days, and I'm noticing that one particular brand is starting to get a good strong foot hold.

 

I'm talking about Scrum.  It's not a methodology, it's a frame work, and while that may just sound like semantics to you it's kind of important.  Methodologies tend to lock a company into a tight inflexible .... well, methodology.  What makes Scurm different is that it's as much principle as it is practice.

 

I'm sure most everyone is aware of the concept that "principles must take precedence over practices".  If you are not familiar with this concept, it's the difference between the spirit of the law verse the letter of the law. 

 

The reason this is relevant is that a framework embodies principles, while methodologies embody practices.

 

But I'm getting off track here.  The main thing I wanted to put out here is that one of the largest advantages to Scurm as a framework to do your development with in, is the very position of Scrum Master. 

 

The main thing that a Scurm Master brings to the table is that they are responsible for maintaining and enforcing the rules of Scrum.  This means that you have one person dedicated to insuring that everyone they come in contact with understands how and why Scurm works.  They know what they are doing that is "Textbook Scrum" and they know where they are adapting.  They can tell you if your team is doing "Scrum", or "Scrum But".  I can not begin to explain how important this is, if for no other reason than a simple rule, "If a team doesn't have a Scrum Master, they are not doing Scrum".  No if's, no and's, no but's .... not Scrum.  It may be Agile, it may be Lean, but it's not Scrum.

 

If you have ever worked with eXtreme Programing before, you may understand how big a deal this is.  I can not begin to tell you how many teams I've heard of that have said, "Oh, we tried XP, but it didn't work" .  The odds are that they tried to pick and choose which XP techniques to use, and then did them poorly.  I've run into teams that said they were doing Scrum, but when I asked them who their Scrum Master was, and how long had they been certified, the answer came back, "Oh, we used to have a Scrum Master, but they've moved on to another position, so we don't have one right now."

I had to tell this person, that while they may be doing some form of Agile Development, they weren't doing Scrum, if they have success, great, but if they have failure, they did it while not using Scrum.

 

This is not to say that a project can not succeed even if they have a Scrum Master, but even the team that I did see using Scurm, and failed, they had the role of Scrum Master as a rolling position that passed from person to person after just about every sprint.  Did I mention that the project was not successful? 

 

So what I'm getting at is, the Scrum Master is an important role and it's one that takes a life time to master.  I'll admit that it's a silly name based on how a ball is put into play in rugby. 

The Scurm Master plays the role of facilitator and coach.  In theory if the product owners and the development staff had everything put together, the Scurm Master role could be eliminated, much the same way that professional sports teams don't need their coaches.  Oh wait, ALL professional teams have a coach.  Maybe there's a reason for that.

posted @ Thursday, August 16, 2007 6:30 PM | Feedback (2) |

Thursday, July 19, 2007

Can anyone give me a better explanation?

I'm not sure who sold the Federal and State government on the idea that "restricting all employee's email to MS Outlook is an effective counter to computer viruses." or "Allowing gmail, hotmail, or yahoo mail is an open invitation to computer viruses".  I'm thinking that the marketing department in the "MS" of "MS Outlook" might be a good starting point to look.

Both thoughts have rendered me temporarily speechless.  Perhaps because both thoughts make as much sense to me as, "Eating apples is the only way to effectively protect your crops from rabbits". 

The speechless problem in both cases (once in a federal agency, and once in a state agency) seems to be related to the fact that I didn't have any response other than, “That’s really funny” followed by "Are you completely stupid?" when I realized they weren’t joking.

I’m guessing that, both times, my inability to speak may have been indicative of my job survival gene kicking in, but I can’t be sure of that.
 
Can someone check me on this?  Last I knew, MS Outlook was not proof against social engineering, and that during that last decade, the major e-mail pathogens have mostly used some flavor of MS Outlook as their primary transport vector. 

Does MS Outlook have some kind of security feature I don’t know about?

posted @ Thursday, July 19, 2007 2:00 PM | Feedback (2) |

Friday, July 13, 2007

Programmers and Capitalism - The $10,000,000 question

My friend Nick Malik recently posted about programming, contracting and pay.

There's a book here somewhere, but sadly it has no audience, and therefore not worth writing. 

Programmers seem to have a genetic defect when it comes to understanding the relationship between their efforts and their pay.  It's not going to happen, they don't want to, and you can't make me. 

Personally, I think that it's a crime that "From Serf to Surfer" is out of print.  It was one of the best consulting "pull yourself up by the boot-strap" books I've ever read.  The advice is relevant to ANY consultant in ANY field.

Programmers seem to understand that "my work is worth $x.xx an hour" but they do not understand the WHY behind it. 

 

 

Here's a quick little story problem to test your job worth intelligence.

 

Let's imagine that company JKL has a particular job function (FooBar) that has to be done.  That job function will have to be done for at least the next 6 years.  The FooBar job function is so important that there's even a FooBar department.

 

JKL's FooBar department has 100 dedicated people doing the FooBar job.  Every one in that department makes $50K annually. 

 

JKL access to a consulting group which offers a tiger team of 5 expensive programmers, each of whom cost $200K annually, and have track record of completing their projects on time and on budget.

 

The tiger team says that they can, in 1 year, automate the FooBar department such that the department can effectively cut %50 percent of it's staff at the end of the project.  

 

The tiger team has one other condition, on successful completion of the project; each programmer will get an additional $100,000 a year for the next 5 years regardless of their employment status with the consulting company.

 

Assuming that the programmers will be successful, and that JKL stays in business for at least the next 6 years, should the company hire the tiger team, and if so, just how much is this project worth to JKL?

 

posted @ Friday, July 13, 2007 1:06 PM | Feedback (3) |

Friday, June 15, 2007

Good Bye TDD

Have you seen the new buzz phrase for TDD?  Pretty much, they just changed the name from Test Driven Development, to Behavior Driven Development. 

 

It's an NLP experiment that I'm looking forward to seeing fleshed out.

 

Long story short, the problem with TDD is the word "Test"... *WAY* too much baggage, and charge on that one single word.

 

Consider:

"Testing your code is a good if you're a new programmer"

"Our department does testing at the end of a project ... if there's time"

"I'm a developer, I don't get paid to do tests"

"As a tester, I believe that most developers couldn't write a good test if their lives depended on it"

 

Here's the two links that I think are the most concise summations of BDD.

 

http://behaviour-driven.org/Introduction

http://behaviour-driven.org/GettingTheWordsRight

I don't think its ready for prime time yet, and the .net version is certainly no replacement for NUnit, *but* I think that this minor tweak can solve a lot of the communication issues that hinder adoption of TDD in the enterprise.

posted @ Friday, June 15, 2007 12:44 PM | Feedback (2) |

Thursday, June 14, 2007

Alex, I'll take "Google Key Words" for 1000

We've got a custom control that consists of 2 radio buttons, a "normal button", and a text box, all on a single line.
Internal to the control, I have all 4 of member controls lined up so that all the text is on one line.
So far, so good.  Except for one thing.
When I put my control on my form, I can not get the text on my form to line up with the text on my label, and I end up manually futzing it into something that resembles "it's place".  Where are my alignment functions?

I guess it's off to google.

My first google search was
 forms align text .net

This didn't get me anything useful, but I did get some stuff from asp.net.

Let's try requiring both "forms" and "align"
 +forms +align text .net

That didn't help either, people with questions, but no answers

Next I tried
 how do I align my textbox with my custom control

And got an interesting hit down at #6
"SnapLines not honored during resize." and the body says
"I have a custom control that contains a textbox. It has two ... the name string (based on the MeasureString length) and my Right snap ... "
let's go look at it.


http://www.devnewsgroups.net/group/microsoft.public.dotnet.framework.windowsforms/topic62981.aspx
well, would you look at that ... snaplines, is that a new keyword?  I go and check out the post.
ravi.s.desai@gmail.com seems to be having the same problem I am, I have a custom control that is just a collection of windows controls, but I can't align them.
As he puts it,
"Actually, to simplify the above, it appears that when you are resizing
a control, all snaplines  defined in the designer are completely
ignored, and the designer simply creates a snap-line for the edge of
the control that you are dragging, and uses that exclusively.  Is this
by design?  It certainly seems to limit the value of snaplines for
layout."

At this point, I stop, and write up the progress of my research up to this point.

Hopefully, the new keyword (snaplines)
a) actually is a keyword
b) produces fruit

Into google goes the phrase
snaplines custom control

The first choice is
"Using SnapLines from child controls of custom user control? - MSDN ..."

Which seems to indicate that while what I want to do, *can* be done, it's not simple, easy, or intuitive.

Now I have to ask the question, is this worth my time.

Answer, not in the short run, but definitely in the long run.

 

I'll be back...

posted @ Thursday, June 14, 2007 11:23 AM | Feedback (2) |

Powered by: