Monday, March 30, 2015
Saturday, February 28, 2015
2. Big upfront requirements gathering
3. Gathering requirements upfront saves cost
4. Analysis follows requirements followed by design
5. Project Management is not part of software development
6. High degree of documentation needed before starting work
7. Customer sees work after all the work is developed and tested
8. Testers need not be involved early
Saturday, January 31, 2015
The Project Management Institute (PMI) introduced the principles behind program management with a critical focus on maximizing benefits. Often project management focuses on controlling scope and schedule using available work flow tools that they miss an important component of not understanding the value of the project on a larger scale.
The question to ask here is what role did the project do in increasing the value to the performing organization, customer, and the society? When we think about this and focus on the benefits, we step into the next stage of ensuring the project risk is constantly monitored. There are various tools to managing the risk but constantly keeping focus and most importantly the risk register.
Understanding these risks is a critical element to the next stage called program management. Why? This is because the program management focuses on what an individual project can't deliver. The impact on value maximization is high in program management a if the risk is not more actively monitored. There will be too many interproject dependencies that may impact this projects higher. So, when advancing to program management, active risk management is critical and is a sine qua non for project management excellence.
Wednesday, December 31, 2014
Sunday, November 30, 2014
- Eliminating the number of testers increases the level of effort on the remaining testers to check every test case as thoroughly as possible introducing errors. The testers that have the accountability to ensure that they don’t release features without signing off are under pressure compromising the quality.
- Keeping more testing resources also does n0t guarantee zero quality always when the testers don’t keep up with the current trends. The number of communication lines increase with the QA manager, test lead, offshore test coordinators, and testers. This functional hierarchy removes the testers from the developers defeating the self-organized team requirements. Consequently, the requirements dilute and morph leading to management problems as the customer complaints increase, time to market slips, and product reviews decline.
- The client facing roles mentioned earlier may actually question why they should do this testing that the testing department is accountable for? It is a valid question but when buying a car why do you want a test run? Why do we do our own walk-through inspection of the home instead of leaving the work completely to the home inspector? We do these because we are equally responsible for the outcome. As these roles face the client who can claim escaped defects or the features for enhancement, how could these responsibilities downplayed?
- Let us face another argument of being busy to do this acceptance testing! When automation is introduced, the developers and testers have to write additional lines of code and test scripts to ensure that the automation works according to the 3A principle (Arrange what needs to be tested, Act by developing code to test, and Assert by evaluating the outcome against the expected). This needs more time commitment and learning additional tools where the developers and testers need to immerse themselves to evolve to the expectations of today’s workforce. So, if one group that is busy can increase their competencies, why should not these client facing roles elevate their skill-competency gap instead of claiming the busy life?
- Another important angle to consider is new functional non-customer value add requirement but a business value add requirement, such as the heartbeat monitors, exception log checks, and time taken to test checks as part of the automation efforts. None of these requirements are part of the actual product feature a customer sees but are additional scope of work that the business mandates on the execution wings to design, develop, and test. When these are baked into the level of effort or timeline and when customer asks to reduce the time to market, the client facing roles cripple the quality by not standing up for best practices.
Friday, October 31, 2014
1. Scrum focuses on timeboxed iterations with self-organized cross-functional teams.
2. Team decides on what can be accomplished in a 2-week sprint and emphasizes continuous improvement by retrospectives
3. Customer representative is expected to be sometimes on-site and be multi-functional with skills in product, project, account, technical, business analysis, etc.
4. Measure of progress is working software delivery
1. Team visualizes the workflow in queue
2. Anyone can pull (i.e., take) any task that is in the queue
3. Tasks are generally not dependent
4. Balances work in progress
5. Reduces waste between tasks