Agile

What are the Scrum Artifacts (resources)?

-Product Backlog -Sprint Backlog -Burn down Chart

What are sprints?

A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. Sprints are at the very heart of scrum and agile methodologies, and getting sprints right will help your agile team ship better software with fewer headaches. "With scrum, a product is built in a series of iterations called sprints that break down big, complex projects into bite-sized pieces,"

How capacity in Scrum is measured?

Capacity is measured using throughput of backlog items

What is Agile?

If one adopts an Iterative and Incremental approach along with something, it becomes Agile. This something, is all about, collaboration, embracing changes, innovative solutions, and continuously inspect and adapt to the circumstances, is what makes the project, Agile.

Problems with multi-tasking

In the traditional flow, We all try to do multi tasking whenever possible, however there are issues observed when we think of system as a whole. Following are some of the challenges when a team or an individual does many things at the same time. •High cycle time due to huge WIP •Too many tasks-in-hand leading to frustration •Insufficient focus •Delay in feedback from customer due to unfinished work in the flow •Low productivity and throughput •Bottlenecks in the flow causing unnecessary delays Kanban follows "Stop starting, start finishing"

Kanban practice - WIP limits

Limiting Work-In-Progress helps in implementing a pull system. Ø Factors to consider for deciding WIP Limits: • Number of concurrent items • Whether the column is split or not • Probability of blockage Ø WIP limits are decided through consensus with stakeholders and can be adjusted empirically. Ø WIP limits are set at each column level corresponding to each stage in work item lifecycle. Ø Limiting WIP has two benefits: • Reduction in cycle time • Improvement in quality by focusing on fewer tasks

When to choose distributed Agile

Other Factors •Duration of Project •Availability of skills at offshore

Characteristics of User Stories?

Stories are not: • "mini" Use Cases • a complete specification • a contract • intended to be interpreted • without a PO Stories are : •User's need •Product description •Planning items •Token for a conversation

Kanban practice - visualize

Visualizations helps to : - Build transparency. - Make the need for actions and interventions visible. - Identify the bottlenecks in the flow and helps in decision-making.

What are characteristics of a SM

•Good inter-personal Skills •Good Communication Skills •Proactive, helpful •Good Listener •Good Observer •Courageous mindset •Committed to the success of the Team •May or may not posses technical expertise •Avoid having team's Manager as Scrum Master

Sprint Backlog

•Sprint backlog defines the work or tasks for the current sprint •Tasks are divided such that each task takes roughly 1,2,4 or 8 hours

Kanban meetings

1) Delivery Planning meeting (a) In this meeting, planning is done for delivering work items in a release. Its frequency is as per delivery cadence. 2) Replenishment meeting (a) This is to replenish work in the input queue (backlog). This generally, happens on weekly basis or on demand. 3) Daily stand-ups (a) These are daily coordination meetings of fixed duration. The team gathers to go over Kanban board and discusses the issues, impediments and flow.

What is Kanban?

- In Japanese language, kanban means a signal card or visual signal. -Kanban systems have been used traditionally in situations where it is desired to limit quantity of things inside the system e.g. Imperial Palace Gardens in Tokyo uses a kanban system to control the number of visitors in the park. -A Kanban system is a pull system. New work is pulled only when something is finished and capacity is made available. Kanban is a tool for managing the flow of materials or information in a process.

Team Hours Available

Another important concept in Agile is that people should plan for only about 80-85% of their working day as productive hours. The remainder would be taken by meetings and other activities like training etc. So for a 9.5 hours day, please plan for about 7.5 hours as productive hours. While this is not mandatory, it is a good practice.

Scrum 5th step - Review

Every sprint ends with a Review. This is a meeting where all the stakeholders come and watch as the team demonstrates what they have achieved in the sprint. This is a demo of working software and is usually done from a QA environment. It is also referred to as, Show and Tell. This meeting is a time for the stakeholders, to give their feedback to the team. Based on the feedback, the team can make any course corrections needed for the next sprint. The last meeting happening for a Sprint is retrospective. In this meeting the team reflects on its ways of working and gives honest and objective feedback on, What went well, what did not go well, Things to escalate, and Things to try. This is also fed back into the planning meeting for the next sprint. So sprint planning, review, and retrospective happen one time for each sprint, and the daily stand-up happens on each day of the sprint. What comes out is potentially shippable software that can be deployed to production if there is a need to do so.

Guidelines for Splitting User Stories - Splitting across Data Boundaries

Example •User Story: As a user I can enter my balance sheet information. •A balance sheet could include a great many fields. So the story is a good candidate for splitting. •User stories after Splitting could be: -As a user, I can enter summary balance sheet data (assets and liabilities) -As a user, I can enter categorized balance sheet data ( covering details such as cash, securities, real estate, loans and so on) -As a user, I want the values I enter to be validated so that I don't make mistakes -As a user, I can enter detailed loan information

How to evaluate User Stories

Independent: Can the user story be built without requiring other - When thinking of independence, it is often easier to think of "order independent". It allows for true prioritization of each and every story. When dependencies come into play, it may not be possible to implement a valuable story, without implementing other much less valuable stories. stories before we can see and test functionality? Negotiable: Can specific details of the story be resolved through conversation so we can maximize the benefit while minimizing development costs? - A story is not a contract. A story IS an invitation to a conversation. The story captures the essence of what is desired. The actual result, needs to be the result of collaborative negotiation between, the customer (or customer proxy like the Product Owner), developer and tester (at a minimum). Valuable: Does the story add value to the software for either or both user and business? - If a story does not have discernable value, it should not be done. Period. User stories should be prioritized in the backlog according to business value. Estimable: Do we know enough about the story to estimate the time to construct the software? - A story has to be able to be estimated or sized, so it can be properly prioritized. What happens if a story can't be estimated? You can split the story and perhaps gain more clarity. Small: Is the story as small as it can be but still valuable? - Obviously stories are small chunks of work, but how small should they be? The answer depends on the team, and the methodology being used. For example, in a two week iterations, which allow for user stories to average 3-4 days of work - TOTAL! This includes all work to get the story to a "done" state. Testable: Can others easily verify that the story is complete? - Every story needs to be testable in order to be "done." As with negotiable above, asking magic question "How will I know I've done that?" can help ensure the user story is testable as well.

Testing the old ways

Old Ways Don't Work: •Phased testing. •Upfront detailed test planning. •Working as a specialized 'Silo' unit. •Creating test cases after development. 1- Manual Testing -> Process of testing after dev. Quality gates come to effect. Code hand-off. Managing test show-stoppers, support etc. Reduced functional deliverables 2- Automated UI Testing -> Meant for Performance Testing Rewrites of automation scripts Tools adoption 3- Unit Testing -> Developer Tests (resistance to writing unit tests) Does not know what to test. Often lack of unit tests result in show stoppers for QA/Functional Testing

Agile Testing Patterns & Anti Patterns

PATTERNS •Share a common product backlog and sprint backlog •Work in the same development team •Common planning sessions •Automation and test script refactoring •Helps the team pre-empt bugs ANTI PATTERNS •Separate backlogs •Separate teams •Testers are only present in the planning sessions •Reliance on only manual testing •Await code drops and hand-offs to begin testing •Catalogue bugs

Difference Scrum vs Kanban

Scrum 1) Delivery in timeboxed iterations 2) WIP is limited per iteration 3) Work items are broken down so that they get completed within a sprint 4) Defined roles - Scrum Master, PO, Dev Team 5) More prescriptive than Kanban 6) Meetings are sprint planning, daily scrum, sprint review & retrospective. 7) Velocity and burndown chart are prescribed. 8) Scrum board is reset for each sprint Kanban 1) Delivery in flow as per cadence 2) WIP Limits set for every workflow state 3) No particular work item size is prescribed. 4) No defined roles. Emerging roles- Kanban SDM, SRM 5) Less prescriptive than Scrum 6) Meetings are delivery planning meeting, replenishment meeting, daily stand-ups, etc. 7) Lead time/Cycle time along with Cumulative Flow Diagram are used. 8) Kanban board remains persistent

Scrum first step- Product backlog

Scrum is an SDLC methodology. It starts with something called a Product Backlog. You can imagine this to be an excel sheet, where every row is a requirement or a user story, which is the terminology in Agile for requirements. The key thing to note here is that the priority of the user stories decreases as we move down the product backlog. This really means that story in row 13 is of lesser priority, than the story in row 10. Who gives these stories, or who creates the Product Backlog? It is a person called a product owner, whom you see just above the Product Backlog. He/she is the sole contact for anything that comes in or moves out of the product backlog. He/she can use various sources to get the input, some of which are shown in the diagram. The scrum team is one of the key teams for giving the inputs.

Scrum 3rd step - Sprint

Scrum recommends that sprint duration is between 1 to 4 weeks. It is very important to note that. 1. The duration once decided will remain consistent all through the project. 2. At any point, if we are unable to complete the stories or tasks for the sprint, the duration will not change. Rather. the scope is changed for the sprint. and the unfinished stories or tasks are moved to the product backlog, and the PO is supposed to re-prioritize the same. Once the sprint starts, there should not be any major changes to the goal of the sprint of the stories/tasks. If there are major changes, it is recommended that the sprint be dropped, and new sprint started with the Planning activity happening again. It is important to note, the planning activity needs to happen at a time when all the team members are available. Hence for teams that are distributed, this needs to be taken care.

Strategies for Handling Distributed Agile - Strategy 7

Setting Up Meetings. Managing time productively is very important , especially, if the overlap is small. Hence ensure, that all meetings have the following characteristics: •Are planned well in advance and participants are given enough notice. •Well defined start and end time. •Well defined agenda and expectation from the meeting. •Logistics like phones, bridge numbers, network issues are taken care.

Strategies for Handling Distributed Agile

Strategy 1 : Managing the communication bandwidth between different time zones. The time zone differences between onsite (particularly US) client locations and many of the major offshore development sites like India are so huge that, at times, it becomes difficult to find overlap in business working hours. Like the slide depicts try having a common working hour by getting some teams to work in shifts. While doing this, ensure that a single team is not an a disadvantage, and all teams work on shift timings turn by turn. This challenge is less in APAC and European countries, as India usually has 3-4 hours of overlap on a normal working day. Strategy 2 : Visibility into Project Status . Use web based tools to track project progress, and ensure that data is updated religiously by the teams in different locations. Strategy 3 : Monitoring Software Quality and Project Health. Strategy 4: Creating Avenues for Collaboration.

What is required from Client Side

Support Knowledge Building *Important for knowledge intense domain •Co-location in the beginning •Client SMEs involvement on knowledge transfer (domain knowledge + code review) •Require investment from both Service Provider and Client Product Owner Involvement •Require time investment, highly involved product owner is a key to build success distributed team •Address offshore team members with their name, give offshore team recognition •Do not just talk to the onshore team but also communicate with offshore team •Be flexible and open, be prepared to change. Don't be afraid to fail.

Iterative Approach

The iterative approach is more like a rework-scheduling strategy, where by there is constant rework received from the stakeholders. Based on the feedback, there is revision or rework of the software. Typically the iterations are small in duration . The product is refined and improved during the course of the project. Every aspect of the SDLC like, Requirement and Analysis, Design, Development and Testing happen all together, albeit in smaller chunks.

Traditional or waterfall approach

Traditional development approach, commonly known as the Waterfall model , divided the SDLC or the Software Development Lifecycle into a series of sequential steps as depicted. Every project was supposed to start with a Requirements gathering and analysis phase, followed by Design, which was followed by coding, and then testing, and finally ending with rework. Every phase ended with a sign off, which was usually based on documentation. Also it was common for the initial set of people, to move out the project by the time the coding started, thus leaving a gap in the knowledge, that was built in the initial stages of the project. The typical project duration was more than a year and sometimes as long as 18 months or more. This really meant that the time between, conceptualizing the requirements, and seeing it in a tangible format in the form of working software, was huge. And in many cases, this usually was the first time, when the customer saw something functional. This was termed as, "Big Bang" release. Disadvantages are: •Business started changing rapidly and hence to be competitive, one had to be ahead of the market. • •This necessitated that changes to the products were rolled out into the market very quickly instead of couple of months. • •Technology helped in meeting the need stated above.

Strategies for Handling Distributed Agile - Strategy 6

When teams are distributed across location, obviously there would be difference in the culture the agile teams would whom they work. Failing to understand this when we go for a distributed teams, would impact the business and organizations. Ensure that each team understand, the culture, holidays, festivals, etc. and respects the same. Expect resistance and coach the companies and people through it. You also mitigate the same using. 1)Multi‐cultural training & awareness. 2)Discuss local interests and events. 3)Team culture aimed at open & direct communication. 4)Plan around local holidays & celebrations, make it known. 5)Create an equal value system. 6)Take virtual coffee breaks.

What do you call a requirement in Scrum SDLC?

user story

When is a team called as distributed team?

•Any team where all the team members are not physically present in the same location •The following team structure represents a distributed team •Teams in same building , same floor but different ODCs ( e.g. 4th Floor in SEZ Software Tower 1, NOIDA) •Teams in same building but on different floors (e.g. 3rd and 4th Floor, Maple Towers , NOIDA) •Teams in different buildings but in same city ( e.g. Campus and ETA, Chennai) •Teams in different cities but same time zone, same country (e.g. NOIDA and Chennai ODCs) •Teams in different cities and time zones but some overlapping working hours (e.g. Indian and Europe or India and Australia) •Teams in different cities and time zones but none or very less overlapping hours ( e.g. India and West Coast , USA) •As you can see, the degree of distribution increases as we go down the list, but each one is a example of distributed Agile

Strategies for Handling Distributed Agile - Strategy 4

"Collaboration and communication," an important aspect of the Agile Manifesto, can be severely impacted, due to the distributed nature of teams. Though frequent travel and resource shuffling across locations is preferred, practically, it may not be possible to use these options due to the huge cost factor attached to them. Ensure video conference facility, chat's, skype (where feasible) to establish quick connects with the distributed team. "Chats" can help trigger quick and spontaneous discussions, and group chats can be used for productive team discussions. Chats are slightly better than email, since it's possible to share emotions via gestures. Collaboration tools like, wikis, Confluence, Alfresco, and SharePoint are better alternatives used in many agile projects.

Factors considered when prioritizing Stories

'Must Haves' are features that must be included before the product can be launched. It is good to have clarity on this before a project begins, as this is the minimum scope for the product to be useful. 'Should Haves' are features that are not critical to launch, but are considered to be important and of a high value to the user. 'Could Haves' are features that are nice to have and could potentially be included without incurring too much effort or cost. These will be the first features to be removed from scope if the project's timescales are later at risk. 'Would Haves' are features that have been requested but are explicitly excluded from scope for the planned duration, and may be included in a future phase of development

Sprint Burn down

- Sprint burndown chart plots hours remaining by day for a sprint - At any point in time it reflects the work remaining to be completed in a sprint. As shown in this example, the team starts with 90 hours on day 1 of their sprint. The blue line represents the ideal line that will reach 0 hours on day 10. The red line reflects the daily status. Seeing this we note that the team was ahead of their planned work on day 2 and day 3. However, it fell behind the schedule on day 5, day 6, and day 7. They finally made up by finishing on time on day 10. Now if one were to see this graph on day 6, they would conclude that something is not correct and that the team needs to pull their socks up, to meet the deadline.

Product Backlog Iceberg

- The "iceberg" idea is that, as you pull items off of the top of the iceberg, other stories that are at lower levels in the iceberg, move up to take their place. The process of developing stories, and moving them up the iceberg, goes on continuously to feed the development process. - The prioritized stories at the top waiting for development, can be fully groomed, with clearly defined acceptance criteria, with story point estimates and are defined two to three months well in advance. - The stories at the middle of the iceberg, can be epics, high level stories written without acceptance criteria, waiting for an estimation and can be grouped together for a release. - The stories at the bottom of the iceberg can be themes, feature wish list, or the functionalities, that needs further definition.

What are User Stories?

- User story is a small amount of text written on an index card to function as a reminder for a conversation between the development team and the customer. - A user story is a software system requirement formulated as one or two sentences in the everyday language of the user.

Guidelines for Splitting User Stories

-Splitting across Data Boundaries -Splitting on Operational Boundaries -Splitting large stories into separate CRUD (Create, Read, Update, Delete) operations

What are Scrum Ceremonies

-Sprint Planning -Product backlog refinement -Daily Scrum -Sprint Review & Retrospection

When to split a User Stories

-When the user story is too large to fit into a single iteration -When there is not enough time left to cover the complete story in the current iteration -When the user story is large (an epic) and a more accurate estimate is required

What is Velocity

-Work that the team can accomplish in 1 sprint based on Story Points •Might fluctuate across some sprints. •Goals to be refined and improved upon through the life of the project. -Measure of a team's rate of progress per iteration •Estimate the work that can be accomplished in future sprints by the team. -Past projects velocity should not be considered for the current project as: •Team may be different. •Different project types. •Prevailing circumstances might be different etc. •Can be used as an inference to figure out ways and means to improve current project velocity.

Kanban Metrics

1) Lead Time: Time taken from request to delivery. 2) Cycle Time: Time taken through the process from the start until ready for delivery. 3) WIP: This refers to the work that has been started but not finished yet. 4) Throughput: Number of items delivered per unit of time. This is also known as delivery rate. 5) Flow efficiency: It is derived by taking the ratio of the time spent actually working on an item (also known as touch time) to the lead time. It indicates how efficient the system is at processing the work. 6) Average cycle time is directly proportional to the total work in progress. a. Cycle Time = WIP / Delivery rate

How will we see Product Owner can make the distributed team successful ?

1) Product owner need to have lot of bandwidth to participate during the agile ceremonies and resolve the impediments as and when required. 2) Product owner needs to have a mind-set change in considering the offshore team, also as part of his team (Onsite team). He should shift his focus on having a one team approach. 3) Product Owner needs to spend time with the offshore team to build confidence and guide the project on need basis and support offshore team always. 4) Product Owner needs to plan to be with offshore team once in a quarter and stay with the offshore team for a week or two weeks time to get the dynamics of the offshore team and bring enough changes to support the distributed team. 5) Both the HCL and client needs to work on building the trust, share the risk and should have partnership mind set.

What are Acceptance Criteria?

1- Every user story should have acceptance criteria. 2- Should be available before user story estimation. 3- Should be agreed by PO, SM, and team. 4- Should be unambiguous. 5- Should be easy to write test cases based on acceptance criteria and easily testable. 6- Sign-off for the user story should be based on acceptance criteria. Example-1 As a user, I should be able to update the country in the master data. Given the user has access to URL < ..... > When a country drop-down is selected Then - the system displays all 20 countries of operation - the user is able to select only one country - the user can click the "Save" button and the updated data got "Saved". Example-2 Given that the Image URI is stored in a database and can be retrieved When an application developer wants to display or download an Image into his application Then the system should accept a valid image id, query the database and return the actual image based on URI stored.

What are the 4 Agile Manifesto values?

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

Testing - the agile way

1- UI Testing -> Expensive and has to be minimized. Minimizing requires thoughts and analysis. 2- Automated Acceptance Testing -> Acceptance Testing. Very good to capture customer or business user perspective. Not a substitute to unit testing. 3- Unit Testing -> Foundation of a solid test automation strategy. Acceptance Criteria drives unit test creation. Testers can help developers to identify unit test cases.

What is a pull system?

A Kanban system is a pull system which means the work items are pulled in the system only when capacity becomes available in the respective columns on the Kanban board indicated as a pull signal. A pull system helps to balance the flow of work in Kanban.

What are the 12 agile principles?

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity -- the art of maximizing the amount of work not done -- is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Why use Kanban

1. Visibility 2. Reduces or eliminates multi-tasking and improves efficiency 3. Reduces lead time 4. Improves quality 5. Controls variability 6. Improves predictability and agility in service delivery 7. Enables adaptive capability 8. Improves governance

Core Kanban Practices

1.Visualize: Visualize each request with a card on a Kanban board. 2.Limit WIP: Limiting Work-In-Progress helps in implementing a pull system. 3.Manage flow: Monitor and report the movement of work items through each state in the workflow. 4.Make policies explicit: This is to make rules and policies concerning knowledge work explicit. This will help to facilitate agreement on suggestions for improvement. 5.Implement feedback loops: Feedback loops are essential part of an evolutionary process. They help to make process and policy adjustments as per the feedback received. 6.Improve collaboratively and evolve experimentally: WIP Limits, trigger discussions and conversations based on empirical observations of changes implemented.

What is Distributed Agile ?

As the name implies, this is a model in which projects execute an Agile Methodology with teams, that are distributed across multiple geographies, separated by distance, time zone and culture. Excellent communication, and creating a highly cohesive team, are fundamental to distributed agile. A distributed agile methodology will often be used in following scenarios when. 1) Large software organizations are developing a complex software solution, consisting of several different components, which are being built separately, at different locations. 2) Software development is outsourced. In this scenario, a small team works on-site with the business stakeholders. The development of a solution using agile methodology from a single location was a limiting factor for competitiveness, growth, profitability, and the need for offering localized solutions. 3) As a result, when the organizations expanded into new markets or offshored or outsourced their products or services, distributed development became a fact of life for them, and "Distributed Agile Methodology" got introduced to meet the demands of next generation of software solutions. 4) What makes distributed development interesting? - Specialized Talent. - Cost differentials. - Advantage of "Follow-the-Sun" approach. - Global Presence. - Virtual Organization. etc.

NFR - Non functional Requirements

At a user story level, Non functional requirements can be defined as part of acceptance criteria. - Non functional requirements generally include performance, scalability, accuracy etc. - Mike Cohn suggests the use of the same user story template: e.g. •As a customer, I want to be able to run Product X on all versions of Windows. •As a user, I want the site to be available 99.999% of the time I try to access it so that I don't get frustrated. - NFR's are cross cutting concerns that have to be validated across many other stories. It is considered as best practice to include these in the acceptance criteria of other stories.

Two Views of Agile Testing

Automated Testing 1. Automated unit testing a) Developers write unit tests b) Daily builds with unit tests always 100% pass 2. Test Driven Development (TDD) a) Test first approach 3. Automated Functional & Regression testing a) Automated using Functional testing tools b) Comprehensive (Include End to End) c) Repeatable d) Timely Exploratory Testing Involves simultaneously learning, planning, running tests, troubleshooting and reporting results Manual testing by skilled testers Using Charters for covering functional areas Flexibility, Ownership and fun for testers Controllability, reliability and high quality Focused & Optimized to find bugs Continually adjusting plans, re-focusing on the most promising risk areas Following hunches Minimizing time spent on documentation

What are Agile benefits

Development Benefits: •Ownership and responsibility •Produce higher quality deliverables •Continuous business interaction •Quick feedback •Improved employee engagement and job satisfaction Business Benefits: •Faster time to market •Adapting to changing business requirements •Mitigate risk earlier •Improved stakeholder satisfaction •Lower cost and higher productivity

Guidelines for Splitting User Stories - Splitting on Operational Boundaries

Example: •Developing a very complex search screen with dozen of fields at the top part of the screen, a middle tier query builder, and a complex data display grid at the bottom. •After splitting: •Iteration 1 -Laying out the basic UI including half of search criteria fields. -Writing portions of the query builder that worked with those fields •Iteration 2 -Building the data display grid •Iteration 3 -Adding remaining search criteria • •As there was a lot of uncertainty in developing the data display grid it was developed as iteration 2 and not in iteration 3 so that the risk is addressed earlier.

Guidelines for Splitting User Stories -Splitting large stories into separate CRUD (Create, Read, Update, Delete) operations

Example: •User Story: As a coach, I can manage the swimmers on my team •User stories after splitting -As a coach, I can add new swimmers to my team -As a coach, I can edit information about swimmers already on my team -As a coach, I can delete swimmers who are no longer on my team - Removing Cross-Cutting Concerns (such as security, logging, error handling etc.) Example: •Many applications contain screen that behave differently depending on the privileges of the current user. If that is too much to develop in a single iteration, develop the screens in one iteration and support for user specific privileges in a later iteration.

When to use Kanban

Kanban can be used in the following situations: When scope can't be fixed even for a period of 1-2 weeks and there are frequently changing priorities. ØWhen optimizing responsiveness to customer requirements is a high priority ØWhen there is need to establish a cadence (rhythm) of flow of work rather than iterations for delivery ØWhen flow visualization is needed to get a clear view of current WIP to help in planning and tracking

Myths and anti-patterns of Agile

Myths •SCRUM equals Agile. •No documentation & coding is done in cowboy fashion. •No viable estimation means or planning. Anti-patterns •Trying to force-fit agile into traditional methods ....CMMi etc. •Inadequate tool usage and wrong tools. •Large scale transition too fast with little time to absorb agile practices and values

Scrum 2nd step- Sprint Planning

Once the Product Backlog is ready, and stories for the sprint have been identified, the Scrum team gets into a meeting called as Sprint Planning. This meeting is usually split into two parts. The first part is where each story that is planned for this sprint is picked, and discussed in detail by the team. Remember, all the team members need to be present as a part of this meeting. The Product Owner provides clarification to the team from a requirement perspective. The job of the Scrum team is to understand the same in detail and cross-question the PO and Scrum Master, if needed. At the end of part one, all the requirements or user stories planned for the sprint should be clearly understood, and the acceptance criteria for the same should have been clearly articulated. The acceptance criteria is a key input against which the developer will write their code, and the testers will write the test cases. Part two of this meeting is where each of the stories selected for the sprint, is broken down into tasks. These tasks are development and testing-related tasks. Each task will have an associated effort with it, which will be given by the person, who is going to execute the tasks. All these tasks will then be captured in an excel sheet, or a tool like JIRA, or Rally, or Version One, or any other tool as agreed. Once this meeting is over, the sprint starts and the teams should be working on only the tasks that are there in the sprint backlog.

Scrum 4th step - Daily Stand-up Meeting

Once the sprint starts, the tracking of the sprint also starts. This is done using a ceremony called a daily stand-up meeting. This should happen at the same time, the same place, on every working day. In this meeting, all the team members give updates to the entire team by answering 3 questions. 1- What I have done since the last meeting regarding this project. 2- What will I do before the next scrum meeting. 3- What impedes me from performing my work effectively or what are the blockers. It is the job of the Scrum master, to address the blockers and take help as needed from other stakeholders. The BA is responsible for grooming the product backlog for future sprints. This is shown as a small circle just above the Sprint circle.

Strategies for Handling Distributed Agile - Strategy 8

Strategy 8 : Product Owners Bandwidth. In some projects, there are proxy product owners, who expedite some of the decisions / discussions without disturbing the Product Owner, who may be handing multiple teams. Two points to keep in mind: 1. The proxy product owner should be empowered to make decisions unless those decisions are critical, and need the product owner's nod. Otherwise, the proxy product owner would be considered overhead, since he has to refer to the actual product owner for every decision, which impedes the team's velocity. 2. The proxy product owner is only a "proxy" and never a substitute for the actual product owner. The team should at no point be completely disconnected from the product owner, since this can result in reduced accountability at the product owner's end. Though it is true that collocation is best for adopting agile, distributed teams should not be demotivated due to this fact and refrain from adopting agile. Teams should identify the scenarios that could hamper their agility in a distributed manner, and work out strategies to handle them in the best possible manner.

Incremental Approach

The incremental approach to software development, is an approach where the entire set of requirements is broken down in smaller chunks. Each of these chunks is delivered in shorter time frames, as compared to waterfall approach, which is a big-bang way of delivering software. In the incremental approach, each chunk undergoes the entire SDLC process which is, Requirements, Design, Development, Testing, and Rework for the small chunks. The entire software is built and integrated chunk by chunk, leading to the entire application or product being delivered at the end of the project life cycle. The advantages of this approach are: •The team gets to work on small chunk and get feedback on a regular basis. This mitigates the risk of failure at the end of the project to some extent. • •There is no surprise at the end of the project. • After delivering each chunk, the team has an opportunity to reflect upon the quality of the deliverable as well as the process used to deliverthe same, thus allowing the team to make any course corrections if needed.

Strategies for Handling Distributed Agile - Strategy 3

Use a lot of engineering tools to get the health of the code. Continuous integration (CI) tools help bridge this gap, by providing build automation as well as continuous tracking of project quality. CI Dashboard lists the various parameters that can be automated, and tracked using a CI server. Build stability is particularly critical, since an entire day might be lost for Team A in Country A, if Team B in Country B went home, without realizing that they checked in a piece of code that had broken the build.

Daily Scrum

•Daily Scrum meeting is time boxed to 15 minutes regardless of the number of team members •Hold Daily Scrum - same time, same place, every workday •Scrum Master to start the meeting at the appointed time, regardless of who is present •Each team member responds to three questions only: -What I have done since last meeting regarding this project -What will I do before next scrum meeting -What impedes me from performing my work effectively •Team gives status to each other and NOT to Scrum Master (They do not have to look at Scrum Master while responding to above three questions)

Characteristics of a Scrum team

•Have focused goals that are aligned with a company's strategy. •Use truth and transparency to establish trust in your teams. •With trust and transparency in place, peer accountability will evolve. •Constantly revisit and revise your processes to improve quality, quantity, and transparency.• •Empower teams to self-manage, giving them the means and authority to remove discovered obstacles.

Sprint Retrospection

•It's an opportunity for the team to discuss what's working and what's not working, and agree on changes to try.

Prioritization of PB

•Items in the Product Backlog are maintained and prioritized by the Product Owner •High Priority stories are at the top of the PB •Stories at the top are described in full detail •Detailing of stories are done for up to two future sprints •Stories down the line may be defined in less details •Stories at the end may only be statements of wish list

What is a Product Backlog

•Product Backlog contains the requirements for the system •The Product Owner is responsible for the Product Backlog •Product Backlog is not frozen but evolves with time •Management constantly changes it to identify what the product needs to be appropriate, competitive, and useful •User Stories are a good approach to write a Product Backlog Items •No one should be working on anything that is not on a Product Backlog.

Describe Product Owner PO

•Product Owner is responsible for prioritizing the product backlog in such a way that it maximizes the ROI for the organization •Refines and reprioritize the product backlog as per the needs from sprint to sprint •Participates in sprint planning and sprint review meetings and provides support to the team as required •Product Owner is responsible for participating in the estimation meeting to provide answers and clarifications for the stories •PO is not going to estimate, developers will estimate •Final decision maker on Product Backlog

Scrum Master

•Scrum Master helps the team in removing the obstacles and impediments to the progress of the project •Protects the team from outside disruption and threats •Teaches Scrum to the team, product owner and company (management) •Ensures that standard practices of scrum are followed •Communicates with Product owner •Facilitates Daily scrum meetings •Keep information about the team's progress up-to-date and visible to all parties.

What is Scrum

•Scrum is an agile process which is used for managing complex projects; where it is difficult to predict everything that will occur •It offers a framework and set of practices that keep everything visible •Keep the Art of possible in mind. Focus on what can be done rather than be frustrated by what can't be done •Scrum is not a very prescriptive process; it doesn't describe what to do in every circumstance

Team Building and Culture Sharing

•Stable team - minimum resource shuffling (unless performance issue, team forming stage) •Don't start unless at least 80% of the team is on board •Continuous Integration and Build is configured with key engineering metrics in all applicable/supported technologies. •Get the whole team onshore for minimum 6 weeks •After stabilisation, more than 50% of your team should be offshore •Ideal team size is 6 - 10 people •You do need minimum 20% of vendor staff onshore (100% offshore will not work) •Have the right onshore vendor staff •Onshore offshore rotation recommended, but can't be too frequent

Scrum roles

•The Product Owner -The person responsible for managing the Product Backlog to maximize the value of the project. The Product owner represents all stakeholders in the project. •The Scrum Master -The person responsible for the scrum process, its correct implementation, and the maximization of its benefits -Provides Leadership, Guidance, and Coaching to the team -Heads the Scrum project •The Team -A cross-functional group of people that is responsible for managing itself to develop software every sprint

Difference between Project Manager Vs. SM

•The Scrum Master is NOT the boss of the team •The Scrum Master does not assign tasks to the team •The Scrum Master does not make decisions for the team •The Scrum Master is not responsible for the team getting their work done on time •The team is responsible for the above mentioned activities.

What consists of a Scrum team?

•The Team -7 people, + or - 2 -Cross-functional •Developers, Testers, UI Designers, BA, technical writers, etc. -Self Organizing and Self Managing •Selects work for each sprint •Everyone commits to ALL TASKS necessary during the sprint •Teams have a velocity •Devises its own solutions to its problems

Sprint Review

•The team demos what they've built during the Sprint •This is not a "presentation" the team gives - there are no PowerPoints •Show what's been built (from environment nearest to QA env.) and get feedback •Product owner, team members, stakeholders and anyone else interested can show up for this review meet

Agile Testing

•Work with Customers, Business, Developers and BAs to define acceptance criteria. •Pair with developers and testers. •Automate whatever you can. (xUnit test suites, Web automation...) -Can avoid manual regression tests. -Creating mock-ups to test end-to-end testing scenarios. •Metrics on bugs surfaced.....but remember -Trailing indicators don't help team much. ( Bugs that escaped into UAT) -Leading indicators do help. (Bugs that escaped just an iteration).