Software the Agile Way....

The cost of change for a traditional software project When changes to a product is introduced during the development stage because of new information or a new customer requirement, a domino effect of negative consequences followed. First, the process had to go through formal change control that was intended to ensure everyone on the team, especially those handling development and QA, understood the change and that the plan of record was kept up-to-date. This meant documentation and meetings. Second, the effort had to be estimated and, often, the schedule recast. Kent Beck, who developed Extreme Programming, asks a very thought-provoking question: if our cost curve were relatively flat (Figure 1.3) Would we behave differently?  Would we delay decisions until we had better information?  Would we over-design in anticipation of future needs or just design and build to our current requirement?  Would we be able to deliver more value to the mar...

DO Say  what  needs to get done. Challenge the team Get interested in building a high-performance team. Practice business-value-driven thinking. Protect the team from outside noise. Incorporate change between sprints. Don’t Say  how  to do it or  how much  it will take. Bully the team Focus on the short-term deliveries only. Stick to the original scope and approach  “no matter what.” Worry the team with changes that might happen, until they become real. Allow change to creep into sprints. Advise from  Lyssa Adkins

C ommunication - Most desirable is face–to–face communication where we can talk, respond, gesture and draw on a whiteboard. Less desirable are written documents. XP stresses communication through practices such as pair programming. S implicity - This is a value of XP teams because it keeps their focus on creating a solution to the problem faced today, not the problem anticipated tomorrow.They remain constantly focused on doing the simplest thing that could possibly work. F eedback - XP teams value feedback, and the more immediate the feedback the better. This is achieved by Pair programming, Continuous Integration,Automated Testing and from customers. C ourage - XP teams value courage. For example, they have courage to refactor their code (because they have automated tests to back up that courage).They will use a metaphor and maintain a simple design through refactoring and test driven development.

S mall releases -  By the end of each iteration( 2 to 3 weeks long)  the team is responsible for delivering working, tested code that can immediately be put to use. The p lanning game -  Prior to the start of each iteration, the team and customer plan the iteration. This involves selecting the highest priority stories that can be completed in the iteration and then identifying the specific tasks necessary to complete the story . R efactoring -  Refactoring (Fowler 1999; Wake 2003) refers to the restructuring or rewriting  of code so as to improve the code without changing its external behavior.Refactoring is one of technique used by XP to replace upfront design. T esting -  XP puts the tests right up front in a practice called test-driven development (Beck 2003; Astels 2003). On an XP project the developers write automated unit tests and the customers write acceptance tests, which are often automated either by the customers themselves or ...

1. Story point estimate is an amalgamation of the amount of effort involved in developing the feature, the complexity of developing it, the risk inherent in it, and so on. 2. The first approach is to select a story that you expect to be one of the smallest stories you’ll work with and say that story is estimated at 1 story point. 3. The second approach is instead to select a story that seems somewhat medium-sized and give it a number somewhere in the middle of the range you expect to use. 4. Velocity is a measure of a team’s rate of progress. It is calculated by summing the number of story points assigned to each user story that the team completed during the iteration. If the team completed three stories each estimated at five story points then their velocity would be fifteen. If the team completed two five-point stories their velocity would be ten. 5. On any given day, in addition to working on the planned activities of a project, a team member may spend time answering em...

PO and team to demonstrate the working software increment to other stakeholders. The goal is to solicit feedback and then make changes to the backlog if appropriate. Think of it as User Acceptance Testing. Talk about the release plan and how the current sprint affected it. The PO should also be highlighting what is comming up in the next sprint. How are we going to deliver the potential business benefits of Agile? Did we pick the right delivery approach for the product and the right stakeholders? Did we coach and engage them well enough? Do they understand the importance of incremental, iterative development and the frequent feedback loops? If business is not available or interested are we really working on the right thing in the right setting? Are we engaging business in the right way?

Normally enterprise architecture should take place before the project even starts.It should be part of the project start-up or mandate.  In particular the organizations application architecture and integration architecture should be done.  Its unlikely that there will be a enough information at this point for information architecture,This will need to evolve as the project progresses. As for the other enterprise level architectures, many of these will be defined and form part of a definition of done. Typically in the start-up of a project, a BA, product owner will capture epic ideas and these will be broken down into high level feature stories/requirements. Note this is not going to be detailed and ready for a team to implement, but it covers enough knowledge that an architect should be able to formulate a technical approach. This also servers as a high level release plan. A good technical/system architect should be able to look at these feature requirement and formulat...

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