The ScrumMaster's skill set differs from those of roles outside the Scrum framework. While project managers have the majority of the skills, the ScrumMaster needs more knowledge and current practical experience on the application development side (analysis, implementation, etc.) to help with the lower level of day-to-day details involved with the role. While application developers and analysts can have the majority of the skills as well, the ScrumMaster needs more knowledge and practical experience in the Scrum framework, influence, agile and lean techniques and principles.
The following describes those topics a ScrumMaster should track and evolve in a notebook for quick reference and continuous improvement.
The Scrum Framework
While Scrum is only a framework for projects (and not a prescribed methodology), it is important for the ScrumMaster to know how to incorporate agile, lean, and development practices and principles into the framework. Knowing where the framework stops, and the team's practices begin can help the ScrumMaster pull the team together in times of misunderstanding and in times of value stream optimization.
Notes on good practices for the daily meeting (stand up meeting) can help as a reference when the meetings run long or when the value of the meeting starts to decrease.
Keeping a list of alternative approaches to the retrospective is valuable. Switching retrospective techniques can help invite new opportunities for team member participation and bring out new ideas not thought of in the previous retro's approach.
The ScrumMaster should also be able to articulate the team's velocity and recent burndown (or hours remaining). A page should be dedicated to creating a burndown (perhaps even a project burndown to show senior management the team trends).
Scrum Team
Information on the Scrum team should be kept in mind to assist with the team's effectiveness. Information on the best size of a team, the ability for the team to be cross functional, and how the team works with management can prove valuable when issues, organizational changes, or team questions arise.
It is important to control the team size and to be able to articulate the importance of the team size. If team members are pulled away or added, then current relationships, velocity, and team effectiveness is affected.
The team should remain cross functional. As a team moves away from new development and transitions to a maintenance phase, for example, it is common for the team to see organizational changes. The ScrumMaster must be able to refer to the fundamental principle for cross functional teams and ensure the team is able to maintain the previous effectiveness.
ScrumMasters should understand how management can work for the team. When to escalate to management, and when to shield the team from management are important things to keep in mind.
Agile
A ScrumMaster should be well versed in agile principles and practices. The benefits of the agile manifesto, and how those benefits map to business value are important to keep readily available. Prioritizing can sometimes be helped with information on why things are done the way they are done, or why the process needs to change.
Specific examples for ScrumMasters to note include story maps, the roles of team members, how to handle debt, and the benefits of information radiators and team boards (physical task boards vs. virtual task boards).
There are lots of development frameworks out there, and the ScrumMaster needs to know when to evolve the current team's framework.
Lean
Just as agile principles and practices are important, lean principles are also important. While Scrum doesn't technically require a knowledge of lean principles, a ScrumMaster can shape its team's effectiveness by incorporating lean principles (such as optimization, limiting waste, making small changes at a time, limiting debt, continuous improvement, visual control, simple technology, using just in time, etc.).
Impediment Removal
ScrumMasters have a responsibility to foresee and remove impediments to the team. However, ScrumMasters should coach the team to proactively remove impediments themselves, so that the ScrumMaster can focus on removing the real impediments.
Pull vs. Push
The ScrumMaster should have an appreciation for the differences between pulling work and pushing work. The team that pulls work is empowered to produce a quality product and innovate. The team that has work pushed to them has less opportunity to do so.
Continuous Delivery
Knowledge of and reference to the benefits of continuous integration and delivery is valuable to a ScrumMaster in situations where the Product Owner needs explanation for the priority of work toward these practices. Mapping the components of automated continuous delivery to business needs is a key skill for a ScrumMaster. The Scrum team benefits from automation, but the entire organization may need to be influenced to see the benefits.
Engineering Practices
The Scrum framework does not prescribe engineering practices, so the ScrumMaster must ensure the team does not lose sight of good practices. Notes on these practices and when to utilize them can assist the ScrumMaster in determining if the definition of done is complete, if the right tasks are considered during planning, and if junior team members are collaborating with senior team members for the right reasons.
Technical Skills
A ScrumMaster should acquire at least a minimum skillset in the technologies used by the team. A background in the team's technologies, processes, and techniques will assist the ScrumMaster in removing impediments, and ensuring team members are working effectively. A reference to these items can help make quick decisions or improve the effectiveness of the decisions made by the ScrumMaster.
Functional or Domain Knowledge and Skills
The ScrumMaster should also acquire at least a minimum level of knowledge or skills in the business domain or functionality of the product. Referring to this information will assist the ScrumMaster in leading the team's planning and prioritization.
System Quality Attributes
Occasionally the team identifies areas of difficiency or debt that the product owner or customer has not realized. The ScrumMaster should be able to assist the team with relaying the relevance of the debt to the product owner. A tactic to improve the product owner's understanding of the problem is to map the problem to one of the standard system quality attributes (or non functional requirements). Refrence information on these quality attributes can make this process more effective.
Feedback
The ScrumMaster is sometimes called upon to resolve conflicts or deal with difficult situations. Readily-available notes on how to deal with these situations, and how to give proper feedback are useful. Sometimes these situations come up unexpectedly and a quick resolution may be required.
Reinvigorating Your Scrum Team
The Scrum team can sometimes get into a rut. Repetitive types of backlog items, or periods of uninteresting work may take away some of the team's excitement. The ScrumMaster should have a list of approaches available to apply during these periods to keep the team engaged.
Leadership
The ScrumMaster is a leadership position. The team has more interaction with the ScrumMaster than with management. Therefore, the ScrumMaster should have a set of leadership skills to match the team's needs and information on how to best use these skills.
Optimizing Value
A team's backlog contains items of varying priority, value, and complexity. The ScrumMaster should understand and have access to the benefits of acting on these items in the way that best optimizes the value added to the product. The Product Owner owns the priority, but the ScrumMaster can influence priority from the team's perspective. For example, consider acting on high value with low complexity items first. When those items are complete, assess the remaining items to determine their remaining value.
Facilitation & Project Management
The ScrumMaster facilitates the Scrum rituals and various meetings with the team and stakeholders. Additionally, standard project management skills are used daily to run the development team. Additionally, ScrumMasters need to guide their team and a program if working within a program following a different methodology (see considerations for agile inside waterfall.)
The ScrumMaster also needs to think quickly about each card on the team board during the daily stand up meeting. Consider the WATCH The Board technique.
While the needs of a ScrumMaster will change with the particular team, notes on the topics identified here will help the ScrumMaster empower and effectively lead the team.
Tuesday, July 26, 2011
Wednesday, July 13, 2011
The Analogy Between Construction and IT Application Development Is Still Useful
There is a commonly used analogy in IT to help describe the details of application development where mechanical construction is compared to the construction of an application. The analogy was more congruent with traditional application engineering, but newer development methods stray more from the analogy (see considerations for the mismatch between agile and waterfall as an example). However, the analogy is still useful when used correctly.
The Analogy
When application development was heavily focused on big design up front (BDUF) or a large waterfall process, this analogy was a simple method to convey details to external stakeholders and those less involved with the process. Architects would make statements that compared a building's foundation to constructing a foundation for an application. Programmers would compare building framing to the application code. User interface designers would compare paint on the walls to the look and feel of the application.
What is Right, What is Wrong
Taking the analogy literally is wrong. The right way to use the analogy is to use it as a more familiar way to convey information. Peers in the IT industry go back and forth on the usefulness of the analogy, but the truth is there is not much of a reason to do so.
An application architect or designer could mention a foundation is needed first in order for the rest of the application to function well. This idea is true, but peers in IT should understand that the scale may have changed with time. Perhaps under BDUF the entire foundation would have been created. Under more iterative processes, a foundation is still created under whatever small functionality is being delivered.
Roles
The roles in both industries can be compared somewhat, but there are some roles that can't. Architects and engineers can cross over and easily be understood. Project managers can also compare easily. Developers in IT mean something different in construction, but a developer in IT can be compared to finish or rough carpentry, or an electrician in construction. Testers in IT can, perhaps, compare to an inspector in construction.
What roles do we have trouble comparing? Configuration management doesn't have a direct comparison in construction.
Agile
The analogy is understandably not as easy to apply in all aspects under an agile process. Building a little at a time, refactoring, and building more is not how you see a house go up. However, what you didn't see before that house went up across the street were the many prototypes created in AutoCAD or scale models created out of Styrofoam board. Therefore, the analogy still applies under agile.
The Analogy
When application development was heavily focused on big design up front (BDUF) or a large waterfall process, this analogy was a simple method to convey details to external stakeholders and those less involved with the process. Architects would make statements that compared a building's foundation to constructing a foundation for an application. Programmers would compare building framing to the application code. User interface designers would compare paint on the walls to the look and feel of the application.
What is Right, What is Wrong
Taking the analogy literally is wrong. The right way to use the analogy is to use it as a more familiar way to convey information. Peers in the IT industry go back and forth on the usefulness of the analogy, but the truth is there is not much of a reason to do so.
An application architect or designer could mention a foundation is needed first in order for the rest of the application to function well. This idea is true, but peers in IT should understand that the scale may have changed with time. Perhaps under BDUF the entire foundation would have been created. Under more iterative processes, a foundation is still created under whatever small functionality is being delivered.
Roles
The roles in both industries can be compared somewhat, but there are some roles that can't. Architects and engineers can cross over and easily be understood. Project managers can also compare easily. Developers in IT mean something different in construction, but a developer in IT can be compared to finish or rough carpentry, or an electrician in construction. Testers in IT can, perhaps, compare to an inspector in construction.
What roles do we have trouble comparing? Configuration management doesn't have a direct comparison in construction.
Agile
The analogy is understandably not as easy to apply in all aspects under an agile process. Building a little at a time, refactoring, and building more is not how you see a house go up. However, what you didn't see before that house went up across the street were the many prototypes created in AutoCAD or scale models created out of Styrofoam board. Therefore, the analogy still applies under agile.
Creative Partnerships For Effective Development Teams
Application development teams transforming to a new development methodology, framework, or process are challenged with ensuring their new working relationship and responsibilities have a positive impact on the results of the transformation. Development managers and leads can enable effective product and feature teams by ensuring the following topics are visible and well understood.
Pull, Don't Push
A basic undercurrent of an effective application development team is its culture of pulling work instead of reacting to work pushed upon it. Pushing work removes creativity from the process to the point where team members lose the vision of the complete solution and only focus on their current work item. Managers and leads should ensure the capacities of their teams are not 100% utilized with work that the team was not ready to pull.
Managers and leads can create effective team members by ensuring end to end integration of the entire value stream (using value stream analysis) and ensuring work is pulled just in time (JIT). Teams enjoy the right to have pride in their workmanship, and barriers to this right should be removed to increase their effectiveness.
With a pull system in place, an application development team can effectively partner with with other teams (as well as with its own team members).
Scrum Team Roles
In the Scrum framework for application development, the following three roles are identified to perform the work. These roles have different individual goals and it is important to distinguish the individual goals from the larger team goals.
Project Managers and Teams
Project managers should partner with teams from a high level. In large organizations, or projects within a program, project managers are needed to monitor, report on, and control dependencies between entities. Teams are needed to self-organize and complete the work. At intervals (just in time or regular intervals), the team should connect with the project manager to communicate any risk changes or issues that affect the dependencies the project manager is monitoring.
The project manager does not need to track or plan the individual work items of the team. However, at intervals when coordinated efforts are required between entities, the project manager can then partner with the team to facilitate scheduling and coordination.
Project managers and teams need to work together especially when combining differing methodologies and frameworks.
Development Managers and Teams
Development managers should partner with the team with enabling in mind. The team remains self-organized, while the manager enables the team to succeed in the greater enterprise. Day to day, the manager assists the team with conflict resolution, providing guidance and objectives, and coaching. The manager then works to strengthen the team by acting as a catalyst, removing barriers, and optimizing the team's value stream.
The team performs the work to meet the set objectives, and works with the manager to identify the barriers. It is the manager's responsibility to provide leadership to the team. The manager can blaze a trail while the team follows up by completing the road.
DevOps
A relationship exists between the application development team and the operations team that runs the application day to day. Whatever the details are, a relationship does exist. In some organizations, the teams are completely separate, where in others the teams are one and the same.
Compliance and regulatory requirements may affect the organization's ability to integrate these teams, but an effective practice is to ensure that the development team has a close relationship with and an understanding of the operational side of the application.
The application development team should partner with the operations team to ensure the execution of and issues for the application are visible and known by each team. Development team requirements, design, reviews, and showcase sessions should include the operations team.
Application development teams can increase their effectiveness by partnering with other teams. An understanding of the differences in teams and their roles and requirements can increase the effectiveness of the partnership. Application development managers and leads can enable teams by leading them into these effective partnerships.
Pull, Don't Push
A basic undercurrent of an effective application development team is its culture of pulling work instead of reacting to work pushed upon it. Pushing work removes creativity from the process to the point where team members lose the vision of the complete solution and only focus on their current work item. Managers and leads should ensure the capacities of their teams are not 100% utilized with work that the team was not ready to pull.
Managers and leads can create effective team members by ensuring end to end integration of the entire value stream (using value stream analysis) and ensuring work is pulled just in time (JIT). Teams enjoy the right to have pride in their workmanship, and barriers to this right should be removed to increase their effectiveness.
With a pull system in place, an application development team can effectively partner with with other teams (as well as with its own team members).
Scrum Team Roles
In the Scrum framework for application development, the following three roles are identified to perform the work. These roles have different individual goals and it is important to distinguish the individual goals from the larger team goals.
- Product Owner - The Scrum Product Owner for the team is responsible for providing the next priority and the answers to any product-related questions. Individually, this person needs to ensure that the requirements conveyed to the team are correct and what the product minimally needs at that point in time. At a team level, this person sets planning goals and is there to assist the team with priority.
- ScrumMaster - The ScrumMaster is responsible for coordinating the team. Individually, this person needs to ensure the team's practices are correct and followed, and that each team member's work flow is going as smoothly as possible. At a team level, this person ensures the team is only committing to work it has the capacity for.
- Team - The Scrum Team is responsible for completing the work. Individually, the team is a set of individuals with the right to perform their roles as professionals. At a team level, the team pulls work from the Product Owner when they have the capacity (see creative examples of how more than the team can work with the Product Owner).
Project Managers and Teams
Project managers should partner with teams from a high level. In large organizations, or projects within a program, project managers are needed to monitor, report on, and control dependencies between entities. Teams are needed to self-organize and complete the work. At intervals (just in time or regular intervals), the team should connect with the project manager to communicate any risk changes or issues that affect the dependencies the project manager is monitoring.
The project manager does not need to track or plan the individual work items of the team. However, at intervals when coordinated efforts are required between entities, the project manager can then partner with the team to facilitate scheduling and coordination.
Project managers and teams need to work together especially when combining differing methodologies and frameworks.
Development Managers and Teams
Development managers should partner with the team with enabling in mind. The team remains self-organized, while the manager enables the team to succeed in the greater enterprise. Day to day, the manager assists the team with conflict resolution, providing guidance and objectives, and coaching. The manager then works to strengthen the team by acting as a catalyst, removing barriers, and optimizing the team's value stream.
The team performs the work to meet the set objectives, and works with the manager to identify the barriers. It is the manager's responsibility to provide leadership to the team. The manager can blaze a trail while the team follows up by completing the road.
DevOps
A relationship exists between the application development team and the operations team that runs the application day to day. Whatever the details are, a relationship does exist. In some organizations, the teams are completely separate, where in others the teams are one and the same.
Compliance and regulatory requirements may affect the organization's ability to integrate these teams, but an effective practice is to ensure that the development team has a close relationship with and an understanding of the operational side of the application.
The application development team should partner with the operations team to ensure the execution of and issues for the application are visible and known by each team. Development team requirements, design, reviews, and showcase sessions should include the operations team.
Application development teams can increase their effectiveness by partnering with other teams. An understanding of the differences in teams and their roles and requirements can increase the effectiveness of the partnership. Application development managers and leads can enable teams by leading them into these effective partnerships.
Tuesday, July 12, 2011
How To Get Your Debt Ready
Application development teams trade costs and benefits, and face prioritization issues daily. Managers and leads should enable their teams to correctly prioritize their backlogs of work items by ensuring the following topics are applied correctly to their teams. This is not a process to follow, but rather a set of practices and topics that teams should adhere to in order to facilitate the tackling of debt (quality, configuration, or technical debt)--just as any other item is ready for development.
Debt Identification
Ensure debt is identified and radiated to the team. The team created the debt (or inherited it), and it is the team that will remove the debt. The identification should occur as the debt is found or created, and the radiation should be simple and visible.
Example radiators include big visible displays or pages in a collaboration tool. Since debt should be removed quickly, the simplest technology works best. Consider this concrete example: a big visible chart on the wall of the planning room divided into areas for each application component containing ranked sticky notes representing each debt item for that component.
Craftsmanship and Commitment to Quality
Before debt can be identified or prioritized, the team must confirm its levels of craftsmanship and commitment to quality. A team divided on the amount of automated coverage or design patterns should first commit to its goals before it can identify debt--the team must know what debt is before it can identify debt.
Faltering engineering practices is a typical problem on new or immature teams when the team is challenged with understanding a new methodology, framework, or process. Managers and leads need to identify this problem and connect with the team to create a baseline of quality levels and craftsmanship to which the team can commit.
Understand How You Get Debt
Debt is incurred whenever you choose today over tomorrow. A common example occurs when reacting to fires creates workarounds or short-term solutions that are not refactored later.
Debt also occurs when there is not a common commitment to quality or where a lack of development maturity (do you have version control?) produces low-quality implementations, repeated manual tasks, or a lack of test coverage.
Debt can also come out of value stream analysis. Identifying waste areas, for example, can lead to the need to prioritize debt items.
Debt also occurs in the following four fashions:
Add Debt Reduction to Goals
Team goals should include commitments that enable team members to map debt reduction to the goals. A goal of automated releases allows team members to raise a manual step in the release as debt or in need of technical improvement. Planning can then consider these goals along with those goals provided in other discovery and capability discussions.
Villages Manage Backlogs
Product owners, managers, or customers should ensure all team roles have input into the preparation of the work item and its impact to the product. While smaller applications can be understood by a single owner or customer, larger applications in larger organizations typically require an entire team of knowledge.
In the picture shown here, a Scrum Product Owner communicates the priority, vision, and goals of the plan, while the remainder of the team provide input based on their expertise and knowledge area
![]()
It is critical to ensure the owner, manager, or customer of the product understands all aspects and points of view when prioritizing.
Definition of Done
A team's definition of done should include references to debt or mottos reflecting their commitments to quality levels and delivery capabilities. While an exhaustive list is not required, the list should be detailed enough for the team to ensure that norms and accountability is congruent across team members.
Responsibilities
Team responsibilities should be clear and team members should take collective ownership of the application. Team members should be empowered to raise debt issues during planning or development, and owners, managers, and customers should respond with an updated priority accordingly. Team members have the responsibility to question a de-prioritization of debt reduction.
Team Should be Savvy Enough to Communicate Business Impact
The team should provide the business impact of a debt item in order for a product owner, manager, or customer to properly prioritize. Development managers and leads should provide leadership to the team to ensure that business strategy and current and future needs are understood. Junior team members can collaborate with more senior members to deliver the impact.
The team can use simple tools to map debt items to system quality attributes or non-functional requirements--where those attributes and requirements are then standardized as requirements for applications under that business strategy. For example, the availability of a system can be affected by an implementation or release process that reduces the availability. An enhancement to the release process could meet the availability requirements.
Reward Quality
Debt can be traced to quality at some level--affecting the quality itself, or the ability to reach the quality level faster. A team rewarded for quality or with a focus on quality can be led to better prioritize resolving debt before tackling another feature that would increase the amount of debt. While managers and leads must be careful of putting too much emphasis on the reward (the team could then game the system), incentives for matching the team's quality commitment can help the team focus on their responsibilities in this area.
Management Leadership
Managers and leads should remove any barriers that rob the team of their right to craftsmanship and pride in their work. Team members want to do their best and take pride in their work without the fear of being questioned over their test coverage or automation additions. Management should identify problems in this area and remove them by having the team commit.
Tackling and managing debt (technical, configuration, or quality) needs daily attention. Team members need to implement together, identify and radiate the debt, and be responsible for communicating the impact of the debt. Managers and leads need to provide leadership to ensure roles on the team are adhering to their commitments.
Those managers and leads using the practices covered here will enable their teams to effectively get their debt ready and prioritized for resolution.
Debt Identification
Ensure debt is identified and radiated to the team. The team created the debt (or inherited it), and it is the team that will remove the debt. The identification should occur as the debt is found or created, and the radiation should be simple and visible.
Example radiators include big visible displays or pages in a collaboration tool. Since debt should be removed quickly, the simplest technology works best. Consider this concrete example: a big visible chart on the wall of the planning room divided into areas for each application component containing ranked sticky notes representing each debt item for that component.
Craftsmanship and Commitment to Quality
Before debt can be identified or prioritized, the team must confirm its levels of craftsmanship and commitment to quality. A team divided on the amount of automated coverage or design patterns should first commit to its goals before it can identify debt--the team must know what debt is before it can identify debt.
Faltering engineering practices is a typical problem on new or immature teams when the team is challenged with understanding a new methodology, framework, or process. Managers and leads need to identify this problem and connect with the team to create a baseline of quality levels and craftsmanship to which the team can commit.
Understand How You Get Debt
Debt is incurred whenever you choose today over tomorrow. A common example occurs when reacting to fires creates workarounds or short-term solutions that are not refactored later.
Debt also occurs when there is not a common commitment to quality or where a lack of development maturity (do you have version control?) produces low-quality implementations, repeated manual tasks, or a lack of test coverage.
Debt can also come out of value stream analysis. Identifying waste areas, for example, can lead to the need to prioritize debt items.
Debt also occurs in the following four fashions:
- Deliberately and recklessly where commitment levels are ignored intentionally
- Recklessly and inadvertently where immature decisions are implemented
- Inadvertently and prudently where mature decisions are implemented but with an inadvertent impact
- Prudently and deliberately where mature decisions are implemented with a concrete plan for later refactoring
Add Debt Reduction to Goals
Team goals should include commitments that enable team members to map debt reduction to the goals. A goal of automated releases allows team members to raise a manual step in the release as debt or in need of technical improvement. Planning can then consider these goals along with those goals provided in other discovery and capability discussions.
Villages Manage Backlogs
Product owners, managers, or customers should ensure all team roles have input into the preparation of the work item and its impact to the product. While smaller applications can be understood by a single owner or customer, larger applications in larger organizations typically require an entire team of knowledge.
In the picture shown here, a Scrum Product Owner communicates the priority, vision, and goals of the plan, while the remainder of the team provide input based on their expertise and knowledge area
It is critical to ensure the owner, manager, or customer of the product understands all aspects and points of view when prioritizing.
Definition of Done
A team's definition of done should include references to debt or mottos reflecting their commitments to quality levels and delivery capabilities. While an exhaustive list is not required, the list should be detailed enough for the team to ensure that norms and accountability is congruent across team members.
Responsibilities
Team responsibilities should be clear and team members should take collective ownership of the application. Team members should be empowered to raise debt issues during planning or development, and owners, managers, and customers should respond with an updated priority accordingly. Team members have the responsibility to question a de-prioritization of debt reduction.
Team Should be Savvy Enough to Communicate Business Impact
The team should provide the business impact of a debt item in order for a product owner, manager, or customer to properly prioritize. Development managers and leads should provide leadership to the team to ensure that business strategy and current and future needs are understood. Junior team members can collaborate with more senior members to deliver the impact.
The team can use simple tools to map debt items to system quality attributes or non-functional requirements--where those attributes and requirements are then standardized as requirements for applications under that business strategy. For example, the availability of a system can be affected by an implementation or release process that reduces the availability. An enhancement to the release process could meet the availability requirements.
Reward Quality
Debt can be traced to quality at some level--affecting the quality itself, or the ability to reach the quality level faster. A team rewarded for quality or with a focus on quality can be led to better prioritize resolving debt before tackling another feature that would increase the amount of debt. While managers and leads must be careful of putting too much emphasis on the reward (the team could then game the system), incentives for matching the team's quality commitment can help the team focus on their responsibilities in this area.
Management Leadership
Managers and leads should remove any barriers that rob the team of their right to craftsmanship and pride in their work. Team members want to do their best and take pride in their work without the fear of being questioned over their test coverage or automation additions. Management should identify problems in this area and remove them by having the team commit.
Tackling and managing debt (technical, configuration, or quality) needs daily attention. Team members need to implement together, identify and radiate the debt, and be responsible for communicating the impact of the debt. Managers and leads need to provide leadership to ensure roles on the team are adhering to their commitments.
Those managers and leads using the practices covered here will enable their teams to effectively get their debt ready and prioritized for resolution.
Subscribe to:
Posts (Atom)