Pablo’s Fiesta – Thank you!

    Pablo’s Fiesta

    Wanted to take this time to say thank you to everyone that attended Pablo’s Fiesta.  This community surprises me every year with the amount of content and dialog that is discussed by so many passionate professionals.  Without each of you, the LosTechies community would not be possible.

    If you weren’t able to make it to this years Fiesta, shame on you! No seriously, all is not lost. A lot of the conveners where able to capture notes about the topics they discussed.  To find out more please visit the following wiki:

    We left with a ton of dialog to be hacked on and vetted. Needless to say this is not the last Pablo’s Fiesta.  Planning will start soon on the next years event. If you didn’t get a chance to voice some improvements around the event, please feel free to leave me a comment. We are all about open honest feedback.

    Again thank you to everyone and I look forward to seeing you at next years event!



    Joe Ocampo



    Announcing Pablo’s Fiesta 2011!!!!!

    Registration is open for the this years annual “Pablo’s Fiesta!”

    We at LosTechies believe in constantly providing insight and strengthening the passion and creativity to our ever expanding software community. Not to mention have an excuse to party and code! Come and join us!

    BTW A new friend will be joining Pablo pretty soon 🙂

    • When: September 30, October 1, & 2
    • Where: St. Edward’s Professional Educational Center, Austin TX

    Pablo Fiesta Registration

    LosTechies welcomes John Petersen!

    I am proud to announce that John Pertersen has joined LosTechies!  We are all looking forward to his perspective and insights into software development.

    LosTechies welcomes Rod Paddock!

    I am proud to announce that Rod Paddock has joined LosTechies!  We are all looking forward to his perspective and insights into software development.

    Check the depth of the pool

    I was really inspired by Jimmy Bogards latest post. I find that taking the simplest path does not always lead a team down the most best path that towards sustainable flow (continuity).

    I am a huge proponent of Agile Modeling. Agile Modeling coupled with Domain Driven Design provides a mechanism that can galvanize a team towards malleable code that enables evolutionary design.

    When I coach on this practice people cringe at the thought of modeling as previous attempts have led towards heavy weight processes.  What I am proposing is before you dive into the pool at least check the depth of the water to see if you are going to crack your skull when dive in. Just because we are practicing Agile development does not mean it is OK to be careless.

    Start simple

    State the problem you are solving for.  The problem should be Feature driven as through the modeling exercise you should arrive at several stories.  You are solving towards the problem indicated on the feature card not towards the application or project. This provides a context that will help guide discussions.

    _Check how cold the water is_
    Take out several index cards and at the domain level just perform a simple Class Responsibility Collaboration (CRC) exercise.  CRC diagramming has been around for over 2 decades and is one of the most over looked practices of software development. It is simple, highly communicative and provides immediate value for the entire team.

    Please DO NOT try to create your entire solution is one diagramming session. Remember you are talking towards the feature.

    _Check the depth of the pool_

    Just like when you prepare to dive into the pool you quickly survey the depth markers on the outside of the pool and determine where the deepest part of the pool is. You then perform a quick calculation in your head. “I am

    What are you solving for?


    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”

    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

    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
       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


    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 status
        git config –global commit
        git config –global checkout
        git config –global branch

    Step 17: configure the global user for Git
        git config –global “Put your full name here”
        git config –global [email protected]

    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:// vendor/plugins/rspec

    git submodule add 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://’
    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’</p>

    # Configures a rails app to use rspec
            git submodule add git:// vendor/plugins/rspec
            git submodule add 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:


    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

    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. 

    Scott Butner's Flicker photostream

    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:


    Back Office (Centralized Admin)

    Super User
    1. can do what the help desk manager and business admin can do,
    2. can defines profiles,
    3. can maintains universal system tables,
    4. has access to the entire application,
    5. 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.)
    6. can update mortgage center home page content,
    7. can create admin users,
    Help Desk Manager
    1. can do what a team lead can do,
    2. can be given the permission to delete loan records from the system,
    3. can reset loan events,
    Help Desk Team Lead
    1. can do what a help desk user can do
    2. can add and maintain users,
    3. can create and maintain loan centers, (full name of lender in table – online view would be an abbreviated version)
    4. can maintain peer level admin profiles or lower,
    5. can pull lead between reps and processors within a loan center,
    6. can push lead and loan records to other loan centers,
    Help Desk
    1. can add and maintain mortgage center users,
    2. has system wide read only access,
    3. can invoke a system wide search
    Business Admin (Centralized)
    1. can add and maintain loan programs and fee schedules,
    2. can create and maintain printable documents,
    3. can maintain dropdown tables (ex. Marketing codes, loan conditions),
    4. can add new contact types and global contacts.
    Loan Office Admin (Loan Center)
    1. can pull lead between reps and processors within their loan center(s),
    2. can push lead and loan records to other loan centers,
    3. can modify user permissions within their specified role within their loan center,
    4. can make a user inactive or active within their loan center,
    5. can make user available or unavailable within their loan center,
    6. shared roles,
    7. can be given access to assign loan to themselves,

    Field Roles

    Loan Center Manager
    1. can do everything a processor can do,
    2. can pull lead between reps and processors within their loan center,
    3. can push lead and loan records to other loan centers,
    4. can modify user permissions within their specified role within their loan center (include permissions to access loan center pipeline)
    5. can make a user inactive or active within their loan center,
    6. can make user available or unavailable within their loan center
    7. Can delete leads across loan centers and users (no credit ordered)
    1. can do everything a loan rep can do and
    2. can upload to desktop originator and loan prospector,
    3. can export FNMA 3.2 file,
    4. can add and maintain conditions to a loan,
    5. can submit loan package to lender,
    6. can print all documents,
    7. can add and update lender denial and counteroffer,
    8. can view all teams pipelines within their loan center,
    9. can edit any lead or application within their loan center,
    10. can run reports for their loan center.
    Loan Rep
    1. can add and edit & delete their leads in the system but cannot delete an application (credit has been ordered),
    2. can view their own pipeline,
    3. can order credit,
    4. can include and exclude liabilities from the 1003 section,
    5. can complete full 1003,
    6. can order appraisal,
    7. can order title,
    8. can add notes to conversation log,
    9. can add contacts,
    10. can create rate locks,
    11. can print 3 day disclosures,
    12. can select loan programs and fee schedules,
    13. can print the 1003 blank or otherwise,
    14. can import 1003,
    15. can view and print rate sheets,
    16. can flag loan as withdrawn,
    17. task creation and assignment,
    18. can submit lead to processor,
    19. can push lead to another user,
    20. can collect and record upfront fees,
    21. can run reports for their pipeline,
    22. can make themselves available or unavailable
    23. can be given permission to pull from loan center pipeline (public queue)

    Managing changes in scope and direction in an agile projects

    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</ul> 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</ul> 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?

subscribe via RSS