Sunday, August 15, 2010

Tips for new BAs

Remember that your business contacts are usually very busy and may not see providing information for project requirements as a priority. Be persistent, but considerate of their situation.
  • Ask people when the best times to talk to them are and when it is best to leave them alone (when end of month process is going on, for example).
  • Find out their preferred method of communication. If someone never responds to your e-mails try phone calls or stopping by their desk. If they hate interruptions, schedule time to meet or use e-mail.

 
If you are not getting adequate time with someone you need to talk to, address the problem as soon as possible. Talk to the person about possible times to meet. Address the issue with the project manager and in your status report.

 
Target your communication to your audience. Busy executives may not read anything except a single page with bullet points. Others will want to read every detail before signing off. Visual people may understand flow charts better than use case descriptions. Don’t use technical jargon or acronyms that your audience is unlikely to understand.

 
Since time is usually limited, use an agenda for all meetings and follow up by sending meeting minutes to the team.

 
Always, always have an agenda for meetings and a set of goals for the meetings.  
 

Friday, July 30, 2010

Mind Puzzles


Here are some ways to exercise creative thinking.  They are separate from eachother. Have fun.

Clear your mind

The idea is to get rid of problems that are keeping you from concentrating on the task at hand.
Take out a piece of paper and quickly write down any issues which come to mind. It doesn’t matter how small the issue is, write it down. Keep writing until there is nothing left to write. Then look at the list and acknowledge that you will deal with these concerns later. Fold the paper up and put it on the corner of your desk for later.

Define your problem

The idea is to come up with different expressions of your problem, leading to a new and unusual solution.
Use an idea quota. Write down 5 different ways to express your problem in 1 sentence.

Repeat at least 3 times.

Why and what ways

The idea is to drive to root cause (why) and back up to potential solutions.

Why do I spend time less time doing this thing that I should?

Why do you want to ...?

Why do you ...?

Why do you ...?

Why ...

Now restate the answers as “In what ways can I ....”

Mind map and negative mind map

The idea is to see the problem from a negative perspective and strengthen the positive.
Do a mind map of the problem.
Now do a mind map of the opposite of the ideas. I.E. opposite of fitness is sloth.

Random words

The idea is to look at the problem from differnt perspectives.

“In what ways can I ________________?”

Choose a random verb.

Explore the relationship between the sentence and your subject and then explore the non-relationship between the sentence and your subject.

Thursday, July 15, 2010

Random Number Generators and Slot Machines

Has this ever happened to you: you're playing your favorite slot machine for nearly two hours, hoping to get that big jackpot but never really winning it. You take a break for lunch and come back an hour later just to see someone else playing your machine hit the big one. Is your first thought, "That's my jackpot! If I had only stayed I would have won it all.” Don't believe it. Slot machines are based on a sequence of pseudo-random numbers and, in a way, the timing of your play.

An slot machine is a computer (Electronic Gaming Machine or EGM actually) and computers can't really create random numbers, but can generate sequences of numbers that mimic randomness - Pseudo Random Numbers which are widely known as PRNs.  These PRNs are pretty good:  they're exercised with battery of tests run against the output to ensure the numbers are statistically random.  The most common algorithm, the linear congruent method (LCM) which generates numbers such that same sequence of numbers won't occur until about 2 billion numbers have been generated. Many EGMs use variations of the LCM that have cycle periods close to the number of molecules in our galaxy!  You can't guess the sequence even if you know the algorithm.

As a rule, EGMs generate a random number continuously, not every time you drop in a coin. It's not unusual for EGMs to generate over 1000 numbers in the sequence every second. Only when you place your bet does the machine capture the next 'random' number.  Knowing the algorithm isn't of much help since you'd have to drop your coin into the machine and bet at the exactly right 1/1000th of a second in order to get the number you were counting on.

Once the number is generated, the computer compares the number to a payout chart.  All games have a payout table referred to as the PAR (Percentage Average Return) chart. Each EGM has it's own individual PAR chart, usually ranging from 99% to 81%.

Every game (even if they look the same) has a different PAR chart and the chart is usually held as confidential by the casino. The payout rate advertised on the machine or in the casino usually portrays an average of all the games taken together. Since each game is a separate entity with its own random number generator, it is not uncommon for one game to have a payout of say 95% and the one next to it, with the same game title having a payout of 86%.


To further complicate matters, PAR charts are usually different depending on the amount of the bet.  Maximum bet has the highest return rate while smaller bets typically have a lower payout rate.

Once the payout (or loss) is determined, the slot machine spins the spinners with a command from the computer to land on a certain display.  The spinners really have NOTHING to do with the actual play, it's all handled by a random number generator and a table.  Even the 'bump' of the spinners is pre-determined based on the random number and table.  Sorry to take the fun out of it.

The bottom line is that gaming is truly random. If you are at the right place at the right time with max bet you too could win a sizable jackpot on an electronic gaming machine. The fun part is the anticipation of the win and the many little wins along the way that make slot gaming fun regardless of whether you win or loose.

Wednesday, June 30, 2010

How much worth is the man

Do you put a dollar on the value your epics deliver to the business?  If not you should; it will help you determine epics’ prioritization and give the the business owners an idea of value the project is delivering.
  

Consider this example: your software is used by 75 sales people and your changes save an average of 2 hours a week per person, you save 2 hour * 75 people or 150 hours a week which translates to 7,500 hours a year (50 weeks).  That's 3.75 people's time.  

If those people have an average salary of $40 an hour, that's a cost savings $300,00 a year (not bad).  If on the other hand each person produces $250,000 in new sales over a year (hopefully you expect staff value is more than their salary) you free up the  250K * 3.75 = $937,500. In the one case you save $300,000 by reallocating people and not growing the business, in the other case you can potentially grow the business by nearly a million.
Next time you’re calculating what a feature is ‘worth’, look at not only the cost savings side but the opportunity side - a perspective that many people miss.

Monday, May 24, 2010

Agile Story Examples

Story Basics

The basic thing about a real story is that it's a metaphor for the work being done. It is not a requirement but a reminder to collaborate about the topic of the story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration. So the story doesn't make you agile, it's the underlying philosophy.

Invest model for good stories

A good story, from our perspective uses the invest model –
  • Independent – reduced dependencies = easier to plan
  • Negotiable – details added via collaboration
  • Valuable – provides value to the customer
  • Estimable – too big or too vague = not estimable
  • Small – can be done in less than a week by the team
  • Testable – good acceptance criteria
But a story is really driven (or perhaps scoped is a better way of saying it) by the acceptance criteria. In other words we try to determine how we'll know when we have satisfied the story before we put any details in it – and we mean actually enough details that we can test the story.




Examples of good stories:


Story:

Generate an Emergency Department Referral

Description:As a provider, I want the option to generate an Emergency Department Referral (EDR) when I close a visit note so that I can share pertinent medical information with other IHE community members.

Acceptance Criteria:
Assumptions:

An IHE Community interface has been configured.
The interface can be configured to send an EDR automatically to the IHE Community.
The interface can be configured to send and EDR to an referral specialist or office staff member.
The interface can be configured to indicate who to send the EDR request.

Acceptance Criteria:
When a user closes a visit note, provide an option on the Visit Checkout screen to generate an EDR. This option will indicate that the provider intends to create an ED Referral.

Story:

Strip special characters from policy fields before creating electronic transmission claim file.

Description:
As a front desk/billing user, I would like to be able to scan insurance cards through OCR and not have to go back and edit certain fields due to dashes in the policy IDs.

In addition, I would also like this information to be formatted correctly for my electronic transmission so that I do not get claim rejections.

Acceptance Criteria:
Provide the ability for dashes to be removed from the member ID and group ID when creating the file for electronic transmission. This process was also necessary by interfacing products to remove dashes from policy IDs to prevent rejections. Investigation may include researching how other products accomplished this task.

Also, users should be able to utilize OCR scanning without having to edit patient information manually (removing dashes).

Story:

Need a way to print multiple patients on a label sheet

Description:
As a System user I would like to be able to print multiple patients on one label sheet so that I don’t have to look at multiple pages.

Acceptance Criteria:
At least 6 patients print on one label sheet.

 

Critique of bad stories:


Story:

Add capability to select the Welch-Allyn Exercise ECG Test

Description:
This requirement was requested during the W-A certification demo 2/17/09.

***Description doesn’t specify who or why this is important. What needs to be done? Can’t tell.

Acceptance Criteria:
***missing

Story:

Cursor should default in assign to field instead of patient field when creating a new procedure task message in FNC.

***Could be shortened to “Default cursor to assign” The rest can be in the description. Overall this may be TOO small to be a story and could be rolled into another related piece of work.

Description:
As a System user, I would like the cursor to default in the assign to field instead of the patient field when creating a new procedure task message. The patient name is already in the field since I'm creating the message, so I would prefer the cursor to default in the assign to field.

***Could shorten this to:

As a System user, the cursor will default to assign field when creating a new procedure task message so that I can be more efficient.

Acceptance Criteria:
***missing. Can add this:

When creating a new procedure task message, the cursor will default to assign as opposed to patient name.

Demonstration must be to the satisfaction of Dr. Lohindez of Rogue Wave software (he has requested this functionality).

Monday, May 17, 2010

Some Good Resources for Agile

A few great books:
• Applying User Stories – Mike Cohn
• Agile Estimating and Planning – Mike Cohn
• Collaboration Explained – Jean Tabaka
• Lean Software Development – Mary Poppendieck
• Agile Project Management – Jim Highsmith
• Agile Project Management with Scrum – Ken Schwaber
• Managing Agile Projects – Sanjiv Augustine
• FIT For Developing Software – Rick Mugridge, Ward Cunningham
• Agile and Iterative Development – Craig Larman
• Domain-Driven Design: Tackling Complexity in the Heart of Software – Eric Evans
• Working Effectively with Legacy Code – Michael Feathers
• Refactoring To Patterns – Joshua Kerievsky
• Fearless Change: Patterns for Introducing New Ideas – Linda Rising, Mary Lynn Manns
• Product Development for the Lean Enterprise – Michael Kennedy

 

 
Online Resources:
http://www.agilealliance.org/
http://www.theagileblog.net/
http://www.rallydev.com/
http://www.mountaingoatsoftware.com/
http://www.stickyminds.com/

 
Yahoo! Groups:
scrumdevelopment
agileprojectmanagement
agiledenver
extremeprogramming
agiletesting

Tuesday, May 4, 2010

New Article Published

I've just had an article published that compares traditional requirements, use cases, and user stories.

Wednesday, March 24, 2010

Six Weapons of Influence in action

The following is an example I created to convince people that retrospectives are useful. I used the six weapons of influence as a guideline.


Recently, team members have questioned the benefit of certain aspects of the agile, specifically retrospectives. [Acknowledge the problem to gain alignment with the audience]

In regards to retrospectives, certainly each of us wants to improve our on the job performance [setting up consistency]. Retrospectives are specifically intended to improve individual and team performance each and every sprint [pointing out the inconsistency of not holding retrospectives]. Numerous studies and experts agree that retrospectives are a potent tool for performance improvement when executed well [Authority or Directed Deference]. Reflecting on how to become more effective and tuning behavior to maximize effectiveness [consistency] is so important that the originators of agile development list it as one of the twelve principles behind the agile manifesto [Authority or Directed Deference].

As a group, we have committed to following agile development through the scrum process [social proof]. Retrospectives are an important part of the process – one that we all need to improve upon in order to better see the benefits [social proof and consistency].

We realize that retrospectives are not easy and take time. It’s no simple task to ferret out good retrospective items and put them in a form that can be actionable [align with audience].

In order to better support retrospectives, upper management will commit to allow time to work on retrospective items during sprints if the retrospective items are written as actionable stories [Reciprocation]. We also commit to providing, upon your request, retrospective coaching for individuals or groups, and will share examples of good and bad retrospective items. In return we ask for your willingness to continue retrospectives and your support in working with us on improving efficiency/quality/delivery [Reciprocation].

Sunday, March 7, 2010

The Inverse Peter Principle?

We all know the developer hero who works for 30 or more hours straight when a crisis comes up and walks away solving the problem. The classic firefighter mentality of software development.  But what kind of manager does this hero make?



Star developers often rise to management because of their ability to program under pressure and, in many cases, their software fire fighting ability, not necessarily the ability to plan, track, motivate, and manage a project.

If the corporate culture rewards a hacker mentality - time savings and emergencies over strategy and planning, developers who rise to management may never be exposed to long term thinking and may not even be told that management is all about planning, managing risks, monitoring, and most importantly reflecting on the future. Do star firefighters have the key ability to plan, see strategy, and organize large groups of people - I would say not always.

So what do we do about this problem? How about promoting people to management for their tendency to over design, over plan, and not necessarily just hack? This is an inverse of the peter principle. Imagine programmers who are mediocre by firefighting standards being promoted to management. We might just be better off in the industry.

Then companies could proudly proclaim “we promote the mediocre” – ah, maybe not.

Sunday, January 10, 2010

Sorry Spock, logic isn't always the best motivator

Influence
A big part of my job is to influence people to perform tasks and behave in a particular way that they're not used to; and I often have no direct control over those who I must motivate. Being a bit of an academic, I thought about and subsequently researched the best way to influence the herd of cats to go in the direction I'd like them to.


Logic
As a classically trained software engineer, my first thought was that through brute force logic I could convince even the most stubborn naysayer of anything, as long as the conclusion and reasoning is logical. With a little research, you too can find interesting articles on formal logic and reasoning.  But if Dr. Phil asked “how’s that working out for you?” my answer, with a hint of frustration, would have to be “not always very well”. Surprise! People don’t always respond to logic – if so there’d be no smokers, heavy drinkers, or suicide bombers.

Influencing people involves not only logic (what you’re trying to convince people of), but invoking their emotions (how you’re convincing them) and a social aspect of convincing the right people.

Emotion
So how do you get the emotion monster involved? After reading many, many texts on the subject, the best categorization of emotional influence techniques is the six weapons of influence. I’ve used one or more of these weapons in combination with quite a bit of formal logic with success many times, but not always. Dispite the best emotional influence and carefully applied logic, some people just won’t move in the right direction.

Social Pressure
This is where the leader crowd comes in to play - some people need to be lead, either explicitly or implicitly. So you have to convince the formal and informal leaders (the leader crowd) to support your ideas before that herd of cats begins heading in the right direction. To influence the leader crowd, the first step is to identify the right people – something that is situational and beyond what I can blog about today.  Do make sure to identify the informal leaders though - they're the people who, when they speak in the meeting, never have to raise their voices because everyone seems to listen. The second step is to use logic, emotion, and social pressure to convince the leader crowd. You’ll find that the lead crowd has its own, smaller leader crowd which in turn has a smaller leader crow and so forth. The deeper you get into the leader crowd, the less prominent the social pressure side of influence becomes. Eventually you’ll get to the leader crowd where you begin to influence without much of the social aspect whatsoever (think Malcom Gladwell’s tipping point). These are the independent leaders, influence them and the rest of the cats herd will be easier to manipulate.

I hope this helps you to look at influence as a bit more than just logic and has inspired you to do a little research on your own.