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 »

 

Recently there has been a long, and very interesting, discussion of do-it-yourself versus third-party metadata tools on LinkedIn’s TDWI BI and DW discussion forum (membership required to follow the link). I have followed but haven’t commented, but I suppose I contributed when Information Management kindly published my article on DIY metadata.

The discussion is extremely informative, presenting the views of a variety of knowledgeable professionals in different situations, and describing successful and sometimes not-so-successful efforts to solve the essential metadata challenge: how to document what information is locked up in databases. Continue reading »

 

I’ve often thought that conceptual data modeling was an underused tool in the arsenal available to requirements analysts, and in a recent conversation I found that many were surprised that it would be used in the requirements phase at all.  Checking the Business Analysis Body of Knowledge (BABOK) I found data modeling listed among the tools available to requirements analysts to “to describe the concepts relevant to a domain, the relationships between those concepts, and information associated with them.”  There’s also Steve Hoberman’s excellent book on the topic, Data Modeling for the Business, an introduction to data modeling aimed at a business audience. Continue reading »

 

Thanks to all who attended my presentation at Richmond Code Camp 2010.1 on May 22.  Here’s a link to the PowerPoint presentation:  The Business End of Data Modeling (2.5m)

The presentation was about what to expect before you start database design and what to do if you don’t get it. Software development  professionals apply technology solutions to meet business needs. The problem is that sometimes we’re expected to meet business needs that aren’t well defined, or not defined at all. The presentation reviewed the requirements side of data modeling and how it prepares a developer to design and build the right solution. Then, it covered typical scenarios where critical business definition elements are missing and what the app dev professional can do make up for the missing requirements pieces and produce a successful result.

 

I always thought the analogy would be cheesy, but Adrian Cho’s “Jazz Process” is a carefully researched and well presented “framework for improving collaboration, innovation and agility inspired by the way in which jazz musicians deliver strong, innovative performances.”  Mr. Cho, with deep roots in both jazz and application development, presents a method for app dev teams to work together the way jazz musicians do to “deliver on-time, high-quality performances that will attract and retain customers and do it all in real-time under continuous scrutiny.”

To put cards on the table, while Mr. Cho is a dedicated dual-career professional who plays jazz at the highest level, I’m a dedicated IT professional who spends some evenings as a serious amateur at local watering holes and private parties.  To me, Mr Cho really nails it.  He groups 14 principles into four categories on how teams can effectively work, collaborate, execute, and innovate together, bringing honed skills, “big ears”, trust, and commitment to deliver successful outcomes. Continue reading »

 

Thanks to all who attended my presentations at SQL Saturday on April 10.  Here are the materials from my two presentations:

- The Business End of Data Modeling (2.5m powerpoint presentation)

- Normalize Metadata For Data Integration Analysis (5.5m full version, zip including presentation and code samples)

- Normalize Metadata For Data Integration Analysis (small) (2m reduced size version, graphics removed from ppt file)

Here are some quick notes for those looking to run the Metadata prototype:

The prototype metadata database includes SQL Server 2008 data definition language and data manipulation language (DDL and DML) needed to create the database and populate it with tables and columns from Microsoft’s AdventureWorksDW sample database. It also includes a sample requirements spreadsheet and source-to-target map, and SSIS jobs to load the spreadsheets to corresponding metadata tables. These define fictional requirements and mappings to populate the AdventureWorksDW FACTInternetSales table from tables in the AdventureWorks sample database.

AdventureWorks and AdventureWorksDW are available here: http://msftdbprodsamples.codeplex.com/Wikipage (accessed 4/14/2010)

 

“Our goals can only be reached through a vehicle of a plan, in which we must fervently believe, and upon which we must vigorously act. There is no other route to success.” – Pablo Picasso

It is an old story: about 30% of IT application projects succeed, 45% are “challenged,” and the other quarter fail altogether.   That’s the consistent result over the years of the Standish Group Study of Project Outcomes.  Jorge Dominguez, here, displays a chart of the remarkably similar results since 1994.  Not a pretty picture, right?  Some question the validity of the Standish studies, but Scott Ambler parallels the Standish story in a recent Dr Dobbs column called “Lies, Great Lies, and Software Development Project Plans,” which itemizes the strategies commonly used by IT project managers to “stay out of trouble” when schedule/budget results don’t match initial estimates.  For example, “18% change the original schedule to reflect the actual results”. Continue reading »

 

I was preparing a presentation about databases and thought of a Dilbert strip I’d seen years ago.  Easily distracted, I searched for it.  I didn’t find the strip itself, but here’s the transcript I found:

Boss: I just got our consultant report and he has identified our biggest problem

Wally: I recommend that we build a tracking database

Dilbert: We can put it on the network

Boss: Would you like to hear what the problem is first?

Wally: I hate to dwell on the negative

Dilbert: We like databases

Boss: You haven’t heard what the problem is yet, how could you recommend building a database to resolve it?

Wally: We always build a database

Dilbert: And we will need coffee mugs for the project team.

Boss: The problem is that we have poor process

Wally: That could be the slogan on our mugs.

 

Need uber-guru types who are willing to challenge the existing groupthink on design and architecture, especially on TDD and emergent design and pair programming anti-pattern” – job post at Monster.com 2/9/2010

I stumbled upon that quote following links on the role of the architect on an agile project. Maybe one important role of the architect is to help the team avoid groupthink. Continue reading »

 

Update 1/28/2010: Saturday’s event postponed to April 10 due to threat of inclement weather Continue reading »

© 2011 Bob Lambert Suffusion theme by Sayontan Sinha