Wednesday, September 09, 2009
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.
Tuesday, September 01, 2009
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.
Saturday, July 25, 2009
Monday, July 20, 2009
http://www.ohgizmo.com/2009/05/08/video-friday-martin-jetpack/
Three words: I want one !
Friday, July 03, 2009
Ok, that was cool and somewhat easy.
Sign up for Google Analytics add your GeeksWithBlogs (GWB) url (mine is "geekswithblogs.net/geekusconlivus")
You will be given a chunk of code.
Log into your GWB page, select
Options | Configure
At the bottom of the page (underneath where it says "Static News/
Announcement") paste that code in.
Go to a couple of your pages, use some of the navigation.
Go back to google analytics and click check status.
You should be set.
Oh, and if you haven't checked the
thirty day challenge yet, go now, the idea is incredibly cool.
[edit]
Got to give credit where credit is due,
I came across the instructions on how to place the code from this post.
Wednesday, December 17, 2008
Pod Cast Recommendation
Hansel-minutes
Lean Software Development with Tom and Mary Poppendieck
http://www.hanselminutes.com/default.aspx?showID=136
These two literally wrote the books on lean software development and they raise some interesting questions.
How do you measure success?
How do you know if you are measuring the right things?
How do you make good deadlines?
How do teams best serve the business?
When and what development should be outsourced?
What is a team’s core competency?
Great questions, and that’s only the first half of the 37 minute podcast.
The second half takes on Consulting Companies trying to teach Scrum.
Hope you all like it
Friday, August 08, 2008
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?
Thursday, July 17, 2008
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).
Monday, June 02, 2008
Once more, Microsoft is handing out free tools, and doing cool stuff, and putting the fun back into programming.
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"
Thursday, May 29, 2008
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.
3
"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
Friday, May 09, 2008
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.
Monday, 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
Tuesday, October 09, 2007
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
Monday, October 08, 2007
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.
Thursday, October 04, 2007
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.