Can you make it right for everybody?

Yes, you can try as hard as you want. Don't we all try to provide an environment that allows people to grow and be their best professionally?

I think this is an important ingredient for a high-performing team. There are limits, however. For instance if you have a team member who isn't particularly keen to actively support changes. Not that I would be surprised by that. People have different personalities and while most are fine with change for a good reason occasionally there are people who resist all kind of change since they may have different preferences and experiences. And that's fine.

If you have a team member with an excellent skill set and huge amount of knowledge and experience that's fantastic. But what if that very person isn't able to proactively work with other team members to help them becoming better as well? What if you have a team member who doesn't attend the first daily stand-up meeting (aka daily Scrum) and comes in late once the meeting is over? What if on day two the same person comes in late but doesn't join the Scrum although it is still on? What if on day three the person is in the Scrum but doesn't participate actively? What if on top of that you observe that it even seems to have a negative impact on the rest of the team?

I think at some point you need to consider your options. Having one-on-one's for coaching is important and helps in most cases. Attempting to consider individual preferences is good, too. But once the overall team performance is affected, you need to act. And don't let anyone hold you hostage. As a leader and coach you need to keep in mind the future of the entire team and the project and objectives the whole team is working on.

An agile environment is not for everybody. There are organizations that work differently and it seems to work for them. Based on my experiences, however, I believe that agile principles work better if properly applied. In some cases this could mean that you may have an individual on your team who has a different perspective, and you should be prepared for that individual moving on. That's just fair and part of the overall change process for the team (and in fact for that individual, too!). Both the individual and the team are most likely better of.

If you have tried everything you can think of and still it doesn't work out, don't feel like a complete failure. You are not! Think of your team and about where you want to take them. And then adapt and move forward. Don't look back unless you want to learn from the past!

I want you to do more!

I have been in the industry for over 15 years now. I have worked in many different environments. There were approaches that you could have called "waterfall", and there were approaches that you could have called "agile". And there were approaches that were somewhere in between (using a linear spectrum).

One thing that has stayed the same during all this time: A customer asking for more. "I want you to do more." And what they mean is: "I want you to increase productivity." (And for the records: A customer could equally be an internal stakeholder, e.g. a product manager.)

The interesting question is, though, how do you measure productivity? The trouble is, if you don't know how your customer measures productivity then how can you improve it? I have approximately 20 or 30 books on metrics in software engineering. Many of them contain attempts to measure the productivity of a software engineer. I am not aware of any metric that really works. If you know of such a metric: Please, I am begging you! Tell me!

An exercise: Let's assume you count lines of code (LOC).... Ok, ok, I got it. We want maintainable code so less is probably better.

Let's try "number of screens". This is more difficult. Do you want to have as much information on one screen as possible? Maybe the screens are used by professionals every day 200 or 300 days a year. In that case, again, less is more!

Let's try "number of stories". Ok, that's an easy one, isn't it? A few years ago a manager asked me how we could motivate the team to deliver more stories (For the less familiar: story = a small piece of work). I thought for a moment and then I said: "Just tell them!" Then he thought for a bit and understood that people would just make the stories smaller and smaller and so we would - on paper - see improvements all the time. In other words "inflation".

Let's try "Defined Scope": I have this statement of work that also includes "The Scope". Let's assume it contains the requirement that on one screen you need a table. For that table you want to reorder the rows because the sequence matters (think of prioritization items for instance). One way to implement that could be that each row gets a unique identifier (or you can select it), and then there are two buttons with "Up" and "Down". Functionality complete! - Well, hang on, wait a second. This is - at least for web applications - what we had about 10 years ago. Today, we need AJAX, and hence at the very least you want the rows to be draggable with the mouse. - Whatever you answer to this is - whether or not the fancy version is in scope or not - the difference between these two versions is about 1:10 in terms of effort.

So where does this take us? It's about scope. And it is about making sure you have the right scope in place. So wouldn't it make sense to precisely define the scope? Absolutely! Have you tried it to define scope in a "waterproof" way? If you were successful please let me know!

Yet another approach is: Just mandate more work to complete. Well, if you don't have family how can you possibly imagine that there are people out there who have family and who do care about their family? How do you know what it feels like if you have to call your partner that you won't be home for dinner? That you won't be home for the weekend? What if your kids start asking who you are? How would you feel? If you are a human being, you know exactly what I'm talking about.

I think all of this is not very constructive. Try to better specify scope is definitely a good thing. Assuming that the scope is completely defined at the beginning of a project - regardless of effort - is in my view a ridiculous assumption. As the project progresses you will discover new items. All IT project, all software projects are so complex that we have to assume that there will be new scope discovered. Do we know how much ahead of time? No we don't. We can try to "guess" as best as possible but there is no guarantee that we will be correct.

So it basically boils down to ensure that all stakeholders are involved, that they always get a sufficient and complete picture of where the project is going. If the remaining capacity is not sufficient for the remaining scope then this needs to be addressed as early as possible, so change management has to kick in.

Creating a blame culture and start finger pointing when coming under pressure won't help make any issue go away. A unilateral mandate or a dictatorial approach will destroy all teams. Requesting respect for one's role and at the same time ignoring a different persons role is destructive and ignorant. It reminds me of the days of the cold war. The Soviet approach was: What mine is is mine, and now let's negotiate about yours. We all know that this approach didn't survive.

Increasing and continuously improving communication and collaboration is the required forward looking approach. Contributing and constructively participating in a proper cross-functional team is where good solutions are created. (And whether or not you use an agile approach doesn't matter at all!)

Impact and Mitigation of Staff Turnover

In my last post I explored the reasons for staff turnover. Reasons can be monetary (e.g. salary) and non-monetary. In all cases the departure of a team member has consequences, some of which may become visible months later.

Example. For one release cycle a project team signed up for a backlog of 70 stories. Two weeks into the release cycle (12 weeks in total) the team got together and identified a few stories that were too large to fit into one iteration (1 week). As a consequence the backlog grew to 80 stories. The team asked the customer to re-prioritize the stories to identify the low priority stories that would have to be moved to a future release. Not surprisingly, the customer wasn't happy about this as it was perceived as "falling behind schedule". On closer investigation it turned out that the initial backlog contained stories that were too big for acceptance. These stories should have been split or re-scoped before the release cycle started. The person who would have spotted this had left the company just a few months ago. Other team members weren't sufficiently aware of the impact large stories could have. The team learned their lesson and it is unlikely that the same mistake will be repeated.

The important lesson to be learned is: The consequences of the departure of a staff member become apparent only as time passes, and sometimes this can be much, much later.

How could the mistake from the example be avoided? I think that it is important to re-emphasize the rules of the game as often as possible. You might sound like a "broken record". But consider the consequences if you don't repeat "the tune"...

The example also demonstrates that when a team member leaves, some knowledge and skills disappear as well. What are the options to mitigate the impact?

Agile methodologies provide quite a few techniques and tools that you can use. In particular all techniques and tools that foster communication, collaborations, and learning are suited to reduce or mitigate the impact to a large degree.

Release planning involving a good cross cut of different roles - developers, testers, customers, performance experts, technical writers, etc. - ensures that all relevant aspects are considered. Techniques like Agile Auction (aka Planning Poker (TM)) help to detect uncertainties or the need for further discussions.

Frequent reviews help to identify over- or under-engineering. Do you really need all these bells and whistles? Are the features implemented in a really compelling way?

Techniques and tools like Pair Programming, wikis and Show-and-Tells help fostering knowledge transfer and the acquisition of skills.

Keep it simple and try tons of different tools and techniques. Don't give up just because one tool or technique didn't work. If it didn't work, try something else. Learn from your observations. And always challenge your team for instance by asking questions like:

• Given this unsatisfying result can you think of a way how we can prevent a similar situation in the future?
• Given the suggested approach, can we think of an even better way of doing this?

Experiment and try new approaches. Doing that you'll have mitigate a large proportion of the possible impact of turnover.