Joe Ocampo (AgileJoe)

What are you solving for?

Joe Ocampo — Fri, 05 Jun 2009 03:46:00 GMT

Exactly!

I am always amazed of how much software is created with the intention of solving a business problem, only to be deployed to production and not deliver any value to the organization.

Some will argue that this is what the short feedback cycles of most Agile methodologies provide. They give you insight from the customer directly, to determine if you are solving their problem but this is where software development is an immature industry. For example:

I always like to give the example of the patient that visits the doctors office complaining that his arm has been hurting after falling off his ladder. He has iced it over, rested it and has even went to far as to self medicate in an effort to subdue the symptoms. The patient then proceeds to tell the doctor that he thinks he must have bruised his rotator cuff and is wondering what his options are to help with this self diagnosis. After a couple of minutes of the doctor looking over a couple of x-rays, the doctor turns to the patient and says, “Your problem isn’t your arm, it’s your back. You have damage to one of your vertebrae that is causing you to feel pain in your arm.”

If this were software development we would have already amputated his arm and given him a new bionic one that would enable him to lift a small car. All the while not solving the root issue but boy what a wonderful technical achievement we would have created.

Joe are you telling me that we shouldn’t listen to the customer? NO! Just like a “good” doctors listens attentively to his patients concerns, carefully weighing every fact of the case. He reserves his diagnosis until he has ran several test and determined if the "data” supports his conclusions. He relies on years of experience and training in order to come up with the best remedy for that diagnosis.

So ask yourself are you solving the symptom, or are you curing the illness?

LosTechies welcomes Sharon Cichelli "Girl Writes Code"

Joe Ocampo — Tue, 02 Jun 2009 04:39:00 GMT

I am proud to announce that Sharon Cichelli has graciously agreed to join LosTechies! We are all looking forward to her perspective and insights into software development. Sharon is an active member of the Austin .NET users community. Her passion for software is equally balanced by her passion to see the bigger picture.

Welcome Sharon!

Setting up Ubuntu Jaunty for Ruby and Rails development

Joe Ocampo — Wed, 06 May 2009 15:06:00 GMT

Getting Ruby setup on Ubuntu – Jaunty

UPDATED: Added RSpec for Rails as well

Here are some quick steps to get you up and running with Ruby on Ubuntu, Take about 15 minutes depending on your internet connection.

Step 1: The first thing you need to do is update the packages in Ubuntu open the terminal window (Applications Menu | Accessories | Terminal) and type in the following commands.

   sudo aptitude update
   sudo aptitude dist-upgrade

Step 2: The next package will insure you have everything you need in order to build ruby packages on your system.

    sudo aptitude install build-essential

Step 3: Type in the following command to install Ruby NOTE: this is all ONE command

    sudo aptitude install ruby1.8-dev ruby1.8 ri1.8 rdoc1.8 irb1.8 libreadline-ruby1.8 libruby1.8 libopenssl-ruby

Step 4: Type in the following command to install SQLite3 NOTE: ONE command

    sudo aptitude install sqlite3 libsqlite3-ruby1.8

Step 5: Install Ruby Gems NOTE: Multiple commands

   wget http://rubyforge.org/frs/download.php/55066/rubygems-1.3.2.tgz
   tar xvzf rubygems-1.3.2.tgz
   cd rubygems-1.3.2
   sudo ruby setup.rb

!! You should get an error stating that Ruby command not found !!

Step 6: creating the ruby symlink (symlink stands for symbolic link, windows user can think of it like a shortcut)

   sudo ln -s /usr/bin/ruby1.8 /usr/local/bin/ruby

Step 7: Install ruby gems NOTE: you should be in the directory rubygems-1.3.2 when you run this command

    sudo ruby setup.rb

Step 8: We need to create the remaining symlinks for ruby utilities NOTE: Multiple commands

    sudo ln -s /usr/bin/gem1.8 /usr/local/bin/gem
    sudo ln -s /usr/bin/rdoc1.8 /usr/local/bin/rdoc
    sudo ln -s /usr/bin/ri1.8 /usr/local/bin/ri
    sudo ln -s /usr/bin/irb1.8 /usr/local/bin/irb

Installing Rails

Step 9: Install Rails

    sudo gem install rails --no-rdoc --no-ri

Step 10: Create a test project NOTE: Multiple commands

    cd ~
    mkdir apps
    cd apps
    mkdir rails_apps
    cd rails_apps
    rails testapp

Step 9: Start Webrick web server in your testapp directory

    ./script/server

Step 11: Open up Firefox and navigate to http://localhost:3000, you should see a page with the text:

    Welcome aboard
    You’re riding Ruby on Rails!

Step 12: Install Rspec

    gem install rspec

Installing source control

Step 13: Install subversion

    sudo aptitude install subversion

Step 14: Install Git because you are going to use plugins from GitHub

    sudo aptitude install git-core

Step 15: Install Git-svn

    sudo aptitude install git-svn

Step 16: Add SVN Like Shortcuts to Git

    git config --global alias.st status
    git config --global alias.ci commit
    git config --global alias.co checkout
    git config --global alias.br branch

Step 17: configure the global user for Git

    git config --global user.name "Put your full name here"
    git config --global user.email you@rackspace.com

Step 18: colorize the output for Git

    git config --global color.branch auto
    git config --global color.diff auto
    git config --global color.interactive auto
    git config --global color.status auto

Installing RSpec for Rails

I want to put a disclaimer here that this is my preferred way of installing RSpec from GitHub. It is not the only way.

Step 19: Navigate to the root of your Rails project. I am assuming that in this case it will be "testapp"

Step 20: Install Rspec for Rails from GitHub as Git submodules. NOTE: Multiple commands

git submodule add git://github.com/dchelimsky/rspec.git vendor/plugins/rspec

git submodule add git://github.com/dchelimsky/rspec-rails.git vendor/plugins/rspec-rails

Step 21: Run the rspec generators, this will enable the rspec_* controller, scaffold, model generators

ruby script/generate rspec

This is going to drive you nuts if you have to remember to do this for every rails project you create so I created a simple bash script. Actually the contains more than the bash script it also has the aliases that I use for Rails development.

Step 22: Navigate to your home diretory

cd ~

Step 23: Create the .rails_aliases file

gedit .rails_aliases

Step 24: In gedit copy the following text to the .rails_aliases file

alias ror-doc-spec='open -a Firefox doc/plugins/rspec-rails/index.html'
alias ror-doc='open -a Firefox'
alias ror-scaffold='ruby script/generate rspec_scaffold'
alias ror-controller='ruby script/generate rspec_controller'
alias ror-model='ruby script/generate rspec_model'
alias ror-git-customerror='script/plugin install git://github.com/gumayunov/custom-err-msg.git'
alias ror-console='ruby script/console'
alias rapps='cd ~/apps/rails_apps'
alias ror-serv='ruby script/server'
alias ror-logtail='tail -f log/development.log'

# Configures a rails app to use rspec
specrails(){
        git submodule add git://github.com/dchelimsky/rspec.git vendor/plugins/rspec
        git submodule add git://github.com/dchelimsky/rspec-rails.git vendor/plugins/rspec-rails
        ruby script/generate rspec
}

Step 25: Save the file and close gedit

Step 26: Open your .bashrc file from the terminal window

gedit .bashrc

Step 27: Add the reference to your .rails_aliases file in your .bashrc at the top of the file add the following line:

source ~/.rails_aliases

Step 28: Save the file and exit gedit

Now if you want to add RSpec to any rails project you simply navigate to the root of a rails project and type:

specrails

If you want to add a controller with RSpec specs you simply have to type:

ror-controller BlogPost title:string author:string content:text ...

Hope this helps! Happy coding!

Role Storming

Joe Ocampo — Wed, 29 Oct 2008 03:06:00 GMT

UPDATE: This excercise is ideal for large projects with many SME's in the room. In this case I was building a Loan Orgination System for a bank with 10+ SME's in the room that were all arguing with each other about the Persona's and thier behaviors this took two days to do but the outcome was well worth the effort. If you have 1-4 SME's this is possibly overkill. Be pragmatic not dogmatic.

Occasionally I am brought in to facilitate story break down sessions. I have to admit that this is one of the more enjoyable aspects for me when dealing with large Agile project because it allows me to learn a ton of information about the business domain.

One of the first exercises I go through is a Roles Storm. This is an exercise that gets the customer to think about the different types of behaviors that certain roles and personas can perform in their software that they are asking you to build. This exercise helps me to hold story authoring sessions in the future.

I try to focus the discussion towards the lowest level persona that does something. The template of the exercise is very simple:

A {Persona/Role} can …

In this case I will use the “Loan Rep” persona.

A Loan Rep

- can view their own pipeline

- can order a credit report

Once we establish the lowest common denominator you simply move up the chain:

A Processor

- can do everything a Loan Rep can do and

- can upload to desktop originator and loan prospector

As you can see I am able to start identifying lots of domain concepts. DO NOT try to dive deep with this exercise. Its focus is around brainstorming of Personas and Roles only. Let the customer do most of the talking. Do not let this turn into a technical discussion.

WARNING: This list does NOT contain stories, it contains concepts for stories but it does NOT contain stories!!!!

Preparation time for this exercise is a few minutes but the event usually last at least a full day.

In the end you end up with a list that looks something like this:

Roles

Back Office (Centralized Admin)

Super User

can do what the help desk manager and business admin can do,
can defines profiles,
can maintains universal system tables,
has access to the entire application,
can delete loan records from the system, (flag to stop display of record in any pipeline view – only available to admin and can be identified on reports.)
can update mortgage center home page content,
can create admin users,

Help Desk Manager

can do what a team lead can do,
can be given the permission to delete loan records from the system,
<revisit> can reset loan events,

Help Desk Team Lead

can do what a help desk user can do
can add and maintain users,
can create and maintain loan centers, (full name of lender in table – online view would be an abbreviated version)
can maintain peer level admin profiles or lower,
can pull lead between reps and processors within a loan center,
can push lead and loan records to other loan centers,

Help Desk

can add and maintain mortgage center users,
has system wide read only access,
can invoke a system wide search

Business Admin (Centralized)

can add and maintain loan programs and fee schedules,
<revisit> can create and maintain printable documents,
<revisit>can maintain dropdown tables (ex. Marketing codes, loan conditions),
can add new contact types and global contacts.

Loan Office Admin (Loan Center)

can pull lead between reps and processors within their loan center(s),
can push lead and loan records to other loan centers,
can modify user permissions within their specified role within their loan center,
can make a user inactive or active within their loan center,
can make user available or unavailable within their loan center,
<revisit> shared roles,
can be given access to assign loan to themselves,

Field Roles

Loan Center Manager

can do everything a processor can do,
can pull lead between reps and processors within their loan center,
can push lead and loan records to other loan centers,
can modify user permissions within their specified role within their loan center (include permissions to access loan center pipeline)
can make a user inactive or active within their loan center,
can make user available or unavailable within their loan center
Can delete leads across loan centers and users (no credit ordered)

Processor

can do everything a loan rep can do and
can upload to desktop originator and loan prospector,
can export FNMA 3.2 file,
can add and maintain conditions to a loan,
can submit loan package to lender,
can print all documents,
can add and update lender denial and counteroffer,
can view all teams pipelines within their loan center,
can edit any lead or application within their loan center,
can run reports for their loan center.

Loan Rep

can add and edit & delete their leads in the system but cannot delete an application (credit has been ordered),
can view their own pipeline,
can order credit,
can include and exclude liabilities from the 1003 section,
can complete full 1003,
can order appraisal,
can order title,
can add notes to conversation log,
can add contacts,
can create rate locks,
can print 3 day disclosures,
can select loan programs and fee schedules,
can print the 1003 blank or otherwise,
can import 1003,
can view and print rate sheets,
can flag loan as withdrawn,
<revisit> task creation and assignment,
can submit lead to processor,
can push lead to another user,
can collect and record upfront fees,
can run reports for their pipeline,
can make themselves available or unavailable
can be given permission to pull from loan center pipeline (public queue)

Managing changes in scope and direction in an agile projects

Joe Ocampo — Sun, 12 Oct 2008 15:35:00 GMT

I was recently asked the following question, “How do you best manage changes in scope and direction in an agile project?”

Embracing change is the quintessential backbone of Agile. How to manage it is a whole other story. ;)

The difficult aspect of this paradox is to understand the context of the change. When I coach people on change I tend to draw a metaphor to building things with Lego’s. In this particular context the change is centered around misguided direction that results in the production team wasting time building the wrong thing.

In this example the product owner has asked you to make a snow man out of Lego’s. We go through preliminary analysis with the team (Development, BA, QA, Product Owner) and determine these high level features and their corresponding complexity ratings:

Head 400
Body 200
Bottom 300

This will give us a ballpark of the project size and we can infer from prior Sprints that the team is capable of producing 50 points every 3 week Sprint.

So it will take 18 Sprints and a total of 54 weeks for the team to complete this work. Of course this is a best case scenario. I usually factor in reserve time as well but this is another discussion.

The team starts with the Head because the Product Owner and the team both believe this is the most complex aspect of the project. They break the head feature into several epics (master level) stories. (Remember we are working with Lego’s here).

Hat 150
Skull 100
Eyes 60
Nose 60
Mouth 60

I can go on and on but the point is that the team ends up building the head of the snowman. Now for some curve balls that I know never happen in real life.

The Product Owner is not really the end customer. They are acting as a proxy for field reps that are actually capturing the customer demand for the products that IT creates. When the product owner shows the working head of the snow man to the field reps it goes something like this,

“That is great if we were wanting a traditional snowman but we were thinking of something more like Sponge Bob dressed up as a snowman”

Based on this news, the team just wasted 23 weeks’ worth of development. But you do have intangible gains:

the team has learned how to work together
the team members have a much greater knowledge of making eyes, noses and mouths with Lego’s.
the team matrix as a whole has a much more holistic foundation for issue and problem solving
Agile is no longer a buzz word but an implemented methodology

The challenges now revolve around the Scrum Master or the person in charge of the project to insure that the teams momentum and self image are kept intact. Like I have always said Agile is 70% people and 30% software. The focus has to be on the team dynamics in order to create a cooperative and collaborative atmosphere.

The focus should now be this:

We are going to have to refactor the head to look more like Sponge Bob.
The team should focus on what components they can reuse when gauging complexity ratings.
Don’t panic and just approach this as if it simply a knowledge gain exercise

You hold a new project planning meeting similar to the first one you held and come up with these high level features:

Head/Body 800
Legs 300
Arms 200

You don’t want to dive any deeper at this point. The purpose is to rebroadcast the scope change from a project time line perspective. Now you have a project that was originally projected at 900 points, explode to a project with 23 weeks down the drain and a new projection of 1300 points (that’s including reuse!) At this point you have not wasted any time developing anything new, you have simply reanalyzed the scope change. You take your projection to the Product Owner and have them make the decision. One of two things usually happens, one they cancel the project or two they embrace the new plan.

In most cases this is what usually happens. The product owner doesn’t like either one of the time lines and is completely frustrated. They go on and on about that they need it by a certain time frame etc. Usually I negotiate at this point.

“You know we can’t create the sponge bob but would you be willing to work with my team and their estimates on a similar product offering in that time frame?”

When it is all done you end up negotiating building a Christmas “Plankton” for the end customer. It doesn’t sell at the volume that the SpongeBob would have but it does bring in revenue. The happy ending for the story is that “TRUST” was established between the development organization and the product teams. In fact trust is so high that they want to start working on the SpongeBob surfer dude for next summer.

I know this was very long winded but I wanted to give you a context for the thought of scope change. Things happen on projects that cannot be forecasted at times. The important aspect of all this is not to panic. Knee jerk reaction is to go into a blame game state. This creates an unhealthy atmosphere and does not focus on producing a value stream. Instead use Agile to help facilitate a discussion around the scope that will drive towards success.

When I am introducing Agile to a team I spend at least an hour on the concept of “Embracing change”. I ask the following questions:

· What does embrace mean to you?
· Does embracing change mean all the time or only sometimes?
· If you embrace something is there a possibility that you can get hurt or have negative emotions?
· If you do experience the “feeling” of hurt, how are you going to deal with it in a way that you do not negatively affect the atmosphere and harmonics of the team?
· What is your responsibility as a team member to insure embracement of change is being met?
· Do you still want to do this?

LosTechies welcomes Derick Bailey

Joe Ocampo — Tue, 07 Oct 2008 18:52:14 GMT

We would like to welcome Derick Bailey to the LosTechies blogging community!

Some of us had the opportunity to meet Derick at Pablo's Day of TDD and were impressed with his passion and commitment to modern day software development. He is able to take low level constructs and communicate at a high enough level to where ideas that appeared to be esoteric suddenly make sense.

We are pleased to have him on board and know his passion will help other developers to find answers to questions or figure out new technologies as all the LosTechies bloggers strive to do.

Welcome Derick!

LosTechies Welcomes Scott C Reynolds!

Joe Ocampo — Thu, 04 Sep 2008 03:43:07 GMT

Captivated by his dashing good looks and over all sex appeal, LosTechies is pleased to welcome Scott C Reynolds to our happy family.

We are pleased to have him on board and know his passion will help other developers to find answers to questions or figure out new technologies as all the LosTechies blogger's strive to do.

Welcome Scott!

Need to get something off my chest

Joe Ocampo — Wed, 27 Aug 2008 02:56:00 GMT

For the most part I have been out of pocket from the .Net community over the last 6 months due to new obligations I have taken on. These new obligations have given me the opportunity to explore other communities outside of .Net such as Java, Python and Ruby. All these groups have their quirks but the some things they do have is an expressive community that welcomes innovation and alternative view points. Where as the .Net community I feel my view points and belief structure are contrary to the majority, so I don't *feel* part of community so much as I *feel* a part of a small rebel faction (which is kind of thrilling in a StarWars kind of way).

As a community we strive to make better software for our fellow developer. To make our lives simpler and more productive. As a community we believe in open source software for the betterment of the community. Which brings me to my issue.

I may get flamed for this but maybe I just need to get my hand slapped to settle me down.

As you may know Jimmy Bogard and I have a an open source BDD framework named NBehave. Jimmy, mainly has been working on this off and on and we have learned a great deal about BDD in that time frame. We have experimented with various ideas that have been cultivated in the BDD community and are striving for best practices. There are directions that we would like to take the framework but we have not had time to move it in a certain direction just yet. As an Open Source project we would love additional contributors to help us with the project and just get the community more involved, after all that is what open source is all about.

The key concept here is community. If you have an idea that is similar to a project that is in an alpha state, shouldn't you simply contribute to the project to help grow the idea? As a fledgling community should we not galvanize on concepts to bring greater acceptance to the masses? Or are we mainly focused on becoming the new Rock Star programmer?

Now the context of the issue. I came across a post today on BDD. Looks very similar to this post but instead of anonymous delegates it uses lambdas. Cool idea and one that we are planning on implementing, oh wait we have that already. hmmmm??

One of my issues with open source development revolves around the very nature of this context. Why as a community do we insist on reinventing the wheel? Take for instance unit test frameworks in general. There is NUnit, MbUnit, xUnit and I am sure I am missing others. The point is they all pretty much do the same thing, just a little differently. Was there a fall out between developers on a certain concept? Where they started at the same time and grew up in separate camps? I don't know.

There is nothing wrong with a little competition to spark innovation, I am all for that. But as a community should we at least communicate with one another to talk about concepts around frameworks that are so similar in nature? If you have conflicting view points on a particular direction then by all means create a new project but if the view points are the same then galvanize with the other projects to help strengthen the concepts and ideas around which the tool is being built, this will only strengthen the community.

I am not the type of person to be married to my code. I believe in dating it. It's ok if you want to change it, enhance it or delete it. I don't really care. What I do care about is the concept and principles upon which the tool is meant to serve. I am not in this industry for the notoriety or the prestige. I simply want to create good software with the help of the community. I love conversing with other developers on ideas or concepts. This is what truly drives me.

I want to go on the record, that I do not think that the authors of StoryQ had ANY ill intentions or malice towards NBehave or other BDD frameworks. I am simply saying, why couldn't the authors have contacted myself or Jimmy to help make NBehave better. The dialog would only have helped to strengthen view points and concepts.

BTW I have contacted Jimmy on any of this so if you have flame don't send it his way.

How healthy is your code?

Joe Ocampo — Thu, 21 Aug 2008 18:56:42 GMT

Technical Debt is not simply an Agile buzzword more than it is a fact of software development. Just like any other debt it imposes negative ramifications on the software and significant loss is revenue.

I hate to get touchy feely but I think what I am about to say holds the most weight when presented in this manner.

If we look at our code as a living and breathing life form, we are responsible for its creation and well being. As we hack through our code feverishly because of dead lines or time constraints we severely retard the health of our code. Why do we allow this to happen? Usually this is because we don’t have anything to monitor the cholesterol or blood sugar level of the code. There is no external indicators that allow us to gauge the health of the code.

Take for instance when I was in high school I use to love to play sports, any sport. If it had a ball in it, I was there. My mother told me to watch what I ate, make sure to eat lots of vegetables , exercise, etc. Did I listen???? No! I ate what ever I wanted and didn’t give it any thought because there wasn’t any immediate external visible signs of what was happening to me internally. I could leap, run and jump with the same intensity as I did when I was a child so why should I change?

Now fast forward 20 years. Well, I still love to play sports but I can’t play them near the same intensity I had as a teenager. My body hurts in places I never even knew could hurt. Jumping down off the kitchen counter causes my knees to buckle under the pressure of descending 3 feet! What I didn’t know is that I was incurring a health debt early on in my child hood that is having horrible compounding effects in my middle age.

The same deteriorating effects happen with software, just at a much more rapid pace. This deterioration happens in front of our noses, we just don’t pay it any attention because there isn’t any external indication of the impact to health of our software. Or is there?

Can you change your code and understand the side effect or worse are you afraid to change your code at all?
Can you *easily* change your code or do you spend sleepless nights adding the simplest of changes to your code?
Do you know how much of your code is tightly coupled?
Do you think that orthogonal principles are something that is only for enterprise projects?
When you run a code coverage tool do you throw the results away because there is so much red and not enough time?
Are you prioritizing defects as Critical, Important, High, Medium and Low; where Important and High account for 80% of the defects but are not taken care of because they are not in a critical state?
Do you follow ANY type of SDLC?
Do you attempt to include your customer or at least have a customer proxy to advocate concern and prioritize your work?
Is your code littered with comments such as, “we need to fix this”, “Don’t change this because I don’t know how I fixed this?”, “WTF?”

Now the magnitude of how much each one of these questions effects technical debt is purely subjective. The point I am trying to make is that your code is not in a healthy state and has the possibility of contracting a terminal illness that will lead to its death if you don’t take care of it now!

Grapevines and Agile make great Wine...

Joe Ocampo — Tue, 24 Jun 2008 20:39:00 GMT

I couldn't resist the title.

By this point in most of your careers you have been exposed to the grapevine exercise. This exercise is geared to show you how one thought through many control points gets distorted and misrepresented. I believe this is true for the majority of conversations out side of work but if leveraged properly can add tremendous benefit to an organization.

Keith Davis did a study of the grapevine in 1953. Keith Davis stated

"the grapevine is a natural part of a company's total communication system...it is a significant force within the work group, helping to build teamwork motivate people, and create corporate identity."

This type of discussion medium is prevalent and natural to the greater society. Just think about what happens in your homes.

In most homes there isn’t a plan written down for how to do the budget, there isn’t a process on how discussions at the dinner table will be deliberated. There are guidelines but these guidelines are mutually agreed upon in open discussion. In most homes these types of forums are left open and honest, focus is on content then exactness.

Organically barriers are established but periodically they are revisited (usually by teenagers) to test their validity. The content however is “I heard...”, “Did you know...”, “Today at work...”. Nothing of empirical substance but enough to spark decisions in the house hold. If we are wrong we readjust and go on.

Some of us however need more control in order to FEEL safe. Some of us feel that the more we pursue exactness the better our decisions will be. Issues arise when this personality type forces others to fall in line with this thought process.

Several heavy weight methodologies have attempted to control discussion and thought through various bureaucratic mechanism. While some have the perception of control, few if any, have ever been able to achieve this.

The Agile Manifesto tells us that we should value Individuals and interactions over processes and tools.

So with this philosophical mindset we must propagate fluid communication and document or create processes around communication when “absolutely necessary.”

Take a moment and evaluate “absolutely necessary,” this implies that you have exhausted all low friction practices to promote communication. Then and only then do you investigate a tool or a process to govern communication.

If you do come up with a process or tool please take the time to put in place some type of 6 week reevaluation period to determine if whatever avenue you are pursuing is proving to beneficial and not wasteful.

How does this have anything to do with the grapevine paradox? Well, you have to remember that people are people, rather then trying to change their innate ability to communicate openly, embrace it!

I would venture to argue that the majority of individual you interact with daily would welcome open communication over documentation. There are the few that do so if your organization is composed of this type of individual you must respect their needs and give them what they need to be successful. But weigh it in contrast to the majority.

Take the grapevine paradox and embrace it by facilitating open communication such as daily stand-ups, fishbowl discussions, innovation games, collaborative retrospectives and development lab architectural discussions. The emphasis is on the openness which breeds transparency.

Let us not forget that People communicating successful to accomplish a common goal are what determine project success not charts or graphs but people.

Simple in concept but often overlooked.

Matrix Resource Management and Agile

Joe Ocampo — Mon, 23 Jun 2008 20:03:41 GMT

I have been having an ongoing discussion lately concerning matrix management styles and how they conflict with Agile Project Management.

If you look at the traditional "Iron Triangle", resources are estimated, in that change is expected in the resource allocation depending upon task and assignment.

In Agile resources are fixed throughout the duration of the project and features are variable.

This is a clear delineation into the approach of Agile resource management. Traditional matrices were based off of manufacturing models that do not lend themselves to effectively managing knowledge-based work such as software development.

Manufacturing management relies on technicians to be trained at various activities in their line of work. These activities rarely, if ever, change. So, mastery of these activities increases dramatically with repetition. This is not a bad thing, since tremendous value is gained through the repetition for the business. From a management perspective it is very easy to assign different work streams to one person since the proficiency level of the work environment is not built upon change or adaptability but on repetition and skill mastery.

Knowledge-based resource management understands that knowledge workers are trained professional but the context domain on which their skills are applicable is in a constant dynamic state. Therefore, this forces the knowledge worker to pursue greater levels of training and reconstitute positions of ideology based on experience. This is the benefit of the organization that employs knowledge workers.

The fluidity of communication and thought surrounding a project (especially a software project) forces the knowledge worker to gain greater depth in the problem domain so that they may better serve the business in providing services.

This idea is compounded when you start to manage teams of knowledge workers. The term, "two minds are better the one", shines in this environment. As knowledge teams ensure business value is rendered and investiture in the project increases, the thoughts and ideas of the whole out weight that of the individual.

As matrix management encroaches upon Agile management the philosophical view points on resource allocation are contrary to each other. Consider the following:

Organization: Gloop Org

• Developer UberBob – Is assigned to

Project A @ 25% of his time
Project B @ 65% of his time
Project C @ 10% of his time

I know this NEVER happens but work with me. The Gloop organization is wanting to move toward a more Agile development approach but is not willing to give up it's matrix model just yet.

• Project A is in the planning stages and several meetings have been setup to discuss how the new billing system is going to work.

• Project B is knee deep in the second release and velocity has been established for each iteration. The new warehouse system is underway.

• Project C is just finishing up but automated testing wasn't followed so the team is mainly focusing on defect removal. Defect backlog is high.

Monday:

Bob comes to work and is perplexed to what standup he has to attend since he has input to each one of the projects he is on. He has already been dealing with this dilemma for the past couple of months as he spends the latter part of his day creating emails to send to the project managers of the standup he will not be attending.

The project managers do their best to convey Bob's work and impediments but usually Bob has to follow up with team members throughout the day to determine what he missed and what issues he has to solve due to the breakdown in communication.

In Project B, Bob is working heavily on how the conveyor system is going to determine what gates to open to ship the merchandise. There is an issue, however, that the team has to figure out because the communication protocol isn't fully supported for the gating system as originally thought. Several meetings are planned in the afternoon with the development team to discuss the correct course of action.

In Project A, they are still going through several domain modeling sessions to flush out how the billing system is going to work. The billing system model for Gloob is unique and is how the company maintains it's competitive advantage. They are going to go over the complexities of this system in the afternoon.

In Project C the defects are just getting out of hand. There are several show stopping defects and the team is going to have to determine how they are going to solve these issues before going to production. They are going to get back to Bob on when the meeting is going to be held.

I am not going to go into what happens here but magically Bob is able to pull a miracle and make it to each meeting but he has to sacrifice time and only go partially to each meeting and rely on the meeting minutes to catch him up to speed.

Bob is an awesome developer, he is prideful about everything he does, and works late hours to overcome all the impediments his projects go through daily. The issues surmount when the communication breaks down.

What Bob didn't know was after he left the Billing System meeting they went into a critical discussion on how the system calculates interest. His fellow teammates estimated that feature at taking days, but in reality with Bob's experience, it will take months. In the warehouse system the Product owner came in and changed the backlog since the “gate issue” is going to take longer to flush out. So they added other value stories above the gate. But Bob doesn't know this and is planning on staying late to figure out how to solve the gate issue. Bob was unable to really bring any value to the defect discussion since he came in at the tail end of the meeting. Bob's teammates weren't too happy with him for missing the defect meeting.

End of Monday…

I know this never happens in the real world but it is very possible (I say that tongue in cheek). All these projects are at risk because of the matrix model. Knowledge workers need to focus on one context at a time so that we harness the power of their collective thought.

By fixing the resources on a given project and dedicating them throughout, you gain momentum and predictability of effort. Matrix models disrupt communication continuity as well as iteration velocity. As you mix and match resource from project to project every week, you might as well throw whatever velocity you have been tracking out the window as the team dynamics have been disrupted. If you simply perform a one for one swap of personnel you cannot expect output not to be disrupted.

I want to make sure that everyone understands that I am not saying that matrix management doesn’t work. I have seen it work on extremely large RUP projects that lasted several years. My definition of “work” is slightly skewed because the project was less then stellar but the work effort was as fluid as RUP can be.

My argument solely revolves around matrix management and Agile. You can do it but the experience of true Agile will be lost. The people aspect of Agile, which to me is the most critical, will be damaged due to constantly managing frustration based around priority and delegation.

I have always said this and continue to say this, “Agile refocuses management to concentrate on people aspect of leadership. By focusing on increasing quality of life for the employee and increasing knowledge share, the benefits are tremendous!”

My issues with the term "Scrum Master"

Joe Ocampo — Sat, 07 Jun 2008 21:54:00 GMT

A few years ago I was very excited at the possibility of becoming a Scrum master. At the time I had been an avid XP practitioner for a little over two years. I had read several books on the Scrum but viewed it as simply Yet Another Agile Methodology (YAAM) with a focus more on the project management. I thought to myself that I must have been missing something. How can something as simple as this methodology be taking off like wild fire in the corporate arena? I figured that a Scrum Master class would shed light on this dilemma of mine.

Day 1 of Scrum Master training, typical PowerPoint presentation with lots of slides telling you how great Scrum is and different scenarios where Scrum has been applied. Still no epiphany. The day goes on and we get to do hands on Sprint planning meetings, we emphasize the importance of the Daily Scrum. OK been there already, understand the importance feedback, still nothing ground breaking. Next we talk about value stream prioritization from the perspective of the Product Owner. People are asking lots of questions on what do you do…etc. Lots of dialog but still nothing earth shattering. Next we discuss organic team composition, something that is near and dear to my heart but we spend around 20 minutes on this topic basically saying let the team self organize to gain the greatest value. On to retrospectives, very enlightening, nothing really new, there isn’t one way to do a retrospective, several books are recommended. And this is the end of Day 1.

Day 2 we actually go though an entire mock release. We form up into 5 person teams. Each of us assumes various roles such as Product Owner, Scrum Master, and the development team. We go through the Sprint Planning session and prioritize a backlog with the product owner learning several techniques on how to gain insight into how the backlog is being prioritized. Now we start our first development cycle that is time boxed to 5 minutes. Team self organizes and pulls stories from the backlog to work on. At the end of 5 minutes we do our daily Scrum. We talk about what we did, what we are going to do and are there any impediments in our way. We go through several cycles with some of them trying to be sabotaged by the instructors with various impediments that the team manages to overcome. At the end of the Sprint we demonstrate the final product to the Product Owner (in this case it was a magazine) they make suggestions and reprioritize the backlog. We then hold a Sprint retrospective and talk about what worked, what didn’t work, and where we could improve. On to the next sprint to start the whole process again.

At the end of Day 2 we had a feedback session about how the class went. We talked about what we learned and ways on which to improve the class. For me it was nothing more of a confirmation of what I had already been practicing but there was something that was missing, more on that later.

Now the scary part! Towards the end of the class we signed several sheets of paper and 30 minutes later I was awarded the title of, “Scrum Master”! What I didn’t tell you is that the class was filled with individuals with out any software development background. Here is a list of some of the titles that where in the meeting. Vice Presidents, CIO’s, Project Managers, Product Mangers, Developers and a Financial Analyst. All of these individuals could now place, the title of Certified Scrum Master on their resume and wreak havoc to any organization that would give them the power.

It is not that I have a problem with Scrum so much as it is I have a problem with title, “Scrum Master”. The word “master” implies that this person has attained a level of mastery of everything related to scrum though experience, experimentation and trial. I would have preferred the term “Scrum Apprentice” to “Scrum Master”.

Scrum is very instrumental at getting an organization to adopt Agile. I have a post about this calling out that, “Scrum is the gateway drug to Agile”. If you choose to adopt Scrum your organization you will gain greater insight into its culture. This insight is not always welcomed as it will expose many of your organization process and personnel related issues. How you choose to deal with these issues will determine how successful your project will be.

Personally speaking Scrum cannot be practiced on its own. Scrum lacks software engineering disciplines and practices, this is where XP excels. By combining both methodologies into one ecosystem you have a very powerful foundation to build on.

If you do decide to go down this path make sure to ask for the Scum Masters list of impediments and how they overcame them. Also ask about what they have learned from their mistakes. This will give you an idea on the level of experience the individual has running Scrum Projects.

Twittering from the command line

Joe Ocampo — Wed, 21 May 2008 04:47:00 GMT

So I was experimenting with Twitter last night and started to use their RESTful services from the command line.

Why you may ask? Well sometimes I just want to tweet something quickly and I don't want to bother with opening a client or web page. So I through together this simple bash script.

tweet()
{
curl -u <username>:<password> -d status="$1" http://twitter.com/statuses/update.xml
}

Simply add this to your .bash_profile and you can tweet from the command line all day.

tweet "Tweeting from the command line is awesome!"

I love RESTful services despite popular belief. :-)

JUnit 4 TestSuite Declaration

Joe Ocampo — Tue, 15 Apr 2008 02:35:00 GMT

This is mainly for my own reference but if it helps people out there great! The documentation on this aspect of JUnit is very poor.

package agalliao.wealthManagment.domain;

import org.junit.runner.RunWith;
import org.junit.runners.Suite;
 
@RunWith(Suite.class)
@Suite.SuiteClasses({
  investmentTests.class,
  catalogTests.class,
  markerTests.class 
})
public class AllTests {
    // why on earth I need this class, I have no idea! 
}

PTOM: OCP revisited in Ruby

Joe Ocampo — Mon, 31 Mar 2008 02:54:43 GMT

I was playing with some Ruby code this weekend and thought I would show some OCP with Ruby.

For more of an in-depth discussion on OCP please read my previous post.

Now the first thing I want to point out is that dynamic languages are naturally by default open for extension. Since the types are dynamic, there are no fixed (static) types. The enables us to have awesome extensibility. It is the closure part of the equation that really scares me more than anything else. If you really aren’t careful when you are programming with dynamic languages you can quickly make a mess of things. This doesn’t take away from the power of a dynamic language you just have to exercise greater care that is all.

So let’s use our OCP scenario template again and apply them to the example scenario.

The ProductFilter is responsible for filtering products by color
The ProductFilter is responsible for filtering products by size
The ProductFilter is responsible for filtering products by color and size

Let’s go ahead and create the ProductFilter first.

class ProductFilter
    
    attr_reader :products
    
    def initialize(products)
        @products = products
    end
    
    def by(filter_spec)
        
    end
end

For those that have never created a class in Ruby let me breakdown the syntax structures.

class keyword is used to define a class followed by the name of the class. It is important to note that class names must be start with an uppercase letter. The uppercase letter signifies to the Ruby interpreter that this is constant, meaning that whenever the term “ProductFilter” comes up it will always reference this class structure.

attr_reader keyword used to signify a read only accessor (read only property). The property name follows the colon.

def keyword is used to declare a method block. The “initialize” method is the same as the constructor method in C#.

The @ symbol denotes an instance variable. Notice that the “products” read accessor is never typed but is assigned in the constructor through @products reference. The instance variable @products is assigned to the products parameter variable that is passed into the constructor.

Now that we are talking about products we have to create the actual product class.

class Product
    attr_accessor :color
    attr_accessor :size
    
    def initialize(color, size)
        @color = color
        @size = size
    end
end

Nothing fancy here, just a class with two read/write accessors Color and Size.

If you remember from my previous post I was using a template pattern to serve as the basis for extending the behavior of my filter class. Well I am going to do the same thing here (kind of) and define an Item_color_filter_spec class.

class Item_color_filter_spec
    attr_accessor :color
    
    def initialize(color)
        @color = color
    end
    
    def apply_to(items)
        
    end
end

Now I have a class that accepts a color and has an “apply_to” method that accepts “items”. I have left out the implementation code of this method on purpose.

The next thing I am going to do is create an array of products I can use against the ProductFilter class. Ruby makes this pretty painless:

products = [
    Product.new("Blue", "Large"),
    Product.new("Red", "Large"),
    Product.new("Blue", "Medium"),
    Product.new("Red", "Small"),
    Product.new("Blue", "Large"),
    Product.new("Yellow", "Small"),
]

So what’s going on here? I declared a variable called “products” and assigned it to array by using the square braces “[ ]”. Yup that simple!

What you may have noticed is that I actually instantiated several new products in the array. To instantiate a class you simply use the “new” method that is part of the Object class that all objects in Ruby inherit from similar to C#.

Now that I have a collection of products I am going to give to my product filter class.

product_filter = Product_Filter.new(products)

In the example below I am going to filter all the “Blue” products.

blue_products = product_filter.by(Item_color_filter_spec.new("Blue"))

At this point I am creating a new “Item_color_filter_spec” and giving the color “Blue” as the color to filter on. The ProductFilter class would then simply call the “apply_to” method on the “Item_color_filter_spec”.

If you ran the code at this point nothing would happen because we haven’t actually written our filter code yet. So to do that we are going to modify the “apply_to” method of our “Item_color_filter_spec” class with the following code.

def apply_to(items)
    items.select{|item| item.color == @color}
end

In the code above the “apply_to” method is expecting an array of items to be passed in. We then call the “select” method on the array class and pass in a filter “proc” by enclosing the statement in curly braces {} (In Ruby a “proc” is an object that holds a chunk of code but more on this later). The pipe block “||” is used to signify parameters to the proc similar to the parameters of a method. After the pipe block is the actual statement that is executed. We are trusting that the “select” method of the array object is going to enumerate over each object (product) it contains and pass it into Proc. Once in the Proc we simply determine if the color of product matches the instance variable “@color” of the “Item_color_filter_spec” in this case the color “blue”. When the Proc evaluates to true it passes the item to an array that the select method returns.

You can possibly equate a “proc” to a lambda expression in C#.

(Normally I would have used rSpec to govern everything I am doing but I didn’t want to explain BDD as well. I wanted to focus on the Ruby language in general.)

Now if you run the code you will have three products in the “blue_products” variable. How do you know? Well let’s iterate over it by using the following code.

blue_products.each do |product|
    puts(product.color)
end

Now remember “blue_products” is an array object. The array object has an “each” method (as do other objects in Ruby) that accepts a “proc” object. The “proc” block is denoted by the “do” keyword and terminated with the “end” keyword. In our block we expecting that the array objects “each” method is going to give us a product. As the each method iterates over each product it passes it to the “proc” and we simply tell Ruby to write it to the screen using the “puts” method. The result of this small statement block in the following:

Blue

Blue

Blue

So there you have it 3 blue products!

I know, nothing special right? Well now let’s play with some Ruby sweetness!

That sure is a lot effort to filter a product by color. Imagine if you had to keep adding different color filters. You would have to create several “color filter specs” over and over again. That is dull and most static languages have played this out! So let’s use some Ruby Lambda’s to accomplish the same thing as the “color filter spec”

We are going to create a filter spec that filters all products that are yellow.

Remember I told you that Ruby views all uppercase variable names as constants; well we are going to harness the power of this convention and create a constant to hold the reference to the lambda. After all DRY principles still apply here.

YELLOW_COLOR_FILTER_SPEC = lambda do |products|
    products.select{|product| product.color == "Yellow"}
end

Nothing in the code block above should be foreign at this point except for the “lambda” key word. What the “lambda” keyword does is tell the Ruby interpreter to assign the “Proc” to the constant “YELLOW_COLOR_FILTER_SPEC”.

We have to now modify our ProductFilter class to accept a Proc object. All you have to do is add the following method to the ProductFilter class.

def by_proc(&filter_spec_proc)
    filter_spec_proc.call(@products)
end

This method has a parameter named “filter_spec_proc” but if you notice there is an ampersand preceding its declaration. This tells the Ruby interpreter to expect a Proc object to be passed in. Since we are expecting a Proc object all we have to do is use the "call" method and pass the products instance variable to the Proc.

Now let’s wire the whole thing together.

yellow_products = product_filter.by_proc(&YELLOW_COLOR_FILTER_SPEC)

Pretty simple about the only thing you have to remember is that you have to place the ampersand before the Proc constant when you call the “by_proc” method on the ProductFilter class.

But wait there is more!

Our ProductFilter class now has a method that accepts a Proc object. In our previous example we passed it a constant that referenced a lambda Proc block. But since it accepts a Proc we can simply write the block in line with the method call like this.

With our new found knowledge lets filter all the “Red” products.

red_products = product_filter.by_proc do |products|
        products.select{|product| product.color == "Red"}
    end

Parenthesis are optional in Ruby when you call a method.

Pretty nice huh?

Now for something really freaky for all you static type people!

Lets say you aren’t dealing with products anymore and you are dealing with Cars.

cars have 4 wheels but they also have color don’t they. Gee it would be nice if we could filter the Cars just like we are able to filter the Products. Wait! We can, we already wrote it!

We have that “Item_color_filter_spec” class. We could use the ProductFilter class but that class already has a purpose but the “Item_color_filter_spec” is pretty agnostic.

class Car
    attr_accessor :color
    def initialize(color)
        @color = color
    end
end

cars = [
    Car.new("Red"),
    Car.new("Blue"),
    Car.new("Red"),
    Car.new("Blue")
]

blue_filter = Item_color_filter_spec.new("Blue")
blue_cars = blue_filter.apply_to(cars)

Wow talk about reuse!!!

How is this possible? Well remember types do not exist in Ruby. There are objects but objects are duck typed when you ask them to perform an action. Meaning if it walks like a duck or quacks like a duck it must be a duck. The “Item_color_filter_spec” only cares that it is passed an array of objects. It is then going to iterate over the array of objects and call the “color” accessor on each object to check for equality against the instance variable that was passed in through the constructor. It doesn’t care if the array contains cars, products or both; just that whatever object it is has to have an accessor of "color."

I know this is a ton on information to digest all at once but I am just very passionate about the Ruby language. I see tremendous potential in its future especially with its entrance into the .Net space through the IronRuby project. I can easily see it over throwing the Visual Basic crowd once it becomes more main stream in the .Net community.