Using a shared code repository and project tracking tools is not enough to guarantee that all project work is transparent. One of the most important benefits of Lean-Agile is that it brings this transparency.

why is transparency important?

It’s more efficient. It is undeniably more productive to share work and get input from others at every step in the process. Coding (or writing documentation, or building a website, or working on any project) all by yourself with little or no feedback for long stretches of time might seem acceptable, or even cool, for a while — if you’re inexperienced or a cowboy. But in reality, it is burdensome and buggy. It’s rife with questionable decisions, bad habits, and shortcuts. Egos get tied too closely with products. Troubleshooting and maintenance becomes a real killer. And pity those who inherit the lone wolf’s pile of work later on.

Lean-Agile’s systematic approach helps ensure that the entire team is aware of what is being worked on and how the work is progressing. Tracking tools (we use FogBugz to good effect), Kanban boards, incremental unit- and acceptance-testing, daily standups, iteration planning sessions, retrospectives, and vigilant facilitation every step of the way help to keep team members from straying off course or going underground.

Problems cannot hide. Agile’s transparency can work so well that it is sometimes misunderstood as the cause of dysfunction and antipatterns. What it is actually doing is uncovering quagmires that have been hiding there all along.

Shortly into our own Agile implementation, a group of items infested our product backlog and refused to go away. These Zombie Features and Defects made something that we suspected all along abundantly clear: We were spending too much time on certain customizations at the expense of working on far more valuable common-good products and services. It also became apparent in our planning sessions that multiple projects vied with one another for top priority — which led us to beat this lack of prioritization into submission and actually prioritize.

Everybody is informed. Everybody learns. Agile team members must be highly cognizant of one another’s work. They have to be involved in planning iterations, evaluating the team’s overall progress, stepping in where needed, developing and agreeing on best practices, and testing and vetting one another’s contributions. Cross-functional learning is an integral part of the workflow. Team members develop an ever-increasing understanding — and a deeper appreciation — of other specialties.

further reading

• The Art of Agile Development
• Agile & Lean Benefits FAQ
• Agile Resources

poster presentation:

• presentation handout
• ploneedu poster
• weblion poster

flickr:

• my photos: highedweb conference 2010
• all flickr photos tagged with heweb10

twitter:

• #heweb10

Thank you, xkcd.com.

Home | Priorities | Giving | Council | Alumni Efforts | Foundation Challenge

You might be able to guess that this is the main navigation for an alumni site of some school. But aside from Home, can you formulate a clear idea of where any of these links will lead?

Supposing your goal is to join this institution’s alumni association. Which of these links would you follow first? Would you follow any at all? And what exactly is a Foundation Challenge, anyway?

You see this all over the Web: critical navigation distilled down to as few words as possible–preferably a single word. Design teams hold meetings in which everyone struggles to come up with the right word to describe a category of activities, a diverse collection of information, a whole branch of services. It’s mind-numbing work, and for a good reason: few single- or two-word descriptions are up to the job. The result is navigation written in a sort of cryptograph that’s maybe understandable to people within the organization but that users must decode by pogosticking all around the site.

This overcondensation of information started with the earliest table-based Web designs, the going mindset at the time being

1. the zeal to keep page dimensions small enough to be seen in their entirety on very small computer screens
2. the assumption that users are never willing scroll under any conditions

The accepted practice was to design Web sites roughly as squares about 600 pixels to a side. Navigation was encased in minute rectangles, stacked in attenuated columns, or paired with distracting and largely useless graphical buttons. Sites of any volume frequently had architectures many layers deep to accommodate the brief amount of signage available in each section.

Eventually, better equipped and more informed Web design delivered us from these claustrophobic dimensions. But the wording of links seems to be slow in recovering. Navigation still frequently gets squinched into little bitty wafers. One of the worst offenders of this is the nearly universal horizontal top navigation sandwiched just below page banners or conflated with the banner design itself. Aside from often falling prey to banner blindness, this type of navigation frequently allows for nothing but the briefest of signage.

Contrast this with the findings of Jared Spool et. al., which show that links of around 7-12 words are far more successful at creating a strong scent of information. This wording can, and often does, include associated text, such as “To see previous issues of Dairy Digest, visit our archive.”

Of course, length alone doesn’t determine whether links will actually help users make correct navigational choices. It’s the wording that must make it abundantly clear what information lies ahead. Wording that instills confidence in the navigating user: Yes! I am heading in the right direction!

I discovered a fine example of this in the late ’90s when I worked on the marketing team in Penn State’s Office of Undergraduate Admissions. Our team spent several months gathering marketing data on student’s applying to Penn State (and their families) to learn what information worked best for them — and how best to deliver that information on the Web and in print. At the time, we had a pretty good idea that the phrase “Prospective Students” meant little to them, and our research confirmed this. But what we learned in addition was that widely used “Future Students” also missed the mark. In the end, we found that “Students interested in applying to Penn State” or “Students interested in attending Penn State” spoke to our audience much more clearly, and that’s what we used in our materials.

The next time you find yourself or your design team wording navigation by casting about for le mot juste, entertain these questions:

• Is the site design imposing too much of a space limit on navigation?
• Who are we helping by condensing the text of our links down to one or two words?
• Do we actually knowwhat trigger words work for this audience?

Granted, sometimes strong scent of information can happen in one or two words within a tiny wafer somewhere near the top of the page. More often, it cannot.

This presentation also is published at http://docs.google.com/present/view?id=ddjp8wn9_1389hk6r9md3.

This presentation is also published at docs.google.com/present/view?id=ddjp8wn9_1271dnxfh2cg.

Here’s how the attack appears in server logs:

The code creates a cursor of all the user tables and all the character columns in the database. It then appends a string to each of the columns, making an ungodly mess.

Mark Kruger’s post goes into a great deal of helpful detail about how this spider operates. If you do a Google search on this attack, you will quickly get a feeling for how widespread this is.

If your site is getting hammered, and you need to buy time while you fix vulnerable code, there are scripts such as this one posted in ColdFusion Developer’s Journal on August 8, 2008, which can be modified to thwart this most recent attack thus.

Be aware that this only buys time. The most effective course is to make sure your queries are protected with cfqueryparam. Ben Forta’s primer on cfqueryparam provides a very good start on protecting code from SQL injection scripts. While you’re fixing your queries, don’t forget the ORDER BY clause, another frequently overlooked vulnerability.

It can be time consuming checking all your queries if you have a large amount of ColdFusion code to wade through, not to mention nerve-racking if you are doing so while the attacks are rolling in. Fortunately there are tools such as QueryParam Scanner that will peruse your code and return a list of any unprotected queries. Unzip this application and place it in a directory in the Web root of your development server. Go to the application in a Web browser, follow its directions, and you will quickly have a report of any vulnerable queries.

• For more links on this particular attack and how to thwart it, go to http://delicious.com/rpruyne/coldfusion.

::: view the slides

play the screencast

listen to the podcast

subscribe