Showing posts with label adapting. Show all posts
Showing posts with label adapting. Show all posts

Wednesday, September 1, 2010

How are you helping the team?

Recently I noticed a disturbing trend on one of my Scrum teams. The senior developer, Bart, who is by design the technical leader and mentor, had begun giving updates that sounded about like this; “yesterday, no scrum related work, today, no scrum related work, no blocking.”

Unfortunately, the team was listening and was in the process of responding with progressively less meaningful updates from day-to-day.

We have all heard the relentless “no blocking” statement but these updates are particularly troubling. Here’s why:
  • It’s incredibly vague
  • The only thing it really says is that he is doing something the team didn't agree to
  • Because of Bart’s position on the team it is a dangerous and potentially damaging to overall team communication and productivity, this becomes the model behavior if allowed to continue
  • There are customers in the room with very poor poker faces, it’s obvious they are confused and worried that the team lead isn’t working on Sprint commitments

After four consecutive days of this it was clear that it had to be addressed and as Scrum Master this falls right to me for immediate action. 

I’m a believer in the concept of “criticize in private, praise in public” so I grabbed Bart for a quiet hallway chat ten minutes prior to stand-up to make sure that there won’t be anymore of this type of “update.” I made no bones about the negative impact and made it clear that he must provide an example for all to mimic. The non-update update is not acceptable. In our discussion I made the above points and really didn’t get any pushback at all.

What I did get was an explanation of a change in his responsibilities that I wasn’t aware of. His boss has directed him to serve in more of a leadership role and technical mentor role and commit to significantly less coding each sprint. Ok, great. How does this impact his responsibilities to the team?

Obviously, he will have fewer stories and tasks that will require updates during stand-up. However, the team, of which he is a part, still has to make its commitments.

After some discussion we arrived at the following conclusion; rather than providing updates on tasks etc. he will provide specifics on what he did and will be doing to help the team meet every commitment. 

Enough time remained for him to spend some time thinking from this perspective prior to stand-up. Bart went first. Response to his retooled update was immediate. The quality and value of every update went back to where it was before the change.

Lessons Learned
  • Don’t wait to address a performance issue, end it as soon as you identify it 
  • Communication is key, we could have addressed the subtle role change proactively had it been communicated
  • Everyone on the team is responsible for the team meeting or not meeting its goals
  • People in leadership positions lead, good or bad, whether they intend to or not

Friday, August 20, 2010

What This is About

I am an experieinced software Product Manager and very involved in the Agile/Scrum software world. I have a number of certifications from the Scrum Alliance and am always looking for ways to get better at coaching teams I work with to be more productive and build better software.

Here's the scoop on what I am going to be writing about; my brother and I build custom motorcycles in our spare time (what there is of it) and I am going to compare that process to that of building software. I think this is a valid comparision as the two processes have many commonalities. Building a bikes(scooters) and software both:
  • Vision is key and drives the process
  • There are many unknowns at each step of a process
  • The people that build them rely on learning to get better each time they do it
  • There are multiple ways to do pretty much everything
  • Projects are never the same
Every so often something will happen at work that I will write about it as well, it may even have to do with software development.

My perspective on software development is very end-user/product focused which will surely show through.

Feel free to send along any questions you might have, I am happy to try and answer them or at least try to point you in the right direction.