Clearly know the distinction between what the business process will do and what the software will do

In the work that I do I have to clearly define the difference between what the business process will do (customers, workers, users, etc.) and what the software itself will do. In addition, I have to know what each of the "tiers" (database, server, front end, etc.) of software will do. In all, my job is to clearly define an "activity system" and what all of the actors in that activity system are going to do (and why).

A good tool in this that I learned for Agile Coach Rod Claar is to write your use cases / scenarios / stories in the following format:

<Actor> can <Function> so that <Business Value>.

This is an important pattern for people at all levels of the organization to understand.

The Actor is the person or system or entity that is doing something; your system will have a finite amount of these; the business analyst will have to determine what roles the system tiers will play and what the business people and users will play, it's a big undertaking.

The Function is the thing that the role is going to do. It should be written as an activity.

The Business Value is the *reason / justification* for the actor to do the function. It is the thing that *should* allow people to assign priority and determine what's next. It is the context and is very important.

Aside from these three process characteristics of actor, function, and business value, there are other parameters such as:

• Inputs
  
• Outputs
  
• Time
  
• Success criteria
  
• Failure modes
  

There are many parts and aspects of the system that we have to take into account when designing one.

My current projects

I've been staying really busy lately with quite a few side projects. Right now I have three side projects: my consulting company brand/web site/ strategy, my Visualize Everything idea, and a project I'm doing with some guys called SnoVision.

My consulting company, EfficiTrends' web site is www.efficitrends.com. I worked with a writer and a web designer about two years ago to put the site up. It was built with old (classic ASP) technology and the way the guy built the CSS structure confused me; it's way too complicated and not very reusable. But it served its basic purpose of being something I could point people to. What I've been doing on that site now is building a SQL Server back end and porting the site over to ASP.NET MVC v3.0 and I am using the Razor View Engine. I have been really happy with the progress and like what I've done. I'm using Scott Hanselman's "BIN deploy" method to get my site published to my host, Re-Invent.com. My goal for the site is to make it more dynamic and to list my past and current projects within it. I would like the site to be a comprehensive view of my capabilities as a web developer and I would also like to use it as the hub of my consulting work. There's a lot of work to do here and I'm having fun with it.

My second big project right now is VisualizeEverything.com, my online printing/t-shirt creation web site that is based on popular or community-contributed phrases. I've been working with an intern, Raheleh, on the site and she has been a great help. The one trick with that is I have to get the domain name bound to my home server and I also want to hook up web security.

My third project is helping a team of guys with their Feral Motion project. Feral Motion and their project SnoVision is a technology to automatically record and upload video of action sports athletes as they use "features" (jumps, etc. in a skate park or mountain terrain park). The technology is really cool. I've written some good code that uploads videos to Viddler and stores metadata in a MySQL database.

So I've been quite busy, FYI!

Make and break the model

A key part of being an entrepreneur, software engineer, or scientist is to make and break "models".

Models are belief systems or hypotheses or lenses or ways by which we see / view the world. They're almost always wrong but we have to operate under them.

Making models is what we do when you define a problem, explain a context or situation and define a plan to test it.

Breaking (or proving) models is the goal. We do this when we finally get to test our assumptions and theories. By testing models we learn if we are right or wrong.

 

Six Sigma “Define > Measure” is “Instrument > Collect” in business intelligence (BI) and software

In order for systems to measure anything or "throw off data", they must be instrumented to do so. This is true for cars, business processes, humans, anything.

There can be external measurement devices that observe the object but this is not the best. It is better for things to be instrumented and throw off their own data to the observer so the observation step can happen as part of the analysis.

Next time you build a system think about the needs for instrumentation, then you'll be more prepared to Collect, Analyze, Improve, and Control the system.

The customer is the person with whom you must be Agile

I learned this in pretty major spades on my current project. I was so *focused and busy* on producing the thing that I thought the customer wanted, that I stopped listening to her.

I never came up for air; I never had time to!

I was so sure that what I was producing was the RIGHT thing, that I ended up being WRONG.

I adopted a very "waterfall" mentality on this project because I was under the gun, behind, etc. But from the beginning. This is no way to run a project.

Never start a project without a signed SOW.

The ½ Project, ½ Consulting Rule

Don't plan a project that's only dev work or only consulting and no product.

In project work, there are two primary ways to derive value and succeed:

1. The work product itself and
   
2. The relationship
   

Both matter a great deal, and perhaps equally so…

Always make sure that you balance these two things: save time in the project for consulting and managing the customer's changes, expectations, requests, and questions. In this way, be Agile.

In other words, projects are neither Agile, nor waterfall, they have to be both.

Sculpting the model

Software development of any kind is like creating a clay sculpture:

We start with our understanding of the problem and solution domain (the clay and base) and then we start making stuff. We add, update, and remove until we're happy. Working with 3D forms is much the same as coding.

There are two models at any given time: the ideal mental model in the developer's head and the physical model that has been coded into the software product.

The developer identifies solvable differences between these two models and either A) modifies the code structure so it more closely resembles his ideal mental model or B) changes his mental model (expectations) about how closely the product must conform to his standards.

In other words, software development is subjective, but the judgment of the end product (art) is in the eye of the beholder.

Analyze the process or the data?

I always start with the process because that's what's most apparent and important to me. Things are broken, things are wrong, A isn't talking to B…stuff like that…

All of this context in my opinion matters a great deal and it's what business is all about! We need to change and improve this stuff, I think!! If we understand this part well, then we can create good, high-functioning supply chains, which I think is the goal.

Analyzing and improving data sucks.

Create a common language between the business and the doers – A call for Agile Scrum

Agile-Scrum tries to do this by breaking down work into stories and then further down into tasks. Each task has an estimated time and the aggregate (SUM) of the tasks is the time for the overall story.

So if someone asks you, "Can you do this by tomorrow?" you should figure out what the stories are and then the tasks. If the work is greater than 24 hours then there's no way.

If the business person can get bought into what the tasks are, or if you have a good scrum master that tracks what the tasks are and the estimated time for each and keeps that data up to date, then communications will be good.

If none of these things are true, you're going to be under water.

Sometimes you gotta call for support

I got over my technical head on a work problem today. I need to make this (what I think to be) really hard report for the customer. It uses SQL processes and whatnot that I've never encountered, so I'm basically quitting until I can get a second set of eyes.

I'm not going to keep billing for work on something that's beyond me, so I stopped.

I emailed my boss and told her that I was doing this and listed about four or five others in the company who could help me with and/or do the task.

I think this is a good thing for me to do.

Separate the concerns

It's critical to understand how to do this in our lives. We should never "pool" our concerns, we should *separate* them. We should not panic. We should parse our problems out and make them clear, tangible, and distinct.

Good, sustainable solutions come from this mental process.

You're lucky if you have a knack for this, you're probably cursed if you don't.

When a five minute phone call saves our butt

This is the reason that good consultants and a healthy personal social network are essential.

Without our advisors and experts, we're nowhere. We can read and dig in and shoot in the dark, but sometimes we need consultants and experts to *help us solve our problems*; we have to escalate.

The reason I emphasized the "help us solve our problems" text above is that this is absolutely critical. We have to know that we have problems. We have to know that we have to solve them and we need to know that others can help us do this and that when the answer is given that we are able to apply the answer ourselves!

You don’t have to code it but you do have to pseudo-code it

You're nowhere unless you understand how the software either works or needs to work. This is the gap, generally speaking.

If you don't understand how the software works now, you won't be able to bridge the gap between the software devs and the business.

If you don't know how the business works now, you don't know what you're doing or why. You're about to get fired; you're dead weight.

Somewhere between these two worlds are people with the skills to bridge that gap; to bring needs into reality and to bring technical opportunities and problems into the light of day.

These people are the real leaders in our organizations; not people who take one side or the other but get both intimately.

The “Business Intelligence Analyst” role

Let's create and train more people to do this!!!!!!

This role understands "the process" of interviewing business customers and creating software.

They can analyze people, data, and processes and create workflows that work, be they on the business or data/software side.

They are high-level thinkers that are senior software architects and analysts that get down to the details of how to make the end solution, yet they get the info from the business (and from their consultant team). They are the glue in the middle.

They know the steps that will have to be made to get to the end of the engagement successfully.

The cost of not having the right consultants is the highest cost of all

Bringing a new resource into a project is expense but sometimes necessary. You might be stuck, you might think your solution will not be good unless you get the proper advice.

The value of a good consultant is very high.

My consulting skill is in Microsoft technologies and enterprise workflow. I can design complex, end-to-end systems that make big differences to businesses. But I, too, need my own consultants. I am not a one-man-band. I need help. I get stuck. I don't know certain things and need experts.

Building your team of experts and consultants is critical. The more challenging your work and scope, the more you'll need good consultants. You might want to hire these people, but you definitely need them. And they're going to be expensive. The good ones will win you REAL BUSINESS VALUE NOW and their cost is worth it in spades.

Just complete the f**ing scenario, already!!

The goal in most projects is to get feedback as soon as possible, meaning time is of the essence. People don't have time to sit around and wait for you; they'll get bored.

So, when you're faced with this reality, working by yourself, don't get mired in detail and "crap" that takes a long time to complete making something perfect. Rather, just finish the scenario, dammit!!

If you're not prepared to do "awesome" work, that's okay. Do your best.These customers will understand, support you and you'll be able to make another (better) product next time.

Don't worry about your demos sucking, their just demos and chances to meet people where you're at.

Are you pair-programming or double-billing?

Hopefully you're doing both and everyone knows about it.

Everyone should know that your output is going to be of higher quality when there are a second set of eyes.

Everyone should know that devs can "hang out" and help each other while also multi-tasking and doing other things.

If everyone knows about these things, then you have a good company and a good customer and all is good. If people question any part of this, all is hell.

Scrum doesn’t fully work without the Scrum Master

You can be an agile team, follow the processes and practices, but if there isn't someone *other than* the dev lead to do the planning and communicating, your project will fail.

One person cannot do everything. They cannot be both the developer, team lead, project manager, business analyst, and scrum master. It just doesn't work. There are too many hats, too many roles, conflicting priorities.

The Scrum Master (or someone other than the people on the hook for deliver and estimates) has to watch the budget and hours and estimates, etc.

Without this person the project and team will fail.

Stepped validation

Process:

1. I interview a customer about what they need
   
2. I share my notes from the conversations with my developer and explain to him the needs / problem.
   
3. I expect the developer to ask me questions and get the job done to *my* liking first.
   
4. The developer reports to *me* now, not the customer.
   
5. I still report to the customer, and the dev to me.
   

I call this stepped validation.

Things that people don’t care about

There are some processes out there that people don't care about or know about. This to me is *scary* territory, but it is also the land of opportunity!

For example, the process of publishing files to a destination is probably well baked but not very well understood by me. I had a situation yesterday were I published "with overwrite" to a destination and the overwrite did not succeed. So now, I am using the more brute method of "delete destination and publish".

In other words, I am doing something sub-optimal because I don't understand the process.

These sorts of areas are the land of opportunity. But when will I / we have time to look into / investigate them?!