Leadership

Scrum won't help the nosey CEO

Malcolm Anderson — Wed, 09 Sep 2009 16:02:03 GMT

I've seen it come up in discussion groups time after time, the management wants to measure productivity in their development team and developers just want to be left alone to code. Recently some one asked:

> Maybe it's also time for a frank discussion of "What does the CEO
> *really* need" for visibility? Is it really metrics that do not make
> any sense (and costs a lot to collect)?

No, it's time that we turn this question on it's head, because it's not "What does the CEO *really* need" for visibility?. The CEO's job is to maximize profits for the shareholders, anything else is a dereliction of their duties, he or she really *does* need visibility.

The question is, how can we turn the development team into a profit center? This is an ongoing issue in the corporate world where IT typically falls under the CFO rather than the CEO.

We as development staff have to remember, CEO's care about raising profits, CFO,s care about cutting costs. We as development staff have trained CxO's that software is unpredictable and mysterious, so naturally, they apply dilbert-esq techniques to it hoping to fix it.

Maybe it's time for a frank discussion of "What can we do to help the CEO with his or her goals of increasing company profits?"

Scrum is not going to help the CEO, at least not directly, but if you have an agile coach helping developers to start taking the profit question seriously then scrum could provide a fast road to moving software development out of the shadows and into the strategy sessions where it belongs in an information age.

Joining the let's-find-out club

Malcolm Anderson — Tue, 01 Sep 2009 11:42:06 GMT

Joining the let’s-find-out club

When it comes to a new idea, a mentor once told me that my feelings and past experiences are lousy tools for evaluating that new idea.

What he said was something to the effect of, “You need to join the let’s-find-out club. Will that idea work? I don’t know, let’s find out”

At the same time, if you are using someone’s already successful system and that system has worked for others, but not for you, just maybe, you’re not really following their system.

And don’t say, “but we’re different here.” No you’re not, you’re just unwilling (or in some corporate settings, not allowed) to make the changes dictated by the successful system.

I once heard a trainer explain

If I told you to dial (555) 123 – 4567, give my friend on the other end your name & address, and he’ll send you a check for $100, don’t come back to me and say,

“I tried your system, and it didn’t work, I didn’t dial the number in the order you gave me, but I dialed all the numbers”

“I tried your system, and it didn’t work, I didn’t use the number 4 because I don’t like to press the number 4, so I just replaced it with two 2’s.”

“I tried your system, and it didn’t work, I put in the first 6 digits and didn’t get any result, so I didn’t bother to finish implementing your system you fraud.”

Laugh, but I have watched people, at great expense, implement their version of other peoples systems and then complain that not only did the original system not work, but that the people explaining the system were unyielding zealots who didn’t understand how things worked in the real world.

Once again, my favorite agile book

Malcolm Anderson — Fri, 08 Aug 2008 18:22:07 GMT

I’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?

Design and Agile Development

Malcolm Anderson — Thu, 17 Jul 2008 20:09:41 GMT

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).