Thursday, December 31, 2015

Friend or foe robot? Designing automated processes for business

Programmers are guys who write your business processes with a kind of invisible ink they call code. The better you tell them what your processes are, the better business results you will have. They don't really model your world because they have no clue how the business works.

Programmers will come up with a well-engineered version of the reality they perceive if left alone and that will have to be the way you run your business if you don't tell them how the business works. It will likely more resemble a massive robot rather than a enabling friend.

As a programming instructor, I talk about the declaration and reuse of a set of statements that become methods (or functions or procedures).

As a business instructor, I teach the same thing concerning recognizing a useful process and promoting the larger scale use of it into the business. As your process maturity level grows, the process expands from your own use, to people around you, to even more people until it's a company-wide standard.


Those same maturity steps are used to develop large scale architectures that provide guidance to the necessary design of the infrastructure that has implemented it. In fact, it's the principles of good design that produce a workable architecture. Sometimes business doesn't know which architecture to choose or isn't able to strategically point the direction and then takes the low road of design by infrastructure. This is the choice to buy instead of build and results are good as long as you stay compatible with the other components that are added on. Again what you end up with is a well-engineered solution without regard to your specific business needs.

The business processes existing within a coordinated automated system or an infrastructure are essentially the executable programs. They have been structured to achieve a specific objective. They take inputs and turn them into outputs. They have a specific trigger. They are layered into automated roles and responsibilities to work well when they have to be maintained. Just as if it were an employee, you can fire an architecture layer and hire another version of that layer that fits the bill when managing a cohesive set of responsibilities in a business.

As far as I know there's not as much business writing going on for how to design a job role with few dependencies to other job roles but one of the common axioms of being promoted in business is that you must make yourself replaceable or else you'll never get out of your job. That's the same kind of thinking as when programmers say they must make their programming units reusable or maintenance will become more of a headache.

The process

If processes equal computer programs then they must have similar features. They can be broken down into smaller processes. They are either ongoing processes or processes that have well defined starts and stops. Processes can update policies, standards, guidelines, activities, other processes, procedures and work instructions if needed just like computer code can generate other code, update rules, and modify data that change how the program operates. A program is made up of activities, procedures, and work instructions or as the programmers know it, the class, the methods, and the program statements.

Metrics for a process are built in from the start and can be injected into computer code or built in to the abstract base of the code. In business, the best place to think about your metrics for success is during the planning stage so you can always build with them in mind or else you'll have trouble retrofitting them later. Roles of who should be involved in the process are important. In code, the types of relationships that you maintain with other code is important and successful relationships are spelled out in recipe books called design patterns. I admire Peter Coad who tried to assign roles to classes and discover some reusable patterns for interactivity and not just static recipes.

Process improvements are always a part of all processes and can be found in wrap-up sessions or project post mortems. In code we get a closed feedback loop from the folks who are using the programs who give us reason to enhance the program and get more financing for the next maintenance project. Feedback comes in the form of new or improved features and it gets added to the system as the value becomes known.

Processes should also be well defined in understandable text just like we always do to our fellow programmers when recommending comments in their code. And just like the norm in programming, most documentation happens after the fact because people don't have enough time to document the program until it has stopped changing at the end of the development cycle.

Process owners are the people who understand the process and can help educate others on how to use the process. I help ITIL students who think process owners are not in charge of implementing the process. This always gets me on my soapbox. An implementation of a process, e.g. an ITIL key process, is not going to happen because you read the book. It must be digested, customized by deleting the right parts, and supplemented with all of the current business structure in order to be understood. Then the process activities are noted and people check them off as they need to when they need to encouraged by success and trimmed down by reality.

In programming, it would be the project sponsor who got the ball rolling for the new software and would own the software when complete. They also get new funding when the project is a success and get project funding reductions when the process is too cumbersome.

How and when the process is used is a matter of policy and the ways that you can use these process steps have limits. Just like a computer program, the steps can be run for certain types of tasks and shouldn't be run for others. You don't close the books of an accounting process except for once a month. You don't ship more inventory than you have in stock. Process objectives are probably determined by what planted the seed in the ground for using this process in the first place. In a software project, the business objectives drive the funding and usually can be found in a business case document or a sponsor's mind.

I was reminded of the input and output nature of a process when looking at the method declaration and saw that it defined a general form of a resource just like all the other types of resources.  But until functional programming came along to supplement object oriented programming, we never had a way to send the process information from one place to another internally even though the values of any data could be sent to and fro.

Process testing

Software testing is a way of thinking about your code from the norm or from the original business requirements. This validation is a quality aspect of coding. Test driven design drives home the point that the test is a way of thinking about how your code should be called and used before the implementation is written. ITIL states that
"Even before starting, it is important to think about what the process outcomes should look like." (Service Design, p. 44) 
We also work with requirements in a hierarchical way so that the lower level requirements of the code can roll up to the next level of activity and eventually be mapped to the business goals that drove the project. Then when the system is complete, we have a measurable way to compare what was originally planned and implement improvements if necessary.

Process enablers

The enablers of a process are combined assets of the resources and the capabilities of the business. These are the raw materials and the smarts of the folks that are getting the job done. On the computer programming side are the programming language capabilities and the hardware and software's raw power to get a calculation performed or a sequence of code executed. We measure performance here in FLOPS (floating point operations per second) and computers are moving through the petaflop (1,000,000,000,000,000) ranges now.

Business processes depend on the business assets just like code depends on the infrastructure it runs on. Unfortunately, business is both enabled and limited by humans and computers both enable and constrain business.

Get in front and drive

Processes are not much different whether you do them manually or if you have a robot do them for you. The programmer acts as a plumber in a business process. They know the mechanics and apply the right torque to the right nuts and bolts to hold the system together. The business analyst is going to map out the system so that it works for the business the best.

Sometimes the programmer has no choice but to plan it out and do the best they can. But the business should always get involved at the first to direct the code so that is best represents the business. That's always the best strategy to take for any new project. Don't let the programmer be a back seat driver and transform your software project into something you didn't expect.

Monday, December 21, 2015

Building your dream home - knowing web site roles and skill sets

As a teacher I'm interested in getting the right information to the right student. A major part of my training is web site building and students often want to know what skill sets to learn for their job or career. Building a house is one of my go-to metaphors I use when talking about developing a web site. Getting a home built from the ground up takes skills from
  • a general contractor to get all the people collaborating, 
  • an architect / designer to figure out how it should be lived in, and 
  • the carpenters, plumbers, electricians, and other specialized contractors to build it.
You can separate the skill sets of building a web site into those same basic categories or roles:
  • admin people to set, build, and deploy the code
  • GUI / UX designers to understand the work flow and usability and
  • the developers and database people who make it work.
These roles of the web admin, designer, and developer have been implicit in many job titles and much training can be fuzzy about who should be learning what for the best results. Here's my simple guide to what skills each role could need in a prioritized list:
  • Web admin - OS, network, server configuration, server-side language, JavaScript, architecture, HTML, CSS, graphic arts
  • Web designer - graphic arts, CSS, HTML, JavaScript, server-side language, OS, network
  • Web developer - server-side language, JavaScript, database, architecture, OS, network, HTML, CSS, graphic arts
My classes at Centriq (including some I no longer teach) and the roles that they target in groups by primary role would then look like:

The JavaScript Tooling class is a two day class highlighting the admin skills for JavaScript based web sites and was taught as part of the JavaScript Powered Web Apps but is now offered separately.
The JavaScript Powered Web Apps doesn't get you hardly any design because it's about setting up a web site using nothing but JavaScript. That means that the web site isn't much to look at but it's very cool under the covers. 

I hope that you are better able to guide your educational path towards a team of skills so you can build your own personal dream home with some of these role explanations. 

Sunday, December 13, 2015

Don't be a LeBron and write user stories for you. Create team value with these examples.

Lebron James by basketlol
I'm still not happy with Agile user stories. The user story should set a goal for the team. Most perspectives of story writing I see follow the LeBron James school of thought. The typical user story I read finds value in winning for the individual player and then the projects follow those rules running into conflicts. I think it's time to do some coaching examples from stories I found on the internet.

The easy expected format

The traditional user story format:
As a (role) I want (something) so that (benefit)
is supposed to benefit the person/business paying for the work. Or at least that's what I want if I'm in charge. You don't want to watch the project goals slip away and then everybody and their dog starts wanting something different. Without a guiding set of project value propositions, the user story will look like
As a <stakeholder> I want <something for me> so that <several excuses>.
Just making an excuse for a personal need does not make a user story a requirement nor makes it easy for a developer to code it. When it's in any kind of formatted statement, the analyst can put it neatly into a document and make it passable as a project document. It's now user stories. Nobody questions it because there are no well understood rules about a good user story.

So stop already. Here's my rules (I get to make the rules if I'm paying for it):
  • The role/stakeholder triggers the activity. It's like a security group description instead of a real type of person at this point. Make it broad.
  • The something is for the business. Make it the focus.
  • The benefit is for the business. Make it have value. No excuses.
  • Use testable functional requirement writing. Any kind of limitation of data or process is a rule.

The hard part

Let's apply this several different ways to sets of requirements I found. In my style of writing requirements, the business rules are extracted out and placed under the requirement (they are given an ID if reusable and placed in another document). The information about the data entities are extracted out and placed in a data dictionary with the business details. The design elements are noted. And any project information is noted as well for inclusion in the project plans. Only the rules stay with the requirements while the rest get sorted and filed away in their own documents.

Desktop backup app

  • As a user, I can backup my entire hard drive.
  • As a power user, I can specify files or folders to backup based on file size, date created and date modified.
  • As a user, I can indicate folders not to backup so that my backup drive isn't filled up with things I don't need saved.
It's interesting to me that this first choice extracted from my Google search didn't bother with the benefit part. So here's my take on them collapsed into one story:
  • As a user, I want to backup my hard drive so I can restore files.
    • RULE - select files by size, date created, data modified, user choice.
    • RULE - select folders by size, date created, data modified
    • DATA File: name, size in Kb, date created, date modified
    • DESIGN - option to select an entire disk backup is the default?
The distinction between the two roles fades away as the trigger is the same for the same result. The ability to use rule-based choices for file selection is what the user story author thinks is important. But the importance might come if there is a functional difference. The distinction between the user and power user will appear as design personas for testing.

Most of the meat of these requirements is in the rules which corresponds to my experience of seeing a document fluff up by including the rules as variations of requirements. It's just bologna.

Agile project management app

Here's another example of four related user stories with other information included from the three other stories that were deemed too broad (vague) or too detailed (mostly data info):
  • A team member can view the iteration's stories and their status with main fields.
  • A team member can view the current burndown chart on the status page, and can click it for a larger view.
  • A team member can view or hide the tasks under the stories.
  • A team member can edit a task from the iteration status page.
This one was interesting to me because the template for writing a user story looked very promising and included the goal of expressing business value. I just didn't see it in the stories. Here's my version:
  • As a team member, I want to view project user stories to be aware of project scope.
    • RULE - select stories by iteration
    • DATA - User Story: status, tasks, main fields(?), rank, name, size, package, owner
    • DESIGN - tasks are able to be hidden and shown under story
  • As a team member, I want to view project status to be aware of project management metrics.
    • DATA User Story: is in scope, hours estimated, hours worked
    • DESIGN - project status is best viewed as a burndown chart
    • DESIGN - the burndown chart should be able to be viewed larger
  • As an analyst, I want to manage user story tasks so that user stories have details.
    • DESIGN - CRUD should start from the iteration status page
I know there are four basic operations on entities which occur. When they all occur together, I find it useful to use a higher level requirement using the word 'manage.' The two operations mentioned in the original versions, edit and view, would be paired with create and delete in a full set of user stories. Data base people know these basic CRUD functions. The entity discovered in the requirements is just the User Story. The project status is a report of all in scope project user stories.

Credit card payment

Another story with additional details from the same Google search result above really did use some value so here's what it looks like before:
  • As a purchaser on the website, I want the ability to pay with a credit card so that I may immediately confirm my purchase.
  • Acceptance criteria
    • accept Discover, Visa, MC
    • Validate CC# when entered
    • Validate expiration data and CVV
    • Validate billing address
    • Generate success and failure messages after processing
  • Definition of Done
    • passes all regression tests
    • passes testing per acceptance items
    • approved by UI team
    • able to show feature in company demo
  • mockup.png
and after using real world documentation:
  • As a customer, I want to purchase a product with a credit card so that transactions are convenient.
    • RULE - credit cards must pass basic local validation before submitting to credit card processor
      • credit card type - Discover, Visa and MC
      • number - passes Luhn algorithm
      • expiration date - after or equal to date of transaction
    • RULE - credit cards submitted to credit card processor must validate with the following information (or create separate DD item)
      • credit card number
      • expiration date
      • card security code
      • billing address
    • RULE - credit card validation should be done within 2 seconds
    • DATA Credit card:  type, number, card security code (not stored), expiration date
    • DATA Message: body, time/date, ID
    • PROJECT Testing, exit criteria:  All regression tests must pass.
    • PROJECT Testing, exit criteria:  Entire UI team approves screen forms.
    • PROJECT Testing, user acceptance: prepare mock data for company demo
    • PROJECT - Project plan, stakeholders: Credit card processor, customer
    • DESIGN - suggested screen layout of entry form - mockup.png
    • DESIGN - self-service customer purchases are best made on a web site
I really don't know why I need to confirm my own transaction since I can't confirm with anything. The confirmations are the validations which should be made quickly. The validations are really in two phases since it's a system dependent on a credit card processor.

Summary of value driven analysis

I believe that people don't do requirements well. It's why user stories were advanced as a replacement for bad requirements. In some ways I agree with Cowan+'s throwing the baby out with the bathwater statement, "User stories are not requirements. They were meant to replace requirements, which suck." But I think that they just help do a better job at user needs elicitation. And then the rest of the analysis should be about writing the business value user stories/use cases.

By following a format of zeroing in on the functional requirement and extracting out all the distracting and fluffing-up text into their own documents, I believe it's much easier to create usable requirements. The thing that drives the requirements the best is value. But it's value to the business, not value to the individual stakeholder. Do it for the team. Don't be LeBron.

Related blogs