Tuesday, March 27, 2007
A Really Short Release Cycle and An Impressive Quality
Just came across a blog entry by David J. Anderson. His company releases every 9.5 business days and with zero defects since January 2007! Impressive!
Agile Certification
In a recent post of a position paper on "Agile Certification" the chair of the Agile Alliance describes the various aspects of whether a certification for agile practitioners should be introduced or provide value.
I'm convinced that there will be people who believe that certification provides value to them for recruitment purposes. With the teams I work we use different means to determine whether a candidate fits the team. That by itself is already a statement: We don't look for certifications, we look for "good fit". Someone can have all the certifications on the planet, we will not hire that person if he/she is not a good fit for the particular team.
Just the other day we had an application by a candidate who used "throw new NullPointerException()" in the programming task. In this particular case we tried to imagine what would happen if we had that bit of code in a deployed system, and the exception fired off... No certification in the world can prevent that, and in the particular case we didn't consider the candidate any longer.
Here are some other things we do when we assess candidates:
In the teams I have worked with I have met accountants, biologists, former HR people, and many more different professions. All of them had degrees and certifications, most of them in areas other than software engineering. And still, all of them were excellent software engineers!
And then, there are the companies that get ISO9000 certified. Sometime people I wonder what that is good for except for becoming supplier for certain companies. Does it mean that the quality improves or the productivity? It might, it might not. The ISO9000 certification certainly doesn't guarantee that. There are companies that are ISO9000 certified and still deliver crab, and there are companies that are not, and they deliver outstanding quality.
Hey! I tried to lean towards the more provocative end of the spectrum in this post. So if you, my dear reader, have a different perspective, I would love to hear from you!
I'm convinced that there will be people who believe that certification provides value to them for recruitment purposes. With the teams I work we use different means to determine whether a candidate fits the team. That by itself is already a statement: We don't look for certifications, we look for "good fit". Someone can have all the certifications on the planet, we will not hire that person if he/she is not a good fit for the particular team.
Just the other day we had an application by a candidate who used "throw new NullPointerException()" in the programming task. In this particular case we tried to imagine what would happen if we had that bit of code in a deployed system, and the exception fired off... No certification in the world can prevent that, and in the particular case we didn't consider the candidate any longer.
Here are some other things we do when we assess candidates:
- Pair programming session
- Programming task
- Design session
- Google search (if the candidate is claiming to be an active member of the community)
- Peer interviewing by members of the future team
In the teams I have worked with I have met accountants, biologists, former HR people, and many more different professions. All of them had degrees and certifications, most of them in areas other than software engineering. And still, all of them were excellent software engineers!
And then, there are the companies that get ISO9000 certified. Sometime people I wonder what that is good for except for becoming supplier for certain companies. Does it mean that the quality improves or the productivity? It might, it might not. The ISO9000 certification certainly doesn't guarantee that. There are companies that are ISO9000 certified and still deliver crab, and there are companies that are not, and they deliver outstanding quality.
Hey! I tried to lean towards the more provocative end of the spectrum in this post. So if you, my dear reader, have a different perspective, I would love to hear from you!
Thursday, March 22, 2007
Embracing Change: What Stays Constant?
My experience is that many people like to have something that doesn't change. Sure people understand that to stay in the game, we need to adapt as quickly to new situations as possible. Only if we are fast enough, the ability to adapt can be turned into a competitive advantage.
But then I observe the people I work with, I observe myself. And I discover that they as well as myself, we are still looking for something that stays a little bit more constant.
And when we take a closer look there are things that stay constant. We change the tools, we change the architecture, the designs of systems, and retire tools in favor of better tools. We change the techniques and processes. We create a flow of all these elements of software engineering. And yet, there are things that stay the same: It is the values and principles that we apply. The people I work with, and myself, we have chosen the agile values and principles as a guideline, as a foundation for how we work. They provide us with the foundation, with that sense of fixture.
Some of the more traditional projects and teams that I have seen in the past, they, too, have things that stay constant and things that change. They often have chosen the process to stay the same, for instance with all the artifacts that people create, but which sometimes don't provide as much value as they require effort to create and maintain them. And the thing that changes are the values. Sometimes they claim that they respect the human individual, their people's dignity. But then, during the execution of the projects, these are the things that go overboard first. With pressing deadlines people are overloaded, with a shortage of people, contractors are parachuted in, with problems popping up here and there, people are moved around (ever heard of a "Move Meeting"?). Should we as leaders really be surprised, if no hand shows up when we ask the question, whether people feel treated as being human individuals?
There is better ways, and one of the questions we should continuously ask and answer is which elements we want to keep constant, and which elements are the ones where we want our teams to be adaptable. If we decide to keep our values and principles constant, and want to change the way we work, the technology, the design, the tools, the processes, then we are usually in a much better position for success! And all people on our team and the stakeholders will have more fun, too!
P.S. I had a very good discussion today on this subject. Thank you Raymond, Mark, and Curt!
But then I observe the people I work with, I observe myself. And I discover that they as well as myself, we are still looking for something that stays a little bit more constant.
And when we take a closer look there are things that stay constant. We change the tools, we change the architecture, the designs of systems, and retire tools in favor of better tools. We change the techniques and processes. We create a flow of all these elements of software engineering. And yet, there are things that stay the same: It is the values and principles that we apply. The people I work with, and myself, we have chosen the agile values and principles as a guideline, as a foundation for how we work. They provide us with the foundation, with that sense of fixture.
Some of the more traditional projects and teams that I have seen in the past, they, too, have things that stay constant and things that change. They often have chosen the process to stay the same, for instance with all the artifacts that people create, but which sometimes don't provide as much value as they require effort to create and maintain them. And the thing that changes are the values. Sometimes they claim that they respect the human individual, their people's dignity. But then, during the execution of the projects, these are the things that go overboard first. With pressing deadlines people are overloaded, with a shortage of people, contractors are parachuted in, with problems popping up here and there, people are moved around (ever heard of a "Move Meeting"?). Should we as leaders really be surprised, if no hand shows up when we ask the question, whether people feel treated as being human individuals?
There is better ways, and one of the questions we should continuously ask and answer is which elements we want to keep constant, and which elements are the ones where we want our teams to be adaptable. If we decide to keep our values and principles constant, and want to change the way we work, the technology, the design, the tools, the processes, then we are usually in a much better position for success! And all people on our team and the stakeholders will have more fun, too!
P.S. I had a very good discussion today on this subject. Thank you Raymond, Mark, and Curt!
Subscribe to:
Posts (Atom)
