How can one improve competency in a software development team? This is a critical question for a software development manager and this video of a presentation given by Jurgen Appelo at the 2010 Norvegian Development Conference provide an insight that attempt to answer this question.
You may also want to view the slides for this presentation.
I believe that Agile is a great tool to help development teams achieve more, improve, and reach their next level in effectiveness, productivity, or creativity. However, like any tool, it can be misused or misapplied. You can shoot yourself in the foot if you are not applying a certain level of discipline or hygiene.
Mike Griffiths posted a short and sweet article on this subject that he entitled Agile anti-patterns. He classifies those anti-patterns as follow:
You may have seen the video below as it was quite popular in the last few weeks. If not, I really encourage you to watch it as it is food for thought if you hold a job where you have to manage other individuals.
As a manager you’ve been taught, either by your peers, or through hard knocks, to avoid micromanaging your teams. You quickly learn that micromanagement only alienate people.
Anyway, I have noticed that delegation appears to be a difficult concept for inexperienced managers that I had the opportunity to mentor. Delegation does not come naturally. Newly appointed supervisors often think “If you want something done, do it yourself.”
Delegation of authority is an investment and you need patience and time to see your investment come to fruition. It may take a few weeks, a few months, or a year but your patience will be rewarded in the end.
This is the theme of Jurgen Appelo’s humorous article.
[via NOOP.NL]
Original photo by mrsmas and published under SXC license.
I just read an article from Jason Gorman, from Parlez|UML, on skepticism in software development. He explains that a lot of preconceived theories about software development abound but few of those theories have been thoroughly investigated and therefore, it is difficult to know if they bring value to the engineering process or not. For example, Jason mentions refactoring that claims to make changes easier without supporting research.
In my understanding, this leads to more academic research on those theories to validate them and also to explore their practical boundaries and limits. I believe that this is a perfectly valid, and necessary approach.
However, in parallel to this academic approach, I would have a tendency to take a more pragmatic route. If a concept like refactoring comes to my attention, I would try it out in my environment, see if it has value to my organization and decide, after retrospective, to continue using the method or not. Also, you can not detach the software engineering method or principle from the human component. The method, under properly applied leadership, has to be accepted and embraced by the programmers, testers, or UX designers that would use it. Therefore, the development team, including its lead, decides, if a particular theory helps bring more value to customers.
[via Parlez|UML]
