Windows Workflow

I have recently discovered a really cool feature of the .Net framework 3.5 called Windows Workflow Foundation.  I know that I am a little slow and that it has been around for a couple of years but this is the first time I have tried using it.  So, if you are not really familiar with WF the reason you would want to use it is if you need to automate business processes.

At the core, WF is a process orchestration framework.  You build reusable components that encapsulate a particular workflow step called an Activity then string them together in the WF graphical designer.  WF reads the graphic you draw and executes the activities in the correct sequence.  Turns out that this is an awesome way to discuss your business logic with a customer because you can show them the flow chart of the activities and they can understand it.  This lets you and your customer communicate on the same level and achieve your project goals faster.  This is especially true in an agile development shop where most of the software requirements are defined during inspection/adaptation loops.

In my company, we develop training content for customers.  This content is web-based and must conform to a content format standard called SCORM that requires metadata and student tracking via a defined JavaScript API.  The customer requires that we run a test suite on all the stuff we develop and publish the test logs and content for their review before final acceptance.  So, we made a WF workflow that packages the content for deliver, automates the test suite, packages the logs for delivery, posts the content to the review web site, posts the logs to the web site, and sends email alerts to all the appropriate stakeholders.  And, it does it all without human intervention.  To put this in programmer terms, we have created a automated build script for the training content using WF and it works great.

Next, we want to build a workflow for the content review process.  This will have a workflow that starts with the customer making a change request and follow that CR through the approval process and into the work order that will drive the actual change.

Product Backlogs and User Stories using CSA

I have been planning for the start of a new project and one of the key decisions to make is how to manage and format the product backlog.  I have come up with a few options that all sound like they could work.  So, here's the list:

Whatever:  The first option is to just put anything in the list.  Make it whatever you get from your customers.  This option has the advantage of making your customers feel more involved because the list has exactly what they said.  It also has the disadvantage of being harder to understand because it is exactly what the customer said.  And, we all know there are three sides to every requirement - what the customer says, what the developer heard, and what is actually needed.  The fact that the items can be just about anything makes the estimation and prioritization much more difficult.  While this is the easiest to collect, it is harder to manage.
 

User Stories:  A slightly more formal way to maintain the product backlog is to use the User Story format.  This format starts with a simple template that keeps all the items one sentence long and in the user's perspective.  Here is the template:  "As a (kind of user) I want to (functionality desired) so that I can (benefit received because of feature)."  This is a simple to use template that you can train a group to use in just minutes.  I like to print out a stack of index cards or forms that have this written on it with blanks to fill in the user, functionality, and benefit.  This format is much easier to estimate and track because of the inherent consistency of form.  It sure looks a lot better on those management reports than the Whatever format.  Additionally, it forces you to stay somewhat more high level.  I think this is good because higher level requirements means that there will be fewer items in the backlog.  A smaller backlog requires less effort to maintain.

Use Cases:  A Use Case is a narrative story or numbered set of steps to perform a required task.  This format is often fairly detailed and may have embedded user interface prototypes.  The advantage of this format is specificity.  They can almost look like a story board and can give the end user a really good picture of what the application will be like.  This allows the developer and user to iron out most of the confusion before coding the application.  The problem with this format is the amount of time it takes to make the Use Case is sometimes just as long as it would take to code the feature!  Here is a partial sample of what a Use Case looks like.

 

So, which one do I recommend?  The answer is all of them.  Let me explain.

I like to use Use Cases as a basis of analysis and discussion about the critical user features of an application.  They are especially good at identifying complex usability concerns and human interaction workflow issues.  However, they are simply to complex for the majority of requirements.  I only use them for the critical user interactions.

I like User Stories for the bulk of the functional requirements in an application because they are simple and consistent.  I can train most users to write them in a matter of minutes and the users can generally do a pretty good job with them.  They leave out a lot of detail, but I don't think this is a bad thing.  I prefer to have the barely sufficient documentation that User Stories give and fill in the details by communicating to the end user on a regular basis.  So, each time a developer picks up a User Story to start working on it I expect the very first step to be a phone call to the end user to talk about what the story entails.  This communication gives the customer confidence in the team and makes sure the requirement is the most up to date that it can be when we start coding.

Lastly, I use the Whatever requirements to collect the additional stuff that does not relate to the functionality of the system.  For example, if we need to produce a burndown chart for senior management or host a training session for end users.  These are tasks that eat up time in the sprint, but they do not add features to the application.  So, I track them in the product backlog as "other" kinds of tasks.

This is what I call the Common Sense Approach (CSA) to requirements management.  I use what works but only in the case where it works WELL!  Don't try to schedule meetings with user stories.  Build a use case when you can't understand what the user story is trying to convey, but DON'T build them for every requirement.  Unfortunately it would seem that CSA is not all that common.  You should try it and let me know how it works for you.

SCORM 2.0 White Paper

So, my white paper is at a draft stage.  I essentially have all the data I need to complete it but it still looks ugly.  I need to clean up the graphics and make them attractive and put the paper in the correct layout.  The IEEE uses a two-column format for white papers, so I will need to lay out my paper in the same format.

Essentially, I have put together a concept for SCORM sequencing that removes the burden of the sequencing engine from the LMS vendor and puts the responsibility on the content creator.  Really, the LMS vendor doesn't know how the content should flow, only the content creator will know that.  Instead of using some really complex XML grammar to tell the LMS sequencing engine what to do, I have proposed a JavaScript event model.

So, whenever a SCO terminates, the LMS will call the OnTerminate event for that SCO.  The JavaScript code for that event is in the Manifest, so it is still outside the SCO.  Being outside the SCO means that we do not break the encapsulation of that SCO and it will still be reusable.  All you have to do to reuse it is build a new manifest with a different organization - which is what you would have to do in SCORM 2004 anyway!

I will have this paper out to the LETSI group soon and I will post a copy on this blog.

Vizdos

I recently blogged about my trip to Tampa for a Certified ScrumMaster (CSM) training course.  I just wanted to say that it was pretty cool.  The guy running it, Mike Vizdos, was a pretty good facilitator and we had a great group there.  There where some developers from Chase bank, the Home Shopping Network, the Orange County School Board, and me.

Thanks Mike.  The class was worth the money.

Scrum Roles

I have recently been very excited about Scrum and agile software development in general.  Today, I was thinking about the team roles in Scrum.  Scrum has only three roles - Product Owner, Scrummaster, and Team.

The Team role includes all the people that actually do the work.  This means you have coders, testers, business analysts, DBAs, architects, and whatever else you may call your people.  Scrum lumps them all together to enforce the "we're all in it together" attitude.  An important way to look at a role in a team is to look at what things that role has control over.  The team controls the source code.  Only the team can make changes to the product and they have to decide how to make those changes in the most efficient way that meets the organizational polices.  Trying to decide between MSSQL, Oracle, or MySQL?  The Team decides.  Trying to decide between C#, Java, or Ruby.  The Team decides.

The next role is the Product Owner (PO).  The PO is responsible for defining and prioritizing the product backlog.  The PO owns the backlog.  No changes can be made to the backlog without the PO's involvement.  What that means to the team is that all the outside influences of "can you do this for me" should go through the PO.  This is the guy that everyone has to talk to if they want a feature added to the product and she has the authority to say "no" to any feature.  Of course, the way you say "no" in Scrum is to add the request to the product backlog with such a low priority that it will never get done.  Everything goes on the product backlog, even if it is just plain stupid.

The last role is the Scrummaster.  Scrummasters are there to facilitate team communications and educate everyone (inside the team and out) on how Scrum works and what the basic operational rules are.  The Scrummaster owns the process.  Some will debate me on this point, but I think the Scrummaster should also own the engineering practices.  The Scrummaster sets the benchmark for organizational compliance.  For example, a Scrummaster may set the organizational policy that a daily build is required for all projects.  This policy is "bigger" than one team.  The Scrummaster does not own the team's internal procedures, he only deals with the policies.  For example, at my organization there is a policy to "use C# unless there is a compelling reason to do otherwise."  As such, 90% of our projects are on the .Net framework using C#. 

But, there is a second responsibility that the Scrummaster has that is less obvious.  The Scrummaster is the team facilitator.  He guides discussions in meetings and helps to ensure time boxes for events.  The Scrummaster has to get the team members to talk to each other and collaborate.  This is no easy task.  Let's face it, most of the programmers we work with are introverted and weird.  The are non-communicative and more at home sending IMs to each other than speaking.  They hang a picture of their avatar in a nice frame in the hallway.  They are not the kind of people that want to talk or share or socialize or go outside when the sun is shining.  Scrummasters have to break through the team's tendency to avoid communication and get them to be agile and collaborative.

There one last role that I should point out, even though it is not a Scrum role.  That is the "everyone else" role.  Managers, marketing guys, executives, and users all fall in the "everyone else" group and should address all their concerns with the PO or the Scrummaster.  They should not disturb the Team during a sprint.  To disturb the team during a sprint has a few specific effects.  First, it slows the team down and reduces their velocity.  Second, it undermines the authority given to the PO.  This is a big deal because the team needs to look at the PO as the authority on the product features.

So, the Product Owner owns the backlog, the Scrummaster owns the process, and the Team owns the work.

ActionScript and JSON Idea

I just had a new idea.  Or, at least it's new to me.  The idea is a framework for a Rich Internet Application (RIA) that allows a Flex-based RIA to communicate with a server-based database using a RESTful JSON communication channel.

The thing that makes this idea different is that the server would not just use JSON to serialize the data, but would actually embed methods into the object with ActionScript code that implements a full ActiveRecord or ActiveResource pattern for the object being retrieved.

So, in the RIA client we could have some code like this:

1: var prod:Product = Product.Create();
2: prod.name = "my product";
3: prod.Save();

So, on line one we have a factory method that creates a new Product object by calling the http://server/product/create rest method and getting back a block of ActionScript code that it can Eval() into an object.  This product object then has properties that can be read or written and methods for saving the data.  The Save() method on line three actually fires off an http request to the server to save that specific record in the database - http://server/product/save/42 where 42 is the primary key value for this object.

The great thing is that the server side code generator and REST API should then be completely generic across all RIAs.  All the custom application logic is in the RIA, not the server.  The server is only responsible for authentication/membership and data persistence.

RoR is the Mac User's Programming Language

I like to keep an open ear for new technologies coming out, especially in the software development arena.  One new item that a lot of people are raving about is Ruby on Rails (RoR).  So, I decided to check it out.

I found out that it's made by a bunch of Mac users.  As most computer professionals know, Mac users all fall into one of two categories.  The first (and larger) category is grandparents that can't type much less use a computer.  This is the group that believes having more than one button on your mouse is far to confusing.

The second group are the elitist non-conformists.  This is the group that believes it is more trendy and cooler than every one else.  This group buys into the idea that owning a Mac somehow makes you more special and accepted into a cult community of arrogant elite users and ultra-hip cool guys.

Well, the Ruby community is in the second group and keeping that stereotype alive and well.  To be fair, RoR is a pretty neat framework with some awesome features that other frameworks just don't have.  You can roughly accomplish the same stuff with .Net or Java but you would have to combine several third party libraries and code generators to do it.  RoR is a sweet little package that gains all of its efficiencies from one central theme ... convention over configuration.  What this means is that RoR has already made most of the design decisions you will ever need to make for your application for you.  You will build database powered web applications with RESTful interfaces that implement a CRUD interface using the Model-View-Controller pattern.  You will use ActiveRecord, and the other framework-provided base classes.  If you don't do this, then your application is, according to the RoR mantra, wrong and stupid.

The RoR founder, DHH, came right out and said that they are not interested in any new innovations from other languages, but will impose their conventions on everyone else.

All in all, I am a little put off by the whole idea that I have to join the movement or I am not really a RoR developer.   But, what do you expect from a Mac user?

ME the Scrummaster

I will be traveling to Tampa, FL this week (Thursday and Friday) to attend a Certified Scrum Master (CSM) training session hosted by Michael Vizdos.  I have read a couple of his books and his web site seems funny.  Hopefully I will learn something about Agile in general and Scrum in particular.

SCORM 2.0 Call for White Papers

The ADL community has turned over the development of SCORM 2.0 to the LETSI organization. LETSI has just put out a call for white papers that will be used to shape the next version of the SCORM specification. You can find some more info on the status of SCORM 2.0 at the LESTI web site.

I am in process of authoring a white paper for LESTI that I hope will help the community. The basis of my white paper is a revamping of the SCORM sequencing and navigation model. The problem I see is that SCORM attempts to use an XML grammar to describe the logic of sequencing. XML is not a logic language; it is a data language. I propose a way to replace the XML based logic grammar with an event based ECMAScript model. This allows the content developer to program their own sequencing behaviors above and beyond what SCORM has envisioned and do it in a way that clearly separates the concerns of the LMS vendor from the content vendor.

I'll have more on this as I flesh out the paper a little more. If you are interested in submitting a white paper, please see the LESTI site soon as the deadline for submission is August 15, 2008!

I'm Finally Taking the Plunge

Yes, I have created a blog. This is a day I thought would never come. It seems that I have all these crazy ideas and I want to put them down in print somewhere and a blog is the easiest way to do that. So, here it is.

I will be brain-dumping stuff about SCORM, ASP.Net development, C#, Design Patters, Agile Development, and a bunch of other stuff you can find and 47,386 other blogs -- but this is the only one that has my adorable face on it.