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/11/being-effective-manager-means-being.html
http://thinkinginsoftware.blogspot.com/2014/10/kanban-as-driver-for-continuous-delivery.html
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
Wednesday, August 20, 2014
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".
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:
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:
- Define your code style and follow it. Be consistent.
- Use descriptive and meaningful identifiers: "redBalloon is easier to read than rdBlln"
- Break up long functions/methods into smaller ones. This will make the code *almost* self documented
- Use comments only to complement the code meaning to explain the *why* and not the how
- Use documentation only to complement the comments meaning provide the big picture, how to get started and a glossary of probably unknown terms
- 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?"
Thursday, August 14, 2014
Tuesday, August 12, 2014
Install telnet in Solaris 11
Why would you do this? Make sure you communicate the security risk involved to those who asked you to enable it. Here it goes anyway:
Friday, August 01, 2014
Does Project Management provide Business Value?
Does Project Management provide Business Value? A similar question came up in LinkedIn and I decided to share my ideas on it.
Project Management is part of any product lifecycle. It is a discipline that should help a team achieve a specific goal. It is needed either as a responsibility of a dedicated individual/department or the whole team.
A team should achieve "predictable delivery with high quality" and for that to happen you will need to measure several productivity KPI. In the words of Joseph E. Stiglitz “What you measure affects what you do,” and “If you don’t measure the right thing, you don’t do the right thing.”.
So IMO if the PM discipline adjust to these ideas PM discipline is to be considered 'an integral part of the overall success of the team'. If these ideas are still not introduced in your team then the PM discipline is a 'must-do' to get you to new levels of productivity. If the PM discipline is thought to be in place but not adjusting to these ideas I would definitely consider it an 'overhead'.
Project Management is part of any product lifecycle. It is a discipline that should help a team achieve a specific goal. It is needed either as a responsibility of a dedicated individual/department or the whole team.
A team should achieve "predictable delivery with high quality" and for that to happen you will need to measure several productivity KPI. In the words of Joseph E. Stiglitz “What you measure affects what you do,” and “If you don’t measure the right thing, you don’t do the right thing.”.
So IMO if the PM discipline adjust to these ideas PM discipline is to be considered 'an integral part of the overall success of the team'. If these ideas are still not introduced in your team then the PM discipline is a 'must-do' to get you to new levels of productivity. If the PM discipline is thought to be in place but not adjusting to these ideas I would definitely consider it an 'overhead'.
Subscribe to:
Posts (Atom)