Software the Agile Way....

In the Scrum meetings, if the one of the team members are digressing from the agenda then  other team member will say "can we take this after this stand-up meeting" instead of Scrum Master saying this. In the daily stand-up meeting, team members are stressing on the done activities rather than discussing something which is not bringing clarity. Team is flexible to accommodate small ( non significant requirement changes) rather than becoming rigid in not accepting this. Team members respect each other and one conversation is going on during the meeting. Team members are asking question to PO on why this feature is needed? Team members are looking for improvements and taking interest during retrospective meeting to bring the topics without any fear. Team members are skilled and confident of the work and are not scared of ambiguity rather than working towards it to make it clear.  Team members respect time. Team members trust each other and do not depend on email or a...

Customers are afraid that • They won't get what they asked for. • They'll ask for the wrong thing. • They'll pay too much for too little. • They must surrender control of their career to techies who don't care. • They won't ever see a meaningful plan. • The plans they do see will be fairy tales. • They won't know what's going on. • They'll be held to their first decisions and won't be able to react to changes in the business. • No one will tell them the truth. Developers are afraid, too. They fear that • They will be told to do more than they know how to do. • They will be told to do things that don't make sense. • They are too stupid. • They are falling behind technically. • They will be given responsibility without authority. • They won't be given clear definitions of what needs to be done. • They'll have to sacrifice quality for deadlines. • They'll have to solve hard problems without help. • They won't ...

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.

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

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

1. Impressive technical skills   Describe your experience with different programming languages. 2. Willingness to learn   What do you do to keep your programming skills current? 3. Debugging skills.   How do you handle bugs in your code? (next, I would give them a trial run to debug code) 4. Work environment match   Some programmers require complete silence to concentrate, while others thrive in chaos. 5. Problem-solving skills.   How would you create (insert near impossible task for your organization)? 6. Passion for the work. True programmers are self-proclaimed “computer geeks,” spending their time gaming, building servers, or creating apps for friends.  7. Grace under fire.   The ideal programming candidate will be able to handle even the most stressful situations calmly and, most importantly, be able to continue working. Describe a time when you were under extreme pressure and your application wasn...