Software the Agile Way....

Do Each active participant in the daily standup is supposed to share what they did yesterday and what they are doing today on work that progresses the work defined for the sprint. Others may certainly attend and listen. Don't Any detailed discussion,  revisions of requirements,  changing of priorities,  changing of the backlog or any other decisions are not to be made in the daily standup. NOTE - If the information shared in the daily standup warrant detailed discussion, changes or decisions, that should happen in a subsequent sit-down meeting  with relevant participants  in which the PO should probably be an active participant.

Programming with Confidence:  unit tests increase your confidence about the code you are developing because the tests will clearly show if the changes you made caused the failure of some part of your code. This way you can fix the code, run the tests again, and if all pass, you can continue to work with the confidence that everything is still working properly. Continuous Integration of Code:  unit testing ensures that the new features developed didn’t cause side effects on the code that was already working, so you have more confidence that the new features developed are working properly and also that they did not harm other parts of the software that previously had been already checked and perhaps even validated. Better confidence on the quality of your code:  with unit testing, you are not only  supposing  that your code is working, but instead you are  sure about it , because when all your tests are passing you know that your system is behaving e...

Technical proficiency -  automation can free the time of testers to do more exploration, which allows discovery.   Investigative curiosity Observational skills Communication skills Writing skills and bug advocacy Domain knowledge Willingness to learn Social skills Humor Practice "Testing is questioning a product in order to evaluate it . Software testing is about revealing the unknown." Source-  http://www.ebaytechblog.com/2013/01/31/becoming-a-world-class-tester/#.VTNlhNKeDGd http://java.dzone.com/articles/3-technical-skills-every

Jez Humble and Dave Farley defined the following principles in their Book “Continuous Delivery”: Repeatable reliable process  – use the same release process in all environments. If a feature or enhancement has to work through one process on the way into the integration find a way of popping up. Automate everything  – automate your builds, your testing, your releases, your configuration changes and everything else. Manual processes are inherently less repeatable, more prone to error and less efficient. Once you automate a process, less effort is needed to run it and monitor its progress – and it will ensure you get consistent results. Version control everything  – code, configuration, scripts, databases, documentation. Everything! Having one source of truth – and a reliable one – gives you a stable foundation to build your processes upon. “Bring the pain forward”  – deal with the hard stuff first. Time-consuming or error prone tasks should be dealt with as soon...

1.  Create constancy of purpose toward improvement of product and service, with the aim to become competitive and to stay in business, and to provide jobs. 2.  Adopt the new philosophy. We are in a new economic age. Western management must awaken to the challenge, must learn their responsibilities, and take on leadership for change. 3.  Cease dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place. 4.  End the practice of awarding business on the basis of price tag. Instead, minimize total cost. Move toward a single supplier for any one item, on a long-term relationship of loyalty and trust. 5.  Improve constantly and forever the system of production and service, to improve quality and productivity, and thus constantly decrease costs. 6.  Institute training on the job. 7.  Institute leadership. The aim of supervision should be to help people and...

How should the software perform when the network is slow? How should the software perform when the network has 5% packet loss? How about 10% or 30%? If the software requires a persistent connection, what needs to happen when the user steps into an elevator, or when the device goes to sleep, or when the application is interrupted by a phone call? The standard screen resolution for smartphones is 320x300 pixels, but tablets are larger and next-generation mobile devices can support HD screens. What should the user see in all that extra white space? We integrate with Facebook, Twitter or Google login. What do we do when that service is down, and how can we test it? Source- http://searchsoftwarequality.techtarget.com/tip/Mobile-application-requirements-Same-process-new-challenges

Tips for Effective Ice-Breakers ·          Keep it simple. ·          Make it fun. ·          Be creative. ·          Consider various types of Ice-breakers--don't just stick to "questions." ·          Consider your audience. ·          Be aware of time constraints ·          Keep in mind technology requirements. Consider using an ice breaker when: ·          Participants come from different backgrounds. ·          People need to bond quickly so as to work towards a common goal. ·          Your team is newly formed. ·        ...

For sustainability, the team really should own and evolve their standards instead of them being handed a bible. The coding standards can and should change over time. The key is clarity, testability, extensibility and maintainability of the code itself.   It is also important to establish from the beginning that the code base is shared by the whole team. No part of the code should be understood and maintained by only one team member.  Pair programming is the best way to get consistent adherence to standards. The key is the discipline of unit testing and refactoring

http://scn.sap.com/community/design-thinking/blog/2013/05/10/design-thinking--so-what http://forty.co/value-balancing-desirability-feasibility-viability

- Programmers write more automated testes and focus on higher automated testing  - Manual testers are more focused on exploratory testing  - Documentation of BRS, FRS, Test Plans are totally reduced to a simple list of features with scenarios; i.e. BDD. This provides a common language that business users, programmers, testers can all understand share and collaborate on.  - Development Team is structured that programmer and testing skills are in the team.Instead team members pair up to both do development and testing in a highly iterative and incremental nature.  - Culturally the team succeeds when the work is done and meets the quality standards defined by the "Definition of Done". If something is wrong, all fail.  - Defects found in Sprint are actually not logged, but the developer / tester pair simply chat and fix it on the spot as the work to the Product Owner is not "Done" yet.  - Missing requirements are not bugs, but simply new requireme...