“The Path” sounds pretty heavy, but it exists out there in the amorphous world of SDLC methodologies and more accurately, the PLC. It is that common abstraction and line that runs through each but might not be so easy to articulate. You might liken this Path to the common truths that religions share without being called ridiculous. You would be left with a wonderfully broad palette of tools and discoveries resultant from freedom. I was a philosopher so religion kind of slid aside for me and was trumped even theoretically by the proclamation that I cannot worship a God I do not know exists. Pascal’s Wager is a cop out, although it is still used in IT “Best Practices”. The whole idea of Best Practices is absurd unless you restrict it to a very definite activity, at which point it defines that activity and you have a tautology.  Every project methodology shares the same *fundamental* goals. Every project shares something.

Just like religion, once instantiated in a human being or group, it can become enlightening and serve as a source of strength or if you are a skeptic, an imperfect but workable guide. It can also rip a team apart faster than an army of Google Recruiters. Here is where something fairly subtle has created a problem; it is a problem that needs immediate remediation.

You have a project lifecycle (PLC) and it details your project from start to finish. You also have a software development lifecycle (SDLC), which details the way the “work” happens and the stuff gets done. The PLC is a kind of container for the SDLC.

I am not sure that this Path (PLC) is anything more than one of Ayer’s Universals, to be honest. Sure, to have an end you need a beginning, but is that a construct or acho fundamental truth? Or, is it the way we have chosen and come to understand the world? A PLC is a way to choose to understand the process of a project. It is something you might find in an employee handbook, or “The Book That Describes OUR Process”. Once you get into the SDLC, there is magic and other cool stuff that is not so easy to capture without doing. I really do not care if you have a Scrum or an XP or a Waterfall SDLC. Compare it to another instance of the same. There will be differences. They may be small, but they will be *important*.

A PLC and an SDLC are both methodologies, although quite different in the amount of science that can go into them as opposed to the amount of theory (in this case, science is objective work). The PMI insists that they do not teach a methodology. Still, they produce PMPs, which are people who have mastered their Book of Knowledge. Book of Knowledge?  If you did not know, yes, they really call it that. There is a PMBOK, or Project Management Book of Knowledge. You get it as part of a package with logos all over it. Apparently, some long-bearded geek came stumbling down a hill with it one day and fell down, proclaiming the way has been revealed. You just need to go buy some PDUs, spend a little money every so often, and you will also glow with the wisdom within the Book of Knowledge.

I didn’t say it sounds like Scientology. I didn’t.

This is Level One out of 5 of the CMM, meaning it is the most IMmature of the 5 levels.

• Initial (chaotic, ad hoc, individual heroics) – the starting point for use of a new process.

Does this sound immediately odd to anyone else?

That is, aside from the fact that apparently there is value in telling us that a brand spanking new thing is not a mature thing. (Cuz yeah, I didn’t know that.)

That also is, totally ignoring the fact that what may appear immature may actually be metamorphosis.

The CMMI is applied to software and other industries. It started in government. It is applied to organizations that make things. How *mature* are these organizations? Can we expect them to deliver? Maturity is repeatability, absence of waste, etc. I see cubicles. 9-5 workers. I see waste of a different sort. You have to kind of hide Agility in there, because agility is kind of like being a Lion Tamer to a lot of execs.

I like working with heroes, personally. The context for the CMMI is narrow and like all things that can be branded (“CMMI for Agile” for instance) is being productized and NOT helping.

Thank you,

Josh

The UX/UI experience in Agile projects is always fun, and the below is very sage, I think, when dealing with custom development… but what about implementing a platform? How does this approach fail? It does, in some cases, for good reason. Where does the skill set overlap between UX/UI people need to merge with development in these cases? OR, do we act truly Agile and just talk? Not working ahead, but along side of…?

UX: The Gatekeeper RoleThe two main recommendations for ensuring good usability in Agile projects remain the same as in our original research: Separate design and development, and have the user interface team progress one step ahead of the implementation team. That way, when it comes time to build something, it’s already been designed and tested. And yes, you can do both in a week or two by using paper prototypes and discount user testing. Maintain a coherent vision of the user interface architecture.

Create the initial vision during a “sprint zero” period — before any implementation has started — and maintain it through annual or semi-annual design vision sprints. You can’t just design individual features; they have to fit together into a coherent whole — a whole that must be designed as well. Bottom-up user interface design equals a confused total user experience the Linux syndrome.

From:  Agile User Experience Projects Jakob Nielsen’s Alertbox.

Compliance is not just a pain in the tushy. While it can be difficult to achieve, the standards for compliance have a sort of soft interpretation. For 508 compliance, there are elements that can be interpreted. Ultimately, a human being or group of human beings have to assert that a site is 508 compliant. Unless that person has the authority to officially dub a site compliant, it is compliance-minded. That’s all. Sometimes that is enough and the compliance police do not come looking.

I have written a bit about 508 compliance and W3C assessability standards. I am not a fan of standards that can be interpreted. That is not really a standard. PCI compliance is a bit nicer in that regard, so I will talk about it a bit today. Hang onto your hats. This is about as sexy as it gets.

There are 12 points (requirements, really) that must be satisfied for a site or site collection or System to be PCI compliant.

1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks
5. Use and regularly update anti-virus software or programs
6. Develop and maintain secure systems and applications
7. Restrict access to cardholder data by business need to know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
12. Maintain a policy that addresses information security

First, what is the motivation behind this? Your safety as an online consumer, ostensively. If you read my blog on any kind of regular basis, however, I tend to think there are other forces at play. Just like SOX Compliance, PCI compliance keeps a lot of companies in business. PCI Compliance experts. But they are not the genesis of this requirement. The credit card companies are. It limits their liability. It puts the onus on the site owner. I do not know if that is a good thing or a bad thing, but as with most things, I would bet the answer is “a little of both”.

So how do items like #6 become proven true or false? The Payment Card Industry Data Security Standards (PCI DSS) Information Security Policy & Procedures Manual sets forth these measures (requirements, really). And the reason I keep saying (requirements, really) is that requirements can be interpreted until UAT takes place. Sure, you can go Agile and you can go JIT, but it does not make sense to here. This is one occasion where yoru developers, stakeholders, phone support staff, and anyone who has anything to do with a transaction will be relevant is a very real and direct manner. You are better off, in my experience, joining forces with one of the organizations capable of dubbing you compliant early. That is in contrast to building, engaging, and changing/adapting. Ultimately, it will be up to your qualified PCI Compliance Agent if your application was designed with security best practices in mind, or if your application is secure. The way they determine this is up to them, although there is more detail behind these requirements – as you would expect with any project… a purely Agile approach would tend to leave people saying “that’s not really what I meant, so let’s iterate.” Why iterate when the deliverables are monitored by those who accept them and who know what they mean?

Point 6 “means”:

• Deliverable: A formalized Security Patch Management Program employee, complete with his/her roles and responsibilities.
• Deliverable: Comprehensive inventory of all “system components” directly associated with the Cardholder environment.
• Deliverable: Comprehensive inventory of all other I.T. resources not associated directly with the Cardholder environment.
• Deliverable: Subscribing to industry leading security sources and additional supporting resources for vulnerability announcements, and other security patch management alerts and issues.
• Deliverable: Procedures for establishing priorities in regards to security patch management. This will include, but is not limited to, the following: 1. Significance of the threat. 2. The existence and overall threat of the exploit. 3. The risks involved in applying security patch management procedures (its affect on other systems, resources available along with resource constraints). 
• Deliverable: The creation of a database of remediation activities that needs to be applied.
• Deliverable: Test procedures for testing patches in regards to remediation.
• Deliverable: Procedures for deploying, distributing and implementing of patches and other related security hardening procedures
• Deliverable: Procedures for verifying successful implementation of patches and other related security hardening procedures.

These are not litmus test deliverables. They are required. The flaw is that we have requirements with detailed discovery yet the requirements are not positive assertions of anything but a hypothesis not proven true or false. They are pointers. Specific documents make up the larger requirement. This is fairly well defined, but still, there is that final UAT (that is indeed stretching it a bit but hopefully my intent is clear) where the dubbing agency says “Yes, PASS”. They are usually very willing to help you fulfill these requirements and create these deliverables.

To protect cardholders and personal information, organizations must not only employ best practices, but they must also pay to have themselves audited. This seems fair, I suppose. I also respect that this is not a rigid set of requirements, but a yielding and forgiving one. It makes sense to temper things with a bit of reality. Still, it is not a standard, in my mind.

If a platform is ever able to say it is PCI compliant (or more likely, a framework), it would be very interesting. To build a framework so that departure from these guidelines is impossible would seem an attractive project for someone.

I am all for complaince, and I am all for standards, but I simply do not believe that PCI Compliance is a gauge against a standard. Advice: get audited by a PCI Consultant early. Let them tell you what they need. It may be less than you would do on your own and the money you spend on them will be money you save internally (lower project TCO). And as always, best practices in your SDLC and intelligent (common sense) design and architecture will be more valuable than whatever cute name you give your process.

AJ Ayer called something that could not be proven true or false “nonsensical”, but I think this is a little different than that. PCI Consultants need to be honest and earnest or they will have no authority. The intent, and the discipline, is valuable here, and I dig that very much.

Thank you,

Josh