Skip to main content

Posts

Showing posts with the label Agile

What are Important Roles in Scrum-Agile Teams?

The Primary Team roles in scrum are named as • Product Owner  • Scrum Master • Development Team Scrum Master, Product Owner, and Team are considered as people who are committed to the project while customers and executive management are considered as involved but not committed to the project. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.  Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity. Scrum Teams deliver products iteratively and incrementally, maximizing opportunities for feedback. Incremental deliveries of “Done” product ensure a potentially useful version of working product is always available. All the roles are based on the concept of “S...

What is Definition of Done?

Done Criteria are a set of rules that are applicable to all User Stories. A clear definition of done is critical because it removes ambiguity from requirements and helps the team adhere to mandatory quality norms. This clear definition is used to create the Done Criteria when a Prioritized Product Backlog is prepared. Definition of done is crucial to a highly functioning Scrum team. The following are characteristics that you should look for in your team’s definition of done. Verifying that your team’s DoD meets these criteria will ensure that you are delivering features that are truly done, not only in terms of functionality but in terms of quality as well. DoD is a checklist of valuable activities required to produce software. Definition of done is a simple list of activities (writing code, coding comments, unit testing, integration testing, release notes, design documents, etc.) that add verifiable/demonstrable value to the product. Focusing on value-added step...

Distributed Scrum Teams

Today businesses are shifting to emerging economies (such as India) due to reduced business operations cost and an easily available workforce. The businesses certainly are more virtual and distributed, with "distributed" as its key element. Thus the need for better managing such teams, using the right tools and processes, is becoming increasingly critical for any enterprise company. Here are some reasons for the shift and need for having distributed Agile teams: ·           Globally distributed teams reduce costs. ·           They can reach the market more quickly with a "follow the sun" model. ·           Distributed teams expand access to new markets. ·           Acquisitions as a result of consolidation results in companies working together to integrate their businesses. ·   ...

Five Phases of Agile Project

There are FIVE phases that an Agile project goes thru. The FIVE phases are ·         Envision ·         Speculate ·         Explore ·         Adapt ·         Close Envision Phase : – This phase is to determine the product vision and project scope, the project community, and how the team will work together. The term ‘envision’ is a clear departure from traditional phase names such as initiate and plan, which while subtle, is also significant. This is because when envisioning you inadvertently accept a level of mishap and are therefore ready to make any necessary adjustments, in contrast to a set plan which has more rigorous connotations. The envision phase covers the ‘Who? What? And how?’ Speculation Phase:  Unlike planning, speculating esta...

When Not To Use Agile

Over the years, Agile methodologies have taken the heat when they appear to have failed to deliver expected benefits to an organization. If our project fails, the tendency is that “we must blame the Agile process and our practices in some way for this”. Agile is not a magic stick to save a failing project and bring immediate results. It lets you uncover better ways of developing software by doing it and helping others do it. As with all development methods, the skill and experience of users determine the degree of success and/or abuse of such activity. So sometimes we obtain the agility by making up our own variation of this methodology. In this case, failure of this project should largely be incumbent upon us for deciding to sacrifice the practices we chose to ignore and the new ones we added.  Some are Agile while just for namesake, and following no methodology, just cherry-picking a couple of practices here and there, and picking the principles they like. ...