agileisbest - Tumblr blog

[agileisbest]

Misconceptions about the Scrum Framework

“We are uncovering better ways of developing software by doing it and helping others do it.” This is how the Agile Manifesto starts. In simple words, the way people have learnt better ways of implementing Agile is by doing it and trying out things. As such practitioners have tried out multiple things and some of those have worked and some didn’t.  However, with time, a few misconceptions started getting associated with Scrum. We will look at some of the most common ones.

a)Documentation – There is this belief in certain quarters that there is no documentation in Scrum. Obviously, not correct. Compared to traditional project management, there is less documentation in Scrum Documentation in Scrum is as per the requirement of the project and stakeholders and is kept to a minimum.

b)Planning –This is another misconception where people believe that there is no planning in Scrum. The reality is that unlike traditional project Management which involves a lot of upfront planning, Scrum believes in iterative planning because remember scope and priorities keep on changing in Scrum. As such there is no use planning for everything at the beginning of the project.

c)Only meant for collocated teams –Although it is true that the principles behind Agile manifesto state that, “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”, still with teams working from all around the world, it is not possible to always have collocated teams. With globalization, you have companies with offices around the world and teams working together. Even with distributed teams, you could still have face-to-face conversations with the help of web conferencing tools. These are as good as being in the same room.

d)Only meant for Software Development – Since the Agile Manifesto was meant for Software Development and it started with Software Development, there is this misconception that Scrum cannot be applied in any other industry. That is actually not the case. With time Scrum framework also evolved and is currently being used in almost every industry. Scrum is best suited for projects where the domain is exploratory/unpredictable and a lot of change is expected.

e)Only meant for Small projects: Since Scrum recommends a team size of 6-10 people with some research showing the productivity of Scrum teams going down with anything more than 6 people in a team, it is erroneously believed that Scrum is meant only for small projects. It is true that Scrum recommends small teams but one Scrum project could have multiple Scrum teams. As such, you could easily scale up and deliver bigger projects. The 3rd edition of Scrum Body of Knowledge (SBOK™Guide) has two additional chapters detailing Scaling Scrum for Large projects and Scaling Scrum for Enterprise.

These were some of the most common misconceptions about Scrum. Do let us know if you found the article useful.  If you liked this article, do join our Linkedin Group for more such articles.

[agileisbest]

How is Quality related to Scope and Business Value?

In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. To ensure that a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements. The Prioritized Product Backlog is simply never complete until the closure or termination of the project. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements.

The fact that Scrum, through repetitive testing, requires work to be Done in an incremental fashion through Sprints rather than waiting until the end to produce deliverables results in errors being fixed right away, rather than postponed. Moreover, important quality-related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team—this ensures that quality is inherent in any Done deliverable created as part of a Sprint. Thus, continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and stakeholders (including customers and users) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Quality and Scope

Scope and quality requirements for a project are determined by taking into consideration various factors such as the following:

The business need the project will fulfill

The capability and willingness of the organization to meet the identified business need

The current and future needs of the target audience

Scope of the project is the sum total of all the product increments and the work required for developing the final product. Quality is the ability of the deliverables to meet the quality requirements for the product and satisfy customer needs. In Scrum, the scope and quality of the project are captured in the Prioritized Product Backlog and the scope for each Sprint is determined by refining the large Prioritized Product Backlog Items (PBIs) into a set of small but detailed User Stories that can be planned, developed, and verified within a Sprint.

The Prioritized Product Backlog is continuously groomed by the Product Owner. The Product Owner ensures that any User Stories that the Scrum Team is expected to do in a Sprint are refined prior to the start of the Sprint. In general, the most valuable requirements in solving the customers’ problems or meeting their needs are prioritized as high and the remaining are given a lower priority. Less important User Stories are developed in subsequent Sprints or can be left out altogether according to the customer’s requirements. During Sprint execution, the Product Owner, customer, and the Scrum Team can discuss the list of features of the product to comply with the changing needs of the customers.

Quality and Business Value

Quality and business value are closely linked. Therefore, it is critical to understand the quality and scope of a project in order to correctly map the outcomes and benefits the project and its product must achieve in order to deliver business value. To determine the business value of a product, it is important to understand the business need that drives the requirements of the product. Thus, business need determines the product required, and the product, in turn provide the expected business value.

Quality is a complex variable. An increase in scope without increasing time or resources tends to reduce quality. Similarly, a reduction in time or resources without decreasing scope also generally results in a decrease in quality. Scrum believes in maintaining a ʺsustainable paceʺ of work, which helps improve quality over a period of time.

The Scrum Guidance Body may define minimum quality requirements and standards required for all projects in the organization. The standards must be adhered to by all Scrum Teams in the company.

[agileisbest]

Analyze Your Social Media Competitors

One of the simplest and most effective ways to begin developing a social media plan for a product, brand or company is to assess the social media activities that competitors are engaging in. By analyzing competitors’ social media activities, realistic benchmarks for the company’s social media plan can be set, based on what others in the industry are experiencing in terms of reach and engagement growth. This strategy enables the team to lay the framework for a successful social media strategy that is based on the successes of other similar companies in the same space.

A company identifies its competitors as a result of the Identify Competition process in the SMstudy book on Marketing Strategy. After identifying its competitors, the first step in analyzing competitors’ social media activity is to identify their voice in social media websites—whether the competitor is portraying itself directly as the brand or whether individuals from the brand are promoting the product.

The next step is to identify the level and scale of engagement of competitors with their audience. Questions like “How many followers does a company have on LinkedIn?”, “What is the ratio of followers to following on Twitter?”, and “How many Likes does the company have on its Facebook page?” are all questions that can be easily researched and answered.

It is also important to know how often competitors engage in specific activities that indicate their focus on various social media elements. Questions like “How many Facebook posts do they write each month?” and “How many tweets to they write each day?” need to be answered to gauge their focus. Some brands may have an extremely high frequency of activities but their level of engagement in an activity may be very small. Others might focus more on quality content, and participate in less frequent activities but may see an equal or higher level of engagement. For example, if a competitor makes thirty Facebook posts but each post is seen by just twenty people, out of whom three “like” it and two share it, this is not a good strategy and doing something similar is not likely to yield better results with the same target audience.

Insights into preferences for different types of content can also be discovered by analyzing competitors’ social media activity. Companies can observe whether competitors are posting texts, links, videos, photos, polls, questions, trivia, or something completely different, and can see the types of posts that engage the most number of customers.

[agileisbest]

How is Quality related to Scope and Business Value?

In Scrum, quality is defined as the ability of the completed product or deliverables to meet the Acceptance Criteria and achieve the business value expected by the customer. To ensure that a project meets quality requirements, Scrum adopts an approach of continuous improvement whereby the team learns from experience and stakeholder engagement to constantly keep the Prioritized Product Backlog updated with any changes in requirements. The Prioritized Product Backlog is simply never complete until the closure or termination of the project. Any changes to the requirements reflect changes in the internal and external business environment and allow the team to continually work and adapt to achieve those requirements.

The fact that Scrum, through repetitive testing, requires work to be Done in an incremental fashion through Sprints rather than waiting until the end to produce deliverables results in errors being fixed right away, rather than postponed. Moreover, important quality-related tasks (e.g., development, testing, and documentation) are completed as part of the same Sprint by the same team—this ensures that quality is inherent in any Done deliverable created as part of a Sprint. Thus, continuous improvement with repetitive testing optimizes the probability of achieving the expected quality levels in a Scrum project. Constant discussions between the Scrum Core Team and stakeholders (including customers and users) with actual increments of the product being delivered at the end of every Sprint, ensures that the gap between customer expectations from the project and actual deliverables produced is constantly reduced.

Quality and Scope

Scope and quality requirements for a project are determined by taking into consideration various factors such as the following:

The business need the project will fulfill

The capability and willingness of the organization to meet the identified business need

The current and future needs of the target audience

Scope of the project is the sum total of all the product increments and the work required for developing the final product. Quality is the ability of the deliverables to meet the quality requirements for the product and satisfy customer needs. In Scrum, the scope and quality of the project are captured in the Prioritized Product Backlog and the scope for each Sprint is determined by refining the large Prioritized Product Backlog Items (PBIs) into a set of small but detailed User Stories that can be planned, developed, and verified within a Sprint.

The Prioritized Product Backlog is continuously groomed by the Product Owner. The Product Owner ensures that any User Stories that the Scrum Team is expected to do in a Sprint are refined prior to the start of the Sprint. In general, the most valuable requirements in solving the customers’ problems or meeting their needs are prioritized as high and the remaining are given a lower priority. Less important User Stories are developed in subsequent Sprints or can be left out altogether according to the customer’s requirements. During Sprint execution, the Product Owner, customer, and the Scrum Team can discuss the list of features of the product to comply with the changing needs of the customers.

Quality and Business Value

Quality and business value are closely linked. Therefore, it is critical to understand the quality and scope of a project in order to correctly map the outcomes and benefits the project and its product must achieve in order to deliver business value. To determine the business value of a product, it is important to understand the business need that drives the requirements of the product. Thus, business need determines the product required, and the product, in turn provide the expected business value.

Quality is a complex variable. An increase in scope without increasing time or resources tends to reduce quality. Similarly, a reduction in time or resources without decreasing scope also generally results in a decrease in quality. Scrum believes in maintaining a ʺsustainable paceʺ of work, which helps improve quality over a period of time.

The Scrum Guidance Body may define minimum quality requirements and standards required for all projects in the organization. The standards must be adhered to by all Scrum Teams in the company.

[agileisbest]

Why Empirical Process Control is Important in SCRUM?

In today’s rapidly changing market trends, the customer may imagine an ‘apple’ and the finished product made by the project team may be an ‘orange’. This though is not the main problem. If the customer is aware of what’s cooking from the start he can steer the team to the ‘apple’ side. But in actuality the customer finds out about the ‘orange’ only too late. In other words if inputs and processes are in control and are reliable, we can get reliable outputs (which are generally the case with Waterfall model). The problem arises when inputs and processes cannot be controlled rigidly which generally means that the outputs would be unreliable (the Agile/Scrum scenario). In such circumstances we need to look beyond the waterfall model and focus on Empirical Process Control which simply means you need to look at the outputs more frequently and if it is not as per your liking you go back to inputs and processes and tweak it accordingly.

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum we have a Project Vision Statement which can be viewed by all stakeholders and the Scrum Team; an open Product Backlog with prioritized User Stories, both within and outside the Scrum Team; clearly visible Scrumboards, Burndown Charts, and other information radiators; Daily Standup Meetings conducted making sure everyone’s aware of everything; and Sprint Review Meetings in which the Scrum Team demonstrates the potentially shippable Deliverables.

The following figure summarizes the concept of transparency in Scrum

Inspection in Scrum is depicted through the use of a common Scrumboard; collection of feedback from the customer and other stakeholders; review and approval of the Deliverables by the Product Owner and the customer.

The following figure summarizes the concept of inspection in Scrum:

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. Risk identification is performed and iterated throughout the project. Improvements can also result in Change Requests, which are discussed and approved. The Scrum Guidance Body interacts with Scrum Team members during many processes to offer guidance and also provide expertise as required. During the Sprint Retrospective, agreed actionable improvements are determined.

The following figure summarizes the concept of adaptation in Scrum:

These three pillars of Empirical Process Control ensure that the problems which projects face in the Traditional Waterfall way of doing things do not happen in Scrum Projects.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com Follow us on twitter - @SCRUMstudy_

[agileisbest]

How are decisions made in Scrum?

How are decisions made in Scrum?

In Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on the three main ideas of transparency, inspection, and adaptation.

Transparency

Transparency allows all facets of any Scrum process to be observed by anyone. This promotes an easy and transparent flow of information throughout the organization and creates an open work culture. In Scrum, transparency is depicted through the following:

• A Project Vision Statement which can be viewed by all stakeholders and the Scrum Team

• An open Prioritized Product Backlog with prioritized User Stories that can be viewed by everyone, both within and outside the Scrum Team

• A Release Planning Schedule which may be coordinated across multiple Scrum Teams

• Clear visibility into the team’s progress through the use of a Scrumboard, Burndown Chart, and other information radiators

• Daily Standup Meetings conducted during the Conduct Daily Standup process, in which all team members report what they have done the previous day, what they plan to do today, and any problems preventing them from completing their tasks in the current Sprint

• Sprint Review Meetings conducted during the Demonstrate and Validate Sprint process, in which the Scrum Team demonstrates the potentially shippable Sprint Deliverables to the Product Owner and Stakeholders

Inspection

Inspection in Scrum is depicted through the following:

• Use of a common Scrumboard and other information radiators which show the progress of the Scrum Team on completing the tasks in the current Sprint

• Collection of feedback from the customer and other stakeholders during the Develop Epic(s), Create Prioritized Product Backlog , and Conduct Release Planning processes

• Inspection and approval of the Deliverables by the Product Owner and the customer in the Demonstrate and Validate Sprint process.

Adaptation

Adaptation happens as the Scrum Core Team and Stakeholders learn through transparency and inspection and then adapt by making improvements in the work they are doing. Some examples of adaptation include:

• In Daily Standup Meetings, Scrum Team members openly discuss impediments to completing their tasks and seek help from other team members. More experienced members in the Scrum Team also mentor those with relatively less experience in knowledge of the project or technology.

• Risk identification is performed and iterated throughout the project. Identified risks become inputs to several Scrum processes including Create Prioritized Product Backlog, Groom Prioritized Product Backlog, and Demonstrate and Validate Sprint.

• Improvements can also result in Change Requests, which are discussed and approved during the Develop Epic(s), Create Prioritized Product Backlog, and Groom Prioritized Product Backlog processes.

• The Scrum Guidance Body interacts with Scrum Team members during the Create User Stories, Estimate Tasks, Create Deliverables, and Groom Prioritized Product Backlog processes to offer guidance and also provide expertise as required.

• In the Retrospect Sprint process, Agreed Actionable Improvements are determined based on the outputs from the Demonstrate and Validate Sprint process.

• In Retrospect Project Meeting, participants document lessons learned and perform reviews looking for opportunities to improve processes and address inefficiencies.

With other methods, like the traditional Waterfall model, considerable planning needs to be done in advance and the customer generally does not review product components until near the end of a phase, or the end of the entire project. This method often presents huge risks to the project’s success because it may have more potential for significantly impacting project delivery and customer acceptance. The customer’s interpretation and understanding of the finished product may be very different from what was actually understood and produced by the team, and this may not be known until very late in the project’s development.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com Follow us on twitter - @SCRUMstudy_

[agileisbest]

What is Agile methodology?

The term “agile” generally refers to being able to move or respond quickly and easily; being nimble. In any kind of management discipline, agile as a quality should therefore be a good thing to aim for. Agile project management specifically, involves being adaptive during the creation of a product, service, or other result.

A number of Agile methodologies originated and gained traction in the 1990’s and the early 2000’s. Here are the various popular Agile methods being used.

Lean Kanban: Lean concept optimizes an organization’s system to produce valuable results based on its resources, needs, and alternatives while reducing waste. Kanban literally means a “signboard” or “billboard” and it espouses the use of visual aids to assist and track production.

Extreme Programming (XP): Originated in Chrysler Corporation, gained traction in the 1990′s. XP makes it possible to keep the cost of changing software from rising radically with time. The key attributes of XP include incremental development, flexible scheduling, automated test codes, verbal communication, ever-evolving design, close collaboration, and tying in the long- and short-term drives of all those involved.

Crystal Methods: Introduced by Alistair Cockburn in the early 1990s, Crystal methods have four roles—executive sponsor, lead designer, developers, and experienced users. Crystal Methods recommend various strategies and techniques to achieve agility.

Dynamic Systems Development Methods (DSMD): This framework was initially published in 1995 and is administered by the DSDM Consortium. DSDM sets quality and effort in terms of cost and time at the outset and adjusts the project deliverables to meet set criteria by prioritizing the deliverables into “Must have,” “Should have,” “Could have,” and “Won’t have” categories

Feature Driven Development (FDD): Introduced by Jeff De Luca in 1997 and operates on the principle of completing a project by breaking it down into small, client-valued functions that can be delivered in less than two weeks’ time. FDD has two core principles—software development is a human activity and software development is a client-valued functionality.

Test Driven Development (TDD): Also known as Test-First Development, and was introduced by Kent Beck, one of the creators of Extreme Programming (XP). It is a software development method that involves writing automated test code first and developing the least amount of code necessary to pass that test later.

Adaptive Software Development (ASD): This method grew out of the rapid application development work by Jim Highsmith and Sam Bayer. The highlights of ASD are constant adaptation of processes to the work at hand, provision of solutions to problems surfacing in large projects, and iterative, incremental development with continuous prototyping.

Agile Unified Process (AUP): Evolved from IBM’s Rational Unified Process and developed by Scott Ambler, AUP combines industry-tried-and-tested Agile techniques such as Test Driven Development (TDD), Agile Modeling, agile change management, and database refactoring, to deliver a working product of the best quality.

Domain-Driven Design (DDD): This approach was meant for handling complex designs with implementation linked to an evolving model. It was conceptualized by Eric Evans in 2004 and revolves around the design of a core domain.

All these methods of Agile differ from each other in a variety of aspects but their commonality stems from their adherence to The Agile Manifesto.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com Follow us on twitter - @SCRUMstudy_

[agileisbest]

Release Planning Sessions in SCRUM

Release Planning Sessions are conducted to develop a Release Plan. The plan defines when various sets of usable functionality or products will be delivered to the customer. In Scrum, the major objective of a Release Planning Meeting is to enable the Scrum Team to have an overview of the releases and delivery schedule for the product they are developing so that they can align with the expectations of the Product Owner and relevant stakeholders (primarily the project sponsor).

Many organizations have a strategy regarding release of products. Some organizations prefer continuous deployment, where there is a release after creation of specified usable functionality. Other organizations prefer phased deployment, where releases are made at predefined intervals. Depending on the organization’s strategy, Release Planning Sessions in projects may be driven by functionality, in which the objective is to deliver a release once a predetermined set of functionality has been developed; or the planning may be driven by date, in which the release happens on a predefined date.

Since Scrum framework promotes information based, iterative decision making over the detailed upfront planning practiced in traditional waterfall style project management, Release Planning Sessions need not produce a detailed Release Plan for the entire project. The Release Plan can be updated continually as relevant information is available.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com Follow us on twitter - @SCRUMstudy_

[agileisbest]

All About Prioritized Program Backlog

The Prioritized Program Backlog plays a very similar role at the program level as the Prioritized Product Backlog does on project level. It identifies the requirements for the program and their priorities.

The items in the Prioritized Portfolio Backlog provide inputs to the various Prioritized Program Backlogs and, through Prioritized Program Backlogs, to Prioritized Product Backlogs of individual projects. As described for Prioritized Program Backlogs only minimal, if any, refinement of User Stories is done at this level, because the refinement is done in the projects and their specific Prioritized Product Backlogs.

There are a few differences, though:

The creation of the respective deliverables and their acceptance is done in the projects of the program. The done or acceptance criteria for each Product Backlog Item / User story may be defined on the program level.  Projects have to adhere to them but can add their own criteria.

The length of a Sprint is project specific and, generally, varies from project to project in a program. In addition, the velocity of different teams is, normally, not the same. Therefore, it is not necessary to have very granular User Stories at the program level. The refinement of User Stories at the program level goes only far enough to ensure that the respective story is clearly understood and tangible acceptance criteria for the program can be defined.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com Follow us on twitter - @SCRUMstudy_

[agileisbest]

What is Servant Leadership?

The preferred leadership style for Scrum projects is Servant Leadership. This term was first described by Robert K. Greenleaf in an essay entitled The Servant as Leader. Below is an excerpt where he explains the concept:

The servant-leader is servant first…It begins with the natural feeling that one wants to serve, to serve first. Then conscious choice brings one to aspire to lead. That person is sharply different from one who is leader first, perhaps because of the need to assuage an unusual power drive or to acquire material possessions…The leader-first and the servant-first are two extreme types. Between them there are shadings and blends that are part of the infinite variety of human nature….

The difference manifests itself in the care taken by the servant-first to make sure that other people’s highest priority needs are being served. The best test, and difficult to administer, is: Do those served grow as persons? Do they, while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants? And, what is the effect on the least privileged in society? Will they benefit or at least not be further deprived? (Greenleaf 1970, 6)

Elaborating on the writings of Greenleaf, Larry Spears identifies ten traits that every effective servant-leader should possess:

Listening—Servant leaders are expected to listen intently and receptively to what is being said, or not said. They are able to get in touch with their inner voice to understand and reflect on their own feelings.

Empathy—Good servant leaders accept and recognize individuals for their special and unique skills and abilities. They assume workers have good intentions and accept them as individuals, even when there are behavioral or performance issues.

Healing—The motivation and potential to heal oneself and one’s relationship with others is a strong trait of servant leaders. Servant leaders recognize and take the opportunity to help their colleagues who are experiencing emotional pain.

Awareness—Awareness and particularly self-awareness is a trait of servant leaders. This allows them to better understand and integrate issues such as those related to ethics, power, and values.

Persuasion—Servant leaders use persuasion, rather than their positional authority to gain group consensus and make decisions. Rather than forcing compliance and coercion as is typical in some authoritarian management styles, servant leaders practice persuasion.

Conceptualization—The ability to view and analyze problems (in an organization) from a broader conceptual and visionary perspective, rather than focusing on merely the immediate short-term goals, is a unique skill of good servant leaders.

Foresight—Their intuitive minds allow servant leaders to use and apply past lessons and present realities to foresee the outcome of current situations and decisions.

Stewardship—Stewardship demands a commitment to serving others. Servant leaders prefer persuasion over control to ensure that they gain the trust of others in the organization.

Commitment to the growth of others—Servant leaders have a deep commitment to the growth of people within their organization. They take on the responsibility of nurturing the personal, professional, and spiritual growth of others (e.g., providing access to resources for personal and professional development, encouraging workers to participate in decision making).

Building community—Servant leaders are interested in building communities within a working environment, particularly given the shift in societies away from smaller communities to large institutions shaping and controlling human lives.

Scrum believes that all leaders of Scrum projects (including the Scrum Master and Product Owner) should be servant-leaders who have the above traits.

For more informative articles on Scrum and Agile, please visit www.scrumstudy.com Follow us on twitter - @SCRUMstudy_

[agileisbest]

Various Dimensions of Team Specialization

In a large SCRUM project, Team Specialization may be required. There are three dimensions of Team Specialization.

The first dimension is the need for accomplishing specific tasks. For example, one Specialized Team might be an integration team that has specialized knowledge of continuous integration.. That knowledge could be especially important when and if there is a Release Readiness Sprint.

The second dimension is the need for special skills of single team members. Theoretically, all Scrum Team members are generalists and specialists in that they have knowledge of various fields and are experts in at least one. However, this might not be the case in a large project. Members of Specialized Teams may need to possess specific skills—such as special domain knowledge like security—which may not be available with all large project teams for which it is needed. For a large project, it would be extremely costly to train everybody in all domains. These experts with special skills and knowledge may work as temporary team members in different teams, and sometimes it may be necessary to hire them from external sources. Adding a new team member will impact the team velocity.

The third dimension is that there may be limitations in team flexibility. As mentioned above, in a large project it would be extremely costly to train everybody in all domains. That means that every team will have one or more domains they are good at, a few domains they can and will work on with some inputs and training, and other domains they cannot work on. When it comes to Sprint planning, every team will have a subset of User Stories that are naturally theirs, some that they can work on, and some they can’t work on because they don’t have the knowledge/skills.

The project will have to take the risk that they may not be able to get all the top-priority User Stories done in a Sprint due to these limitations and may need to develop some User Stores of lower priority while waiting for the availability of team members with specialized skills.

To know more, please visit www.SCRUMstudy.com

[agileisbest]

All about Time-boxing in SCRUM

Scrum treats time as one of the most important constraints in managing a project. To address the constraint of time, Scrum introduces a concept called ‘Time-boxing’ which proposes fixing a certain amount of time for each process and activity in a Scrum project. This ensures that Scrum Team members do not take up too much or too little work for a particular period of time and do not expend their time and energy on work for which they have little clarity.

Some of the advantages of Time-boxing are as follows:

Efficient development process

Less overheads

High velocity for teams

Time-boxing can be utilized in many Scrum processes, for example, in the Conduct Daily Standup process, the duration of the Daily Standup Meeting is Time-boxed. At times, Time-boxing may be used to avoid excessive improvement of an item (i.e., gold-plating).

Time-boxing is a critical practice in Scrum and should be applied with care. Arbitrary Time-boxing can lead to de-motivation of the team and may have the consequence of creating an apprehensive environment, so it should be used appropriately.

To know more, please visit www.SCRUMstudy.com

[agileisbest]

Best Methodologies in SCRUM:

SCRUM is a considered to be set of guidelines that oversee the growth process of a product, from its design phase to its completion. Scrum is one among several agile methods that practices an iterative and incremental procedure in the course of development of a project.

As per SCRUM, a project is divided into what is known as sprint or iteration. Each sprint is timeboxed usually between 2 weeks to a maximum of a month. After a sprint, the team meets and reviews the progress of the project. Here team tries to identify the problems encountered during the sprint and formulates the objectives for the next sprint. In the course of every sprint the team analyses and works on user requirements (also known as user stories) in order to confirm that after every sprint, user needs are taken into consideration and are being satisfied.

One important aspect of SCRUM to note is that it depends on self-organisation. Self-organisation helps the team to achieve the goal by following the most resourceful path with the available resources, knowledge, skills and abilities. This allows team to experiment with different approaches, to analyse and to learn from their failures and to improve.

In a self-organised team, there is no one elected as team leader. The teams work cross-functionally and the team is responsible as a whole in decision making.

SCRUM has been successfully engaged in many companies in many different fields and has achieved outstanding results.

Listed below are few of methodologies used in SCRUM:

Burn down charts : This chart is used to track the progress achieved during the course of the project against the release plan using a release burndown chart. This chart is updated at the end of each sprint by the ScrumMaster

  Stand up meeting: The team meets every day for a swift status update. The meeting is usually time boxed for 15 minutes.

In this meeting everyone tries to answer the three questions

                        What did you do yesterday

                        What are you going to do today? 

                         What are the challenges you are facing?

  Product backlog : It is prioritized list of all the desired changes to the product being developed which is done by the Product Owner.

This is used to record requests for modifying a product.  This is used to add new features, changing old features, removing features and fixing issues.

[agileisbest]

SCRUM IN THE RIGHT DIRECTION

Value to your career.

Meeting a client’s need is very important for generating the revenue with the decreased cost, that’s the main aim for the companies, leading to the conflicts among the company employees. Factors involved in order to prioritize the requests of the clients are such as –

Developing what kind of features? 

Any time period for the changes to be done? 

How and what should be given the priority?

  A structured workflow is always useful in such situations to resolve it. There are more valuables in the project than such small challenges which can be reduced by working with Scrum Methodology i.e. a company with better revenues can be achieved.

Why Agile in the first place

It’s becoming common to work in the Agile Methods of developments and the most common method of Agile is Scrum because of it resulting features.

Out of several reasons on why should we even consider applying this method of Agile in respect to getting better business are listed below-

You want to gear up your project or you are facing issues finishing the project on time.

Limited resources so you looking at the ways to get good development with the resources available.

You want to limit the cost occurred in development. 

You are finding a way to give more value to the process so as to get better value to the business.

Is Using SCRUM on a daily basis, beneficial

Someone said it right, “Post-it looks good on whiteboard when you have one project but looks equally messy when you have multiple”

Other reason why you need Daily-Scrum can be;

You don’t have much of knowledge of the project progress.

You want to give better value to the development process in different locations.

You want to get deep into the value and knowledge of the project.

[agileisbest]

Scrum Shortcomings

Scrum is not only a specific set of practices, but also it is a structure that provides clarity, and a technology that allows adjustability to research and conform. It works by making clear the malfunctions and obstacles clear. These malfunctions and hindrances directly impact the Product Owner and the Team’s effectiveness. Scrum helps them to be addressed. For instance, it might be possible that the Product Owner is unaware of the market and its different traits and the estimated business value. Also, it’s possible that the team working on the sprint is not really skilful as per the project requirement.

The Scrum structure will instantly reveal these shortcomings. It does not fix the issues of advancement; it makes them completely visible, and offers a structure for people to find out ways to fix issues in short cycles and with small enhancement experiments.

At time it happens that the team fails to deliver what they have targeted to achieve in the first Sprint due to improper work analysis and evaluation skills. This looks like a failure for the whole team. However in fact, this understanding is the primary step towards becoming more realistic and thoughtful about its forecasts. This Scrum pattern helps to make visible the shortcomings and makes the Team to work upon it. This basic technique provides the most relevant benefits.

The team members always find it challenging whenever any changes in the Scrum process is required. For instance,  those teams who have trouble performing might work upon to make the Sprint duration extendable, so that they always have enough time – and in this process they also ensure that  they never have to learn time management. In such ways, without the help and participation of an experienced ScrumMaster, organizations can change Scrum into just a reflection of their own flaws and shortcomings, and demean the real favour that Scrum offers: Making transparent the good and the bad, and giving the organization the choice of moulding accordingly.

One more common mistake is to just think that a method is dropped just because Scrum does not really need it. For instance, Scrum does not advise the Product Owner to make a long term approach for his or her product; nor does it require engineers to look for expert advice to sort out complicated technical issues. Scrum leaves it to the team members completely to work upon the right decision.

The good thing about Scrum is that even if the first Sprint is usually very challenging to the Team, the benefits the team derive later are immense in terms of making the methodology and the process better.

[agileisbest]

Who should use Scrum and why?

Any organization that has a complex project can use Scrum to their benefits as it helps in prioritizing large to-do lists into manageable tasks and channelizes better teamwork, communication and better, faster and improved results.

Scrum has been streamlined into most of the software development companies and most of the teams working in this field have realized the importance of Scrum and started using it to the fullest. In fact Scrum is used by 66% of the companies in this particular field.

Why use Scrum?

With Scrum you wield the power to transform the management of projects across all the industries, all businesses and also life in general. With Scrum, we tend to become more Agile and more receptive to changes in the industry and by staying focussed, collaborative and communicative we can easily accomplish what needs to be done more successfully.

Scrum is proven concept and is the most successful in the Agile frameworks and has been tried and tested in various projects and teams. Companies and Universities have been using Scrum to deliver value based projects to their clients on time; military has been using Scrum to successfully deploy troops and vessels into the battlefield so basically Scrum finds it applications in both civilian and military lifestyle.

Why some companies fail at Scrum?

The reasons why some companies fail at Scrum is that they don’t really adopt Scrum the way it should be adopted. They tend to make Scrum work in their old way of working which they have been doing so far. One cannot become Agile by sticking to month long projects and keep sticking to the old methodologies. Scrum is about being Agile and always be focussed on the changing customer requirements and adapting to them.

To be successful in Agile companies must allow their team to be more independent and have more belief and trust in them. They should be allowed to try new methods of planning and budgeting and also be allowed to self-manage. Also the Scrum Master must remember the purpose of his role very well. The role of a Scrum Master is to manage the team and take care of the impediments which the team comes across and he needs to understand that his role is that of a facilitator and not of a Project Manager.

In a nutshell, Scrum generally fails because companies aren’t comfortable changing to allow it to work.

[agileisbest]

Characteristics of an organization for easier Agile adoption

“Embrace the change” is the buzzword everyone is shouting at the top of their voice in every conference and seminars. Agile process to succeed in your value delivery’ is also very much prevalent across discussions. Once the top management finalizes Agile transition, the entire approach changes dramatically. Hence, not all organizations respond to this change positively. In such scenarios, it will be better to stick to the traditional waterfall model or opt for a customized hybrid model.

Below are some of the desired characteristics of a company for a smoother Agile transition:

Urgency to deliver: Agile is best suited for teams and customers who know their priorities according to market dynamics. When all the features are of same priority, Agile will not be very effective. But when features have to be prioritized according to maximizing value for the customers, with an eye on the criticality and time constraint, Agile is best suited to deliver the highest value.

  Volatile Requirements: Unlike waterfall model, wherein requirements are locked before design and development begins, Agile is all about expecting changes and embracing it. This thought process is very practical in nature because market dynamics and competition force your customers to be light footed and nimble. Also, there might be internal conflicts among different stakeholders about which feature should be given higher priority, which can also lead to change in requirements.

  Customer Availability: Customers don’t have to be available at all the times, but there are several instances wherein their presence is mandatory. Customers have to provide inputs at the right instances; else the entire effort becomes futile. Also, once customers involve themselves more and more with the projects, they will start to appreciate the effort that is being put in by the delivery team, and they will become more supportive and considerate.

  Consistent resources: In traditional method, functionality silos exist. But in Agile, “one team” culture is followed. The primary reason is that Agile teams have a learning curve, and they eventually get better with experience and time. Also, frequently changing resources in an Agile project will mean more effort from the new resource to understand the processes. So, highly motivated individuals are preferred who want to be part of the Agile transition, and as much as practically possible, teams should not be tinkered with.  

  So, in case an organization scores high in the above mentioned characteristics, it can be assumed that transition to Agile process will be smooth, rewarding and satisfying.