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

Sunday, August 17, 2014

Speaking about software productivity, does your team write effective code?

Speaking about software productivity, does your team write effective code?

Most people think about efficiency when it comes to productivity. This is only logical as most people think tactically in order to resolve specific problems. These are our "problem solvers". However as a reminder Productivity is not just about Efficiency but firstly about Effectiveness. Thinking strategically *as well* will bring to the team the maximum level of productivity. These, effective programmers are "solutions providers" What can we do to be effective programmers?

Dr. Axel Rauschmayer in his book Speaking Javascript, Chapter 26 explains, IMO, what the effective software development team should do. This applies to any programming language BTW. This is what I take from his statements. This is what I support based on my own experience as a programmer:
  1. Define your code style and follow it. Be consistent.
  2. Use descriptive and meaningful identifiers: "redBalloon is easier to read than rdBlln"
  3. Break up long functions/methods into smaller ones. This will make the code *almost* self documented
  4. Use comments only to complement the code meaning to explain the *why* and not the how
  5. Use documentation only to complement the comments meaning provide the big picture, how to get started and a glossary of probably unknown terms
  6. Write the simplest possible code which means code for a sustainable future. In the words of Brian Kernighan "Everyone knows that debugging is twice as hard as writing a program in the first place. So if you are as clever as you can be when you write it, how will you ever debug it?"
The effective programmer works as a "solutions provider" and not just as "problem solver".

Followers