Tags
Agile, Definition of done, Development Team, Focus, Planning, Quality, scrum, scrum master, Sprint, Teams, Work
Hi all,
In the few past weeks working with my Teams I still get the very same recurring “problem” when we are a few days in a Sprint. Today’s subject is Focus. Yes. I shall extrapolate what we are looking for when talking about Focus, because it seems like lots of people choose to make it mean something different than what it is, especially when adopting Scrum. Focus is one of the many values of Scrum and is important if a Team is to deliver high value to the 
Product Owner, therefore the organization. Focus in this context is not about losing sight of your surroundings and putting your head down to concentrate on some complex piece of work, though that is exactly what comes from habit with most of the developers. One aspect of what plagues sprint delivery is that Teams lose sight of the value that must come out of it, members get caught up in the work and have difficulty acting as an actual Team. This problem occurs most of the time because of poor work design. The actual work to be accomplished has not been designed for Teams, rather it is put into a series of hands that a single person will take responsability for and hand it over. Another phenomenon that happens is this functionnal “lust” that is created during the sprint where it seems that no one can resist the temptation to start something new before even remotely finishing the agreed upon “Definition of Done”. The argument for the behaviour is that while it seems some of the members are enjoying work on a piece of functionnality, others feel the need to start another in order to get ahead. This illusion of creating great strides into the selected increments of the Product Backlog leaves the Teams exposed to weak integration and low quality all around. We all know where this is leading, if there is poor quality then value has not been attained. As a leader and force of influence, one must work to have members Focus as a Team on a global objective. Making them explicitly aware of what the next steps are to accomplish that goal and for them to set in motion the necessary work to achieve it is where they should excel at. Like all previous subjects I have written about, it always amazes me that after all this time Teams struggle with these concepts. To be clear, the responsability and accountability of the making sure this is understood lies with the Team coach (i.e. Scrum Master). Like many aspects of the efficiency of the Teams organization, the coach is a strong and essential component if an organization wishes to adopt Team processes. Remember that when it comes to focus, be aware of the business objective and always make sure that members don’t dig themselves into holes.
Thank you and scrum on!
