Scrum is a great development framework for teams focused on developing a product. If the framework is followed, the product owner will see clarified requirements, a production-ready implementation, and have a stable velocity with which to plan, at the end of the sprint. However, if the framework is not followed, and if the framework is not congruent with the actual workload and organizational environment, it may be beneficial to consider other framework options (after attempts to right the issues under Scrum have been unsuccessful).
A typical set of problems with the Scrum framework arises when the product transitions to a maintenance phase in the context of a large organization. The problem includes issues such as priority changes mid-sprint, incongruent processes between teams, unfocused work, and sprints not completing.
Priority changes can affect a Scrum team's velocity, ability to complete a sprint, and planning. Production issues may change the team's plan and incomplete work may accumulate. Organization-wide objectives or mandates may also affect the team's plan once the product has been coupled with other dependent products in the larger organization. Once the sprints become harder to complete, planning is affected because the team's velocity is unstable.
Once a team transitions to a maintenance phase, the team may have turned over support or deployments to another group. Environment changes may also be handled differently. Often, different groups within an organization are not yet operating with compatible development processes. The Scrum team may need to wait for or artificially break down a story in ways that affect the story's ability to complete within the sprint.
The Scrum team may experience a shift in the type of work required, and notice the focus of their team is not as narrow as it once was. Once a product is introduced to a larger integration of other products, the focus may broaden, other groups may introduce priorities, and the potential for interruptions in the sprint increases.
These issues can compound and make it difficult for a Scrum team to complete sprints. While there may be solutions to remain with Scrum (protecting the team and plan from interruptions, prioritizing better, pull from a good ScrumMaster notebook, etc.), these solutions won't always solve the problem completely.
An alternative approach may be to modify the Scrum team's use of the Scrum framework. While the major goals of agile and lean development still apply, and while Scrum still applies, a slight change can be made to introduce the ability for allowing more frequent changes, allowing for incongruent processes, and allowing for a broad focus of work.
Scrumban is a combination of the Scrum framework and Kanban. Information on Scrum, Kanban, and Scrumban is readily available and can prove why the approaches are successful.
If Scrumban has been identified as an option for your team, consider the following approach for transitioning your Scrum team to Scrumban.
Sell Scrumban
The first win is to get your leadership team familiar with and set up for an approval of the new framework. There are differences with a framework that incorporates Kanban practices, and the leadership team will need to feel comfortable with the changes.
During your pitch, cover the following topics to help influence the decision: Current problems team faces with Scrum, solution options, pulling work, the value stream, Kanban, and lastly Scrumban. Lean principles should also be incorporated throughout the discussion.
The current problems should be identified as areas with which Scrum has difficulty helping. A team often facing priority changes during a sprint, incongruent processes between the Scrum team and external teams in the organization, broad objectives, and incomplete sprints are typical issues maintenance teams face under Scrum. These problems may be solved by protecting the team, or with a more influential Product Owner, but these issues can go beyond the reach of the ScrumMaster and Product Owner.
The options should include ideas shuch as allowing for more frequent changes during the sprint, allowing for incongruent processes in the near term, and allowing for unfocused and broad objectives.
Once the problems and their potential solutions are identified, ensure the team understands the subtle difference between pulling work and pushing work. Highlight that pushing work task by task onto the team only allows the team to focus on those individual tasks. Pulling work gives the team more ability to view their work in the context of the larger system, and where it can make improvements. Pulling work is a basic lean software development principle and a fundamental practice in Kanban.
The value stream is not a focus in Scrum. However, Kanban allows you to easily see the value stream. Ensure the leadership team understands the concept of the value stream, and the importance of optimizing it. Visual control over the value stream is the lean principle the team should understand the most. Show how to identify ways of optimizing the value stream by using examples.
Next, cover the basics of Kanban. Walk through a brief scenario. Show how it covers the solution options identified earlier. Make sure the leadership team sees the difference between measuring Scrum and measuring Kanban (burn down vs. cycle time).
Lastly, incorporate Kanban into your current Scrum framework. Show how you would like to start with small changes and leave it to the team when more changes are introduced. Start with a team board change and tracking cycle time for each backlog item type (or size).
Once the leadership team has agreed to the framework changes, introduce the Scrum team to the idea. Get their feedback, answer their concerns, and propose to start during the next sprint. Since Kanban can be used with your current process, it is possible to introduce with little lead time.
Create Board
After the team has agreed to the new framework, create the current value stream on a team board. For example, use the back of your current Scrum team board and make one column for each step in your SDLC from the start until your definition of done is reached.
Use this board in the final step discussed next.
Walk Through A Sprint
Finally, simulate and walk through a sprint with the Scrum team. Show how the backlog items appear on the board. Note the differences in the board, and how the previous tasks in Scrum planning are now left up to the team members to lead themselves. Give the team the feeling they have already been through a sprint with the new framework to help ease them into the next sprint.
Using the approach discussed here, a team facing situational issues with their Scrum framework can start Scrumban as an ongoing evolution until their product development and organization align.
Monday, August 8, 2011
Tuesday, July 26, 2011
The ScrumMaster's Notebook
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.
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.
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.
Wednesday, June 29, 2011
Effective Version Control
Application development managers and leads should pay attention to how the following practices on their teams can ensure complete control over their development artifacts. This is not meant as an exhaustive list, but rather as a base framework for version control on a typical development team.
Source Code
One of the most fundamental items in the development team is the source code. Senior team members should ensure all source code is under version control (leading junior members by example and coaching). Source code includes the implementation; unit tests; acceptance and regression tests; and all associated files, libraries, and configuration running within the component.
Legacy or Existing Systems
Many teams inherit or obtain existing systems. The first activity a team should perform is to version control all components of the system and ensure they are able to reproduce that system in a non-production environment. An unfortunate common issue with existing systems is only binary or executable versions of the implementation exist, and therefore, these artifacts must be version controlled and managed without merges.
Installations and Tools
Version control does not stop with source code. All tools and components used to produce the source code should be version controlled as well. Frameworks, libraries, and tools come and go, and a legacy system still needs to be built and packaged well into its lifetime. Ensure your team does not rely on a vendor to provide tools n number of years into your system's maintenance period. Risk is managed by your organization, and that risk may very well be accepted after your vendor's support has ended.
Branches
A goal of the development team should be to minimize the use of branches in version control. A single active development line is much easier to manage than multiple lists of feature, patch, task, and release branches. As it is not always possible to work directly from a single branch (for technology, schedule, or product version reasons), the team should ensure branches are introduced only for a defined list of reasons (including parallel efforts).
Issues associated with branching strategies include merge conflicts, changes in schedule for features (feature A is built into branch A, but a schedule change needs the feature in branch B), and other external changes not planned for.
Development Lifecycle
Agile teams have an increasing need for simple and automated development. Version control systems can be used in the automation of development practices. Teams transitioning from one development methodology or framework to another should consider the implications on their version control strategies.
Executables
Executable components (latest build, historical builds) should not be version controlled with the implementation. Issues with keeping the source synchronized with the built components and ease in retrieving specific builds will interfere with the team's effectiveness. Consider labeling or marking the source at build time, and then either storing the build in a separate area under version control or storing on a build server file system (recommend the file system to your team as the source can always be re-built from the label later if needed).
Configuration Management, Build, & Packaging
As mentioned earlier, all tools used in producing the components should be version controlled. Specifically, configuration management tools and scripts may contain their own configuration as well. For example, a continuous integration server may need to be configured to call out to a custom build script. The configuration of that integration server as well as the custom build script should be version controlled. The installation package of that integration server should also be version controlled.
Depending on size and industry, organizations may have third-party groups or units performing configuration or build management. The development team should ensure that their components' entire value stream is under control and can be reproduced in a non-production environment.
Supporting Documentation
Documentation for the system development as well as release and training should be readily available and reproducible. Determine the right level of needed documentation, and implement a way to keep versions of that documentation in sync with your application components. Documents can be stored in the same system as the implementation or in other knowledge bases (depending on your unique requirements with compliance and traceability).
Once your team uses these practices, further practices can follow such as lower-level control of infrastructure and environment configuration, improvements in automation and delivery, tier-specific enhancements and innovations. Evolving your lifecycle, processes, and value stream should be a continuous process.
Source Code
One of the most fundamental items in the development team is the source code. Senior team members should ensure all source code is under version control (leading junior members by example and coaching). Source code includes the implementation; unit tests; acceptance and regression tests; and all associated files, libraries, and configuration running within the component.
Legacy or Existing Systems
Many teams inherit or obtain existing systems. The first activity a team should perform is to version control all components of the system and ensure they are able to reproduce that system in a non-production environment. An unfortunate common issue with existing systems is only binary or executable versions of the implementation exist, and therefore, these artifacts must be version controlled and managed without merges.
Installations and Tools
Version control does not stop with source code. All tools and components used to produce the source code should be version controlled as well. Frameworks, libraries, and tools come and go, and a legacy system still needs to be built and packaged well into its lifetime. Ensure your team does not rely on a vendor to provide tools n number of years into your system's maintenance period. Risk is managed by your organization, and that risk may very well be accepted after your vendor's support has ended.
Branches
A goal of the development team should be to minimize the use of branches in version control. A single active development line is much easier to manage than multiple lists of feature, patch, task, and release branches. As it is not always possible to work directly from a single branch (for technology, schedule, or product version reasons), the team should ensure branches are introduced only for a defined list of reasons (including parallel efforts).
Issues associated with branching strategies include merge conflicts, changes in schedule for features (feature A is built into branch A, but a schedule change needs the feature in branch B), and other external changes not planned for.
Development Lifecycle
Agile teams have an increasing need for simple and automated development. Version control systems can be used in the automation of development practices. Teams transitioning from one development methodology or framework to another should consider the implications on their version control strategies.
Executables
Executable components (latest build, historical builds) should not be version controlled with the implementation. Issues with keeping the source synchronized with the built components and ease in retrieving specific builds will interfere with the team's effectiveness. Consider labeling or marking the source at build time, and then either storing the build in a separate area under version control or storing on a build server file system (recommend the file system to your team as the source can always be re-built from the label later if needed).
Configuration Management, Build, & Packaging
As mentioned earlier, all tools used in producing the components should be version controlled. Specifically, configuration management tools and scripts may contain their own configuration as well. For example, a continuous integration server may need to be configured to call out to a custom build script. The configuration of that integration server as well as the custom build script should be version controlled. The installation package of that integration server should also be version controlled.
Depending on size and industry, organizations may have third-party groups or units performing configuration or build management. The development team should ensure that their components' entire value stream is under control and can be reproduced in a non-production environment.
Supporting Documentation
Documentation for the system development as well as release and training should be readily available and reproducible. Determine the right level of needed documentation, and implement a way to keep versions of that documentation in sync with your application components. Documents can be stored in the same system as the implementation or in other knowledge bases (depending on your unique requirements with compliance and traceability).
Once your team uses these practices, further practices can follow such as lower-level control of infrastructure and environment configuration, improvements in automation and delivery, tier-specific enhancements and innovations. Evolving your lifecycle, processes, and value stream should be a continuous process.
Subscribe to:
Posts (Atom)