On leading teams

I recently saw a presentation that opened my eyes on some points I probably should have known about long time ago. For me it was a breakthrough, and I apologize I wasn't aware of them sooner.

First of all, regarding the question: "What is my top responsibility as a team lead? What should be the No. 1 in my TODO list?". The simple answer is:

Keep asking myself how my team has improved in the past interval: how my team has improved in becoming a team, how my team has improved in doing things, how my team has improved in becoming a super team, how each member of my team has improved himself/herself, how did I improve myself for my team, how did I improve myself for myself...

If I am not at least thinking about that, I am just a programmer with special attributions!

Secondly, I realized that nothing can improve out there in the comfort zone. If I'm leaving you in your comfort zone, and I stay in mine, we might be more comfortable with each other, but we won't in any way progress in anything.

So If I don't have the guts to challenge somebody or myself out of his/her/mine comfort zone, I am just a programmer with special attributions!

Thirdly, I realized that I can easily become an impediment for my team. Yes mister Scrum master, you can easily become an impediment for your team! If somebody comes to you complaining about the WiFi in the meeting room and you don't ask him "what will you do about it?" but just forward the question, you're on the right track in becoming impediment.

Fourthly, I realized that broken window theory doesn't apply just to failed unit tests but to any practice you would like to have in your team. Skip a code review once, and code review will become optional, skip a retrospective, and all the retrospectives will become optional or nice to have, just break the window and everybody will know it's save whatever they want.

So if you have an hour, enjoy the movie, it contains also other cool stuff: Code Leaders and Beautiful Teams

The guy's site is pretty helpful too: 5whys.com

Agile Software Development with Scrum: Book Review

The Book


Agile Software Development with Scrum by Ken Schwaber and Mike Beedle.


The Review

As part of the efforts to keep our projects on the right track, our teams are trying to apply Scrum. As a result, this book was bought by my manager as an alternative to a Scrum training that could not be taken in Timisoara.

After some research of his own on various books on the Scrum topic, he decided that this book practically is the foundation of Scrum and the first book that must be read on the topic.

It was a very wise decision. I'm also against 2-3 days trainings with no-name topic experts: they can only provide an initial image, for an in depth study of a topic, books and lots of research are needed. After reading it, I must say the book is a perfect starting point on Scrum methodology.

What did I want to learn?

• A confirmation that my view on the Scrum methodology formed from various blogs & articles that I read was right. (I have a lot of experience in XP, RUP, CMMI, PMI - I know a lot about agile and I read a lot of material stating that XP - Scrum - Lean are very much overlapping.)
• How various Scrum practices must be adopted? What do they mean?
• How can Scrum be adopted in our very large and chaotic project?
• Are there any more practices than Sprint Meetings, Daily Meetings, Backlog Burn-down charts and Sprint Retrospectives?

What did I learn?

• Compared to XP, Scrum seems to be more focused on management, control and various forms of organization - If Extreme Programming Explained lists a lot of Engineering practices, this book focuses on process and project management practices.
  
• Understood what is expected in Scrum from the various roles and why.(Scrum Master - removes impediments, takes decisions "any decision is better than no decision", mentor)
• Liked a lot "the art of possible" idea: What can be done in the current (poor) circumstances to reach the sprint's goal. It's not only Scrum master's responsibility to remove impediments, but creativity and adaptability is encouraged to all scrum team members - they must be aware that by themselves can remove impediments.
• Backlogs and Sprints - learned and understood why when adopting Scrum, Scrum practices need to be adopted by the book. Backlog - should be visible to every stakeholder and should contain all identified pieces of work (not only pure programming tasks). Sprints - very important to have a defined goal. Sprints - shelter against the chaotic needs from an application.
• Understood the scientific justification of Scrum practices and learned a lot about defined and empirical processes.
  
• Understood how large(multiple team) projects can be managed efficiently in Scrum.
  
• Scrum values
  

In Summary

The first step of Scrum adoption in any form of organization should be the reading of this book.
The book helped me gain deep understanding on this software development approach as opposed to various blogs & articles I have read which only presented me semantic diffusion.