We want to manage our organizations, don’t we?

I blogged earlier (http://kickmajorbooty.blogspot.com/2010/06/why-do-organizations-have-top-theory-of.html) about the Theory of Wringable Necks. We want things to wring, manage, grind. Why? We require visibility and manageability. We don't want unmanageable things, or do we? Do we want chaos or order, variability or knowledge?  Probably both.

Do the Math Because Life is Math

Why is this true? Life is a collection of tests. Tests must be clear, visible, and verifiable to be quality and so must life to be brilliant, resistant, and attainable. Test life with clear goals, visibly today.

Your Organization *is* the Test Suite

How and why is this? Somehow it's true. If you see your organization or life as a collection of tests, you're set to succeed. But you need to make this a visual, visible, and measurable (external) system/process. How? Read on.

You have to know and define the *process* and *way* by which you will achieve your goals; you have to develop a tool and measurement system that throws off data that you can analyze. How? What's the data, what's the system, what's theprocess? What's the context? Read on.

You want to test and achieve your most important goals. Project management can help you get that. Goal statement and testing / verification of goals to achievement is necessary. You need data to *control and manage* your business. This gap *is* the system; the third leg of the define, do, achieve goal. It's how you adjust and get feedback.

A project is collection of tests. An organization is a collection of tests.

Tests arise in a couple of forms but the bottom line is that you have to be able to verify them *in* the computer, not in your head, against the model.

• Acceptance testing: does the product perform against the expected actions? (doing this requires you to document the expected actions or activity system as a model but this is hard to verify because it is subject. Subjective = bad for organizations)
  
• Unit testing: does the software created allow itself to be tested against a collection of tests, the policies and processes of the organization? Are the tests managed and maintained? If yes, this is good. This is visual, this is visible. Verification is good.
  

The activity of running a life or business *is* managing a collection of objectives and tests. This is often not done visually or systematically and is most commonly done randomly and individually. Bad!

As leaders, let's reduce the variability in our lives and organizations by managing things concretely and visibly; data-driven. Start unit testing your development projects today. Build your test suite as you build your business.

I Became a Very Strong Proponent of Adopting Organization-Wide Test-Driven-Development (TDD) Today

For years I've known about software testing but I never had to apply it. This probably means that I wrote crappy software; but the bottom line is that people "accepted" it, one way or another. I used to just "get by". That all changed today.

I used to be a DEVELOPER, plain and simple. I'd write a web site and show it to the customer or users and it they said it was done, it was done. Then I became slightly more advanced in my practice and learned about UML "use cases" or "scenarios"; user stories. I learned how to write a stories and workflows and make software that aligned with those high level structures. But there is an even lower level that I had to go to that I was missing: unit tests. These matter!

My brand new tool/to y in my tool-set/toy-box are unit tests. I love these. These are important. They are critical. They are potentially even THE GLUE that could unify technical and non-technical types. They represent A LANGUAGE that can be understood by technical and non-technical types together that could be a unifying force in the process of designing custom software and business rules.

Acceptance tests, use cases, scenarios, and this kind of stuff are too "high level". In a way they are very "ethereal" (understood by few) and unverifiable. One person might think the test passes, and the other doesn't. In that sense they are very QUALITATIVE and ambiguous. Bad juju in business and softare!! Bad!

On the other hand, writing unit tests and ensuring that the code or business rules you write (policies) adhere with the spirit of the law is a beautiful thing. They are very low-level, understandable, and I would argue are NON-TECHNICAL. Yay, a non-technical thing for describing the business rules and logic that must be written. Awesome! Win win!

Overall, I think our organizations need three, types of people: Those who make rules, those who break rules, and those who watch the system and determine what to change. Each of us may need to be all three types of people sometimes; wear many hats. But having these clear distinctions between responsibilities is, I think, game-changing.

Clearly Separate Your Inputs, Process, and Outputs - Know the Jobs of Everything!

When we write spaghetti code we mix all of these components up. We're not clear on the jobs of things so we make everything do many things. And it gets confusing!

On a data warehouse I'm building I have to be very clear on what are my inputs (the stuff flowing in), what is my process (the things I'm changing and I have to use temp tables during that process) and what I am outputting. Each one of these stages and events needs to be very clearly separated; ie I can't ruin my inputs while creating my outputs.

I have to preserve everything but also be able to create and destroy everything as well. That's a lot of power to harness.

Be Cooperatively Tenacious

Merriam-Webster's defines the word tenacious as, "persistent in maintaining, adhering to, or seeking something valued or desired". The only thing I would add is do this TOGETHER with someone and be tenacious about your ideas WITH others.

Never Burden the Customer with the Backlog – Keep them Focused on the Product Itself and Let them Go About their Business

If you are good at product development, then YOU and not the customer will keep the product backlog. Never burden the customer with the list of open items or anything like that. The goal is work and progress and not the list.

Today I had a meeting with the customer and we agreed on the items that needed to appear in the next iteration. We made the list together and I shared it with him over email before I began. I'm now code complete on all of the changes. But I don't want to burden him with this detail. All he wants is quality, working software, not any administrative work.

So I'm going to demo the product to him tomorrow and tell him that all of the stuff we'd talked about last time was integrated and that we are now on a whole new review cycle. This keeps things fresh and focused.

Don't carry too much process baggage with you. The goal is the product, not the process, supporting artifacts, or other metadata.

Iterations to Demonstrate Mastery of Understanding

Having a meeting with someone where you show them your work and/or art is great. Be thankful for an audience and a customer!! In these reviews there will ALMOST ALWAYS be comments, needs, and next steps (at least you should hope there are or you're likely out of a job!). So be very clear on what these are and commit then with them to the next iteration. Work with them through the process without bothering them too much. And then, when you're ready for a big demo with them (and another iteration), go for it!