One of the Scrum values is “Focus”. It can make or mar a product. It brings direction to the development of a product – from start to finish; and is the back-bone of an effective business strategy.
Having said that, overdo it and the tables are turned. Fret too much over ‘focus’ and what could have been a blessing may become your curse.
Here’s why:
Analyse this picture. Highly focused teams (teams seeing project from sprint to sprint) may well become blind to the big picture perspective.
Tangled in their ‘focus’, they start thinking like what sight-less (blind) people are doing in this picture. These people without sight are touching different parts of the elephant – trying to comprehend/visualize the object. They would be able to place/figure the ‘bits’ or the ‘parts’ with ease if they knew the ‘context’, which is – an Elephant.
If the blind man knew the big picture is Elephant, he would interprete the tail to be ‘tail’ and not ‘rope’. The Big Picture need not be very well defined always like is it an African or an Asian Elephant. It’ll suffice to know that you are building an Elephant.
These are the different user stories that you see in the product backlog. Being too focused on each sprint may help you do an excellent job within THAT specific sprint; your user stories may be well detailed; they may pass all 3C’s and INVEST criteria. BUT, your product may still fail. Because, each of these stories was comprehended in a different context. Phew!
The team never got a chance to grasp the overall goal or the big picture. There are a few reasons why this happens:
- Myopic view of the team
- Lack of visibility about the overall product itself – what are we making, why, for whom etc
- Product owner himself is unaware of product vision and roadmap
- Product owner is aware of the big picture but did not consider worth sharing with the team
This is a dangerous situation any team should not get into – if they do not want to build a wrong product.
At the earliest signs of such a scenario, it’s critical for a team to ask all the right questions and raise red flags – so as to gain understanding of the larger context or the big picture.
Have you faced such a blind man situation on your projects? Please share your story. And, if you can throw light on how you won over it.
Prakash J says
Hi Avineaash,
Good Post. You have articulated the problem very well and it reminded me the challenges we have faced when i was managing teams.
There are couple of things which has worked for me/my teams in the past.
1. Some sort of Visual story mapping. We got inspired by Jeff Patton’s Story Mapping post and tried. Some of the links i could get from my bookmarks
http://www.agileproductdesign.com/blog/the_new_backlog.html
http://www.slideshare.net/mackaraja/mapping-out-agile-product-management
http://projectslittlehelper.com/2012/02/28/being-agile/creating-a-product-backlog-story-mapping/
One of the challenge we have faced is that my development teams were in offshore and the Product Owner was onsite. Typical Distributed Environment Challenge.
If you cannot replicate the story mapping offshore then at least have an video Recording explaining the Story Mapping and whenever there is a change, record a new video and share it with the team. This may help your team a little bit more to understand the bigger picture, road map and how are we helping in achieving the vision.
2. The Second item which has worked is to talk about the product vision before every Sprint/iteration planning meetings. This would help in reminding the bigger picture to the entire team and take it forward with your theme.
But, it all works only if the PO on the other side is interested and understands agile. If you are an offshore company and your client is not agile (or not ready to move to), irrespective of whatever we do, this may not really help.
Thanks
Prakash J
Avienaash Shiralige says
Thanks Prakash for sharing your thoughts. I completely agree with you. Story mapping exercise is very useful to do along with the team. This gives very good picture and a joint ownership/accountability. Team should be very proactive in asking right questions till the time they get bigger vision/roadmap clear. If team does not have this big picture clear, then it leads to less team motivation and more rework.