Symptom: Epic stories are on the product backlog and are not being broken down leaving the backlog stagnant and smelling.
Probable Cause: The epics are most likely not being broken down actively.
Suggested Resolution: Why not set up a regular session to break down epics? Invite relevant and willing parties to the session and consider only one or two stories that need to be broken down. If you keep the sessions short and sharp they should provide high value to the team and can be used as a break between heavy coding sessions.
A little bit and often can go a long way to keeping your product backlog healthy and fresh.
For more agile coaching options, check out agile coaching
Thursday, November 26, 2009
Monday, November 23, 2009
#27 The Part Done, Done Criteria
Symptom: Unplanned work appears consistently on the sprint backlog and unexpected work appears towards the end of the project usually attributable to testing or UAT work.
Probable Cause: The testing activities may be out of synch with the other activities in the sprint, and may well have been excluded from the done criteria.
Suggested Resolution: Sometimes it can be very tempting to fix the done criteria to be something other than potentially shippable or ready for production, such as done in test or potentially shippable to UAT for example. This may be down to availability or some other factors beyond the team's control and so seems reasonable when the team start thinking of how to define their done criteria.
However the outstanding work of UAT testing, defect fixing and regression testing in our example where UAT is outside of the done criteria, will still have to be done at some point before the project is completed and the features delivered. And even though a team may say that they are done when compared to their done criteria, they may well be the people tasked to perform this work that is still outstanding.
Excluding some of the work in this way has the down stream effects of unplanned work or specialist stories such as "UAT testing defects" appearing consistently on the sprint backlog as the outstanding work begins to be realised by the team. In addition, the velocity may seem to drop where previously a good velocity was attained but didn't take into account the UAT work in our example. This may also impact the release plan as the average velocity is skewed.
To remedy a situation such as this, try to modify the done criteria to be production ready or potentially shippable and to encompass all activities involved in delivering a working feature to the client. This may mean that additional team members may need to be added to the team and additional work items added to the user stories on the sprint backlog, but this is the work that would have to be done anyway to deliver the project.
What you are looking for here is a feature to be completed and shippable to a client within a sprint with a true velocity and no excluded or hidden work. Also all of the activities during a sprint should revolve around a common user story or feature context that is vibrant and fresh.
For more agile coaching options, check out agile coaching
Probable Cause: The testing activities may be out of synch with the other activities in the sprint, and may well have been excluded from the done criteria.
Suggested Resolution: Sometimes it can be very tempting to fix the done criteria to be something other than potentially shippable or ready for production, such as done in test or potentially shippable to UAT for example. This may be down to availability or some other factors beyond the team's control and so seems reasonable when the team start thinking of how to define their done criteria.
However the outstanding work of UAT testing, defect fixing and regression testing in our example where UAT is outside of the done criteria, will still have to be done at some point before the project is completed and the features delivered. And even though a team may say that they are done when compared to their done criteria, they may well be the people tasked to perform this work that is still outstanding.
Excluding some of the work in this way has the down stream effects of unplanned work or specialist stories such as "UAT testing defects" appearing consistently on the sprint backlog as the outstanding work begins to be realised by the team. In addition, the velocity may seem to drop where previously a good velocity was attained but didn't take into account the UAT work in our example. This may also impact the release plan as the average velocity is skewed.
To remedy a situation such as this, try to modify the done criteria to be production ready or potentially shippable and to encompass all activities involved in delivering a working feature to the client. This may mean that additional team members may need to be added to the team and additional work items added to the user stories on the sprint backlog, but this is the work that would have to be done anyway to deliver the project.
What you are looking for here is a feature to be completed and shippable to a client within a sprint with a true velocity and no excluded or hidden work. Also all of the activities during a sprint should revolve around a common user story or feature context that is vibrant and fresh.
For more agile coaching options, check out agile coaching
Sunday, November 22, 2009
#26 Adjusting The Sprint Commitment With Respect To The Team Availability
Symptom: Loss in comparable velocity and dependencies arising when team members are unavailable.
Probable Cause: There may be a lack of visibility of the team's availability during the sprint planning sessions and the sprint commitment is not adjusted accordingly.
Suggested Resolution: Try to use an availability matrix detailing the percentage availability of the project team members with any leave booked or other absence from the project during the sprint.
This should improve the visibility of when team members are available and help to refine the sprint commitment and estimated velocity for the current sprint during the sprint planning sessions.
What you are looking for here is a sprint commitment that is achievable with the current availability of team members, especially in an organization that has a fluid approach to projects and team members.
For more agile coaching options, check out agile coaching
Probable Cause: There may be a lack of visibility of the team's availability during the sprint planning sessions and the sprint commitment is not adjusted accordingly.
Suggested Resolution: Try to use an availability matrix detailing the percentage availability of the project team members with any leave booked or other absence from the project during the sprint.
This should improve the visibility of when team members are available and help to refine the sprint commitment and estimated velocity for the current sprint during the sprint planning sessions.
What you are looking for here is a sprint commitment that is achievable with the current availability of team members, especially in an organization that has a fluid approach to projects and team members.
For more agile coaching options, check out agile coaching
Saturday, November 21, 2009
#25 Including The Specialists As Part Of The Project
Symptom: Dependencies and bottle necks with key staff start to arise on a project, which can cause delays, burn down flat lining and impediments.
Probable Cause: An underlying cause might be that the staff are pretty busy with other things and their contribution is not really included as part of the project nor are they recognised as part of the team.
Suggested Resolution: These key staff could be IT admin, architects and support staff for example, who support the project teams with their expertise at various times during a project, but are not working on the project all of the time. In a lot of organizations these important people are usually performing their role across many projects or perform other duties in addition to their project contribution, and so tend to appear on a project from time to time when they are needed.
It can be easy to become reactionary and request these guys input as it is needed, but unless your project is the number one priority in the organization it can present a risk to the project if they are not available when the call goes out for their assistance. It would be much better to be proactive and be able to let these guys know that a spike is needed or that their input is required in the coming sprint or iteration.
A good way to prep them is to invite them along to the last half hour or so of the sprint planning meet to give them a heads up on what is being planned for the sprint and what kind of input the project team may need from them. This then allows them to provide some input on their availability and provide feedback on what is being proposed. Even if they are not needed in the coming sprint, it would be good to let these guys know so that they can arrange their schedule accordingly.
Including these key individuals at a regular planning meet signals that you value their input and that you want to work collaboratively with them to arrive at some plan of how to tackle the next sprint, which can have other positive spin offs such as building that team bond and including them in the decision making.
What you are looking for here is to include these key staff as being part of the project and include their input as being part of the team, even if they are only part time or just a "passer by" on a project.
For more agile coaching options, check out agile coaching
Probable Cause: An underlying cause might be that the staff are pretty busy with other things and their contribution is not really included as part of the project nor are they recognised as part of the team.
Suggested Resolution: These key staff could be IT admin, architects and support staff for example, who support the project teams with their expertise at various times during a project, but are not working on the project all of the time. In a lot of organizations these important people are usually performing their role across many projects or perform other duties in addition to their project contribution, and so tend to appear on a project from time to time when they are needed.
It can be easy to become reactionary and request these guys input as it is needed, but unless your project is the number one priority in the organization it can present a risk to the project if they are not available when the call goes out for their assistance. It would be much better to be proactive and be able to let these guys know that a spike is needed or that their input is required in the coming sprint or iteration.
A good way to prep them is to invite them along to the last half hour or so of the sprint planning meet to give them a heads up on what is being planned for the sprint and what kind of input the project team may need from them. This then allows them to provide some input on their availability and provide feedback on what is being proposed. Even if they are not needed in the coming sprint, it would be good to let these guys know so that they can arrange their schedule accordingly.
Including these key individuals at a regular planning meet signals that you value their input and that you want to work collaboratively with them to arrive at some plan of how to tackle the next sprint, which can have other positive spin offs such as building that team bond and including them in the decision making.
What you are looking for here is to include these key staff as being part of the project and include their input as being part of the team, even if they are only part time or just a "passer by" on a project.
For more agile coaching options, check out agile coaching
Thursday, November 19, 2009
#24 Wavering Direction At The Project Start
Symptom: The project starts with large epics and does not have a concrete direction with the first sprints wavering and even contradicting each other.
Probable Cause: This may be due to an absence of a release plan and some strategic thinking up front.
Suggested Resolution: Agile is fantastic as it allows you to perform a course correction on the project at regular intervals. However, you still need to know the objectives the project is to deliver and a rough direction on how you are going to achieve them.
A release plan done at the start of a project and then maintained regularly can really help to bring the poject concept with strategic releases into a cohesive direction. This can really help the team to consider not just what is immediately in focus in the current sprint, but also be aware of what is coming up, much like peripheral vision.
The trick of course, is not to over cook it and get into over analysing, but a rough idea of where you are heading and what milestones or mini-objectives you want to achieve along the way, can reap rewards when trying to settle down the product backlog.
A good way to get an initial release plan together is to determine the end objective for the project and then work backwards to derive strategic deliverables that count towards the end goal.
What you are looking for here is to get past that fuzzy start of the project quickly so that the team can settle into a solid rhythm and start delivering at a constant velocity.
For more agile coaching options, check out agile coaching
Probable Cause: This may be due to an absence of a release plan and some strategic thinking up front.
Suggested Resolution: Agile is fantastic as it allows you to perform a course correction on the project at regular intervals. However, you still need to know the objectives the project is to deliver and a rough direction on how you are going to achieve them.
A release plan done at the start of a project and then maintained regularly can really help to bring the poject concept with strategic releases into a cohesive direction. This can really help the team to consider not just what is immediately in focus in the current sprint, but also be aware of what is coming up, much like peripheral vision.
The trick of course, is not to over cook it and get into over analysing, but a rough idea of where you are heading and what milestones or mini-objectives you want to achieve along the way, can reap rewards when trying to settle down the product backlog.
A good way to get an initial release plan together is to determine the end objective for the project and then work backwards to derive strategic deliverables that count towards the end goal.
What you are looking for here is to get past that fuzzy start of the project quickly so that the team can settle into a solid rhythm and start delivering at a constant velocity.
For more agile coaching options, check out agile coaching
Wednesday, November 18, 2009
#23 Mid Week Sprints
Symptom: Sprints start and finish mid week and the team are becoming disenchanted with the project.
Probable Cause: The team are probably feeling that the project is one continuous flow of work with no break in between sprints.
Suggested Resolution: Try to arrange the sprints to start on a Monday and finish on a Friday with the weekend available to the team as down time between sprints. It sounds obvious, but sprints that start and finish mid week tend to leave the team in a continuous work schedule with no immediate relief, especially for long term projects.
Finishing up a sprint on a Friday can be a real positive experience and starts the weekend completely free of any thoughts, conscious or sub conscious, about work, the sprint or any impediments. This can be quite liberating leaving the team to have a great weekend and be fresh on Monday to start the next sprint.
What you are looking for is a team that is rested and hyped up ready for the next sprint to start. The periodic rest between sprints should help the team to stay sharp and focussed.
For more agile coaching options, check out agile coaching
Probable Cause: The team are probably feeling that the project is one continuous flow of work with no break in between sprints.
Suggested Resolution: Try to arrange the sprints to start on a Monday and finish on a Friday with the weekend available to the team as down time between sprints. It sounds obvious, but sprints that start and finish mid week tend to leave the team in a continuous work schedule with no immediate relief, especially for long term projects.
Finishing up a sprint on a Friday can be a real positive experience and starts the weekend completely free of any thoughts, conscious or sub conscious, about work, the sprint or any impediments. This can be quite liberating leaving the team to have a great weekend and be fresh on Monday to start the next sprint.
What you are looking for is a team that is rested and hyped up ready for the next sprint to start. The periodic rest between sprints should help the team to stay sharp and focussed.
For more agile coaching options, check out agile coaching
Tuesday, November 17, 2009
#22 The Sprint Holiday
Symptom: The team are getting weary after spending a long time on a project.
Probable Cause: Working on sprints for a long time can begin to take their toll on a team who might feel demoralized and in need of a break.
Suggested Resolution: Try a sprint holiday. This could be a full sprint or part of a sprint dedicated to something not necessarily related to the project, and could be allowing the team to fix those annoying things that keep getting shelved, working on their own pet project or training and up skilling for example.
Sometimes a change is as good as a holiday and taking the pressure off the team for a short while will help them to re-energise and find their mojo again.
For a long term project a week or so is not going to make that much of an impact on the schedule, (if it does, then the project as other problems and may be at risk of missing its dates anyway with the current scope.) A rejuvenated team can return the investment with an increase in productivity and quality and any short term schedule slip should be recovered with a happier team.
It can be easy to think of people as interchangeable parts such as cogs in a machine, but we have to remind ourselves that the team is made up of human beings who have human needs. If these needs are not addressed, then the project will be at risk from a decrease in productivity and quality. What you are looking for here is a happy and productive team and a little investment with a human touch can go a long way to reduce the risks on your project.
For more agile coaching options, check out agile coaching
Probable Cause: Working on sprints for a long time can begin to take their toll on a team who might feel demoralized and in need of a break.
Suggested Resolution: Try a sprint holiday. This could be a full sprint or part of a sprint dedicated to something not necessarily related to the project, and could be allowing the team to fix those annoying things that keep getting shelved, working on their own pet project or training and up skilling for example.
Sometimes a change is as good as a holiday and taking the pressure off the team for a short while will help them to re-energise and find their mojo again.
For a long term project a week or so is not going to make that much of an impact on the schedule, (if it does, then the project as other problems and may be at risk of missing its dates anyway with the current scope.) A rejuvenated team can return the investment with an increase in productivity and quality and any short term schedule slip should be recovered with a happier team.
It can be easy to think of people as interchangeable parts such as cogs in a machine, but we have to remind ourselves that the team is made up of human beings who have human needs. If these needs are not addressed, then the project will be at risk from a decrease in productivity and quality. What you are looking for here is a happy and productive team and a little investment with a human touch can go a long way to reduce the risks on your project.
For more agile coaching options, check out agile coaching
Monday, November 16, 2009
#21 The Stale Product Backlog
Symptom: There is no enhancement of stories as the project progresses leading to a static product backlog and the team feeling that they are driving the project rather than the client.
Probable Cause: The product backlog may not be reviewed regularly by the product owner and there is a disconnection. Also new story ideas may not be captured effectively during the project.
Suggested Resolution: A static product backlog may seem to be the optimum, but with an empirical process, change is actively encouraged and for most projects it is needed in order to "grow" the product backlog into a real product concept. Without these enhancements to stories the product backlog becomes static and stale, which may well result in a waterfall like outcome - "it is what I initially asked for, but not what I need."
To promote an evolving product backlog where the product owner acts as a gardener by encouraging some aspects to grow whilst also pruning others back, try to capture new ideas as new stories during every project activity. This could be actively listening for new ideas during the daily stand ups or capturing feedback during a review and writing them as a new user story to be prioritised in the next prioritisation round for example.
Also try to hold regular product backlog discussions with the product owner and really encourage them to be the "gardener" and connect with the evolving product concept.
What you are really looking for is a constant evolution of stories and ideas that begin to converge on the real solution rather than just a static collection of stories that begin to go stale and smell as the project moves forward.
For more agile coaching options, check out agile coaching
Probable Cause: The product backlog may not be reviewed regularly by the product owner and there is a disconnection. Also new story ideas may not be captured effectively during the project.
Suggested Resolution: A static product backlog may seem to be the optimum, but with an empirical process, change is actively encouraged and for most projects it is needed in order to "grow" the product backlog into a real product concept. Without these enhancements to stories the product backlog becomes static and stale, which may well result in a waterfall like outcome - "it is what I initially asked for, but not what I need."
To promote an evolving product backlog where the product owner acts as a gardener by encouraging some aspects to grow whilst also pruning others back, try to capture new ideas as new stories during every project activity. This could be actively listening for new ideas during the daily stand ups or capturing feedback during a review and writing them as a new user story to be prioritised in the next prioritisation round for example.
Also try to hold regular product backlog discussions with the product owner and really encourage them to be the "gardener" and connect with the evolving product concept.
What you are really looking for is a constant evolution of stories and ideas that begin to converge on the real solution rather than just a static collection of stories that begin to go stale and smell as the project moves forward.
For more agile coaching options, check out agile coaching
Thursday, November 12, 2009
#20 Prioritising Non-Functional User Stories
Symptom: Technical or non-functional user stories are not prioritised effectively when compared to functional user stories leaving the team to make their own judgement calls on when to incorporate them in a sprint. This can lead to subversive behaviour in a team if they feel that the product owner is not taking them seriously enough.
Probable Cause: The product owner can relate easily to functional user stories relating to the client domain for example, but may not be able to see the importance of non-functional user stories, which may be technical in nature and outside of their skills and knowledge.
Suggested Resolution: Try adding a client value and a tech value number to the user stories that can be estimated in a similar way to user story points prior to prioritisation. The client value is a rating to indicate the relative importance to the client in terms of delivered functionality, whereas the tech value relates to the importance to the team to complete the story to improve the code architecture or to avoid technical debt for example, which may not be immediately clear to a product owner.
Adding these two extra ratings may help the product owner to see the relative importance, even if it is a rough guide, of a story whether it is a functional or a non-functional story, and be able to make a better judgement call when prioritising them.
For more agile coaching options, check out agile coaching
Probable Cause: The product owner can relate easily to functional user stories relating to the client domain for example, but may not be able to see the importance of non-functional user stories, which may be technical in nature and outside of their skills and knowledge.
Suggested Resolution: Try adding a client value and a tech value number to the user stories that can be estimated in a similar way to user story points prior to prioritisation. The client value is a rating to indicate the relative importance to the client in terms of delivered functionality, whereas the tech value relates to the importance to the team to complete the story to improve the code architecture or to avoid technical debt for example, which may not be immediately clear to a product owner.
Adding these two extra ratings may help the product owner to see the relative importance, even if it is a rough guide, of a story whether it is a functional or a non-functional story, and be able to make a better judgement call when prioritising them.
For more agile coaching options, check out agile coaching
Wednesday, November 11, 2009
#19 The Story That Halts Progress
Symptom: A story on the sprint backlog takes a long time halting all progress.
Probable Cause: There may be a number of unknowns or external dependencies for this story that may need to be handled individually.
Suggested Resolution: When this happens to an established team it can be quite disruptive to the flow of work and a surprise to the team.
The problem story will need to be resolved if possible, but it may be down to unexpected complexity, an external dependency or something beyond the control of the team.
For unexpected complexity, sometimes this is due to some unknowns and so splitting the story into an investigation part to learn more and an implementation part to do the work may help.
If it is a known area try to break down the story into additional user stories to decompose the problem into manageable chunks that can be easily resolved.
For an external dependency or something beyond the team's control look to defer the story until the dependency is resolved by some action or delivery of a component for example.
For each of these options, reprioritising any new stories may be needed and they may not necessarily be all done in one sprint.
What you are looking for here is to restore the flow of work and this might mean breaking things down a little more to be able to complete them effectively and efficiently.
For more agile coaching options, check out agile coaching
Probable Cause: There may be a number of unknowns or external dependencies for this story that may need to be handled individually.
Suggested Resolution: When this happens to an established team it can be quite disruptive to the flow of work and a surprise to the team.
The problem story will need to be resolved if possible, but it may be down to unexpected complexity, an external dependency or something beyond the control of the team.
For unexpected complexity, sometimes this is due to some unknowns and so splitting the story into an investigation part to learn more and an implementation part to do the work may help.
If it is a known area try to break down the story into additional user stories to decompose the problem into manageable chunks that can be easily resolved.
For an external dependency or something beyond the team's control look to defer the story until the dependency is resolved by some action or delivery of a component for example.
For each of these options, reprioritising any new stories may be needed and they may not necessarily be all done in one sprint.
What you are looking for here is to restore the flow of work and this might mean breaking things down a little more to be able to complete them effectively and efficiently.
For more agile coaching options, check out agile coaching
Tuesday, November 10, 2009
#18 Breaking Down The Uber Release
Symptom: The team are working through the priorities but across many areas with no defined production releases other than the single uber release.
Probable Cause: This can be down to not having a release plan to break up the product backlog into cohesive releases.
Suggested Resolution: Try to create a series of releases in a release plan that looks to group common product backlog stories together to form production deliverables or common objectives.
A good way to do this is to define the end objective and get in touch with the product concept for the project, and then work backwards to define good, and sometimes strategic, releases that will enable a team to achieve the end deliverable.
These defined releases can then be used to partition up the product backlog stories into areas of focus for the team.
What you are looking for is a segmented product backlog by release that may have a collection of sprints each with a collection of prioritised user stories. This higher level partitioning of the backlog should help the team to focus on the current release whilst being aware of future releases and also help them to prioritise effectively within the objective of the current release.
For more agile coaching options, check out agile coaching
Probable Cause: This can be down to not having a release plan to break up the product backlog into cohesive releases.
Suggested Resolution: Try to create a series of releases in a release plan that looks to group common product backlog stories together to form production deliverables or common objectives.
A good way to do this is to define the end objective and get in touch with the product concept for the project, and then work backwards to define good, and sometimes strategic, releases that will enable a team to achieve the end deliverable.
These defined releases can then be used to partition up the product backlog stories into areas of focus for the team.
What you are looking for is a segmented product backlog by release that may have a collection of sprints each with a collection of prioritised user stories. This higher level partitioning of the backlog should help the team to focus on the current release whilst being aware of future releases and also help them to prioritise effectively within the objective of the current release.
For more agile coaching options, check out agile coaching
Monday, November 9, 2009
#17 Chasing The Velocity Target
Symptom: The team continually fail to reach the velocity expectations required for a delivery date.
Probable Cause: The team and the product owner may not be realising the actual velocity of the team.
Suggested Resolution: The velocity metric is there to indicate the team's actual productivity based on real data. It can be tempting to go back to a project management style and try to "force" the velocity to achieve some milestone or delivery objective for example, rather than use the actual velocity to recalibrate the release plan or actively descope lesser prioritised stories to reach the release date.
Also, for a team to be continually failing to meet a velocity "target", this can be quite demoralising if done over a number of sprints. However, if a team lowered the expectations to be in line with their past velocity history, then there is a positive effect on the team's morale. Both situations might produce the same velocity and output, but the latter may well lead to an increase in future sprints.
Try to reduce the expectations to be in line with the exhibited velocity that has been experienced for past sprints and this should have a positive effect on the team and their work. This may require that the scope needs to be recalibrated if a fixed release date is intended, but to be honest, you were never going to reach that date with the scope in its present form anyway. ;o)
The velocity metric is there to provide information based on real data, and so you really need to take note of it and use it appropriately when managing your own and other's expectations.
For more agile coaching options, check out agile coaching
Probable Cause: The team and the product owner may not be realising the actual velocity of the team.
Suggested Resolution: The velocity metric is there to indicate the team's actual productivity based on real data. It can be tempting to go back to a project management style and try to "force" the velocity to achieve some milestone or delivery objective for example, rather than use the actual velocity to recalibrate the release plan or actively descope lesser prioritised stories to reach the release date.
Also, for a team to be continually failing to meet a velocity "target", this can be quite demoralising if done over a number of sprints. However, if a team lowered the expectations to be in line with their past velocity history, then there is a positive effect on the team's morale. Both situations might produce the same velocity and output, but the latter may well lead to an increase in future sprints.
Try to reduce the expectations to be in line with the exhibited velocity that has been experienced for past sprints and this should have a positive effect on the team and their work. This may require that the scope needs to be recalibrated if a fixed release date is intended, but to be honest, you were never going to reach that date with the scope in its present form anyway. ;o)
The velocity metric is there to provide information based on real data, and so you really need to take note of it and use it appropriately when managing your own and other's expectations.
For more agile coaching options, check out agile coaching
Sunday, November 8, 2009
#16 Retrospectives Losing Their Value
Symptom: The attendees of retrospectives are losing interest in the forum.
Probable Cause: There may be some underlying expectations of the retrospectives that are not being addressed.
Suggested Resolution: Try to do a retrospective on the retrospective at the end. It sounds a little weird, but the idea is to discover ideas on how to improve the way that retrospectives are done and if the current format needs to be changed.
In this case look at what is good about the current retrospectives, what are the challenges during the retrospectives and what improvements can be made for future retrospectives.
The retrospectives and their format can also be subject to continuous improvement as with other forums.
For more agile coaching options, check out agile coaching
Probable Cause: There may be some underlying expectations of the retrospectives that are not being addressed.
Suggested Resolution: Try to do a retrospective on the retrospective at the end. It sounds a little weird, but the idea is to discover ideas on how to improve the way that retrospectives are done and if the current format needs to be changed.
In this case look at what is good about the current retrospectives, what are the challenges during the retrospectives and what improvements can be made for future retrospectives.
The retrospectives and their format can also be subject to continuous improvement as with other forums.
For more agile coaching options, check out agile coaching
Saturday, November 7, 2009
#15 Personal Backlogs
Symptom: The team work individually on a number of user stories in a sprint rather than work as a group to tackle user stories by priority. This is often given the excuse that there is no work to do for some team members and so to keep everyone busy more user stories are started. This often results in lots of work in progress and no closure of stories at the end of the sprint with a reduced velocity.
Probable Cause: The team are probably still thinking in silos and that only certain skill sets can work on a story at a given time.
Suggested Resolution: Try to ensure that the team are familiar with the objectives of the sprint - to complete user stories, and that half done does not equal completion. How the team rally to close stories is not so important, only the delivery of high quality software at the end of the sprint is of high value.
To try to dissolve the silos try using pair programming techniques from extreme programming. You can also expand these to include pair testing, pair unit test design, and anything else that will bring the collaborative working within the team to life.
Gently educating the team that it is ok to cross the silo boundaries and that they do not have to work on stories alone should help the team to learn to tackle stories as prioritised objectives rather than as units of work, and ultimately improve the rhythm and velocity of future sprints.
For more agile coaching options, check out agile coaching
Probable Cause: The team are probably still thinking in silos and that only certain skill sets can work on a story at a given time.
Suggested Resolution: Try to ensure that the team are familiar with the objectives of the sprint - to complete user stories, and that half done does not equal completion. How the team rally to close stories is not so important, only the delivery of high quality software at the end of the sprint is of high value.
To try to dissolve the silos try using pair programming techniques from extreme programming. You can also expand these to include pair testing, pair unit test design, and anything else that will bring the collaborative working within the team to life.
Gently educating the team that it is ok to cross the silo boundaries and that they do not have to work on stories alone should help the team to learn to tackle stories as prioritised objectives rather than as units of work, and ultimately improve the rhythm and velocity of future sprints.
For more agile coaching options, check out agile coaching
Friday, November 6, 2009
#14 Unplanned Work: Part 2
Symptom: Unplanned work appearing consistently on the sprint backlog.
Probable Cause: User stories not prioritised effectively.
Suggested Resolution: Sometimes unplanned work finds its way onto the sprint backlog just because it needs to be done at that time, which also suggests that the work is of high priority.
Try to associate any unplanned work with user stories as described in part 1, and in the sprint planning sessions, really try to connect with the product concepts, release plan and what really needs to be the top priorities at that point in time.
The product owner should try to really understand what is required from the product and when, and provide a balanced approach to both functional user stories and technical user stories. (Tech stories are to be covered in another post.)
Effective prioritisation of the user stories will really help to put things into perspective and allow the team to focus on the needs of the project and make good progress.
For more agile coaching options, check out agile coaching
Probable Cause: User stories not prioritised effectively.
Suggested Resolution: Sometimes unplanned work finds its way onto the sprint backlog just because it needs to be done at that time, which also suggests that the work is of high priority.
Try to associate any unplanned work with user stories as described in part 1, and in the sprint planning sessions, really try to connect with the product concepts, release plan and what really needs to be the top priorities at that point in time.
The product owner should try to really understand what is required from the product and when, and provide a balanced approach to both functional user stories and technical user stories. (Tech stories are to be covered in another post.)
Effective prioritisation of the user stories will really help to put things into perspective and allow the team to focus on the needs of the project and make good progress.
For more agile coaching options, check out agile coaching
Thursday, November 5, 2009
#13 Unplanned Work: Part 1
Symptom: Unplanned work keeps appearing consistently on the sprint backlog.
Probable Cause: These unplanned tasks may not have been made visible during the sprint planning and are not attributed back to a user story objective.
Suggested Resolution: Try to understand what these unplanned tasks are and what objectives they are trying to achieve. If it is possible to attribute these back to a user story, then the visibility can be improved and they can be prioritised effectively.
Also during the sprint planning sessions try to understand this unplanned work and determine if this work needs to be done now or if it should be prioritised and the load on the team may be reduced.
What you are looking for here is clear visibility of the work to be done. Only then can you prioritise effectively and focus on what really needs to be delivered in the sprint.
For more agile coaching options, check out agile coaching
Probable Cause: These unplanned tasks may not have been made visible during the sprint planning and are not attributed back to a user story objective.
Suggested Resolution: Try to understand what these unplanned tasks are and what objectives they are trying to achieve. If it is possible to attribute these back to a user story, then the visibility can be improved and they can be prioritised effectively.
Also during the sprint planning sessions try to understand this unplanned work and determine if this work needs to be done now or if it should be prioritised and the load on the team may be reduced.
What you are looking for here is clear visibility of the work to be done. Only then can you prioritise effectively and focus on what really needs to be delivered in the sprint.
For more agile coaching options, check out agile coaching
Wednesday, November 4, 2009
#12 Dependency On Other Teams
Symptom: Your sprint productivity is impacted by another team.
Probable Cause: Dependency relationship with another team impacting the sprint
Suggested Resolution: All teams move at different paces and have a number of variables unique to that team and their productivity. When a dependency relationship exists between two or more teams, they probably are not going to work at the same pace and match each other, hence, if one team is late on another team's deliverable, then the latter is going to lose soem productivity or velocity until the deliverable is provided.
A good way to ensure that there are no impacts on a team is to avoid working on dependency stories in the sprint until the deliverables have been physically received by the dependent team. Only then can the associated user stories be considered for the sprint with no impact to the flow of work.
Ideally you are looking to minimise waste and improve the flow of work by the team, and arranging the sprint backlog in a way that supports this should help.
For more agile coaching options, check out agile coaching
Probable Cause: Dependency relationship with another team impacting the sprint
Suggested Resolution: All teams move at different paces and have a number of variables unique to that team and their productivity. When a dependency relationship exists between two or more teams, they probably are not going to work at the same pace and match each other, hence, if one team is late on another team's deliverable, then the latter is going to lose soem productivity or velocity until the deliverable is provided.
A good way to ensure that there are no impacts on a team is to avoid working on dependency stories in the sprint until the deliverables have been physically received by the dependent team. Only then can the associated user stories be considered for the sprint with no impact to the flow of work.
Ideally you are looking to minimise waste and improve the flow of work by the team, and arranging the sprint backlog in a way that supports this should help.
For more agile coaching options, check out agile coaching
Tuesday, November 3, 2009
#11 The Expanding User Story
Symptom: A little way into the sprint a user story expands to be more work than was initially estimated.
Probable Cause: One probable cause is that the acceptance criteria was not provided or specific enough and the vague interpretation of the story has bloated the tasks associated with it.
Suggested Resolution: Try to redefine the acceptance criteria to be more specific, testable and in keeping with the original objectives for the story. Based on this refined definition, try to reallocate tasks that no longer seem appropriate to new user stories that can then be prioritised in later sprints.
Ideally, you are looking for user stories to be a good granular level that are short and sharp with a testable acceptance criteria that can be completed within a sprint.
For more agile coaching options, check out agile coaching
Probable Cause: One probable cause is that the acceptance criteria was not provided or specific enough and the vague interpretation of the story has bloated the tasks associated with it.
Suggested Resolution: Try to redefine the acceptance criteria to be more specific, testable and in keeping with the original objectives for the story. Based on this refined definition, try to reallocate tasks that no longer seem appropriate to new user stories that can then be prioritised in later sprints.
Ideally, you are looking for user stories to be a good granular level that are short and sharp with a testable acceptance criteria that can be completed within a sprint.
For more agile coaching options, check out agile coaching
Monday, November 2, 2009
#10 Controlling Scrum Master
Symptom: The scrum master tends to control the daily standups and other forums, and the team feel isolated from the decision making.
Probable Cause: The scrum master may be too controlling, probably due to a sense of obligation to get things moving rather than from a position of "power".
Suggested Resolution: As a scrum master try to do the counter intuitive thing and prompt the team with searching socratic questions, and wait..., and wait..., and wait for an answer even if you know what the answer might be.
In this role the scrum master needs to get into that coaching and training frame of mind rather than be a one dimensional project manager. In a sense, the scrum master is there to coach the team through the scrum framework, and ultimately to train the team to elevate their thinking whilst on a project. The best way is to coach the team to verbalise their thought process through answering the socratic questions. The real art of the role is knowing which questions to ask and when, rather than knowing all of the answers.
What you are looking for is a team that learns to think on its feet and happy to be accountable rather than the scrum master feeling that they have to be in control all of the time to get things done.
For more agile coaching options, check out agile coaching
Probable Cause: The scrum master may be too controlling, probably due to a sense of obligation to get things moving rather than from a position of "power".
Suggested Resolution: As a scrum master try to do the counter intuitive thing and prompt the team with searching socratic questions, and wait..., and wait..., and wait for an answer even if you know what the answer might be.
In this role the scrum master needs to get into that coaching and training frame of mind rather than be a one dimensional project manager. In a sense, the scrum master is there to coach the team through the scrum framework, and ultimately to train the team to elevate their thinking whilst on a project. The best way is to coach the team to verbalise their thought process through answering the socratic questions. The real art of the role is knowing which questions to ask and when, rather than knowing all of the answers.
What you are looking for is a team that learns to think on its feet and happy to be accountable rather than the scrum master feeling that they have to be in control all of the time to get things done.
For more agile coaching options, check out agile coaching
Sunday, November 1, 2009
#9 Retro Missing Key Improvements
Symptom: The retrospective only takes into account the last few days of the iteration and the derived improvements tend to be quite generic.
Probable Cause: The team are not remembering what happened during the iteration and bringing this into the retrospective.
Suggested Resolution: Try to draw a time line of events at the start of the retrospective and get the team to add what significant events affected them either in a positive way or what events had a negative impact.
Taking a little time at the start of the retrospective to draw a white board representation of what happened over the past iteration will help the team to remember the context for what went well and what improvements can be made, and should lead to a richer retrospective.
What you are looking for here is to improve the quality of items raised at the retrospective so that you can get some high value improvements and real traction for the team.
For more agile coaching options, check out agile coaching
Probable Cause: The team are not remembering what happened during the iteration and bringing this into the retrospective.
Suggested Resolution: Try to draw a time line of events at the start of the retrospective and get the team to add what significant events affected them either in a positive way or what events had a negative impact.
Taking a little time at the start of the retrospective to draw a white board representation of what happened over the past iteration will help the team to remember the context for what went well and what improvements can be made, and should lead to a richer retrospective.
What you are looking for here is to improve the quality of items raised at the retrospective so that you can get some high value improvements and real traction for the team.
For more agile coaching options, check out agile coaching
Subscribe to:
Posts (Atom)
