Tag Archives: Project Management

Be careful with agile methods if…

I’ve written a number of posts about agile techniques of project management on this site, all in a spirit of advocacy. A comment on the most recent reminded me that agile/scrum isn’t necessarily the right solution in all situations, and in some it may work but needs to be applied carefully. After that comment I thought it would be interesting to write about situations in which agile methods should be applied with care, if at all: Continue reading

So Agile/Scrum Really IS Like Rugby

OK, I’ve lost a five-metre scrum, my pack has been overrun, and the ref has raised his arm between the sticks for a penalty try.  My colleague Margy Thomas, with support of fellow rugger Billy Tilson, has convincingly argued that agile development in fact is very like rugby union. Margy cleverly fended my meager one-point case with a point-by-point list of the ways that agile projects and rugby are similar. I’ll hold on to my view that sports analogies are generally weak in describing application development, but I’ve come to observe a fundamental similarity between rugby and agile/scrum. Continue reading

Double test efficiency and build app dev culture at no charge

What if you could double the efficiency of your software testing process, and substantially reduce errors found during the test, deployment, and maintenance phases, without purchasing any tool or method? The November 28 InformationWeek offers just that in a reprint of a recent Dr. Dobbs article on formal inspections by Capers Jones and Olivier Bonsignour.  They call formal inspections the “defect removal tool of choice” and back up their claim with lots of hard evidence, but I think they are still selling short. Continue reading

Project managers: is yellow the new green?

I’ve never understood the obsession with “green” status among IT application development project managers, and the intense pressure put on them to “stay green” by the program management offices (PMOs) they report to. We would benefit from a cultural shift away from avoiding yellow status.

For those not in the field, it is in vogue to express IT project status using a stoplight analogy, where green means things are going well, yellow indicates some quality, schedule, or budget risk, and red means there’s imminent risk of failure.

Continue reading

Get an early start for on-time data modeling

I’m a data modeler, so I enjoyed Jonathon Geiger’s recent article entitled “Why Does Data Modeling Take So Long”.  But why does he say it like it’s a bad thing?

Mr. Geiger’s bottom line is exactly right: “Most of the time spent developing data models is consumed developing or clarifying the requirements and business rules and ensuring that the data structure can be populated by the existing data sources.”  On the projects he describes, no one took time before modeling to determine available data sources and identify business entities of interest, relationships among them, and attributes that describe them before database design started, so the data modeler had to do it.

Continue reading

Thoughts after agile training: strengthening values, reducing the cost of honesty, and growing apps

I recently completed ScrumMaster training ably presented by Lyssa Adkins. Throughout the two-day class we appreciated Lyssa’s Zen-like, enabling, style. If her name is familiar, it’s because Ms. Adkins is the author of the book Coaching Agile Teams, one of the leading texts on the subject.

I’ve participated on agile projects, but so far only in a piggish/chickenish role, once in a three-week stint as a consulting architect and twice as the project manager serving as interface to the non-agile organization.

To me Ms. Adkins rocks at making students very introspective and critical of their past project experiences.  These lessons stand out:

Continue reading

Health care data security: how bad is it?

It is really bad, according to a recent survey by the Ponemon Institute (available here with registration). The white paper, entitled Health Data at Risk in Development: A Call for Data Masking, presents the results of a survey of 492 health care IT professionals on their companies’ practices regarding use of live personal health care data in application testing.

It makes a scary read.  Here are the lowlights: Continue reading

But is it art? Skills of the next generation BI professional

There’s a data explosion going on and perhaps the strangest result is that business intelligence analysts need to become more artistic.

Recently my friend Ben Harden directed my attention to a post from Steve Bennett of Oz Analytics on the future of BI. One challenge to analysts that Mr. Bennett cited was the unprecedented explosion in data quantity to “an almost inconceivable 35 trillion gigabytes” by 2020.  Part of the solution, according to the post, is “actionable insight”, as illustrated by Harry Beck when he created the now-iconic map of the London underground network from the previous rather spaghetti-ish version.  What Mr. Beck did was to distinguish significant from insignificant detail for the intended audience and present that detail in a clear and appealing way.

Continue reading

Building a writing culture in application development

One of the key skills needed in today’s IT shop is communication, and one of the best ways to improve ability to communicate is to write blog posts and articles.

In spite of “IT guy” stereotypes, communication and analytical thinking about business are among the most important skills in application development. Developers, analysts, and managers require ability to interact effectively with business people, to conceptualize solutions that match business needs, critically evaluate those solutions, and effectively make the case for one of them. Of course this is true of the overall project business case, but more importantly it applies to the daily “IT guy” to business person conversations that happen throughout analysis, design, development, and testing. Continue reading

Agile development: rugby analogy considered harmful

Recently my friend Mark Hudson posted about the inappropriateness of the term “sprint” for an agile project phase, preferring the cycling term “interval.” That post really struck a chord with me.

As a rugby union fan and former wing/fullback I’ve always thought the whole rugby analogy was wrong. Agile development is continuous and fluid, yet the agile originators chose the word “scrum” for its daily standup meetings.  In rugby union a scrum is a set play resulting from a minor penalty, like offside in American football or a foot fault in tennis.  If you like the rugby analogy the right term would have been “ruck,” which is kind of like a scrum but part of the continuous run of play (in the other kind of rugby, called rugby league, the scrum has devolved into an almost meaningless stylized ritual – which I guess happens on some agile projects). Continue reading