CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

Some stuff to think about

Robert Glass has a nice, short article on some findings on software project success:

http://www.developerdotstar.com/mag/articles/software_success_failure.html

 

Something he lists as a surprise finding that bothers me:

"Post mortem reviews are rarely held, and when they are it is almost always on successful projects "

I'm pretty sure it's more important to do lessons learned activities when things didn't go well.  Learning from mistakes seems to make the lessons more permanent.  I think one of the signs of a healthy team environment is the ability to do retrospectives freely and calmly, then follow through with changes.  I'd call this post from Steve Eichert, detailing some hard lessons learned his team faced, a sign of a healthy team.

One of the findings Robert Glass talked about was:

"Success comes from a culture that investigates and deals with problems "

I'd simply add that it helps to do retrospectives often, preferrably after each iteration and release.  Software development is still an unsettled, chaotic process.  Success seems to be largely predicated upon the frequency of your feedback cycles and your ability to make changes based on that feedback.

Anyway, enough from me.  Go check it out.



Comments

Jeremy D. Miller said:

Emad,

Keep in mind that this is strictly my opinion.  I think Robert Glass was referring to UML Use Case diagramming in the context of requirements gathering.  I used to like to sketch out use case diagrams for myself, but I've never, ever had a business partner or BA that could derive any useful information from a Use Case diagram.  

Even for design, UML is generally only useful for people who are visually oriented in their learning style (like me).  I would have thought that encompassed most of the better developers out in the world, but only a small minority of developers that I've worked with have been comfortable with UML (granted I've worked in Agile shops the last 3+ years).  I've worked with a number of very strong people with effective design skills who simply don't grok UML.  Based on that, I don't think you can say UML is an essential ingredient at all.

I still use UML occasionally (XP/Scrum leans toward CRC cards but doesn't prescribe the usage of anything), but really only on whiteboards and just in time.  I think CRC card type design is more effective anyway though.

As far as the RUP stuff, as long as it works for you.  I've always thought RUP sounded way too heavyweight, but I'd take RUP over waterfall in a heartbeat.
# July 5, 2006 6:10 AM

James Simmonds said:

I absolutely agree that retrospectives (I'm a Scrum practicioner) whether at sprint (iteration) end and at other points in the project cycle are an excellent indication of team health.

A team that can talk in a composed, calm & positive manner about the problems it has just faced and the enevitable solution and modifications to working practice (feedback loop) are much more productive in my experience and show real maturity in their approach - a true sign of "professionals" at work.

My first experience of a Sprint retrospective was pretty gruesome - it was hard and we didn't approach things well or in a particularly adult professional manner - however we still agreed on the problems and looked for fixes. Over time the more of these we did the less finger pointing and more fixing we did.

It also prompted people to come down off their ivory towers and broke their belief that they were too good to make mistakes. They thought they were infallable but that was because there was never an opportunity to air problems or highlight friction areas within the team - very few issues cannot be fixed by a rational discussion.

This feedback loop is essential to get problems out in the open, discuss and resolve them before they spiral out of control and disrupt the team beyond repair. It prompts inclusivity - the entire team have a voice and the concerns of a "junior" are just as valid as a team leader, "architect" or anyone else in the team. Software development follows the same rules as any team based activity - human nature and interaction within a dev team is no different to anywhere else!
# July 5, 2006 6:50 AM

Jeremy D. Miller said:

Thanks for the comment James, I couldn't agree more.

I'd add that there has to be a healthy level of trust between the team.  I worked on a strong XP team once that had poor chemistry.  Our retrospectives were pure torture.

I touched on this topic last year on a post about being able to make mistakes at work --> http://codebetter.com/blogs/jeremy.miller/archive/2005/06/03/129560.aspx.

I know one of the best culture changes at my shop over the last year and a half is cutting down on the "you can't make mistakes" culture.
# July 5, 2006 7:43 AM

Emad said:

Jeremy,

thank you very much for your comment, i'd admitt that it's a surprise though! UML has always been occupieng huge part in my enhancing dreams.

anyway, i am doign this step by step (i mean enhancing the process), and thank god that i have an understanding boss (he liked the idea of enhancing the process to the latest methodoligies...but step by step)
not the whole RUP thin at once

as for retrospectives, i do it with my team; but the result is always "lets avoid that in future", not "lets get back to the code and fix it"; (the very known reason..."no time to fix the past, lets proceed and finish this release"), is this good or bad?
# July 5, 2006 8:00 AM

Jeremy D. Miller said:

Emad,

Honestly, doing any kind of iterative retrospective puts you ahead of the mass majority of software teams.  

As far as the "no time to fix the past," it depends.  If it's technical debt that will slow you down in the future, you need to get back to it and pay it down.  If it's just a matter of "it would have been faster/better to do it this way, but we can live with it" you're simply smarter for the next time.  Telling the difference between the two situations is purely a matter of judgement.

The faster you can detect problems in your code or design the faster and more likely you'll recover.  One of the cliched cautionary notes I'd repeat about doing UML upfront is a false sense of security in the correctness of a design.  No design is correct or finished until it's working in code.
# July 5, 2006 8:18 AM

Emad said:

thanks, that was really helpful, thanks again  :)
# July 5, 2006 9:57 AM

Jeremy D. Miller -- The Shade Tree Developer said:

I'm spending a lot of time today running some *slow* build scripts and FitNesse tests, so I've got time...
# July 5, 2006 11:20 AM

fuzzydev said:

Hi jmiller,

Developers criteria for project success sounds to be true....

As far as UML is concerned, I feel any project/product needs to be
graphically represented to understand the system.

It doesn't mean that project/product without UML will be a failure but
it does assist us to visualize the system. Also UML representation will
be usefull to members who were not initially part of the design but
were roped in mid-way. UML may not be required where the whole
team have the same visual picture of the finished product(this is purely
based on my experience).

There are other aspects like better understanding of the system,
knowing the problems during the design stage. So UML does help
by playing a key role.

"Post mortem reviews are rarely held, and when they are it is almost always on successful projects" - this is where many companies fail
to act, any failure can be taken positively by retrospecting on the
causes and learning from it.

"Software development is still an unsettled, chaotic process" - I like
this statement Miller, it truely is; but we can surely make it less chaotic
by using our experience and wisdom.

"BA that could derive any useful information from a Use Case diagram" -
Hmm sounds familiar to many developers :)

Very few companies involve developers during project estimation,
this is sure sign of failure( if the persons involded in estimation had
poor/no knowledge of software ).
# July 5, 2006 9:54 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#. Check out Devlicio.us!

This Blog

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

TestDriven

MVP