Agile Information Management

Generally on a topic so important I would spend the time to write about this in a more palatable manner - but as time is limited I am going to give you the information without couching it in a example. For that please read Dr. Kevin C. Desouza's book - "Agile Information Systems: Conceptualization, Construction, and Management" which was very helpful to me when I had already reached the same conclusions during a very high visability consulting gig. His book allowed me to defend my position definatively and objectively. (http://www.amazon.com/Agile-Information-Systems-Conceptualization-Construction/dp/0750682353)

Don't wait until you are working on a project that matters to you (read: "=$$$") to understand that we may live in a world once inhabited by dinosaurs but using old clumsy methods are not an effective way to create and scope new software projects or manage information effectively. Here's the straight dope --

Agile development models include just in time information gathering processes. Agile information gathering processes include rapid collection of content and the clear appearance of the resulting documents. Collecting technical business requirements and immediately folding them into the client template is an agile information management method in planning software requirements.



Business Analyst Teams need to capture requirements as they are clarified. This is especially important when:
1. The deliverable is the requirement document first and foremost
2. The outline for documenting incoming requirements already exists
3. Tight deadlines exists and there is any risk of delays in documentation, or in overlapping out-of-date information being presented to the client–
4. Or if the document control tool, which is commonly used for working together interactively, is flakey and as a result document versions may become dated

It is not an agile process to wait to add known requirements. For example having project management, or development directing a business analyst to wait until later to add or modify incoming requirements prior to a document presentation. It makes sense to put the correct and current requirements into the current document. It is more logical to keep found things found by categorizing them immediately. (It's a little like keeping the kitchen clean - do it right away).

1. It is a waste of time and money, searching when editing the same document repeatedly, or by different individuals, when the requirement should be added on the fly
2. It is frustrating for the BA trying to keep track of multiple versions of the same requirements, it is frustrating for the client when they read out of date requirements
3. It creates unnecessary control issues
4. It runs counter to the clients' actual needs and requests
5. It isn't agile any more, it is an outdated technique!

Presentation of business requirements is 50% of the job of development consulting, that is, what a document actually looks like really matters to governance and business people.

1. Because governance and business people spend all their time in documents, generally they want them to look familiar and be formatted correctly, so it makes sense to use their existing templates
2. They care about documentation, and delivering documentation is your value to them, in other phases they may care about the actual software project delivery or user interface
3. Your clients will never have your depth of knowledge regarding technology, which means you will have to explain your processes and reasons if you do it any other way (slowing the process down) besides using their processes and procedures
4. The business and governance or project management office people will participate in decision making about actually building the project, or not, and you want them to want to work with you, by showing that you will work with them!

When things go south in a project managed and maintained by old, confusing, out of date, clumsy methods - at least YOU will know why. And if you get really great at sniffing out these kinds of information management control issues, perhaps you can head them off at the pass, and get your posse working together effectively to collect the information you need and turn it into the requirements you need right now.

Agile workplace configuration at Microsoft

Working as a development product manager at Microsoft at the time I had no idea what scrum or agile development was, but this configuration of tables and chairs in the hallway of the 3rd floor of Microsoft's Building 114 just made sense to me.

I found these tables abandoned or stuck in hallways from other floors and dragged them here with my new team members. Then I ordered comfortable chairs from Microsoft's internal portal. We were set and took off and developed like mad.

The person, my friend, in the foreground found our environment to her liking, quiet, convenient yet friendly and joined us; as many travelers or consultants did from time to time. This worked for many reasons and gave MS full-timers the ability to find and interact with us without having to search around much.

Due to the location, our rules were straight forward, low tones, quiet, leave nothing in the room when leaving, push in your chair, and police your area. As you see in this photograph we had one phone for 18 + people. It rarely rang. The person being sought was nearly always there.

Twice in several months there was a slight disagreement about how open or closed the blinds should be but that environment worked very well for the team. We launched our project on time of course.

I absolutely loved working with them.

After I studied and worked with Agile development I came to understand that the techniques I had developed on my own, such as short daily meetings (scrum), worked for others.

Design and Change in Highly Secure Corporate Settings ( a brief reflection )

The question posed was how do you design and develop in highly secure corporate settings, are there standards? what do you do when the corporate environment makes it too difficult to meet these standards?

As consultants we took standard security measures that went one step farther - everyone was required to lock computers (all laptops) upon leaving even briefly for a biobreak, all texts closed, printed matter of any kind was turned face down or placed in locked cabinets or shredded, no forwarding of internal email, text or images to external addresses, and use of Pretty Good Privacy encryption for FTP or transferred files over the Web to 3rd parties

When leaving for the day, all printed materials were removed from tables and desks, and all laptops went with the users. The building itself was cell dead, because it was a Faraday cage basically. As a scrum/agile team we shared a single phone which eliminated all but the most important and direct calls, such as arranging to be picked up from work.

This was not only the norm in the environment but specified in our contracts. Developers were required to perform a urinalysis (commonly called a 'pee test') prior to getting hired - but as it turned out that was not a requirement of the main company. A lead coming in refused on legal/privacy/moral grounds, and was transferred to another subcontracting firm where invasion of privacy was not promoted. Even better than that, the new subcontracting firm was honest, with the transfer came a $5 an hour raise. (He converted to full time almost immediately).


As PM/ team lead I requested everything be removed from all public and private working spaces which worked well. No casual public discussion of design / dev topics outside of our working environment and team members.

In prior orgs (which go unmentioned here) I encountered extreme difficulty explaining why one should use security, what the role of PGP was, and why use it (they had regulations against using any kind of encryption!) I insisted on testing Web security in application design. Finally my request went to an internal review board (Audit committee), and it gained backing for the spend (about a million to fix back end problems), using the following logical statement - "How many years do you want to have your CEO in jail for breaking privacy laws under HIPAA because the UI allows mal-use. " etc.

Some corporations are so far behind the curve on technology it is a struggle to work with them. I found shared terminology (language), and a safe phrase which worked - to a point - in convincing them to change, it was: "As your consultant I would not be doing my job if I neglected to point out X..."



A large part of being successful involved getting others onboard, through explanation and education of what is reasonable security (security audits in test, for Webapps and applications) and what isn't (pee tests for one class of workers), through associated risk assessment.

The first time an employee told me that he was doing a 'pee test' I thought it was some kind of software test for backend stuff I'd never heard of. He had to repeat himself - it was embarrassing. Then several others stepped up to say they had undergone urinalysis too.

No one even wants to say "pee test" much less do it - it just does not seem professional. If the level of what you are doing is highly specialized, you handle other people's lives, such as being a Space Shuttle Pilot, and need security, such as coding landing software for planes, and/or there are some really good reasons, such as you are observed coming to work apparently stoned, etc, ok that makes sense. But for designers and developers working on software projects, for the most part it's a scary and unnecessary invasion of privacy, with a questionable effect on security.

Usually fighting against established business practices that no longer make sense is a waste of time because the wave of change itself seems to swamp the environment eventually flattening all prior concepts of what should be used, done, or what standard processes and procedures are.

The natural quality of change in secure environments should be practical, do-able, applied uniformly for good reasons, not because "we have always done that" or "it's the rule" or "I am just following orders" - but for logical reasons that work to provide the level of security needed, even if it needs to change or be set as a standard in the future. I have found that the topic of change and security is an especially difficult one, which people resist for many reasons.

(photos in this article shot by Linda Lane, 2007)