Out of curiosity I recently reviewed articles critical of Agile Methodologies. I had expected agile-versus-waterfall arguments and attacks from vendors selling new alternatives, but even given the reputation that advocates have for flaming well-intentioned critics, I wasn’t prepared for the level of emotion I found.
My opening position was that Agile techniques are great, but like any other tool there are limits and prerequisites. The critical articles I read strengthened that view. Let’s review three examples that stood out, in reverse order: Continue reading →
As important as it is, data modeling has always had a geeky, faintly impractical tinge to some. I’ve seen application development projects proceed with a suboptimal, “good enough”, model. The resulting systems might otherwise be well-architected, but sometimes strange vulnerabilities emerge that track directly to data design flaws.
Recently I saw an example where a “good enough” data design, similar to the one pictured, enabled a significant application bug.
Recently the BBC posted this video. On first view it is just funny, but watching those dogs learn to drive really reminded me of personal experiences with IT teams making big learning transitions. To represent those real situations let’s consider a fictional team of SQL developers facing the daunting task of deploying a functional Hadoop-based analytics prototype in two months. The video parallels their critical learning success factors: (1) set audacious goals, (2) learn bit by bit, and (3) know your limits.
Recently I was in a conversation about data modeling standards. I confess that I’m not really the standards type. I understand the value of standards and especially how important it is to follow them so others can interpret and use work products. It is just that I prefer to focus on understanding of the principles behind the standards. In general, it seems to me that following standards is trivial for someone who understand the principles, but impossible for someone who doesn’t. But there doesn’t seem to be general understanding of data modeling principles. Continue reading →
In my experience, some BI projects ultimately finish as a success, but exceed budget and schedule targets and fall short of functional goals along the way. On projects like this, somewhere in the midst of report development, things get sticky and tasks fall behind schedule as the team runs into unexpected complexities. Continue reading →
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 →
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 →
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.
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.
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.