Darrell Norton's Blog [MVP]

Fill in description here...

7 simple ways to add a little agile

StickyMinds has a good public article available right now called Traditional – with a Twist: 7 Simple Ways to Add a Little Agile without Going to Extremes by Peter Schuh. Here’s the intr

“Are you in the midst of a traditional development project that cannot take a leap toward Agile, but you know could benefit from being nudged in that direction? Does your project have stakeholders or management who are willing to discuss the merits of Agile development but won’t give you the time to investigate an Agile methodology, much less switch to it? Are you a project manager or team lead who has read or heard a bit about Agile development and wants to experiment with it but are, yourself, too skeptical to make a large upfront investment?”

It’s a good read on basic agile practices that you can do on any project without needing management permission (except for the one about the user). It’s a good list to get started with.

Published Aug 20 2004, 11:28 AM by darrell

Comments

Rakesh said:

"Traditionally, some programmer named Scott gets assigned the invoicing system for the dapper new leasing application, bangs away at it in his cube for about six months, shoves it off to testing at 2 am, steps off a curb in front of the proverbial bus, and there goes the project."

Nothing wrong with that. If Scott had good Lego blocks to work with then let him build something with it. Dividing a large project into subsystems and using a common framework is a great approach. Thats one of the main things most methodologies forget or assume is already present. The establishment of a solid framework to assemble things. Most projects that Ive seen fail dont have any sort of framework on them. Or the framework was not good enough. Its like building a house but first everyone molds their own bricks, chops their own wood, forge the hammers and so on. It just wouldnt get done fast enough regardless of how many are involved or how good the carpenters are. The quality also wouldnt be very good. I will bet on a single decent programmer building a sub system (with a framework) anytime.

# August 22, 2004 7:08 AM

Rakesh said:

"However, it does help illustrate the issue many Agilists have with assigning specific application areas to specific programmers: Nobody understands anybody else’s code. Because of that, defects fester in code that is never fully reviewed by a second set of eyes, shifting programmers to troubled areas of the system halfway through the project is difficult at best, and turnover can really smart."

Its suppose to be a black box world. You give me your component and the interfaces to it. I use it to build other components. I shouldnt have to worry about auditing your code. Everyone has different view points on what is good code. But having a common, agreed upon framework to work with helps standardize things. Presumably when the HR department hired you, they screened for decent/basic coding skills.

Im not at all against code review. Yes, it can provide some benefits but time is better spent on other things that can give a bigger bang. I rather spend time reviewing the technology, architecture and training prior to starting to code. More time on the white board than on the keyboard.

# August 22, 2004 7:42 AM

Darrell said:

Rakesh, first comment - the problem is when a person works on a subsystem and there is no transfer of knowledge. When Scott leaves, or his code needs bugs fixed, nobody really understands how the code works, and time is wasted trying to figure it out before progress is made. According to a Standish group survey, employee turnover is one of the top issues causing schedule delays.

# August 22, 2004 2:37 PM

Darrell said:

Rakesh, second comment - it is supposed to be a black box world *with the expectation of support*. I can rely on a vendor's component to be a black box if I know they will help me resolve any issues. A black box is terrible if there is no support, and if there is no review of the design or the code.

I do agree that reviewing the architecture and design is more important than reviewing the code. I've learned the hard way not to let anyone design anything by themselves. The end product is never as good as when a team (of relatively equal ability) develops a product (or architecture, or design, etc.).

# August 22, 2004 2:39 PM

Rakesh said:

Excellent points

1. It is expected that a programmer will leave a project. Which is why component/object interfaces should be documented at all times. Those are the things that are audited not the code used to implement the interfaces. Preferably these interfaces are already designed(and audited) prior to the start of coding. If the component is malfunctioning, it is often better (and faster) to just rebuild it than to flog the existing code or take a lot of time debugging it. Documentation is important.

2. A team is indeed building the software. Its who'se responsible for the sub system is what I was trying to convey. There will always be collaboration. We agree that we will be using red bricks, wood floors to build the house. When we my subsytem has to integrate with yours, we agree that this is how they will integrate and so on. But we cannot design everything by committee. Thats why projects have architects.

But all of the above is what I mean by having a framework. The basic building blocks that should already be there before we even start coding. To be desigining the framework as we are coding is a sure recipe for disaster. A lot of the methodologies out there assume that there is already a framework in place. They assume that there is already some form of organization when most software outfits dont have one. Hence the failures. The methodologies are usually management techniques while coding is already taking place. Note a basic framework is not necessarily the architecture. Its the tools we will use to build the architecture.

But it is also good for a programmer to be able to do some form of design. Software development is an art form than most people would like to accept. Any programmer that cant design/build a subsytem is not a software developer at all. Theres that famous saying "The optimal number of developers in a software project( or sub system) is one. "

Great topic! Thanks for the comments.

A

# August 22, 2004 5:46 PM