Microsoft has release its Framework Design Guidelines guidelines for designing libraries that extend, and interact with the .NET Framework. The goal is to help library designers ensure API consistency and ease of use by providing a unified programming model that is independent of the programming language used for development. They recommend you follow these design guidelines when developing classes and components that extend the .NET Framework because inconsistent library design adversely affects developer productivity and discourages adoption.
Being ‘Agile’ is the buzzword in IT these days. I will not be overstating it if I say that all industries are leveraging the benefits of Agile.
In complex projects, it is not possible to gather all the requirements upfront at once, due to extreme uncertainties. Therefore, we use Agile methodologies to divide user requirements into short independent requirements, each of which is called a ‘user story.’ These user stories are given to the team for implementation.
It is important that requirements in a user story are well understood and well documented. Moreover, you need to ensure that the team is complying with the delivery standards. To ensure that all the above aspects are fulfilled, the following standards processes have been devised:
1. Definition of Ready: What Does It Mean?
It means that a user story should be written correctly and explained to the team in detail. In a Sprint which lasts for 2-4 weeks, the requirements can’t be discussed for days/weeks. Hence, it is important to consider following points while a user story gets accepted by the team to be worked upon in the Sprint:
a. It should be well worded and explained to the team.
b. All open queries which the team has raised during grooming sessions must be closed/resolved.
c. All dependencies must be resolved.
d. It should follow INVEST criteria, i.e. Independent, Negotiable, Valuable, Estimable, Small, and Testable.
e. Each user story should be small enough to be completed within the Sprint.
2. Definition of Done: What Does It Mean?
It means that once the team has agreed to work on a user story, the following things should be considered as completion factors for each user story:
a. Code review is done and review comments have been incorporated.
b. Testing done in the specified environment and not on a development machine.
c. Automation test scripts in place.
d. All raised defects have been resolved and closed.
e. Tool (JIRA/Rally/RTC) being used by the team has been updated with the actual hours and correct status of the story and all the tasks.
f. Sign-off from PO.
See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies.
Agile Project Management is revered as one of the prominent methodologies introduced to practice modern day Project Management. It is also one of the recent and value-driven project management strategies has been widely applied to software development practices to deliver high priority and high-quality work. Therefore, it is best suited to relate software development processes to Agile project management methodologies for better understanding and enhanced leadership.
With the advancement in software development, requirements and technologies, traditional models like the Waterfall model are not robust enough to cater to the ever changing demands of clients. In order to address the agility of the requirements, the need was recognized to build a more flexible and robust alternative. As a result, Agile software development models were developed. Since the Agile development models are different from the traditional models, Agile project management is a specialized area in project management.
Leadership in Agile Project Management
In the traditional Waterfall model, the Project Manager is burdened with improvising and adapting the requirements of change and maintaining the project quality, scope, reporting, risks, etc. Whereas in Agile project management, these roles are divided among the entire team and it is not just the manager’s responsibility.
It is divided into following Agile leadership roles:
• The Product Manager: Sets project goals, adapts to the changing requirements, balances the scope versus schedule, acts on and sets the priorities for product features.
• The Scrum Master or Iteration Manager: Guides the team and removes the obstructions by prioritizing and monitoring their tasks.
• Team Members: Handle the assigned tasks, development, process reporting, and the product quality control.
It is very evident that the entire team is responsible for managing the affairs and unlike the Waterfall model, it is not just the project manager’s responsibility. The right person at the right place and division of labor ensures that things can progress at a faster rate and there is no time lapse in decision making.
With that said, many of you might be wondering who is supervising the Agile development projects.
The simple answer to this question is ‘not an individual but the entire team.’ The principles of the Agile Manifesto call for self-motivated and directed professionals to work on the projects as self-organizing teams. Team members handle the specified tasks as per their capabilities and project requirements, and the entire team is collectively responsible for the successful completion of the project. The Agile Manifesto believes in spreading the management tasks across the team, so as to empower all team members and spur productivity and innovation.
If you are responsible for the team working to attain a common objective, then I believe you are a Supervisor or Leader. In this blog, I’ll be discussing the ways to enhance the leadership capabilities of certain roles, especially for Project Managers and Scrum Masters.
Here are a couple of recommendations:
1. Maintain Focus and Perform Your Duties
2. Some people believe that Agile environment offers as little the Project Management as possible. With all due respect, I completely disagree with this statement. The Agile process is very fast paced and disciplined. To accommodate change and to stay on track, the Agile approach demands constant attention to the team, processes, and results. Easy to understand and implement Agile methodologies suggests a number of practices that assist us with the basics of software development and project management in the Agile model. But what’s essential and equally important is to alter the leadership style to reap the maximum number of benefits while adopting the Agile methodologies. Some novice Project Managers follow the ‘hands off’ approach, and because of this their team struggles through the initial maturity phases, and Agile appears to fail. It is essential for the success of the project that the team members find ways to interact, have good debates, and solve problems together. An ideal leader will encourage and facilitate these processes throughout the various project steps. As a Project Manager or Iteration Master, you should:
◦ Plan and improvise the activities.
◦ Conduct informal social events.
◦ Conduct team building activities.
◦ Conduct Retrospective sessions.
3. Understand Your Team Members
4. Understand your team and identify the outliers, if any. During Scrum sessions, if you find missing characteristics of hard work and self -discipline in an individual, then you should do whatever it takes to counsel those professionals as much as you can. Self-discipline can be measured by following characteristics:
◦ Accepting accountability.
◦ Engaging in debates and interactions.
◦ Willingness to work.
5. Make team members trust each other. How do you do that? You must trust them first! To operate effectively with your team members, you must facilitate knowledge sharing with the entire team. As a leader, you should be open to learning so as to build an amiable working environment and strong professional relationships.
6. Learn to Use Collective Wisdom
7. In an Agile project management, there are many questions that are to be answered and decisions to be made. Prioritizing the functionality, estimates of work, work allotment, requirements, etc. How do you decide on these factors? Are you making the decisions unilaterally? You are not supposed to do that and should learn to utilize the ‘Collective Wisdom’ effectively. It is expected that under the ideal conditions, a group will collectively make a better decision than one specialist. Ideal conditions for using Collective Wisdom effectively include:
◦ Member independence.
◦ The diversity of opinions.
◦ The accumulation of opinions.
In the end, there are many challenges that lie ahead for the Agile project leader. These leaders have to follow and innovate different leadership approaches on the Agile projects than they would on Waterfall or any traditional style projects. What leadership approach do you follow while managing an Agile project?
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
Opinions expressed by DZone contributors are their own.
See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies.
The first post was about scaling functions to working as collaborative Agile teams. See Defining “Scaling” Agile, Part 1: Creating Cross-Functional Teams. Now, let’s talk about moving to multiple teams working together, a program.
The good news is that you have a few cross-functional teams. They’ve been delivering as project teams. And, now you have a program, a collection of several projects with one business objective.
Programs come in a wide variety of shapes and sizes. Here are some kinds of programs:
• You might have just one feature team and need people from Marketing or Legal to release the product. You need to bring those people into the program somehow, so they can accomplish their deliverables so the organization can release the product.
• The project is larger than one or two feature teams. You may have several feature sets and need people from Marketing, or Legal, or Finance (or someone else) to be able to release the product.
• You might be managing the software program, and have several feature teams or programs within the larger program. You might have the Engine program, and the Admin and Diagnostics programs. Each feature set has several teams collaborating on the code in their feature set(s). And, you probably need people across the organization to finish the work for the product. Those are the people from Marketing, Legal, Finance, or others that I keep talking about.
Programs exist when you need a little structure to organize the feature teams and/or organize the deliverables across the organization. Agile programs especially don’t need too much structure. The key is to create something that helps the people collaborate and visualize the work they need to complete.
Here’s a way to think about scaling to a program:
Scale the collaboration across product development to release products.
Here’s how I think about scaling collaboration across product development:
• Each team thinks about how fast they can release their work to the rest of the program (BTW, fast isn’t useful unless the work is great).
• Each team manages its WIP (Work in Progress) so they aren’t bottlenecking themselves or anyone else.
• The POs work as a team so the feature teams always work on the most valuable work for the program. Sometimes, feature teams move from one feature set to another because that work is more valuable. If you’re worried about interdependencies, you might not have feature teams. Or, the POs aren’t working together. See Understand Your Project Interdependencies.
• Teams use the power of their small-world networks (and possibly Communities of Practice) to solve problems at the team level. Teams often don’t need help from anyone with “manager” or “master” in their titles.
Aside from trusting the teams to deliver and asking them to let you know if they can’t, I also suggest these ideas:
• Scale the visualization of the work. How do people see what other teams or people are doing? (I have plenty of images of kanban boards so you can see if any of those work for you).
• Keep the hierarchy as flat as possible so problems don’t have to go up a hierarchy, over and down, and then follow their path back before someone gets the answer they need.
• Consider a cadence of meetings that solve problems. These meetings are not standups. Standups might expose problems but they don’t solve them.
I recommend teams decide if they need to organize as small programs (such as above with the Engine, Admin, and Diagnostics programs). That allows a cadence of limited-participation program team meetings to solve problems the teams can’t solve.
In addition, measure at the program level. Sure, the teams need to measure their cycle time and velocity, whatever they choose. In addition, measure the features complete at the program level, program level WIP, and any other program measures that make sense to you (see Velocity is Not Acceleration for two of these charts).
Agile program management helps product development use Agile approaches to release products. Next up is how to scale Agile from product development to other parts of the organization.
Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies.
A Management Framework
Scrum is a management framework for incremental product development using one or more cross-functional, self-organizing teams of about seven people each.
It provides a structure of roles, meetings, rules, and artifacts. Teams are responsible for creating and adapting their processes within this framework.
Scrum uses fixed-length iterations, called Sprints, which are typically 1-2 weeks long (never more than 30 days). Scrum teams attempt to build a potentially shippable (properly tested) product increment every iteration.
An Alternative to Waterfall
Scrum’s incremental, iterative approach trades the traditional phases of “waterfall” development for the ability to develop a subset of high-value features first, incorporating feedback sooner.
Figure 1. Traditional “waterfall” development depends on a perfect understanding of the product requirements at the outset and minimal errors executing each phase.
The greatest potential benefit of Scrum is for complex work involving knowledge creation and collaboration, such as new product development. Scrum is usually associated with object-oriented software development. Its use has also spread to the development of products such as semiconductors, mortgages, and wheelchairs.
Doing Scrum, or Pretending to Do Scrum?
Scrum’s relentless reality checks expose dysfunctional constraints in individuals, teams, and organizations. Many people claiming to do Scrum modify the parts that require breaking through organizational impediments and end up robbing themselves of most of the benefits.
- Single person responsible for maximizing the return on investment (ROI) of the development effort
- Responsible for product vision
- Constantly re-prioritizes the Product Backlog, adjusting any long term expectations such as release plans
- Final arbiter of requirements questions
- Decides whether to ship
- Decides whether to continue development
- Considers stakeholder interests
- May contribute as a team member
Scrum Development Team
- Cross-functional (e.g., includes members with testing skills, and often others not traditionally called developers: business analysts, domain experts, etc.) Self-organizing / self-managing, without externally assigned roles
- Negotiates commitments with the Product Owner, one Sprint at a time
- Has autonomy regarding how to reach commitments
- Intensely collaborative
- Most successful when located in one team room, particularly for the first few Sprints
- Most successful with long-term, full-time membership. Scrum moves work to a flexible learning team and avoids moving people or splitting them between teams.
- 3-9 members (originally 7 ± 2 members)
- Facilitates the Scrum process
- Helps resolve impediments
- Creates an environment conducive to team self-organization
- Captures empirical data to adjust forecasts
- Shields the team from external interference and distractions to keep it in group flow (a.k.a. the zone)
- Enforces timeboxes
- Keeps Scrum artifacts visible
- Promotes improved engineering practices
- Has no management authority over the team (anyone with authority over the team is by definition not its ScrumMaster)
- Not a coordinator
All Scrum Meetings are facilitated by the ScrumMaster, who has no decision-making authority at these meetings.
Sprint Planning Meeting
At the beginning of each Sprint, the Product Owner and team hold a Sprint Planning Meeting to negotiate which Product Backlog Items they will attempt to convert to working product during the Sprint. The Product Owner is responsible for declaring which items are the most important to the business. The team is responsible for selecting the amount of work they feel they can implement without accruing technical debt. The team “pulls” work from the Product Backlog to the Sprint Backlog.
When teams are given complex work that has inherent uncertainty, they must work together to intuitively gauge their capacity to commit to items, while learning from previous Sprints. Planning their hourly capacity and comparing their estimates to actuals makes the team pretend to be precise and reduces ownership of their commitments. Unless the work is truly predictable, they should discard such practices within the first few Sprints or avoid them altogether.
Until a team has learned how to complete a potentially-shippable product increment each Sprint, it should reduce the amount of functionality it commits to. Failure to change old habits leads to technical debt and eventual design death, as shown in Figure 15. If the top of the Product Backlog has not been refined, a major portion of the planning meeting should be spent doing this, as described in the Backlog Refinement Meeting section.
Toward the end of the Sprint Planning Meeting, the team breaks the selected items into an initial list of Sprint Tasks, and makes a final commitment to do the work.
The maximum allotted time (a.k.a. timebox) for planning a 30-day Sprint is eight hours, reduced proportionally for a shorter Sprint.
Daily Scrum and Sprint Execution
Every day at the same time and place, the Scrum Development Team members spend a total of 15 minutes reporting to each other. Each team member summarizes what he did the previous day, what he will do today, and what impediments he faces.
Standing up at the Daily Scrum will help keep it short. Topics that require additional attention may be discussed by whomever is interested after every team member has reported.
The team may find it useful to maintain a current Sprint Task List, a Sprint Burndown Chart, and an Impediments List. During Sprint execution it is common to discover additional tasks necessary to achieve the Sprint goals. Impediments caused by issues beyond the team’s control are considered organizational impediments.
It is almost always useful for the Product Owner to attend the Daily Scrum. But when any attendee also happens to be the team’s boss, the invisible gun effect hampers self-organization and emergent leadership. People lacking real experience of team self-organization won’t see this problem, just as fish are unaware of water. Conversely, a team that needs additional expertise in product requirements will benefit from increased Product Owner involvement, including Daily Scrum attendance.
The Daily Scrum is intended to disrupt old habits of working separately. Members should remain vigilant for signs of the old approach. For example, looking only at the ScrumMaster when speaking is one symptom that the team hasn’t learned to operate as a self-organizing entity.
Sprint Review Meeting
After Sprint execution, the team holds a Sprint Review Meeting to demonstrate a working product increment to the Product Owner and everyone else who is interested.
The meeting should feature a live demonstration, not a report.
After the demonstration, the Product Owner reviews the commitments made at the Sprint Planning Meeting and declares which items he now considers done. For example, a software item that is merely “code complete” is considered not done, because untested software isn’t shippable. Incomplete items are returned to the Product Backlog and ranked according to the Product Owner’s revised priorities as candidates for future Sprints.
The ScrumMaster helps the Product Owner and stakeholders convert their feedback to new Product Backlog Items for prioritization by the Product Owner. Often, new scope discovery outpaces the team’s rate of development. If the Product Owner feels that the newly discovered scope is more important than the original expectations, new scope displaces old scope in the Product Backlog.
The Sprint Review Meeting is the appropriate meeting for external stakeholders (even end users) to attend. It is the opportunity to inspect and adapt the product as it emerges, and iteratively refine everyone’s understanding of the requirements. New products, particularly software products, are hard to visualize in a vacuum. Many customers need to be able to react to a piece of functioning software to discover what they will actually want. Iterative development, a value-driven approach, allows the creation of products that couldn’t have been specified up front in a plan-driven approach.
Given a 30-day Sprint (much longer than anyone recommends nowadays), the maximum time for a Sprint Review Meeting is four hours.
Sprint Retrospective Meeting
Each Sprint ends with a retrospective. At this meeting, the team reflects on its own process. They inspect their behavior and take action to adapt it for future Sprints.
Dedicated ScrumMasters will find alternatives to the stale, fearful meetings everyone has come to expect. An in-depth retrospective requires an environment of psychological safety not found in most organizations. Without safety, the retrospective discussion will either avoid the uncomfortable issues or deteriorate into blaming and hostility.
A common impediment to full transparency on the team is the presence of people who conduct performance appraisals.
Another impediment to an insightful retrospective is the human tendency to jump to conclusions and propose actions too quickly. Agile Retrospectives, the most popular book on this topic, describes a series of steps to slow this process down: Set the stage, gather data, generate insights, decide what to do, close the retrospective. (1) Another guide recommended for ScrumMasters, The Art of Focused Conversations, breaks the process into similar steps: Objective, reflective, interpretive, and decisional (ORID). (2)
A third impediment to psychological safety is geographic distribution. Geographically dispersed teams usually do not collaborate as well as those in team rooms.
Retrospectives often expose organizational impediments. Once a team has resolved the impediments within its immediate influence, the ScrumMaster should work to expand that influence, chipping away at the organizational impediments.
ScrumMasters should use a variety of techniques to facilitate retrospectives, including silent writing, timelines, and satisfaction histograms. In all cases, the goals are to gain a common understanding of multiple perspectives and to develop actions that will take the team to the next level.
Backlog Refinement Meeting
Most Product Backlog Items (PBIs) initially need refinement because they are too large and poorly understood. Teams have found it useful to take a little time out of Sprint Execution — every Sprint — to help prepare the Product Backlog for the next Sprint Planning Meeting.
In the Backlog Refinement Meeting, the team considers the effort they would expend to complete items in the Product Backlog and provides other technical information to help the Product Owner prioritize them. (3) Large vague items are split and clarified, considering both business and technical concerns. Sometimes a subset of the team, in conjunction with the Product Owner and other stakeholders, will compose and split Product Backlog Items before involving the entire team in estimation.
A skilled ScrumMaster can help the team identify thin vertical slices of work that still have business value, while promoting a rigorous definition of “done” that includes proper testing and refactoring.
It is common to write Product Backlog Items in User Story form. (4) In this approach, oversized PBIs are called epics. Traditional development breaks features into horizontal tasks (resembling waterfall phases) that cannot be prioritized independently and lack business value from the customer’s perspective. This habit is hard to break.
Agility requires learning to split large epics into user stories representing very small product features. For example, in a medical records application the epic “display the entire contents of a patient’s allergy records to a doctor” yielded the story “display whether or not any allergy records exist.” While the engineers anticipated significant technical challenges in parsing the internal aspects of the allergy records, the presence or absence of any allergy was the most important thing the doctors needed to know. Collaboration between business people and technical people to split this epic yielded a story representing 80% of the business value for 20% of the effort of the original epic.
Since most customers don’t use most features of most products, it’s wise to split epics to deliver the most valuable stories first. While delivering lower-value features later is likely to involve some rework, rework is better than no work.
The Backlog Refinement Meeting lacks an official name and has also been called “Backlog Grooming,” “Backlog Maintenance,” or “Story Time.”
- Force-ranked list of desired functionality
- Visible to all stakeholders
- Any stakeholder (including the Team) can add items
- Constantly re-prioritized by the Product Owner
- Items at top are more granular than items at bottom
- Maintained during the Backlog Refinement Meeting
Product Backlog Item (PBI)
Figure 7: A PBI represents a customer-centric feature, usually requiring several tasks to achieve definition of done.
- Specifies the what more than the how of a customer-centric feature
- Often written in User Story form
- Has a product-wide definition of done to prevent technical debt
- May have item-specific acceptance criteria
- Effort is estimated by the team, ideally in relative units (e.g., story points)
- Effort is roughly 2-3 people 2-3 days, or smaller for advanced teams
- Consists of committed PBIs negotiated between the team and the Product Owner during the Sprint Planning Meeting
- Scope commitment is fixed during Sprint Execution
- Initial tasks are identified by the team during Sprint Planning Meeting
- Team will discover additional tasks needed to meet the fixed scope commitment during Sprint execution
- Visible to the team
- Referenced during the Daily Scrum Meeting
- Specifies how to achieve the PBI’s what
- Requires one day or less of work
- Remaining effort is re-estimated daily, typically in hours
- During Sprint Execution, a point person may volunteer to be primarily responsible for a task
- Owned by the entire team; collaboration is expected
Figure 10: Sprint tasks required to complete one backlog item require a mix of activities no longer done in separate phases (e.g., requirements elicitation, analysis, design, implementation,
Sprint Burndown Chart
- Indicates total remaining team task hours within one Sprint
- Re-estimated daily, thus may go up before going down
- Intended to facilitate team self-organization
- Fancy variations, such as itemizing by point person or adding trend lines, tend to reduce effectiveness at encouraging collaboration
- Seemed like a good idea in the early days of Scrum, but in practice has often been misused as a management report, inviting intervention. The ScrumMaster should discontinue use of this chart if it becomes an impediment to team self-organization.
Product / Release Burndown Chart
- Tracks the remaining Product Backlog effort from one Sprint to the next
- May use relative units such as Story Points for Y axis
- Depicts historical trends to adjust forecasts
Figure 12: A Release Burndown Chart variation popularized by Mike Cohn. ( Agile Estimation and Planning, Cohn, Addison Wesley (2006)) The red line tracks PBIs completed over time (velocity), while the blue line tracks new PBIs added (new scope discovery). The intersection projects release completion date from empirical trends.
Bad News: It’s Hard.
Scrum addresses uncertain requirements and technology risks by grouping people from multiple disciplines into one team (ideally in one team room) to maximize communication bandwidth, visibility, and trust.
When requirements are uncertain and technology risks are high, adding too many people to the situation makes things worse. Grouping people by specialty also makes things worse. Grouping people by architectural components (a.k.a. component teams) makes things worse . . . eventually.
Good News: Feature Teams May Help.
The most successful approach to this problem has been the creation of fully cross-functional “feature teams,” able to operate at all layers of the architecture in order to deliver customer-centric features. In a large system this requires learning new skills.
As teams focus on learning — rather than short-term micro-efficiencies — they can help create a learning organization.
More Bad News: It’s Still Hard.
Large organizations are particularly challenged when it comes to Agility. Most have not gotten past pretending to do Scrum. (6) ScrumMasters in large organizations should promote transformation and remove organizational impediments. (7)
Large Scale Scrum (LeSS)
To learn more about large scale Agile development see Large Scale Scrum.
Scrum is a general management framework coinciding with the Agile movement in software development, which is partly inspired by Lean manufacturing approaches such as the Toyota Production System. (8)
eXtreme Programming (XP)
While Scrum does not prescribe specific engineering practices, ScrumMasters are responsible for promoting increased rigor in the definition of done. Items that are called “done” should stay done. Automated regression testing prevents vampire stories that leap out of the grave. Design, architecture, and infrastructure must emerge over time, subject to continuous reconsideration and refinement, instead of being “finalized” at the beginning, when we know nothing.
The ScrumMaster can inspire the team to learn engineering practices associated with XP: Continuous Integration (continuous automated testing), Test-Driven Development (TDD), constant merciless refactoring, pair programming, frequent check-ins, etc. Informed application of these practices prevents technical debt.
Figure 15: The straight green line represents the general goal of Agile methods: early and sustainable delivery of valuable features. Doing Scrum properly entails learning to satisfy a rigorous definition of “done” to prevent technical debt. (Graph inspired by discussions with Ronald E. Jeffries)
Engaged Teams Outperform Manipulated Teams
During Sprint execution, team members develop an intrinsic interest in shared goals and learn to manage each other to achieve them. The natural human tendency to be accountable to a peer group contradicts years of habit for workers. Allowing a team to become self-propelled, rather than manipulated through extrinsic punishments and rewards, contradicts years of habit for managers. (10) The ScrumMaster’s observation and persuasion skills increase the probability of success, despite the initial discomfort.
Challenges and Opportunities
Self-organizing teams can radically outperform larger, traditionally managed teams. Family-sized groups naturally self-organize when the right conditions are met:
- members are committed to clear, short-term goals
- members can gauge the group’s progress
- members can observe each other’s contribution
- members feel safe to give each other unvarnished feedback
Psychologist Bruce Tuckman describes stages of group development as “forming, storming, norming, performing.” (11) Optimal self-organization takes time. The team may perform worse during early iterations than it would have performed as a traditionally managed working group. (12)
Heterogeneous teams outperform homogeneous teams at complex work. They also experience more conflict. (13) Disagreements are normal and healthy on an engaged team; team performance will be determined by how well the team handles these conflicts.
Bad apple theory suggests that a single negative individual (“withholding effort from the group, expressing negative affect, or violating important interpersonal norms” (14) ) can disproportionately reduce the performance of an entire group. Such individuals are rare, but their impact is magnified by a team’s reluctance to remove them. This can be partly mitigated by giving teams greater influence over who joins them.
Other individuals who underperform in a boss/worker situation (due to being under-challenged or micromanaged) will shine on a Scrum team.
Self-organization is hampered by conditions such as geographic distribution, boss/worker dynamics, part-time team members, and interruptions unrelated to Sprint goals. Most teams will benefit from a full-time ScrumMaster who works hard to mitigate these kinds of impediments. (15)
Scrum is intended for the kinds of work people have found unmanageable using defined processes — uncertain requirements combined with unpredictable technology implementation risks. When deciding whether to apply Scrum, as opposed to plan-driven approaches such as those described by the PMBOK® Guide, consider whether the underlying mechanisms are well-understood or whether the work depends on knowledge creation and collaboration. For example, Scrum was not originally intended for repeatable types of production and services.
Also consider whether there is sufficient commitment to grow a self-organizing team.