Software the Agile Way....

When I first read the Agile values and principles, I found it really easy to understand as it talks really the basic things. And I thought this is already there in me and i know really well. But I was wrong. There is a deep meaning of each and every values and principles and understanding and implementing it, is a difficult job. But I took up the challenge and started learning about these and started implementing when I was just a software engineer. I volunteered for the role of Scrum Master and started applying these concepts. I learned during the implementation phase that before helping other understand and influence, I need to convince myself why this is helpful and how it is benefiting me. For example, instead of sending a formal email to my test engineer, I started going to his desk and started having the better interaction. This saved a lot of my time as I don't have to explain in email and i can close that issue quickly by having a quick interaction. This helped me to...

Agile manifesto clearly says give more value to Individuals and Interaction than to process and tools. This means there can be occasions while building product/feature we come across change sometimes small enough (Remember, in a software development phase it is very much possible to get changes) that could be easily absorbed in a sprint but if team says we need to prioritize this in next sprint as this is a change and should be followed as a process then we really need to rethink on this. Scrum is a lightweight framework and this clearly means we should try to avoid too much of process. This "we" includes  Product owner,Team. When a change need to be accommodated within the sprint then team should see if this impacts overall plan for the sprint, if yes just talk to PO and negotiate with some low priority work. if no then they should just implement instead of wasting efforts in following process. And at the same Product owner should try to think through the solu...

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