Tag Archives: Agile

Agile General

Types of leaders by Roy Osherove

In my previous post The three team phases – from Notes to a Software Team Leader: Growing Self Organizing Teams by Roy Osherove  I was looking at team phases. Now lets check what types of leaders we can become according to Roy Osherove.

Command and control

We’ve all seen or have been this type of leader at some point. You tell people what to do. You are the “decider.” You take one for the team, but you also have the team in your pocket in terms of hierarchy, decision making, and control over everyone’s actions.

The command and control leader might also solve everyone’s problem for them. I once had a team leader who, on the first day that I joined the team, set up my laptop while typing blazingly fast on the keyboard and not sharing with me anything he was doing. When I asked questions, he muttered something along the lines of “Don’t concern yourself with this now. You have more important things to do.” (read that sentence with a heavy russian accent for better effect.)

With a controlling leader, there is little room for people to learn, take sole ownership of anything, or take initiative that might go against the rules. And that’s just the way things are.

This approach won’t work if your team already knows what they’re doing or if they expect to learn new things and be challenged to become better.


The coach is also known as “the teacher” and is great at teaching new things to others. The opposite of the controlling leader, the coach is great at teaching others to make decisions while letting them make the wrong decisions as long as there is an important lesson to be learned.

Time is not an issue for a coach because time is meant for learning. It’s like teaching your kid to put on their shoes and tie their shoelaces—it takes time, but it’s an important skill, so you’d be making a mistake not taking the time to let your kid to go through this exercise on their own, cheering them from the sidelines.

This approach won’t work if you and your team don’t have enough free time to actually practice and do any learning. So if you’re busy putting out fires all day, and you’re already behind schedule anyway, you won’t have time to also learn or try new things like refactoring or test-driven development.


The facilitator stays out of everyone’s way. Whereas the coach challenges people to stop and learn something, the facilitator simply makes sure that the current environment, conditions, goals, and constraints are such that they will drive the team to get things done. The facilitator doesn’t solve the team’s problems but instead relies on the team’s existing skills to solve their own problems.

This whole approach won’t work if the team does not have sufficient skills to solve their own problems (such as slow machines, talking to customers, and so on).


That was one of many great thoughts from Roy Osherove book. I will post some more soon. If you would like to read this book, please follow this link:

Agile General

The three team phases – from Notes to a Software Team Leader: Growing Self Organizing Teams by Roy Osherove

In order to see team leadership from new perspective I decided to read “Notes to a Software Team Leader: Growing Self Organizing Teams” by Roy Osherove. It is very interesting book and I would like to share with you some of great citations.

As one of most important things Roy mentions three team phases. I totally agree that we always have to think about where we are as a team. Those phases are:

  1. Survival phase (no time to learn)

    “Survival” sounds dramatic and is as alarming as it sounds. It doesn’t necessarily mean coffee-stained carpets and a sleepless staff. I define survival as your team not having enough time to learn. In order to accomplish your goal as a leader (getting people to grow), you need to make time to learn, so your main strategy, or instinct during this phase is to get the team out of the survival phase by creating slack time. In order to slack time, you will most likely need to use a command and control style of leadership.

  2. Learning phase (learning to solve your own problems)

    You can tell you’re in the learning phase when your team has enough slack time to learn and experiment and you’re actually using that slack time. Slack time can be used for learning new skills, or removing some technical debt, or at best doing both at the same time, such as:

    • Learning and slowly implementing test-driven development, with people who have no
      experience with it
    • Enhancing or building a continuous integration cycle, with people who have no experience
      with it
    • Enhancing test coverage, with people who have no experience with it
    • Learning about and refactoring code, with people who have no experience with it

    In short, use slack time to do anything, and tack on the phrase “with people who have no experience
    with it” at the end of the sentence. Your main goal as a leader (in order to achieve your overall role of growing people) is to grow the team to be self-organizing by teaching and challenging them to solve their own problems. In order to achieve that, you need to become more of a coaching style leader, with the occasional intervention of the controlling leader, for those cases when you don’t have enough slack time to learn from a specific mistake.

  3. Self-organizing phase (facilitate, experiment)

    You can tell you’re in the self-organizing phase if you can leave work for a few days without being afraid to turn off your cell phone and laptop. If you can do that, come back, and things are going well, your team is in the quite unique position of solving their own problems without needing you to help them

    Your goal in the self-organizing phase is to keep things as they are by being a facilitator and keeping a close eye on the team’s ability to handle the current reality; When the team’s dynamics change, you can determine what leadership style you need to use next. The self-organizing phase is also a lot of fun because this is the phase where you have the most time to experiment and try different approaches, constraints, and team goals that will grow you and your team even more.

That was one of many great thoughts from Roy Osherove book. I will post some more soon. If you would like to read this book, please follow this link:


Fixing bugs as a chance and challenge

I love codingWhenever we develop software, we introduce some bugs. There is no exception (almost). I often find people don’t want to fix bugs, but only want to develop new features. As developers we like to be creative, to be innovative. We like to be challenged. And many of us think that fixing bugs is  boring.

I don’t agree with this approach. When I started working on my current project I had been working on bug fixing for month or two. It was phase of our project called stabilization. You may think that this phase is not needed in lifecycle of an agile project, but in this particular case it was necessary (I will write about this in next posts).

This period gave me great opportunity to learn what is what in this project. With each bug I was gaining business knowledge and I was learning architecture of our system. Now people come to me and ask how is this possible that I know so much about project?

And my answer to this question is really simple – Do bug fixing!

But you should do it wisely. Here are some of my advices:

  1. Find root cause of problems.
    It can happen that you seen some exception in logs, lets say NullPointerException. First thought in your mind could be to add null check, commit and put defect to Pending Test status. This is not the way you should go. First of all adding null checks is BAD – it means that your design is broken. Moreover your null check can fix this particular place in code, but application will brake is some other, not directly connected.

    Look for root cause of this issue. Check why you are getting null here. Maybe you are reading some value from web services and it was null, maybe you are parsing some message and format has changed, maybe your configuration has changed, and somebody had disabled some feature. This part of investigation can be most challenging.

  2. Understand the flow of your application.

    During your investigation try to get better understanding of data flow, business rules, etc. If you don’t know enough to understand the code ask more experienced developers or analysts. If you just simply find a root cause quickly, fix it and don’t think about it any more you will never be an expert. You will be able only to fix issues, but not to fix design.

  3. Go through all layers

    I sometimes find people debugging only one layer of application instead of looking deeper. Remember that in big applications root cause of issue can be found in most unexpected places. For example you are checking why data is missing in XML send to web service and the root cause can be found in Javascript parsing user input on the web page. Go through all layers of application.

  4. Get better understanding of what is not working

    When you see bug report try to understand what is not working correctly and ask how it should work. Look for some documentation or maybe analysts to find story which describes correct behavior. After getting better understanding of problem ask yourself if this is really a bug or maybe author of the story had something else in mind and there is some misunderstanding in implementation. It is also possible, that bug is something that has influence on user experience. Maybe during fixing it you could somehow improve it?

    Bug fixing

    Bug fixing by Geek and Poke

In my opinion bug fixing can be a really good chance to get experience and better knowledge. Don’t miss that opportunity!


Done, done, done and done

While working in big projects we often try to get some story points instead of making story done. After some time we are not even sure if functionality is still working correctly. But there is a solution.

I recently read very interesting book: The Art of Agile Development by James Shore. Between many important information I found one thing that is really crucial.

read more »


Agile in some “agile” company

In the past I was working in some small company (about 15 people, 7-10 developers) which was telling every customer that they are agile. That they use agile methodology to build solutions, that they bring products with high quality, that they can quickly change software according to requirements, etc. read more »