Software the Agile Way....

http://chrissteeleagile.com/scrum-kanban-scrumban/

1. Understand the organizational setting and nature of the work, 2. Makeup of the team, 3. and then choose a method that works for that setting 4. What is the business workflow that is going to work for you? 5. What are your organizational strengths and weaknesses, and 6.  how can you harness the former and shore up the latter? 

What do your customers really want from you? No matter what your industry, your customers want more than just great products and workable solutions. What they really want to know is that you--personally--are the type of person whom they can trust to get the job done.  Here are the seven things they want to see in you: 1. Independent Thinking Customers want to know that you'll represent their interests, even it's not in your own financial interest--and particularly when the proverbial chips are down. (Of course, it's your job to make certain that the chips stay up.) 2. Courage Customers want to know that you can be trusted to do the right thing. They expect you to tell them if buying what you're selling is a mistake, or not truly in their interests.  That takes real guts. 3. Pride The best customers don't want you to truckle and beg. Because they're trusting you to deliver, they want to work with proud, successful people who can handle even the most diff

Good Change management and frozen wishlist from the product owner are the keys to handle such situation.

http://www.businessanalystfaq.com/financebankingknowledgeforba.htm http://ecommerce.hostip.info/pages/279/Customer-Relationship-Management-CRM.html http://www.21crmsystems.com/about_crm/crm_components.aspx http://www.marketingteacher.com/lesson-store/lesson-crm.html# http://www.destinationcrm.com/Articles/News/Daily-News/What-Is-CRM-46033.aspx

http://www.techsmith.com/jing.html http://www.techsmith.com/camtasia.html http://www.gliffy.com/ http://www.collab.net/products/scrumworks http://teamforge.net/

http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/ INVEST in Good Stories I -  not overlap in concept N - the  essence, not the details V - valuable to the customer E - We don't need an exact estimate, but just enough to help the customer rank and schedule the story's implementation S - Smaller stories tend to get more accurate estimates. T - Writing a story card carries an implicit promise: "I understand what I want well enough that I  could  write a test for it." SMART Tasks S -   S pecific  enough. helps people understand whether the tasks add up to the full story. M - The key  M easure   is, "can we mark it as done?" A -  The task owner should expect to be able to  A chieve  a task. R -  Every task should be  R elevant,  contributing to the story at hand. T - A task should be  T ime-boxed : limited to a specific duration. This doesn't need to be a formal estimate in hours or days, but there should be a

Whiteboards and stickies. Start with the basics and get the teams involved before you invest in tools. At this point, tools are detrimental. Learn the game before investing.  Some things you should think about:  1. Who's your audience?  2. What value are you capturing?  3. What type of measurements do you want visible?  4. Who will actually be using the tool?  Keep retrospecting with the team over a few months while working the stickies and the whiteboards and the team will define the requirements. Compare this will the foreseen business value from your stakeholders and you should be able to drive a decision.  Lastly, don't buy something that has too many gadgets; that defeats the simplicity of agile.  

1. Eliminate Waste 2. Build Quality In 3. Create Knowledge 4. Defer Commitment 5. Deliver Fast 6. Respect People 7. Optimise The Whole In the future posts we will discuss the above mentioned principles.

How should we handle reliability, availability, portability, scalability, usability, maintainability in Scrum product backlog? These are constraints which should be part of either the Tasks of a backlog item/user story or acceptance criteria. Example - Data migration projects where no business functionality/features are there we just need to create a utility which will migrate the data. For such requirement, we can create a user story which is to create the utlity which will allow me to handle the data migration and its tasks should have the constaints like  reliability, availability, portability, scalability, usability, maintainability.

Kanban is just a device for a "pull system" to realize Just-In-Time . Just-In-Time can be paraphrased as "making and delivering what is needed, just when needed, and just in the amount needed." It aims at meeting a customers' need: "the best quality product at the lowest price as soon as possible." 

Try the INVEST acronym. If you just google this, you should find a few links.  One should try to have Stories be:  Independent  Negotiable  Valuable  Estimatable  Small  Testable  Also, a popular format used is:  As a <Persona> I need <some functionality> so that <benefit>.  Acceptance criteria is critical to get before sprint planning as this removes any ambiguity of what has to be delivered and how it will be accepted. That is if you can prove the acceptance criteria (and your other DoD) then the product owner has to accept it. If suddenly a "Yes, but it doesn't do", the answer is simply "Not in the acceptance criteria, add this to the backlog and prioritise when it should be done" 

DSDM originated in England, has become popular in Europe, and has a number of sites using the approach in the U.S. 1. Active user involvement is imperative. 2. DSDM teams must be empowered to make decisions. 3. The focus is on frequent delivery of products. 4. Fitness for business purpose is the essential criterion for acceptance of deliverables. 5. Iterative and incremental development is necessary to converge on an accurate business solution. 6. All changes during development are reversible. 7. Requirements are baselined at a high level. 8. Testing is integrated throughout the life cycle. 9. A collaborative and cooperative approach between all stakeholders is essential.

http://implementingagile.blogspot.in/2011/06/scrum-metrics.html - Quality -Productivity -Satisfaction -ROI

Individuals and interactions  over processes and tools Working software  over comprehensive documentation Customer collaboration  over contract negotiation Responding to change  over following a plan

http://allianceglobalservices.com/blog/best-practices-for-agilescrum-for-onshoreoffshore-model-a-hybrid-model-part-i/#.T-0-ObUoSGw

Few important links would help us to understand the estimation techniques... http://www.agilebuddha.com/agile/agile-estimation-9-reasons-why-you-should-use-story-points/?goback=%2Egde_81065_member_127714312 http://www.infoq.com/articles/agile-estimation-techniques http://www.techrepublic.com/blog/tech-manager/comparing-traditional-and-agile-project-management-estimation-techniques/4357 http://www.techrepublic.com/blog/tech-manager/agile-project-management-estimating-the-unknown/1435 http://leadinganswers.typepad.com/leading_answers/2007/11/agile-estimatio.html http://msdn.microsoft.com/en-us/library/hh273016(v=vs.88) http://msdn.microsoft.com/en-us/library/hh273055(v=vs.88).aspx

I have read various articles,blogs,sites on Scrum and to me all this means is that Scrum is a culture in an organization to bring discipline and framework which could be implemented to enhance productivity, reduce attrition and reduce wastage.

As we all know Agile software methodology offers various ways to deal with the project/product development issues. We  have various Agile Methodology today like Scrum, Lean,Kanban, Extreme programming,DSDM,RAD,TDD and many others. How should we utilize each of these in our projects to create a success. In my future posts i will talk about each of the methods and discuss the pros and cons , starting with Scrum.

In the IT world, every stakeholders know their roles and responsibility still there are project/products that fails. The reason of project failure could be many as you could see the list below - 1. Lack of User Input 2. Incomplete Requirements & Specifications 3. Changing Requirements & Specifications 4. Lack of Executive Support 5. Technology Incompetence 6. Lack of Resources 7. Unrealistic Expectations 8. Unclear Objectives 9. Unrealistic Time Frames 10. New Technology 11. Lack of Planning 12. Didn't Need It Any Longer 13. Lack of IT Management The above list provides us with some of the issues in project execution.