The good people at IBS have posted a little article by me at the IBS Quality Management 2.o Blog

I recommend you chat with them should you have needs surrounding these topics. Good people, as I said.

More soon!

Josh

Ten things that have been thematic lately and are also Good (this is not much of a post, I admit, but hey… ):

1. Knowing you do not know what you do not know.
2. Being the SME, but challenged by SMEs within complimentary disciplines.
3. Realizing Agility is not a software methodology, and that things are packaged in a specific way for presentation to you. There is a reason for this. Intent accompanies deliberate action.
4. Over-delivering can be as detrimental as under-delivering. You want to consistently deliver.
5. Knowing that until proven, it is an idea. There is a difference between Universals and Particulars and that difference is profound yet transparent. Please see AJ Ayer for more on this.
6. Owning the fact that your word and your actions hold more weight than a contract. Contracts are documents mandated to mitigate risk therein. Your word and your actions are your life’s work. Especially when nobody is watching (Thanks, Dad, for that one).
7. Knowing that emotion is not betrayed by careful and clinical assessment. It is, in fact, made assured and actionable.
8. Knowing that despite feeling as though there is a need to find your “purpose” it may be that Continuous Improvement is your calling, and what more can you want?
9. Examining how language and words have baked-in prejudice.
10. Moving in the right direction. It might not be clear where you want to go, but your gut will tell you if you are headed the right way.

There are more, but I wanted to post something. The title reads as it does because people visit things like “3 Ways To Improve Your Love Life” and “Six Steps To Be Handsome” more. Somehow, assigning a number or a list to a topic makes the read appear authoritative, or wrapped around a proof of sorts. Within that last paragraph lie many of the above 1o Good Things. There are more. Next: “10 Random Thoughts”. We will see how the analytics compare.

Until then,

Josh Milane

Bad for everyone. Seriously. It can just as easily be about finding information (in a way machines can be taught) as it is being made for people to find web pages. I would rather cure myopathy than get a quick recipe for brown gravy.

Yes, that was a metaphor. I cannot write without them.

Josh

I am not sure why this week was a week of standards, but in a lot of ways it was that and a standard week in that I never know what the topic or theme of the week will be. This past week, the subject of 27k (or ISO 27001) Compliance came up. The first was a friend who wanted to know what it was, the second was work-related, and the third was in a casual discussion that started out about Armadillos, of all things. It moved to Platypuses (Pattypusi?) and looped back around to a more philosophical take on what a standard is (think again about Universals and Particulars and my previous posts that attempt to lend value to my Philosophy degree).

That said, it made sense to write a little about the 27k Standard or at least a portion of it, much like I have written about a portion or segment of PCI Compliance, 508 Compliance, and general human Compliance.

ISO was there when I worked construction. They made sure we all had hard hats on and nobody wore steel toe boots. That was easy. You saw them coming and you put a hard hat on if you could find one and it didn’t matter if it was flopping around on your head like a bobblehead doll. When it comes to technology and technical compliance, it is a little harder to slap something together although it is a little easier in some ways to comply, because there really is no litmus test aside from rather blatant and uninformed decisions like storing credit card numbers locally, not encrypting sensitive data, etc. 508 has things you need to do, things that you really should do, things you might do, and things that would make people really happy if you did them but nobody quite expects you do. Not so with PCI or 27k but again, even PCI and 27k Compliance are determined by formal audit and let’s just say that I have heard the auditing companies be accused of running a racket, of being for sale, and generally everything you might expect someone to say about a company they feared in some sense or had to pay a bunch of money to for them to essentially go through your underwear drawer. In this case however, it is only your drawer, and the underwear belongs to other people. This is a perversion we will overlook for the sake of the blog post although it is a metaphor I could carry for pages and pages.

The ISO 27001 Standard is in reference to Security Management. Notice it is not related only to Information Technology Security, because it gets into things like hiring practices (be sure not to hire any bad guys) and workplace safety (have hardhats handy). You have 27001 and 27002 but in reality they are just references to each other. 27001 is a bucket that somewhere around 130 items fall into, all detailed within 27002. I would have suspected that they would use dot notation for the sake of simplicity, and I have no idea why they would start with 27001 when it seems to me they could just call it “Security Management Standards” but I suppose ISO just might handle that many types of specifications. The purpose of 27001 is to serve as something that is audited through examination of 27002. That really, is all it is, as far as you will likely ever need to know. It is sometimes coupled with ISO 9001 (Quality Management Standards) and ISO 14001 (a voluntary Environmental Management Standard) just to give it that little something extra. A little spice to keep it from being boring, and indeed, mixing ISO Standards can be as delicious and exciting as a little “pow” in the kitchen. I guess. I mean, the addition of layers of compliance only serves to create a more robustly compliant System that pleases everyone with a tie and an appetite for things ISO.

ISO sleepy, but I will press on. That was a joke. Say it out loud. Ha, right?

There is an ISO 27002 (used to be ISO 17799 but you gotta keep ‘em on their toes) and it is more geared towards the organization than a product or data. There is also an ISO 27003 Standard which oversees an ISMS or Information Security Management System: something to wield against ISO 27002. You might guess there is an ISO 27004. You are right. It determines how effective your 27003 is. I hear you saying “a ha – so there must by an ISO 27005 that either details 27004 or provides a framework for 27004” but you are wrong. It made sense, but you were wrong. ISO disappointed in you. 27005 covers the Risk associated with information security and how to manage risk therein. What’s that? You are dying to know what 27006 is? All I know is what I read about this one and it apparently makes clear a specification for requirements listed in ISO 17021 which in turn evaluates organizations against ISO 9001 and ISO 14001. It stops there for the 27k line. Thank Goodness. I know.

So, ISO 27001 is really a guideline for auditors to look to in order to be told that they really want to be evaluating the system against ISO 27002. Everyone flips the page and looks at 27002 after noting that 27001 mentioned there are about 130 points of interest to be relished.

ISO 27002 is the one that you can act against, judge against, measure against (in some cases) and sink your teeth into like a big delicious steak with “pow”.

The cool kids call ISO 27001 and 27002 “ISO27k” so I will too, because I just want to fit in, really. Remembering that 27001 is like a Table of Contents and intended to be used for existing as well as incipient systems. It is beautifully robust in that fashion. It also employs the “Plan, Do, Check, Act” cycle which keeps a lot of people constantly working and coming back to make sure things are still as they are supposed to be when something goes live. To be fair, because I know I sound a little bit critical, this is all good stuff. ISO 27002 is something that you do not pass or fail outright, and it is broad enough to in some cases tell you exactly what you need to ensure and in other cases have you wondering how the heck that section applies to you. Let’s take a look at it.

Hey, this is the theme of the week. Next week will change. And I want to make it clear that just because it is called ISO 27001 it does not mean that there are 27000 Standards preceding it or that the ISO Standards Group is a monster. It is fuzzy and cuddly, like a baby bear.

ISO 27002 is outlined in 27001 and consists of 16 sections, although I am happy to see one section is called section “0”, like iteration 0 in development, but in a much more sensible way in that section zero is just an intro, not a whole boatload of things that someone has to do. The sections are:

0. Intro

This section tells you what the heck you are supposed to do with the rest of the sections.

1. Scope

This section gives general recommendations.

2. Terms and Definitions

Since this is all about information security, the document recognizes that the term can be construed in a wide variety of ways and gives you some context as to what ISO is intending. There is an ISO 27000 which seems to be slated to contain many of these definitions, which would make sense as the terms are used throughout the 27k guidelines.

3. Structure of the Standard

Yes, they do get a little carried away. You are looking at the structure of the standard, after all.

4. Risk Assessment and Treatment

But don’t we have another ISO Standard for Risk? Not quite the same, and not explicitly for Information Security. This section is short and lets the person doing the audit or building towards compliance the freedom to decide what the best method to control Risk in their given situation may be. This is hard to pass or fail, obviously, and I think it exists just to let you know there should be some Risk Management practices in place. Formal ones. Ones you can explain to the Auditors if they ask. Not just “well, Jimmy makes sure.”

5. Security Policy

They really want you to have a manual outlining your security practices, efforts, mandates, rules, exclusions, and anything you can think of or that they might think of for you. The end goal of this compliance effort is admirable. But so far it does, to some, seem like a lot of documentation that is not even clearly required or clearly not applicable. Having a Policy document makes it clear that someone in management recognizes this effort because if it is an official company policy, it needs support from those able to make company policy, and our buddy Jimmy is probably not the one to give their stamp of approval.

6. Organization of Information Security

Governance. How will it all be controlled and utilized?

This section happily includes dot notation:

6.1 Internal Organization

Roles, responsibilities, dictum, and how the organization will collaborate to give life and breath to what would otherwise be simply paper or digital assets and something people file away next to the company policy on what to do if you have a heroin addiction and need to talk to someone on an 800 number.

6.2 External Parties

You are not supposed to compromise security by bringing in shady third parties or, more formally, any interaction with a third party should be carefully evaluated and recognized as an extension of the System, with efforts surrounding Information Security cascading to the limb. To some extent, if you create software or a product that is fully compliant in every sense, someone who purchases it and has rights to do so may completely blow your efforts out of the water by linking up with a less than scrupulous, talented, informed, or able partner or system. Much like PCI, you may create a compliant system, but pack it’s lunch and send it off to school and no matter what you teach it at home someone in History class might convince them to do something risky and unmitigated or outright dangerous (like launch themselves from the swing when it is at its apex and lead to a bad sprain). All you can really do its try, in some situations, which is partly why 27001 points out that 27002 is contextual.

7. Asset Management

You need to, as an organization, keep your stuff secure. This is not software-specific, and easily could be one of those items that does not apply. You might not have any assets. Your assets might be inherently dangerous and wrapped in another set of ISO Standards for safety. Or, you might just plain not have anything worth stealing. More dot notation here. I enjoy dot notation.

7.1 Responsibility for Assets

Keep an inventory. Little stickers on everything. Someone keeps track of who has what and where it is. At all times there should be someone who’s job includes knowing where the last batch of laptops wound up and who has which one and what they are doing with it. Again, this could very easily not apply.

7.2 Information Classification

Some things are worth worrying about and some are not. The vending machine’s current Twinkie count is not something that would likely be relevant to security, but access to a database that stores information regarding purchasing those Twinkies might be. How to classify? In a way that makes sense.

8. Human Resources Security

This is not about software, but more about the organization, obviously. This is not even about Information Security until you look at the happily dot notated children of section 8 describe.

8.1 Prior to Employment

You do not want to hire people who are going to compromise security. More or less.

8.2 During Employment

Make sure people get a copy of the Policy and understand how they fit into it. The standard also calls for some form of reprimand, or spanking, if someone gets out of line

8.3 Termination or Change of Employment

When people leave, make sure they don’t injure the organization, make sure they return all their stuff (neatly organized as per section 7), and that they get a police escort out if they are prone to violence or you wish to humiliate them on a Friday afternoon without fear or an outburst. I saw this with a failed Sarbanes-Oxley audit. The guy didn’t even do anything wrong. They played him for a patsy, but gave him a police escort just to (in my opinion) make it appear as though he was potentially going to throw a fit. Meanwhile, he was one of the nicest guys I ever met. ISO 27002 helps you if you decide that you need a fall guy. If it is policy, it is policy, and the police are coming to show you the door.

9. Physical and Environmental Security

The question is often asked; “Is common sense all that common?”

9.1 Secure Areas

Sometimes, doors need locks.

9.2 Equipment Security

Extension cords that lay across puddles are a bad idea.

10. Communications and Operations Management

This is where things become a bit of a beast.

10.1 Operational Procedures and Responsibilities

Don’t let anyone have too much power or be the one person who knows everything. That proverbial bus that always hits the important people is coming down a pothole-pockmarked street someplace and who knows. Things happen.

10.2 Third Party Service Delivery Management

When you work with a third party (yes, we have been here before), make sure they are not putting you at risk in any way. And then do it again. And then again. You are going to have to hire someone to make sure you are doing it again and again, so document each time and have something written down and executed. Not shot, but signed. Shooting is not safe for people or for data. Bullets and NOCs do not mix.

10.3 System Planning and Acceptance

How to plan and deliver good stuff in line with this Standard.

10.4 Protection Against Malicious and Mobile Code

Hoo boy. This makes good enough sense, but if a new exploit is found and someone takes advantage despite best efforts to avoid that very thing, does that invalidate your checkmark next to this item? I don’t think it does. It is about protection, not hermetic sealants.

10.5 Back-up

Even Grandma does this. You should, too. But, you should do it in accordance with the framework set forth in ISO 27k. Grandma does not understand her role. I asked her. She offered me a scone. I took it as a bribe and reported her.

10.6 Network Security Management

This is what it sounds like. Keep your network secure from the cabling (nothing in a puddle, please) to your VPN and authentication schema.

10.7 Media Handling

If you have a floppy disk with something sensitive on it, make note of that and document how many pieces you cut it into, why on Earth you had it on a floppy disk, and what you did with the pieces as well as why you decided to cut it up, who gave you the instruction to, or anything at all that may be questioned. In some of these you have to assume the role of defendant and anticipate that everything you do will be questioned so document, CYA, or try to get someone else to document that they have accepted responsibility for it all.

10.8 Exchange of Information

While it is on the way, before it goes, after it lands, and while the exchange is being planned, everything should follow guidelines that ensure security. I would not email a list of credit card numbers from Gmail or send them in a message on Facebook. You might want to use PGP and an RSA key or something of that nature, handcuffing the briefcase to someone who is not on anyone’s hit list and can run really fast. This is not just in relation to electronic data, although that should be obvious. If you have sensitive information on a spreadsheet that is printed out and on your desk, get ready to start chewing and swallowing when the auditors come.

10.9 Electronic Commerce Services

Here, I would personally suggest leaning on PCI. That is really what it seems they are calling for. And, by leaning on PCI, you are keeping another whole group of consultants in work. If you are not using credit cards, the same principles apply.

10.10 Monitoring

Know who is on your network and system, who tried to get on but failed, have proper procedures in place for when a breech occurs, and make sure nobody gets their grubby little hands on anything besides a “connection refused” or similar message that is not supposed to. This can go very deep to role security monitoring if you want it to and even applies to things like making sure all server clocks are in sync

11. Access Control

Another beast of a section; the main takeaway is to control access to your system.

11.1 Business Requirement for Access Control

They want another Policy here, taking into account the specific business rules and requirements that may necessitate someone or some role being able to get to specific data of a security sensitivity level other than what the company logo looks like, in theory.  Those people who are responsible for a given task or for ensuring a specific procedure will be identified here (the who) along with the details of the why and the what as well as possibly then when and the when not.

 11.2 User Access Management

This sounds a lot like using a tool akin to Active Directory in a secure fashion to control who (individuals and roles) along with the details of the why and the what as well as possibly then when and the when not. As with most things in 27k and other Standards, there is the need to periodically review. Not surprisingly, there are a host of organizations who will be happy to bill you for help you with this task that is not cut and dry nor always completely relevant and in context.

11.3 User Responsibilities

RTFM. Read the Manual (or Policy) so you know what is expected of you and how to interact with the secure system

11.4 Network Access Control

It seems like we talked about this already and addressed it in 10.6, but because of the amorphous nature of this effort and because of reasons I am sure I do not understand today, this is here as well

11.5 Operating System Access Control

They do not mean Access to Windows 2000 Server here. They mean the system that is operating to handle Access Control. You have to be sure it is used and used in a secure manner. This looks like a systems requirement, but it is really an organizational requirement.

11.6 Application and Information Access Control

Your Policy will touch on this if not detail it to 4 levels of dot notation, which is very sexy in my book. This calls for a deliberate and thoughtful protocol concerning who can use what and how. Seems like we were here before as well. Indeed, the entirety of section 11 is in some ways a retooling of other items within 27002. However, this is a one size fits all document and so context may render one item inapplicable when the need persists so you have a safety value in section 11.

11.7 Mobile Computing and Teleworking.

I think you can figure this out, but in case you cannot, this section asks that you have a policy towards how those who work remotely or will be sitting in the airport on their mobile phone and using the application are told that they cannot, for example, access the application, system, document, or entity while at the airport on their mobile device.

12. Information Systems Acquisition, Development, and Maintenance

Another lengthy one.

12.1 Security Requirements of Information Systems

Test what you are buying or ask to see an audit report that is as close to the morning of the acquisition as possible. If you are not buying it and are instead building it, build it in a secure fashion with “27k Makes my Day!” written on the development room wall.

12.2 Correct Processing in Application Systems

When you put things into the system, do it right. Better yet, prevent the ability of doing it wrong.

12.3 Cryptographic Controls

You will want to manage and define a good cryptography method and continually review it without calling attention to it or sharing it with more people than you need to because after all, this is Top Secret (Section 7.2) stuff we are dealing with here.

12.4 Security of System Files

Goodness gracious.

12.5 Security in Development and Support Processes

Make sure the people who are involved with doing all this stuff, and especially the ones developing it, are not building back doors for themselves or sending data to a mailbox in some far away land.

12.6 Technical Vulnerability Management

If an exploit or security flaw is identified, knock that sucker out. Then, find out who is responsible and have them escorted via law enforcement to the door at 4:55 on a Friday and pack their desk for them, leaving the box on their desk for a few days and then mailing it out to them at home.

13. Information Security Incident Management

Because things happen.

13.1 Reporting in Information Security Events and Weaknesses

You want something in place to rapidly ensure any reported “incident” is quietly screamed to the appropriate people, documented, and stored in a way that nobody can access, in accordance with 11.1 – just kidding, but yeah, that is what is going on here. Fix the problem through a predetermined manner that not only solves the problem but documents it, does a damage assessment if appropriate, and is weaved into the product or physical building’s structure. This is not always about code. It could be that people smoke and leave the back door propped open because it locks from the inside when closed. Make sure the door closes and make the smokers do it in a little circle painted far away from where they might damage someone’s lungs. Of course they will damage their own, but we accept this, and it is done in a controlled fashion

13.2 Management of Information Security Incidents and Improvements

Formalizing the practices that fall into place when 13.1 is kicked off, 13.2 will serve as a method to revisit and revisit and revisit and re-audit and re-audit and re-audit your 27k compliance statement.

14. Business Continuity Management

Be sure your organization can carry out all procedures denoted and do so on a regular basis, checking for gaps, holes, flaws, and changes. Applaud nobody, but berate those who have failed to do their job. You get no points for doing what you are supposed to do. That last sentence is not part of the Standard, but Mom used to say it to me so I get to say it to you now. I did not like it then and if you read this far, you are likely to think it is didactic. You would be right. You would also be someone I did not take quite seriously because if you read this far you must have something wrong with you. That, or be a true connoisseur of finely tuned prose.

15. Compliance

Say what? Wasn’t this whole thing about compliance? Let’s see:

15.1 Compliance with Legal Requirements

There are laws above and beyond your silly little handbook. You need to follow those as well. This, of course, does not apply to government agencies *wink* and *nod* to the Bush Administration (I really do not know enough about it to say anything, but I sometimes catch Fox News or the Saturday Night Live Weekend Update so I am a bit qualified to make political statements of fact).

15.2 Compliance with Security Policies and Standards and Technical Compliance

People who tell other people to do things or hire other people to do things should tell or hire smart and capable people to be sure their people are smart and capable and that their compliance effort is being adhered to. When the people doing this audit show up, they will be looking for people who are frantically shoving paper into their mouth, masticating it, and swallowing without the aid of water. Listen for the gags and follow the sound to locate weak links.

15.3 Information Systems Audit Considerations

When you do an audit, do not do it in a way that will affect the business negatively (unless it is affected negatively because of a miserable failure of an audit) and try to audit securely. Those who audit are able to open all doors and examine all assets, so make sure that they at least have a business card saying that they really work for an auditing company.

 J

 Hope you enjoyed.

 Best,

 Josh Milane

Agile has you delivering small pieces of value (working software). Efforts are broken into iterations (not Sprints, but iterations). Items are disaggregated into the smallest piece with value.

And of course, there is Iteration Zero, the “we have to do this but it is standard and not really something we are going to make part of our sexy project” stuff. That non-compelling stuff that you, well, would fail without but is devalued enough to actually call it “zero”.

When you were young, you probably stacked blocks, Legos, or your parent’s treasured family heirlooms. Endless possibilities. Personally, I think as soon as the little Lego man with the construction hat came out, they lost their innocence and started being an Out of the Box solution of sorts, which is where I am going. In case you wondered.

Out of the Box solutions are great, but if you take a step back from the solution and stop just before it becomes a feature and do all that you can without actually putting a Lego Man in the box, you have no Technical Debt. Baked-in presentations and features are often Debt as we refactor them or re-engineer them to apply Business Rules and things that make it what we really need it to.

Or, we can have a Lego Land village that looks like one the kid down the street just built and move into his city instead of building our own. There is the problem of prepackaged straitjacketing software that comes wrapped with a bow and looks like a fantastic amount of value but is truly just a bow you have to untie, a box you have to unwrap, and something that most of the time is not built for you but for the abstraction of you or your fictitious persona. Abstracting people and businesses into the simplest common denominator is valuable but not in order to offer the Persona a solution that is ready to go. It is valuable to build what is common and facilitate the building of the remainder that will make your solution yours and mine mine.

Frameworks are great for this kind of thing. Open APIs are great. Web Services are great. Simple methods that can be built upon or retooled and instantiated again as something unique are great. Processes that allow for flexibility are great.

Slamming down even something as seemingly “free and open” as the Agile Manifesto is not, in my opinion, such a good place to start. Take a step back. Why do we like People over Process, for instance? Take nothing for granted and you will miss no chance to realize that you are not stuck with something that does not fit. There is the “Five Why’s” and some use the “Four Why’s” to get to the root of a problem or need. There is something I like to think I invented but probably did not where you keep defining things you believe you understand and force yourself to answer your own questions. My Philosophy degree was not a total waste. An example:

I am too fat.

What is fat?

Fat is something ugly.

What is ugly?

Ugly is something I don’t like the looks of.

So you don’t like the way you look. We can take action on that. Wear this blindfold. I will happily alleviate you of your lunch. To me, fat is always a pound heavier than I am. Works for me.

You know what I mean, I hope. That was an oversimplified example, but we have true statements about Unicorns and Unicorns are not real outside of thought. Is it any wonder the Agile community is at it’s own throat over academic nuances between camps? And still, even the PMI has to accept Agile because it works before you get too crazy about it and paralyze yourself with academic arguments. I call this muda, to appeal to the cool Agilistas out there. Muda means waste, but it is the hip thing now, or as of just about the same time people had Chinese characters tattooed on their arms and are not sure what they really mean. It is exotic. Unless you are from China, which a huge portion of the world is. And of course, people will email me and say it translates as waste but is slightly different. Yep. And my definition of waste is different than yours. What is this complexity adding?

A toolkit, programmatic or linguistic or process-oriented will always trump a tool resultant from someone else’s efforts and especially any entity selling you something. The ability to assemble your own toolkit will always trump a toolkit that comes in a box and is on sale. In the end, the more dirty you get and the more you do yourself, the simpler things appear and when things are simple, you do not sound like a dolt trying to explain them. You can also get a lot done very quickly and assuredly. Test Driven Development is a great example of this. Regardless if you go as far as to do Behavior Driven Development and what tool you use – the process has veracity and value and it is no coincidence that reusability is a term that applies outside of programming.

Best,

Josh

More reasons? Yep. Just only have time for these right now.We have gone from “Agile is cowboy coding” to over responding to that notion by creating a PMI of Agility. It is not logical, and will only stand for so long.

One more: people are too emphatic about their particular Agile camp and too ready to accept ideas as real entities that dictate without context, as if they were handed down from the Heavens.  It hurts the community. Not the Agile community, but the community of software engineers.

Best,

Josh

We did Agile development before it was called Agile development. My coining a phrase, you create an entity (real or not – you have heard of a Unicorn, no?) and by setting forth a method by which to accomplish the goals in mind such as Scrum does you in no way break any tenets.

Agile is not unique to software. Nor is lean, Kanban, or any of the new buzzwords. They are buzzwords. They make enough money and generate enough revenue that PMI is starting to incorporate Agile methods in their PMBOK.

A bunch of guys in a cabin in the woods is not necessary in this day and age and only serves to add to the mystique behind the Agile Manifesto. As far as I am concerned, people who write Manifestos in the woods are suspicious and up to something. Not all of them are planning on blowing something up. Some are just meeting so there will be no distractions. Yeah. Because it requires complete concentration to chase a Unicorn. You cannot do it head on, after all.

I hate to say it, and I will hear about it, but Scrumban and all the over-intellectualization of what amounts to getting work done as a team is a symptom of big brains without enough to do. Or, and equally as valid, are those big brains who see the ability to make money off of the latest fad. It is nothing new, but the buzzwords are. There was always a brownie with less calories. It was not called a Light Brownie until someone marketed towards people who wanted a less fattening brownie. And that is all it is. Less fattening.

I have wondered a bit about why this bothers me so much. In a world that does not seem to reward honesty, why would I insist on calling like I see it? Saying that I care sounds and even resonates a bit hollow because I really cannot care about you if I do not know you.

I guess it boils down to a disdain for bullies. People throw words like punches and get all bent out of shape and worked up because of something as idiotic as what “done” means. Have we forgotten that everything is in context and everything has eyes upon it, therefore perspective, and that there is no judge without an opinion?

Then there are those who think it really is important to define what done is aside from any actually physical project. I will tell you what it is: an idea. A Unicorn.

Get your work done. Inform yourself. Learn. Be wrong once in awhile. Be honest even if it hurts. Scrum, Kanban, Lean, and the like are all meant to take your attention away from what they entail and that is delivering software. I did not say good software. There is no such thing. There is software that does what it is supposed to for some people and not others and there is software that plan stinks because nobody likes it.

Do your best and keep learning and dont let the intellectuals bully you into thinking you need ScrumLeanBan in place. Muda… why do they use a Japanese word? Like the cabin, it makes things more mythical. It is what it is.

And it will always be work.

Thanks,

Josh

Iteration zero has always been the bastard child of any project. It is there, and it has to be dealt with, fed, remembered, and attended to, but it in reality gets a blanket thrown over it and shoved into the corner like something you have to step around in order to get to the real stuff. The good stuff. The stuff that has value.

As much as people can, will, and do say that there is a lot of value in iteration zero, within many of the Agile trains of thought, iteration zero is “all that stuff like what kind of servers, licenses, and architecture we need” and it is not part of any creative or iterative process. It is the foundation, plain concrete, and has to fit correctly but once you get past it and into the real building, you do not see it again. Once in awhile, if it was executed poorly, you get leaks and the whole schebang gets thrown out, torn down, and built from the ground up again. Iteration Zero. Not Iteration One. It has even been devalued in name. You do not call something a zero unless it has a value of zero or you are trying to separate it from the rest of the group.

This has become an assumption that is no longer recognized as such. It has been grandfathered into many modern SDLCs riding on the back on Corporate notions such as Scrum. It is a mistake, and needs to be re-examined, especially when all it truly applies to as distinct from the software platform itself is custom development. If, for instance, I know I have to install an SAP ERP System, does that not become part of this “Iteration Zero” along with all that the platform, architecture, structure, services, functionality, workflow, and other valuable (how much does SAP cost out of the box?”) The notion of Iteration Zero changes a bit, but many of the common SDLCs and Project Methodologies do not allow for this mandatory truth. In my fifteen years of building software, I would guess that 80 percent of projects assume some sort of software framework – be it .NET, PHP, or Flash. Many times if not most, at least the LAMP vs Windows vs Other conversation has happened before the kickoff meeting and many times it has happened before even Inception.

Change thought patterns a bit, toss out assumptions regarding waste and how it is bad all the time, how Iteration Zero is just a bunch of stuff to get out of the way, and recognize that there is enormous possibility in what might appear to be waste. Think about compost heaps, even. There is no waste. There are only products of labor that do not work towards achieving a predefined goal.

We know one thing about predefining anything in software. We know it is a mistake to not expect things to change. Within Iteration Zero is more than commonly accepted both in terms of it’s contents and it’s potential.

The tides exist because of the love between the moon and the deep blue sea, to paraphrase Jimi Hendrix. Everyone should have some Hendrix in their back pocket, even if it seems as though the lyrics are just a byproduct of some late night in a smoky dorm room – not speaking for myself, here, obviously.

Best Regards,

Joshua Milane