A flow diagram to help empowered team members with decision making regarding picking up new work. The diagram will help teams keep focus towards their collaborative goal.
This flow diagram is extremely useful for newer Agile teams who may not yet be comfortable with the empowerment that is granted when working in iterative development cycles with a regular cadence. The flow diagram enforces the message that we should at all times look to finish work that is in progress before moving onto something new.
If a team member finds themselves without anything to work on, they should ask themselves if there is anything critical that they could be working on or helping with. If not, they should work collaboratively with their team peers to see if they can help finish any of the existing work that is currently in progress. This should always be the preference to starting something new because no value can be gained from unfinished work!
If there is no in progress work that the team member can contribute to, the next check would be to look at any un-started work, but only work that contributes to the original team commitment. This is the next best priority when it comes to adding value. The team should have a goal set for the iteration and achieving the goal should be the highest priority. Therefore, picking up work that directly impacts the goal (rather than work that might be part of a stretch goal, or of a lower priority in the iteration) will be important as it once again focuses on value added. The team can pick anything up until this point without asking or informing anyone like the Scrum Master or the Product Owner – they are fully empowered to make these decisions.
If there are no critical work items, no in progress items or no items related to the iteration goal that they can work on, the next thing to look for would be to check the backlog for any bugs or technical debt that can be picked up. Whilst this might not deliver any visible value to the customer, you can be sure that addressing technical debt will be invaluable to the continuous product development. A courtesy check with the Scrum Master is recommended at this stage, mostly to make them aware that the team member will be working on something that doesn’t directly contribute to the iteration goal.
The final stage if there are no bugs technical debt to be addressed (which you should be congratulated for!), is to go to the Product Owner directly and ask them for some more work to move into the sprint. At this stage, there might be some quick win items that can be added which will add some value to the product for little investment. The Product Owner needs to make this decision because ultimately they are responsible for the overall return on investment for the product.
Following this flow diagram should allow team members to make the right decision all the time when it comes to picking up new work. Above all else, the underlying message from this flow chart is simple: stop starting and start finishing!
Click here to download the full Agile Team Decision Making Flow PDF.Download Diagram
Tuckman’s model of group development suggests that teams pass through multiple stages; Forming, Storming, Norming & Performing, along the way to achieving true potential.
DevOpsGroup are the first to deliver training in DevOps via the BCS that will take lean and agile methodologies to the next level.
Head of DevOpsGroup Academy explains the importance of continuous learning and how you can use it to accelerate your career in today’s interconnected world.