BOGO is Back!

written by: Admin on May 23rd, 2014


Software development is a team effort and making sure the whole team is on the same page is vital to the process.

Buy one class scheduled in July or August and receive a second seat in the same class for free!

This is a great way to supplement training for your entire team. Enter code: SAVE2014BOGO at checkout to receive the discount. When registering, specify “2” in the quantity box; the discount will not be recognized unless you specify you want the second seat. You may also call one of our Training Advisors to register for the course. Second seat is available when first seat is purchased at list price and cannot be combined with other offers.


Click to continue »


What Chuck Norris Can Teach Us About the CBAP

written by: Rob Snowden on July 29th, 2014
  1. chuck-norrisChuck Norris didn’t apply to take the CBAP.  He told the IIBA when he was going to pass the test.
    That may work for Chuck, but you will have to complete an application and ensure that you have enough hours over the past 10 years in BA work (7500 hours).    Also, of the 6 Knowledge Areas, you will have to ensure that you have at least 900 hours in 4 of the 6 areas.

    To accomplish this, be very careful when completing the application that you do not check mark any activities that are not true BA tasks.  For each project, for each Knowledge area, there are a series of check blocks that you use to indicate which tasks you’ve completed.  Those check blocks include tasks that are not true BA tasks, but may be PM or QA tasks.  Don’t check anything that is not a BA task per the BABOK.  Additionally, the wording can be tricky – such as did you “Prioritize requirements?”  Well, a BA doesn’t prioritize requirements.  The BA works with SMEs and the SMEs prioritize requirements.   Each error on the check blocks subtracts hours from your totals (the formula for this is unknown – except to Chuck Norris).  Also, you’ll need to indicate the percentage of time spent on each Knowledge Area for each project which is how your project hours are allocated over the Knowledge Areas.  Build a spreadsheet to ensure your results are in keeping with the 900 hour requirement for 4 of the 6 Knowledge Areas.

  2. The IIBA paid Chuck Norris a fee to take the CBAP.
    Maybe so, but you will pay $125 to file an application.  If it is accepted, then the next step is to select when want to take the test and pay a fee of $325 if you are an IIBA member, or $450 if you are not a member.  You have 3 tries at the test, with 3 month intervals each year.  If you do not pass the test or take the test during that year, you have to reapply.
  3. Chuck Norris did not read the BABOK.  He stared it down until he got the info he needed.

    You will not only have to read the BABOK, you will have to memorize many things like definitions.  You must go by what the BABOK says, not what you may have done on a particular project that was successful.  Read, highlight, take a prep course, do practice tests, read, underline, repeat as necessary.

  4. Chuck Norris passed the CBAP by answering each questions with “Chuck Norris.”

    That won’t work for you because there are 150 multiple choice questions and no credit is given for write-in answers.  You not only need to absorb the BABOK, but you need to employ various test taking techniques such as eliminating wrong answers, and carefully reading the question to look for clues of what is really being asked.  No matter how hard you study, you will be faced with questions like “What is the best way, of these choices to do . . .” or “All of these choices are valid except . . . .“  In these cases you will need to perform analysis, which is what you are doing anyway in your job.  You just need to understand that taking the test is like a project with twists and turns and 150 unanswered questions.



Why Software Testers Can’t be Pessimists

written by: Tegan Smith on July 25th, 2014

Do you believe in the elusive “silver-lining” to every situation? If your answer is no, you’re most likely a pessimist. Pessimists are known to anticipate and expect undesirable outcomes. Wouldn’t this trait be great for a software tester whose job is to find out what’s wrong and hunt down the bugs within an application? Though one might think the answer is yes, there are three important reasons the answer should be resounding NO!

  1. Pessimists find things that are not there:
    If you are looking at an app pessimistically it is easy to see so many pieces, glitches, and bugs that could induce problems. Yes, no app will ever be perfect and we would be crazy to think this is even possible. But this not so perfect mindset does not come easily to pessimistic software testers who might not be able to see past inevitable glitches. This can and will create a combative relationship between the developer and the tester.

  2. Pessimism could hinder ability to think clearly:
    Ultimately, testers are hired to simulate use of software in order to find bugs. Going into the process of simulation with a pessimistic attitude could hinder the tester’s ability to think clearly and do the major task testers are assigned to do, which is find places that have the possibility of being improved. If you are always anticipating undesirable outcomes then you will always find the bad in what could be good.

  3. All talk the talk and no walk the walk:
    Testers that discover problems within software or Apps need to be able to prove why it is a problem that needs to be fixed and how the fix will add value to the software. Developers want their testers to provide relevant and useful information in order to reproduce the problem that was found as well. Furthermore, pessimism is often a state of mind that does not come with substantial claims to back it up. If a tester thinks that the app is not going to work, then they better have some good reasons to back their claim up.

All in all, pessimism in the workplace can be a disease that is hard to cure, especially in software testing. As a rule of thumb, it is always better to look at things with the mindset of the “glass half full” instead of empty. Testers should approach situations with a more optimistic point of view in order to accept that no software is ever going to glitch free. Testers, look at your job positively and one can expect positive results in return.


Web Seminar Recap: Agile Certifications Options Primer

written by: Tegan Smith on July 24th, 2014

Agile has made the leap and is now mainstream.  The reality is, once something becomes mainstream, hiring needs to happen.  When this happens, hiring managers need a baseline to judge applicants.   In comes certification.  The agile certification market has grown extensively over the last two years with both large and small organizations entering the market place.  In this one hour web seminar we will discuss what the components are for a traditional certification program, one that will gain respect and recognition. From there we will discuss the value of certifications from an employer perspective and an employee perspective.  The reality is they are not mutually exclusive.  Finally we will detail the top Agile certification in the market place and give details on steps to achieve each certification, including thought on the best certification based on needs.

Attendees Learned:
-Difference between certification and certificate programs
-What the elements are for certification programs
-How employers use and value certifications
-How employees use and value certifications
-Scrum Alliance certification stack
-IC Agile Certification stack
-PMI Agile based certifications
-Other Agile certifications (Flavor based and holistic)

This one hour seminar, Agile Certifications Options Primer, was presented by Tom McGraw on Wednesday July 23, 2014.

Missed this seminar? Download the slides and recording to catch up!


So, How Many Use Cases Do I Write?

written by: Mary Repetto on July 23rd, 2014

writingThat is a question we, as facilitators of use case workshops, often get asked and it is a good one.  My favorite answer for all sorts of questions is that “It depends”.  Is it a large system with all sorts of functions or a small with just a few.

Use cases describe functions of the system in a sequential way that shows the steps it takes to complete the function or process of the system.  So, let’s think about who is using the system and just what they need to do.  Once we define everything that needs to be done and get it approved by the sponsor, we have defined the functional scope.  Now we sit down and write a use case for each process or function we have identified.

So, how many uses cases are there in the system?  Well, I guess “it depends”!


Scrum Basics

written by: Melissa Monroe on July 18th, 2014

Scrum is one of the many subsets of the agile methodology. It places an emphasis on the idea of “empirical process control” which means Scrum uses the actual progress of a project to plan and schedule releases. Projects are broken down into brief work cadences, called sprints. Sprints usually last between one to three weeks. After each sprint stakeholders and team members meet to evaluate the progress of a project and plan its next steps. This approach allows a project’s direction to be changed based on finished work, instead of speculation or predictions. Scrum works because it has a simple set of unchanging roles, responsibilities, and meetings. Scrum not only provides flexibility but stability that teams can rely on when development gets hectic.

Scrum has three roles: Product Owner, ScrumMaster, and team member.

Product Owner:

Responsible for communicating the vision of the product to the development team. They also represent the customer’s interests through requirements and prioritization.


Acts as a facilitator for the Product Owner and the team. They work to remove any obstacles that are preventing the team from achieving its sprint goals. They also advise the Product Owner about how to maximize ROI for the team.

Team Member:

Responsible for completing work. Ideally, teams are made of seven cross-functional members, plus or minus two individuals. The team is responsible for deciding how it will complete the work for each sprint.


The Beauty (?) of a Use Case

written by: Mary Repetto on July 16th, 2014

I’m not sure anyone else has ever called  use cases beautiful, but they really are!

storyUse cases tell a story from beginning to end in a way that makes sense to all sorts of folks including extreme opposites like developers and business users.  In the use case we set up the story and give you a short summary, we tell you who all the key stakeholders are and we tell you what should happen and how it is supposed to end.  Then we go through some steps to actually tell the story from the actor’s perspective…what they see happening when they interact with the system and whether or not the story has a happy ending and, if not, just exactly how it does end.

So now when I sit down with my stakeholders and ask them to review the requirements, I can actually just tell them a story.  And, isn’t that beautiful?


Agile Tradeoffs: Schedule vs. Cost

written by: Melissa Monroe on July 14th, 2014

Something that isn’t talked about often is the tradeoff between schedule and cost. To a certain extent on software projects it is possible to deliver a project faster by adding more people, but at what cost?

Whenever additional human resources are allocated to a project, it may often reduce the time to complete, but it also can add to the overall “person months”. These “person months” account for misunderstandings between team members, miscommunication, and other human errors. Additional “person months” can often make a project  more expensive to deliver, if the added resources do not entirely counteract by reducing the time to deliver by a proportional amount.

This phenomenon shows that there is a tradeoff between schedule and cost. Schedule typically wins. This can be explained by an article in the Harvard Business Review in 1988. In this article George Stalk Jr. said that the next source of competitive advantage was time. Companies may want to get things at the lowest price possible but not at the expense of schedule. Shortening development cycles and releasing new products faster create a competitive advantage that is often more important than developing products at the lowest cost.

However, a shorter schedule is not a priority all of the time. Optimizing for schedule and optimizing for cost have subtle, but important, differences in how an Agile process could be applied.

Optimizing for schedule means following standard Agile advice and having the designer work as closely as possible with the team. Ideally, user interface designs are done in the same sprint as the rest of the development work but exceptions can be made for complex interfaces where the designer may work a sprint ahead of the team. By having the designer work closely with the team the schedule is shortened but there are potential expenses due to reworking design inconsistencies discovered over multiple sprints. Additional costs could also come because the programmers are idle for periods, waiting for the most recent design.

Optimizing for cost in some ways means doing the opposite of optimizing for schedule. When optimizing for cost the designer works as far ahead as possible while avoiding designing ideas that are hard to implement and designing things that are not needed. The designer should not try to make a perfect design of every screen that will be part of the system but, if cost is more important than schedule, it may be best for the designer to work ahead of the development group.