What Is Agile Software Development?

One of the best explanations I’ve seen yet of Agile is the article “10 Key Principles of Agile Software Development” over all All About Agile.  Not only does the author give a good summary of some key concepts, but also some of the variations, including the original DSDM.

Enjoy!

Technorati Tags: it pm,information technology,project management,software development

How To Manage Software Development

Sometimes, project managers wear 2 hats.  Hopefully, you don’t wear much more than that, or you quickly become ineffective at one of the items.  I’ve done both resource and project management, so I’ve published an article on Helium on “How to manage software development”.  Below is an excerpt from the article:

Management of any team is exercising a certain amount of control over resources: Time, personnel, equipment and processes. However, an effective manager also realizes where management of their particular team is unique. Software development is no exception. While there may be environmental factors that require unique strategies in any given organization, there are general items to be aware of across the board for managing a software development team. You need to ensure that the proper tools, proper environments and proper training are in place in order to ensure successful completion of development projects.

You can read more here.

Technorati Tags: project management,it pm,information technology,software development,managing software,application development

Better Estimating Through Software Sizing

How do you know how long it will take?  Gut feel is how many do their estimations.

Late last year, I attended a webinar that intrigued me.  I had heard of feature point analysis (FPA) before, but I didn’t know much about it.  I decided to look into it more.

Software sizing is the software engineering term for estimating the size of a piece of software (whether component or entire application).  These estimates then can be used in project management activities.  Software sizing processes are a requirement for CMMi level 2.

Lines of Code

One of the original measurements for coding projects was Lines of Code (LOC).  When procedural languages were the norm, it gave a rough estimate of effort based upon the developer’s output.  With OO software, though, it is a less useful measure, and so it has fallen out of favor in recent times.

In the 1970s, IBM tapped Allan Albrecht to come up with a better tool for estimation.  The result was published in 1979.  He came up with a way of measuring based upon 5 areas:  Internal logical files, external interface files, external inputs, external outputs and external queries.  The Code Project has a 2 part posting that goes into more detail on function point analysis.  Unfortunately, it appears there were supposed to be additional postings that did not occur.

One of the complaints leveled against such measurement is the amount of time required to do the measurements.  However, an experienced person can document one person-year’s worth of effort in about one day.  While some criticisms of function point analysis may be valid, “others are excuses for avoiding the hard work of measurement” (Total Metrics).  There are far too many organizations that would avoid procedures in the estimation process if it took an hour because it would “take too long”.

To me, the biggest disadvantages are the requirements of previous measurements and specialized training.  Previous measurements can be substituted with industry standards, though you will lose the impact of organizational maturity and influences.  Training and experience increase the accuracy of estimates by the estimator.

You also have a catch-22 situation in that functional requirements need to be detailed enough to make an accurate estimate.  No matter the method of estimating, you’ll have this problem, anyhow.  Estimates are improved through the progressive elaboration of requirements.

Both of these disadvantages are quite likely to discourage, rather than encourage, a more systematic approach to estimation.  In addition, FPA is not without its critics for other reasons.  For one thing, best practices in software and the way software is developed is pretty far removed from the 1970s, when FPA was developed.

In addition, project management itself has changed a lot since then.  The concept of FPA might have worked fine with monolithic waterfall projects.  However, with the adoption of Agile by many organizations, such detailed analysis prohibits change rather than encouraging it.

Use Case Points

One alternative to pure FPA is estimation built upon the number and complexity of use cases.  There are tools that can make this much easier, and anyone who understands use cases already can put together an estimate with little additional training.

There is a Windows tool you can use to estimate size with use cases called EZ Estimation at http://ezestimation.googlepages.com/.  I downloaded it, and it looks like a pretty decent estimator that can be used in the requirements gathering phase.

Conclusions

A good plan today is better than a perfect plan tomorrow.

~ George S. Patton

One thing to keep in mind is that any initial estimate is going to be wrong.  That is why progressive elaboration is pointed out in the PMBOK.  One place I worked realized this and broke all but the smallest of projects out into an analysis phase and a construction phase.  The gateway for the construction phase was how the estimate stacked up against the analysis estimate and whether or not the project was still worth it.

The beauty of Agile, of course, is that estimates are adjusted as more is learned.  Estimates become more accurate, as estimates over the life of the project become more accurate towards the end.

If time allows, however, it would seem prudent to do enough analysis upfront so as to be able to hit that middle ground of estimation so that less will be left out in the end.  By doing use cases and using estimating tools based upon that seems to me to be the most reasonable approach.  The larger the project, the more this approach might make sense.  In an Agile environment, this would be done once to get the best possible overall estimate, but user stories, backlogs and adjustments after a sprint would still be carried out on  a normal basis.  The key would be “appropriate detail” in use cases.

I would love to hear anyone’s experience with these.  I have a feeling it depends a lot upon the type of project, the type of customer and the overall project size.

Technorati Tags: pm,it pm,project management,software development,estimating,software sizing,function points,function point analysis,use cases,agile,waterfall

—
Sources:

1. Buglione, Luigi.  (25 July 2008).  Functional Size Measurement.  Retrieved 12 May 2009 from http://www.geocities.com/lbu_measure/fpa/fpa.htm.
2. Cohn, Mike.  (2005).  Estimating With Use Case Points.  Retrieved 12 May 2009 from http://www.methodsandtools.com/archive/archive.php?id=25.
3. Function point.  (n.d.).  Retrieved 12 May 2009, from http://en.wikipedia.org/wiki/Function_points.
4. s.kushal.  (11 Mar 2007).  Function Point and Function Point Analysis.  Message posted to http://www.codeproject.com/KB/architecture/Function_Point.aspx.
5. Software Composition Technologies, Inc.  (June 2003).  Function Point FAQ. Retrieved 12 May 2009 from http://www.royceedwards.com/floating_function_point_faq/about_function_point_analysis.htm.
6. Software Sizing.  (n.d.).  Retrieved 12 May 2009, from http://en.wikipedia.org/wiki/Software_Size.
7. Total Metrics.  (June 2007).  Methods for Software Sizing: How to Decide which Method to Use. Retrieved 12 May 2009 from http://www.totalmetrics.com/function-point-resources/downloads/Why-use-Function-Points.pdf.

When Am I Done?

The question of “done” comes up quite often.  Ask a developer when the coding for the module is done:

PM: Is the module done?

Developer: Yes.  I finished it yesterday.

PM: Good!  So, it works with the user interface that Jo is working on.

Developer: Well, I don’t know.

PM: So, I thought you were done.

Developer: Well, I coded it.

PM: Did you test it?

Developer: No, but it’s otherwise done.

PM: Well, how do you know it’s done if you haven’t tested it?

You laugh.  Unfortunately, entire projects can be like this as well.

Sponsor: Is the project done?

PM: Yes, it is in testing now?

Sponsor: Well, if the customer isn’t using it yet, how can it be done?

PM: Well, the important parts are done.

Sponsor: But, how do you know it will pass testing?

These scenarios depict the problem of “done”.  Done should be done, and the measurements need to be clear and defined.  “Done” is not some vague feeling.

This doesn’t mean WBS tasks should be a micromanaged checklist of activities to check off.  Each task should be a work package that is identified with inputs and outputs.  Each task should be no less than 1 day in duration, and typical work packages are under 80 hours in duration.  Of course, the larger the project, the larger the work packages may need to be.  It requires a balance between a WBS where tasks can be adequately tracked and having so many tasks that people don’t know which they are really working on.

However, there needs to be a definition of when the task is done.  Scope needs to be clear throughout the project.  Perhaps, a generalization of when a software module is complete:

1. The test cases are clearly written out according to the functional and technical requirements, along with responses for invalid input and approved by the testing engineer.
2. The code is written and compiles without error (don’t assume).
3. The module has been tested and passes its test cases, including those for invalid input.
4. The module has undergone peer software review and all high priority recommendations have been implemented.

Note the inputs and outputs in each of these.  This is vital.  Notice that each has a qualifier: approval, no compile errors, passes test cases, implementation of peer recommendations.  Safety gates keep low-level scope creep to a minimum.

Setting up and communicating rules for “done” will reduce confusion later and stop additional ridiculous “tasks” (really activities) on a WBS.  Team members should be encouraged to provide any additional rules that may be specific to the project or the environment they are working in.

Note that if, using these guidelines, developers are still hesitant in giving estimates for completion of work packages (tasks in WBS), then identify if the requirements and approach are clear or if there is something missing.

Using work packages allows developers to get the job done without micromanaging them.  Give them a target, and have them aim for it, rather than telling them how to do their jobs.

Setting up and communicating appropriate rules for “done” with a project will similarly reduce nasty surprises at the end of the phase/iteration/project.

Technorati Tags: it pm,pm,project management,software development,done,when are you done,task completion

It’s Not Just My Opinion

Someone actually did a 5 part series of articles on “Why Software Development Projects Fail” that states a lot of what I have been telling people for years:  The need for the correct methodology, the need for enduser involvement throughout the length of the project, the need for special care when using distributed teams and the need for visual prototyping.

Although aimed at CIOs, it is a series that any consultant or project manager should read as a review.  Because, your CIO might not have read it.

I guess my only possible disagreement would be whether or not there really is a need for waterfall in today’s world.  However, I readily concede I’ve never worked for NASA, so perhaps it really does work there.

Technorati Tags: it pm,project management,information technology,software development,cio,pm,why projects fail,implementing project management,requirements gathering,methodology,release,implementation,distributed teams

Defensive Programming

Remember when you learned how to drive, and you had to take a course called “defensive driving”?  You learned to anticipate problems on the road instead of racing down the road assuming nothing would ever go wrong.  By driving in a manner that would put you in the best position possible should something go wrong, you often avoided anything going wrong at all.

Software developers tend to be an optimistic bunch.  Write code for that?  No problem!  Want it in a week?  No problem!  Somehow, they tend to underestimate the power of a computer to do only exactly what it is told to do, whether by their own code, someone else’s they have to interface with or the compiler.

Agile development encourages people to do their test cases up-front.  I am in complete agreement with that concept.

There are problems with that, as there are with anything in life.  In “Developers Can’t Test for Toffee!”, Kelly Waters asks, “Why is it that developers can’t test?”  Waters pretty much states it is the “can’t see the forest for the trees” syndrome.  Developers can only test for issues they think of.  They are down in the bowels of the code, so naturally testers can think of scenarios the developers have not.

Waters makes a pretty good case, I think.  However, my experience is that most developers aren’t trained to think about what goes wrong.  I remember more than one post-mortem where I would ask, “Why wasn’t this accounted for?” and the answer very often was “I never thought that [condition] would occur.”

I guess I was fortunate in that I had a professor who insisted that code ran and produced the expected result.  “Code for the error conditions first,” he used to say.  “Think about what will happen, because it eventually will, when you get in some bad data.  Don’t assume users will input valid data.”

I began to call this concept “defensive programming”.  Anticipate the problems before the best case scenario is even written.

Technorati Tags: pm,it project management,software development,programming,coding,bugs,risks,risk management,defensive driving,defensive programming,agile,test cases,developers,testers,kelly waters

The Beast Called “Waterfall”

There seems to be an unofficial theme this week of pointing out some fallible lines of thinking.  I honestly didn’t plan it to come out this way, but sometimes patterns emerge before we become cognizant of them.

This week started off talking about “What is Agile Project Management?”  Basically, describing Agile as a “methodology” doesn’t make much sense.  Rather, it is an umbrella, or better a philosophy, underneath of which are some methodologies (scrum, XP, etc.).

Tuesday, I pointed out some faulty beliefs that point to a lack of proper priorities in “Where Is the Time?”

Wednesday’s post was on “Web 3.0, Anyone?”  While the technology is emerging to do some really cool stuff, a lot of it just isn’t here yet.  Somehow, though, I saw job postings for people “experienced in Web 3.0”.

Thursday’s post was about “Don’t Make It Hard!”  This was mainly about how people can make things harder than they need to.  It also scratched the surface of how a team’s reaction can make the problems worse.  Finally, I used the example that bore the topic of implementation and how it isn’t implementation that is hard, but rather it is the sequence of steps and missteps that lead up to it that are hard.

It seems appropriate today to come full circle and examine the waterfall method.  Just like the others this week, I read something that made me go “No!” out loud.

In case you are new around here, let me summarize from my own Associated Content article on “Agile Project Management” just how I feel about the waterfall:

Like a dinosaur, the waterfall methodology is large, cumbersome and slow. If it trips and falls, it makes a very large noise. Unfortunately, the waterfall is not like a dinosaur, as the latter is extinct.

So, what do you think went through my mind when I read that Steve McConnell of all people wrote about a company that “embraced Extreme Programming (XP) as the development approach”.  Yet:

Development went on for about two years. While the team was being highly responsive to customer input, that wasn’t good enough. The cumulative total of its work was not converging to anything resembling a saleable product. Eventually the company concluded that the team was never going to produce a product, at which point most of the 200 people were laid off and the company reported a $50 million loss on the project.

~ McConnell, Steve.  (29 July 2008).  Agile Software: Business Impact and Business Benefits.  Retrieved 29 April 2009, from http://forums.construx.com/blogs/stevemcc/archive/2008/07/29/agile-software-business-impact-and-business-benefits.aspx.

The real tip-off here is that nothing was “converging” to make a “saleable product”.  Say what?

Sometimes life is a lot like Alice in Wonderland (or at least the Disney version).

Alice: Would you tell me, please, which way I ought to go from here?

Cheshire Cat: That depends a good deal on where you want to get to.

Alice: I don’t much care where–

Cheshire Cat: Then it doesn’t matter which way you go.

Alice: –so long as I get somewhere.

Cheshire Cat: Oh, you’re sure to do that, if you only walk long enough.

On George Dinwiddie’s Blog, Dinwiddie posted an article “Agility and Predictability”, where he addresses the predictability factor.  However, I want to focus on the fact that the product owner in the above example “didn’t have a vision for a salable product.”

I hope many of you got the chance to attend the webinar yesterday on “Agile Requirements (Not an Oxymoron)” by Ellen Gottesdiener of EBG Consulting.  She pointed out you need: A “now-view” at the iteration level, a “pre-view” at the release level and a “big-view” at the product level.  It is debatable if the team even had a release level view in McConnell’s example, but it is certain that they did not have a “big-view” of the end product.

Agile is no excuse for not knowing where you are going.  Agile won’t help you get there if you don’t know the destination.  The methodology cannot help you if you are simply wandering around Wonderland.

In fact, Agile is not a cure-all by any means.  If anything, Agile will tend to uncover organizational and procedural deficiencies much sooner than the waterfall method.  However, regardless of the methodology, if an organization buries its head in the sand, it won’t work out.  One of the main features of Agile is evaluating performance at the end of a sprint.  Like any evaluation, though, individuals and teams can gloss over and politic, or they can admit mistakes and make adjustments.

Waterfall will cover up mistakes until the very end, when suddenly, everyone realizes the project is behind schedule.  It’s almost inevitable on any project of any complexity or of any significant size.  So, yeah, waterfall is more “predictable”.  It is more predictable that it will fail!

When does waterfall work?  Waterfall works when the results and processes to get there are well known.  If you are setting up servers just like the last 20 you did in the last quarter, then the waterfall approach will most likely be suitable.  When the chance of randomness is very low, then it is much easier to project the end.

Waterfall also works when the duration is shorter than 4 weeks (not including project management paperwork).

IOW, waterfall sometimes works when the one iteration is about the same size as recommended for one or two Agile sprints!

When you think about that, you think about how there is no real feedback until the end of the cycle, you think about how little testing is done until the end and you think about “progressive elaboration”, then why would you tie your cart to the waterfall horse?

Technorati Tags: it pm,project management,sdlc,plc,pmbok,definition of project,agile,waterfall,methodology,scrum,predictability,vision,product,software development

Book Review: The Big Red Fez by Seth Godin

OK, I’ll admit it: I am a fan of Seth Godin.  I got introduced to Seth’s Blog through Small Business Trends (specifically Anita Campbell).  Consider this a free endorsement, guys!  I am not associated with either in any formal manner (but I know Anita from a previous company).

So, that’s why I have such high expectations of Seth’s books.  My expectation of The Big Red Fez: How To Make Any Web Site Better was no different, and it did not disappoint!  If you are in IT and have any say whatsoever in the user interface, especially on the web, drop everything and get this book!  Now!  If you are a front-end developer, get this book.  If you are an IT manager overseeing software applications that run on the web, get this book.  If you are a project manager overseeing web projects, get this book.  If you are a QA engineer and test the front end, get this book.  Oh, and did I say to get this book?

Compare the price of this book (under $10) to any user interface guide, and tell me what gives you the bigger bang for the buck!

Godin presents the material from the viewpoint of a user.  We in IT need to face the fact that it is the enduser who is going to either validate or invalidate the interface.  Unfortunately, some engineers forget that it is the enduser who either is going to use the thing or quit and do something else.  If that enduser is internal, then you might have a captive audience, but you will also have a lot of trouble tickets and user frustration.  If that enduser is a customer, they might just decide your competitor’s site is easier.  Not only does Godin provide very practical advice, but he does so in a way that is humorous and engaging.

Godin starts off by telling us that engineer’s and marketers view user interfaces differently.  He then will have us imagine a monkey in a red fez.  You know, the kind that you see in the pictures of organ grinders and such.  What motivates the monkey?  Bananas.  The monkey searches for the banana in the same manner that a user will search the web site for the payoff.

Before I get too far along, Godin isn’t looking down on people.  He includes himself in this by saying “we” and “us”.  He stresses the point that “we” are often too busy and “we” are distracted too much to really think very long about a web page.  In fact, he later on tells us that the average person decides whether or not to stay on a particular web page in 3 seconds.  Therefore, the banana must be so obvious that it sticks out on a web page in 3 seconds or less.

OK, let’s get the cons out of the way first.  Or, should that be “con” singular?  Godin puts in a lot of screenshots, thankfully.  However, be sure to have your reading glasses on!  I was reading it with my lower powered glasses, and it was a bit of a struggle.  Fortunately, the accompanying text pointed out the important bits.

Still, I have to admit that there were times when I was reading through the book and I was ready to exclaim “hallelujah!”  Just about every pet peeve I’ve ever had with websites is in this book.

In more than one section, he points out that a lot of input screens ask for redundant information.  In “If the Computer is so Smart, Why am I Doing All the Work?”, he asks why does it ask for a billing address when you’ve already given it a shipping address.  Right across the page is one of my favorite pet peeves: You know the zip code, so why are you asking for the city and state? Let me add one even further, because I’ve seen some horrendous ones lately that ask for country, state, region of state and nearest municipality, all with the zip code and city already input!!!!!  I can understand why Godin says that 60% of all online shopping carts are abandoned just before checkout.  I know I’ve done it.

OK, another pet peeve I have with about half of existing software is the handling of error states.  They are not graceful, they are usually uninformative and they are sometimes downright cryptic.  Godin’s perception on these is that on the web it is even worse because many error pages do not give any rewards for reporting the error, no way to contact someone about the error and no incentive for even trying again.  In other words, companies are just begging you to go visit the competition through frustration.

Oh, yeah.  Ever been in cubicle and need to check out something online, only to go to the site and have it blare out loud music? What about going to a website and have it play some dumb movie when all you want is to check on the price of an item?

The point is, you don’t want to lose a potential customer in a maze of unrelated activities that not only frustrate them but cause them to become either frustrated and quit or think less of your company or IT as a result.  Decide what the goal should be and put the banana in an obvious place to lead them there.  Make it simple to view and simple to use.  Imagine how much easier tech support would be if everyone did this!

I’m going to repeat my mantra here: Internal users are internal customers.  If internal customers get frustrated, then IT gets a bad rep.  That affects everyone in IT eventually.

The book covers much, much more, but one point that project managers can relate to is measure the changes.  You don’t know if you are improving or not unless you measure.

Once again, even though Godin writes from a “marketing” point of view, he hits a homerun with IT management concerns as well.  Go to his site, go to the link at the top of this review or go to the library, but read this book!

Technorati Tags: pm,project management,it management,user interface,web apps,web applications,usability,customer oriented,customer use,internal customer,software development,business analysis,web design