Jiri Lundak

Archive for the ‘Scrum Agile’ Category

Courageously “Kicking Dead Weight”

In Agile, Leadership, Scrum Agile, Team, Values on March 31, 2013 at 2:22 am

This is the first installment of a small series on trimming away fat, that inhibits organizations in realizing full potential, when trying to adopt Agile ways.

First let me make one thing clear: this is also about one value, that often seems to fall by the wayside. I am talking about courage. People tend to minimize the impact agility has on their organization. This is a natural reaction, because we have all the inclination to self-protect, our position, our job, etc. On the other hand we – as Agile change agents – want to maximize the impact of agility in the organization. So, to take action, we must go against our natural inclination. And this is really hard… but usually worth the effort.

“Kicking dead weight” or getting rid of processes, ceremonies, activities and even people, that do not contribute to our goals, is very hard to do, but extremely necessary. It might even be very urgent in your project.

Years of experience show me, that many organizations (especially larger ones) have lost control of their appetite (for “resources”, for regulation and for simultaneously ongoing projects). How comes?

They take on more projects than they can handle. They add external people, because they have not enough themselves. They are not able to control this much people, so they add rules. They have not enough people that check compliance with the rules, so they add more people, making projects heavier and more complex. Then the cycle starts again.

Once people are hired, processes are installed and rules are established, getting rid of them is seen as daunting at best and impossible in all other cases. Why is this so hard? Because many people contribute to the problem (sometimes unknowingly) and only few, if any, try to solve it. Many people joining the company just take existing rules and behaviors as unchangeable company policy and have usually not the courage and/or time to act on it.

Now, let us focus on the people problem. How can we get on top of it?

Here are some basic principles, that come to mind:

  • Think twice about who you hire: First think “Do we really need to fill that position?”, then “Can we just shift forces internally?”, and if you really need to hire somebody “Has this person really the skills to help us?”. Choose wisely with highest possible standards. Put candidates to the test. Do not just let HR decide. Make your teams choose the people they want to work with.
  • If possible, never hire external people: If possible to not overcommit in the number of project you staff can handle. When hiring external experts, you often end up devaluating your own people. The simply do not get any chance to build up new skills. This is a death spiral, leading to even more dependency on exteral help. And what is worse, you even loose the ability to judge the goodness of the external people's work.
  • If you have to hire external experts: Do not create a Troian horse, where the providing company can send you anybody they like. Treat external people like your internal ones. Evaluate them with the same rigour and diligence as you would when hiring for a top notch permanent position. When hiring them, do it only for a limited period of time. Make it paramount, that they teach your own people how to do the job well. It is better to give the complete project outside or buying an off-the-shelf product, than having a pseudo-internal project.
  • People just do not cut it: If you have people on your team, that do not solve problems, but – on the contrary – often contribute to create them, then do not hesitate to try to help them. If they live not up to the chance, remove them. How do you know someone, who does not contribute? If you collaborate closely with your team, you will know. Else ask the team. They know the good people. External people, that are of no help, should be immediately removed.

I know this might sound hard, but it is the only way to improve things. But remember: it takes courage. You need courage to go counter useless policies within you company. You need courage to face a person, that you need to correct or even remove.

In the next installment we will talk about trimming processes.


…And Should We Keep In Mind

In Agile, Agile Development, Scrum, Scrum Agile on May 4, 2012 at 12:50 am

That we always start from different positions and situations in any one organization.

That my organization (team) is not your organization (team).

That sheer size makes things complicated and long-winding.

That – because of entropy – things tend to fall apart.

That boundaries are fuzzy and thus changes come along leaky and not clear cut.

That small changes can have huge impact.

That a bigger and divers toolset available to you, gives you more leverage to cause or to react to change.

I totally agree with Ron Jeffries, when he states:

“Agile, Scrum, XP, Kanban, Lean: the same elephant, different points of view.”

And I would add:

“…and you can make it dance or pull tree trunks, just not at the same time.”

Because context is needed to choose your tools wisely. And as with software engineering ability: the more you practice using your tools and the better you master them, the more you are able to apply them, when need arises. And the more varied your toolset, the more possibilities of intervention you have.

What ways to you know that could improve the situation and in which context where you successful?

Recruiting People With Agile Potential

In Agile, Agile Development, Scrum, Scrum Agile on March 9, 2007 at 11:48 pm

We are currently in need of new developers and testers for our teams. As we try to live Scrum as an Agile development process I often ask myself, what kind of criteria we should expect of the candidates, besides the usual developer or tester skills.

Sure you can not see inside the cadidates’ mind. But more and more we try to ask Agile questions during the interview. Often I ask a question, that I hope will show the candidate’s attitude towards Agile practices and values and to see whether he would have the potential to lead other people by giving them a strong example.

One such question was recently: “The build fails. What will you do?”. The usual answer I get is: “I will fix the build.”. Then I add the tweak. “But, if your code did not break the build?”. Often people then revert back to the ‘I am not responsible for THIS!’ attitude, so they say “I wait till the build is fixed by the developer who broke it.”. The better one’s will propose: “I contact the developer that broke the build and we resolve the problem together as soon as possible.”. As I often see people not acting pro-actively, but in the ‘wait and see’ manner, I hope to get more people on board, that act on problems, instead of tending only their own garden.

Another question I recently asked a potential senior developer and team lead was: “Your team seams not to be able to deliver the functionality they commited to at the beginning of the sprint, because of quality problems. Your demo with the customer at the end of the sprint is to be compromised. What do you do?”. One answer to this question was: “I go to the customer and postpone the demo.”. Boing, a warning sign! Further questioning revealed, that this candidate did not even know what a commitment within an iteration was and how it worked.

Another small test I do with candidates is to refactor a piece of bad code with them in a pair programming fashion. I am not so much interested in solving the particular problem at hand, but in the way the person approaches the problem, how she thinks about the code and how she works herself through to understand it. Does she write a unit test first to frame the working code? Does she rename variables and classes to have a better grasp of what the code is doing?

To people previously not exposed to Agile development I first explain our development approach (Scrum) and then try to ask practical a question on consequences this has on the interaction between team members or between developers and the customer (product owner). Their answers usually reveal a good deal about themselves. How they think about the development process, what they would like to happen in a development process, etc. The additional question I then add is: “What would YOU do to improve the process?”. So I try to at least see how their attitude is concerning the development process. How do they want to live their lives as software developers? Do they think about improving something, they see, is going wrong?

What are your questions you come up with to check for job candidates’ compatibility with Agile values? Let me know about it.

Technorati :
Del.icio.us :