In the real world many people may have a stake in projects as they are either sponsoring the project, supporting the project, or are affected by the project. So as a Product Owner you will have to interface with stakeholders and sponsors to get their feedback, issues, goals, etc...

Likewise, a Project Manager/ScrumMaster might encounter similar situations where they are trying to garner consensus and agreement.

The problem however is that large committees rarely are capable of making decisions.

Once you've got 7 people in a decision-making group, each additional member reduces decision effectiveness by 10%, according to Marcia W. Blenko, Michael C. Mankins, and Paul Rogers, authors of Decide & Deliver: 5 Steps to Breakthrough Performance in Your Organization. Thus, a group of 17 or more rarely makes any decisions.

Tips:

• Hold a series of smaller sessions (e.g. instead of one 10 person meeting, have two separate 5 person meetings).
• Pre-meet in advance with individuals to gather their feedback, stance, concerns, requirements to that you can factor that in and further prepare for the main meeting.
• Instead of starting with a blank slate and trying to work with the committee to collaborative decide/plan/prioritize/etc... gather initial data and create a good starting point ? e.g. a draft plan, and then let people argue/discuss over it.
• Always make sure your management supports where you want to go so that they back you up behind the scenes.

...read the full article ]]> Mon, 14 Mar 2011 23:13:00 PST http://www.dopejam.com/shownewsitem.cfm?NewsID=589 coldfusion http://www.dopejam.com/shownewsitem.cfm?NewsID=587 lenghty editorial on how natural human behavior affects the scientific community when it comes to studies, in that selective reporting and significance chasing leads to 'publishing bias'.

"the act of measurement is going to be vulnerable to all sorts of perception biases. That's just the way human beings work."

"researchers engage in what he calls "significance chasing," or finding ways to interpret the data so that it passes the statistical test of significance - the ninety-five-per-cent boundary invented by Ronald Fisher. The scientists are so eager to pass this magical test that they start playing around with the numbers, trying to find anything that seems worthy,"

"...the decline effect is largely a product of publication bias, or the tendency of scientists and scientific journals to prefer positive data over null results, which is what happens when no effect is found. The bias was first identified by the statistician Theodore Sterling, in 1959, after he noticed that ninety-seven per cent of all published psychological studies with statistically significant data found the effect they were looking for."

"The decline effect is troubling because it reminds us how difficult it is to prove anything. We like to pretend that our experiments define the truth for us. But that's often not the case. Just because an idea is true doesn't mean it can be proved. And just because an idea can be proved doesn't mean it's true. When the experiments are done, we still have to choose what to believe..."

Although the context is regarding the scientific community, I was thinking how there are direct parallels to the business and B.I community as well. perhaps we're too focused on the pursuit of truth, when the 'reality' is that there no truth, only perception & interpretation.

So instead of using data to prove things, we need to look at data to be more of a guide. For example monitoring trends, inflection points, velocity of change over specific numbers. Not that specific numbers are unimportant (e.g. shareholders will continued to demand exact profitability statements), but in terms of managing a business not to exhaust enormous efforts on proving perceptions/suspicions/hypotheses but to define data driven decision supporting guides. ]]> Mon, 03 Jan 2011 12:31:00 PST http://www.dopejam.com/shownewsitem.cfm?NewsID=587 management http://www.dopejam.com/shownewsitem.cfm?NewsID=586

If that were even possible, and your life depended on it, you wouldn't feel comfortable until the team has spent an enormous amount of time putting together analysis and various levels of technical design.

In order for that possibility to exist you would have to be aiming for a fixed target, whereas developing software is a moving target where scope can change at an time (agile embraces and expects change).

So after weeks or even months of analysis you drop the bomb on the stakeholders of the project that what was asked for won't fit the required timeline without a decrease in scope or change another project dimension (capacity, budget, resources, etc...).

Meanwhile, stakeholders want an estimation done immediately. There may be a constraint or deadline that needs to be hit, there may be a funding window to get approval, stakeholders might need time lining up shared resources and don't want to reserve people if they're going to end up vegging out on the bench waiting for the project to commence, etc...

So what's the compromise? Story points!

Story points solve the problem
The problem is we need a quick and easy way to schedule out work. In the waterfall approach the business views estimates as commitments, but estimates are estimates - they're not actuals. You'll only ever know the actual once the work is completed.

In waterfall land your plan relies on as accurate as possible estimates because you build out your timeline based on that. With agile, your work is based off of fixed-length time boxes - so you know how long each iteration is going to be, the only question is what you fit inside each of those fixed sized buckets of time.

So imagine you're filling up boxes with various household items, do you really need to know down to millimeter accuracy how big each object is in order to have a sense of how much you can fit in a box? More importantly would it be worth it to spend 2 weeks cataloging all your household items into Excel using a measuring tape in order to make a plan that fills each box to it's maximum capacity - or is there more value in spending that time to just start filling the boxes by eyeballing roughly what will fit?

I know that some things are twice as big as others, I may not know their exact dimensions but I can guestimate that I can probably fit:

• 10 small things
• 5 small things, and 2 big things
• 4 small things, 2 medium things, and 1 big thing

In this case I'm working on filling a box, but on another project I could be working on buildings and I may not even need to change my point system much.

My buildings might fit into a 1 (small) to 5 (really big) range of categorization. The nice thing about using points is you get away from using time to estimate size. In theory you could use hours, such as 1hr for small things, 5hrs for medium, and 10hrs for large. But the problem is that when you start talking hours people start assuming you're talking about duration or effort, so it's best to use points or any term that signifies size.

Story points converted to time
These numbers initially can't be converted into time, you have no data in order to base such a conversion on. But as you perform iterations over time you'll be able to track how many story points are completed with each iteration and thus know what your velocity is. Knowing that an iteration was 60 man hours, and it was 6 story points, you could formulate that a story point is about 10hrs of effort.

Knowing actual hours might be an interesting tidbit, but one could argue they're irrelevant. This is because when you're planning out your next iteration you're still using the story point technique to fill your boxes, but now you have historical data to improve your understanding of how many points fit into a box.

Recap

• Estimates are estimates, not actuals.
• Actuals are historical, you can never know them upfront.
• No developer in their right mind would commit to an estimate without heavy duty specs.
• Waterfall requires time consuming analysis in order to get specifications detailed enough for someone to commit effort and duration to. Knowing effort, waterfall then plans out the timeline.
• Agile is fixed-length timelines. You already know when an iteration/phase/sprint ends. You just need to fill up those iterations with work.
• Story points are a quick way to estimate out the relative size of one feature vs. another feature. Size is the keyword (vs. effort or duration).
• Using relative sizes, you'll have a rough idea of how many points can be completed within an iteration.
• As iterations end, you'll have a stronger understanding of how many points an iteration can fit.

The magazine is free and can be downloaded here.

]]> Wed, 03 Nov 2010 22:47:00 PST http://www.dopejam.com/shownewsitem.cfm?NewsID=585 flex http://www.dopejam.com/shownewsitem.cfm?NewsID=584 Unfuddle is an affordable hosted service providing source code repository hosting (Subversion and Git) with basic project management (tickets, users, milestones, etc...). They have free plans, to $9/mo plans for super small teams, and their most expensive plan is only $99/mo.

We use this for hosting some of our smaller initiatives, so I was playing around with their ticketing feature to see if we could use it in an Agile manner.

Although they provide custom fields, I found it works well if you use their milestones as sprints. To support a backlog you'd create a milestone called backlog and then just dump all your backlog items in there.

After that, it allows you to track the basics:

• Treat tickets like stories
• Assign story points to each item using a custom field
• An upgrade allows you to track effort if you want
• Assign a priority to each ticket
• In planning a sprint/iteration - you'd pull in the combo of highest priority items and size of stories (e.g. if you know you can do roughly 20 story points in a sprint, you wouldn't pull in 50 story points of work).
• Unfuddle's versions map directly to a release (a collection of sprints).

Here's an example of what I was fooling around with:

]]> Mon, 11 Oct 2010 16:23:00 PST http://www.dopejam.com/shownewsitem.cfm?NewsID=584 agile http://www.dopejam.com/shownewsitem.cfm?NewsID=583 ColdBox based feature for one of Amcom's sites, however the rest of the site itself isn't framework driven, so I decided to move the entire site into one common ColdBox application.

Since I'm in rewriting mode, might as well take advantage of ColdFusion 9's ORM/Hibernate feature. This technology is quite mindblasting, and I have to give major kudos to the ColdFusion team for making it work with CF so seamlessly. It is so seamless it's like a native feature of CF. Nice (especially considering you have 400 page books on the topic)! If it's one thing ColdFusion does well it's integrating technologies.

Anyways, below is list of resources I found to be very useful in quickly ramping up with CF9 ORM.

• Getting Started with CF9 Hiberate (ORM) Integration slides by Bob Silverberg
• Getting Started with ColdFusion-ORM by Manju Kiran
• Using CRUD Functions by Manju Kiran
• Define One-To-Many and Many-to-one relationships by Manju Kiran
• How to handle this relationship by Dan Vega
• Debugging hibernate schema exports by Dan Vega
• Experimenting with type vs. ormtype by Bob Silverberg
• Things to watch out for by Henry Ho

Reference wise:

• Introducing ColdFusion ORM
• EntityLoad
• Mapping properties

After that a variety of other server side technologies across the board with C#, Java, Ruby, Python, Groovy, Scala, etc...

]]> Tue, 07 Sep 2010 20:55:00 PST http://www.dopejam.com/shownewsitem.cfm?NewsID=581 coldfusion http://www.dopejam.com/shownewsitem.cfm?NewsID=579 Within the CF realm, you want to be leveraging the new features of CF9, learning the available frameworks, etc...

But in this day and age, where technical skill is rapidly becoming a commodity, it's wise to have more than skill in your tool chest.

Lately I've been researching what the current trends are, and am curious to see what other technologies fellow ColdFusion developers have been scoping out ? even out of curiosity.

So I whipped up a quick 30 second survey ? let me know your thoughts, and spread the link. Take me to the survey.

I'll post the results in a few days.

Thanks! ]]> Thu, 02 Sep 2010 17:41:00 PST http://www.dopejam.com/shownewsitem.cfm?NewsID=579 coldfusion