Ilja Preuss

Sean Landis wrote:

Working software is the primary measure of progress.

Let applicants do real work for you, in the real environment, with the team they will later be part of. That's the best measure on whether they will be a good fit.

There is something to be said for that and we do it in one form or other. I'd say though the primary measure in the hiring system is the quality and quantity of hires.

Yes. And the primary measure of the quality of hires is how well they do on the job (in contrast to how well they did in tests or interviews).

Roman Burdakov wrote:Agile couch?

In the last team I worked for as a developer, we had one in our team room. Proved to be very useful for afternoon naps. (Nice typo, couldn't resist... ;) )

It seems to me that we can use the model for at least two purposes:

* adapting our hiring process to the skill level of the applicant, and

* filtering applicants based on skill level for a certain position. Can we afford to have an Advanced Beginner in a certain position, or are we specifically looking for an expert? How do we find out who is?

It also occurs to me that the model doesn't really apply to a person as such, but to a *skill* of a person. So, someone could well be, say, an expert in debugging EJB applications, but a novice in OOD.

Hi,

I'm not a hiring expert, still I'd try to take a stab at it. I'll try to simply translate the principles to hiring, without judging whether it results in a good advice or not. ;)

Gagan Grover wrote:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Who is the customer of the hiring process? Probably the company we are hiring for. And the product is the work force. So "Our highest priority is to help the hiring company through early and continuous improvement of the work force"?

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

I see two main domains where change can happen in hiring: our understanding of what the company needs, and our understanding of the best job for an applicant. So if you find out that the person who applied as a, say, Java developer, would in fact make a great usability expert, see whether it would make sense to hire him as a usability expert. Don't cling to the original job description.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Not sure how to reasonably translate this.

Business people and developers must work
together daily throughout the project.

Applies directly to the hiring process: both business people and technical people must be involved in the hiring process to find the best candidates.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

Again, applies directly. Hire people that are passionate about their job, even if they are not a perfect fit, skill-wise. Trust them to acquire the skills they'll need.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Face to face. Anything needs to be said about this?

Working software is the primary measure of progress.

Let applicants do real work for you, in the real environment, with the team they will later be part of. That's the best measure on whether they will be a good fit.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Not sure how this applies to hiring. Any ideas?

Continuous attention to technical excellence
and good design enhances agility.

Don't let the hiring process happen to you, design it for your needs. Be sure you know exactly why you are doing each step of the process, and that it is the best way you are aware of to get the information you need for hiring.

Simplicity--the art of maximizing the amount
of work not done--is essential.

Any translation needed?

The best architectures, requirements, and designs
emerge from self-organizing teams.

Mhh, is the same true for hiring? Should teams do their own hiring, perhaps?

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

Certainly applies directly to hiring. Inspect and adapt.

Hi Jeanne,

the most important difference that comes to my mind is that contractors are probably hired for a shorter time frame, and may leave easier, so you don't want to invest as much into them. Consequently, when hiring, I would probably want to shift the focus from "how easily can they acquire the required skills" to "how many of the required skills do they already posses?"

Makes sense?

Hi Tom,

quite to the contrary, Agile is about continuous attention to design. The only way to be successful while embracing change is to keep the design simple and adapt it to new circumstances. A good Agile devoper never stops thinking about design issues.

Well, I'd say, the important thing is that you write *tests*.

If you don't know what you would do with a test plan, I'd suggest to try an experiment and see what happens if you simply do without it. And once you actually miss something important, you will have a much better idea of what you need.

What are you writing the test plan for? What will you do with it, once you have it?

In that case, I recommend "Agile Testing" by Lisa Crispin.

There are dozens of good books on Agile out there.

What makes you interested in Agile? What do you already know about it? What is it that you want to learn next? Are you specifically interested in testing?

Why do you generall need a spike task? And if you don't know how to break the story into tasks, how could you estimate it?

Curious, Ilja

The official description of Scrum can be found in the free Scrum Guide: http://www.scrum.org/scrumguides

What kind of interaction between the team and the customer are you thinking of? What's your knowledge of Scrum, and why are you interested in this?

The best way I know of is acknowledging that his perspective is in no way less valid than mine. And to keep in mind that such a decision is always far from being objective, anyway.

When you discuss this topic, always be clear that the goal is not to use library X. The goal is to solve a problem. You first need to agree on what the problem is. Then you need to agree on what the criteria are for solving the problem. Then you should explore options: what different solutions are available? Be creative. Only then you can make a good decision.

Also keep in mind that a decision doesn't have to be final. Often the best decision you can make is in the form of a timeboxed experiment.

It also doesn't need to be in favor of exactly one solution. Often it makes sense to try several solutions in parallel for a time, to be better able to evaluate them. Make sure that it's not just "everyone evaluates his prefered solution".

Hope this helps.

In Kanban, the system gets released whenever the responsible business person decides to.

Scrum doesn't specify when or even whether to "tag" the code base. That's deliberately left open for the self-organizing team to decide.

First, Agile Software Development is NOT a methodology. It would rather describe it as a movement, perhaps a philosophy.

Scrum and XP both are approaches (I hesitate to say "processes"), that contributed to the Agile movement.

Lean Software Development is inspired by Lean Manufactoring, which is inspired by the Toyota Production System. From what I know, it looks like a rather high level description of the forces of software development, which makes it look to me at rather a similar level as the Agile movement.

Kanban is a project management process that is also inspired by a process of the same name from the Toyota Production System. It is roughly at the same level as Scrum, and can be seen as an alternative to it. There is also a hybrid process called Scrumban.

Lean and Kanban are generally considered to be very compatible with the Agile mindset. I would consider them part of the Agile family, but I have heard of people who would disagree.

Does that help?