Thursday, September 11, 2014

Microphone not working in Windows 7 guest running on Virtualbox (v4.3.16) from a MAC OS X (Mavericks) host?

Microphone not working in Windows 7 guest running on Virtualbox (v4.3.16) from a MAC OS X (Mavericks) host?

The very first thing you should do is to change the Audio Controller in VirtualBox. Below is a setting that worked for me:



Windows will complain about not finding a suitable audio driver but if you know that all you need is to install a "Realtek AC'97 Driver" for "Windows 7" then you will find http://www.ac97audiodriver.com

After installing the driver followed by a Windows restart you should be able to setup the microphone using the "configure/setup microphone wizard" options. If you get into troubles make sure "properties/advanced" show as default format "2 channels, 16 bit, 44100 Hz (cd quality)" as shown below:



I have read on the web the suggestion that this setting should match the host settings which you can set from the "Audio MIDI Setup" application. I have tried different combinations and it still works, the important thing is to rerun the setup microphone wizard to make sure distortion is kept to a minimum. In any case I left mine with the below settings:

Thursday, August 28, 2014

Can we apply the 80-20 rule to find out the Minimal Marketable Feature?

Cam we apply the 80-20 rule ( "for many events, roughly 80% of the effects come from 20% of the causes" ) to find out the Minimal Marketable Feature (MMF)?

In my personal experience over bloated requirements as the norm. So I have the practice (even in my personal life) to analyze the root cause of problems to try to resolve as much as I can with the minimum possible effort. The 80-20 rule becomes my target and unless someone before me actually applied it I can say that in most cases at least I can present an option. Whether that is accepted or not depends on many other factors which I rather not discuss here.

Why this rule is useful in Software development is a well known subject. But making the whole team aware of it comes in handy when there is clear determination to be occupied 100% of the tine in producing value. If we can cut down to 20% the apparently needed requirements our productivity would literally skyrocket. Of course the earlier you do this analysis the better but be prepared because perhaps you, the software engineer will teach a lesson to everybody above when you demonstrate that what was asked is way more than what is needed to resolve the real need of the stakeholder.

Monday, August 25, 2014

We are hiring an experienced Javascript developer who has worked on angularjs for a while

If you have built directives to the point of having configurable widgets using AngularJS and you are interested in working in an agile lean environment where people come first please apply here.

Saturday, August 23, 2014

How to eliminate the waste associated to prioritization and estimation activities?

How to eliminate the waste associated to prioritization and estimation activities?
  1. 5 minutes per participant meeting: Business stakeholders periodically (depending on how often there are slots available from the IT team) sit to discuss a list of features they need. This list must be short and to ensure that it is stakeholders come with just one feature per participant (if the number of slots is bigger than the number of participants then adjust the number of features by participant). Each feature must be presented with the numeric impact for business ( expected return in terms of hours saved, dollars saved, dollars earned, client acquisition and retention, etc ) and a concrete acceptance criteria ( a feature must be testable and the resulting quality must be measurable ). Each participant is entitled to use 5 minutes maximum to present his/her feature. Not all participants will make a presentation. Sometimes the very first participant shows a big saving idea that nobody else can compete with and the meeting is finalized immediately. That is the idea which should be passed to the IT team.
  2. The IT team does a Business Analysis, an eliciting of requirements. The responsible IT person (let us call that person Business Analyst or BA) divides the idea implementation in the smallest possible pieces that will provide value after an isolated deployment, no bells and whistles. In other words divide in Minimal Marketable Features (MMF)
  3. The BA shares with the IT development team the top idea and the breakdown.
  4. IT engineers READ the proposal and tag each piece with 1 of a limited number of selections from the Fibonacci sequence representing the time in hours (0 1 2 3 5 8 13 21 34 55 89). Hopefully there is nothing beyond 21 and ideally everything should be less than 8 hours (an MMF per day!!!)
  5. BA informs Business and gets approval for the MMFs. Note how business can now discard some bells and whistles when they realize few MMFs will provide the same ROI. Ideally the BA actively pushes to discard functionality that is expensive without actually bringing back a substantial gain.
  6. Developers deliver the MMFs and create new slots for the cycle to start all over again.
The Organization can calculate an expected Return on Investment (ROI) for the Minimal Marketable Features related to any idea that without doubt should be implemented next. All that without unnecessary "muda" (lean term for waste) related to prioritization and estimation.

Wednesday, August 20, 2014

This is a Summary of my posts related to Agile and Lean Project Management

This is a Summary of my posts related to Agile and Lean Project Management which I will try to maintain down the road. I hope it will allow me to share with others who try everyday to lead their teams on the difficult path to achieve a constant pace, predictable and high quality delivery.
http://thinkinginsoftware.blogspot.com/2014/08/can-we-apply-80-20-rule-to-find-out.html
http://thinkinginsoftware.blogspot.com/2014/08/how-to-eliminate-waste-associated-to.html
http://thinkinginsoftware.blogspot.com/2014/08/define-pm-in-three-words-predictable.html
http://thinkinginsoftware.blogspot.com/2014/08/speaking-about-software-productivity.html
http://thinkinginsoftware.blogspot.com/2014/08/does-project-management-provides.html
http://thinkinginsoftware.blogspot.com/2014/06/on-productivity-what-versus-how-defines.html
http://thinkinginsoftware.blogspot.com/2014/06/continuous-delivery-must-not-affect.html
http://thinkinginsoftware.blogspot.com/2014/05/continuous-delivery-needs-faster-server.html
http://thinkinginsoftware.blogspot.com/2014/05/is-tdd-dead.html
http://thinkinginsoftware.blogspot.com/2014/04/small-and-medium-tests-should-never.html
http://thinkinginsoftware.blogspot.com/2014/04/continuous-integration-ci-makes.html
http://thinkinginsoftware.blogspot.com/2014/04/agile-interdependence-as-software.html
http://thinkinginsoftware.blogspot.com/2014/04/have-product-vision-before-blaming-it.html
http://thinkinginsoftware.blogspot.com/2014/04/non-functional-requirements-should-be.html
http://thinkinginsoftware.blogspot.com/2014/04/on-agile-minimum-marketable-feature-mmf.html
http://thinkinginsoftware.blogspot.com/2014/04/personal-wip-limit-directly-impacts.html
http://thinkinginsoftware.blogspot.com/2014/04/having-exploratory-meeting-ask-how-will.html
http://thinkinginsoftware.blogspot.com/2014/04/test-coverage-is-secondary-to-defect.html
http://thinkinginsoftware.blogspot.com/2014/04/continuous-improvement-for-people.html
http://thinkinginsoftware.blogspot.com/2014/04/are-you-developing-product-or.html
http://thinkinginsoftware.blogspot.com/2014/04/got-continuous-product-delivery-then.html
http://thinkinginsoftware.blogspot.com/2014/04/lean-is-clean-without-c-for-complexity.html
http://thinkinginsoftware.blogspot.com/2014/03/on-lean-thinking-continuous-delivery.html
http://thinkinginsoftware.blogspot.com/2014/02/wip-limit-versus-batch-size-fair.html
http://thinkinginsoftware.blogspot.com/2014/01/is-kanban-used-as-buzz-word.html
http://thinkinginsoftware.blogspot.com/2014/01/kanban-wip-limit-how-to.html
http://thinkinginsoftware.blogspot.com/2013/12/kanban-prioritization-estimation.html
http://thinkinginsoftware.blogspot.com/2013/11/kanban-show-stale-issues-to-reach.html
http://thinkinginsoftware.blogspot.com/2013/07/agile-team-did-you-already-script-your.html
http://thinkinginsoftware.blogspot.com/2013/04/it-agile-and-lean-hiring.html
http://thinkinginsoftware.blogspot.com/2013/02/the-car-factory-software-shop-and-la.html

Solaris calculating date difference

It is common necessity to know how long our script takes. In Solaris 11 just as any linux system the below will work: However in Solaris 10 and below it won't and so a hack will be needed.

Monday, August 18, 2014

Define PM in three words: Predictable Quality Delivery

Define PM in three words: Predictable Quality Delivery.

I can't help to look at PM from the Product Management angle rather than from the Project Management angle. The three constraints (scope, schedule and cost) might be great for building the first version of a product but enhancement, maintenance, the future is a different story. Without a constant pace delivery it will be difficult to remain competitive. That constant pace cannot be supported if quality is not the number one concern in your production lane.

In order to provide value, PM should ensure the team has "hight quality predictable delivery".

Followers