Here are some material that will be referred to in Mortens and my talk at NDC2010:
The slides for Modularization, testing and technical debt (in a large agile project) is available at http://www.slideshare.net/harals/modularization-testing-and-technical-debt-in-a-large-agile-project
A whitepaper on the same topic (from the proceedings of the XP2010-conference) can be found at http://www.slideshare.net/harals/cou
Viser innlegg med etiketten scrum. Vis alle innlegg
Viser innlegg med etiketten scrum. Vis alle innlegg
onsdag 16. juni 2010
tirsdag 25. mai 2010
XP2010 accept
The 11th International Conference on Agile Software Development is coming up (June 1-4 in Trondheim). Unfortunately, I will not be able to be there. But I have been authoring and co-authoring some material for the conference.
First, Morten's and my experience report "Tech Challenges in a Large-Scale Agile Project" was accepted, and will be both presented and included in the conference proceedings:
This experience reports focuses on the major technical challenges that arose during the project, especially those challenges that we think can be attributed to the SCRUM methodology. For each of them, we try to identify the consequence and the cause, and then follow up with any solutions we tried, and an analysis of whether the problem was successfully solved or not. The session paper lists three major examples of such problems.
Then, I got accepted a lightening talk as well: "Agile Methods may Discourage Quality". However, since I have to be attending a customer at the time, Morten will be presenting this instead of me.
Agile methods, and in particular scrum, have a very strong focus on productivity and immediate business value. The developers are encouraged to complete their tasks in due time, and this may lead to quick and dirty solutions. Thus, a quality assurance system is required to ensure that technical quality is within required bounds. This system may be implemented through pair programming, code review, design review etc. It is crucial that whatever QA systems one choose, it has strong enough authority to inflict a decrease in focus factor, or even a postponed deadline.
Cheers and good luck to you all in Trondheim! See http://xp2010.org/
First, Morten's and my experience report "Tech Challenges in a Large-Scale Agile Project" was accepted, and will be both presented and included in the conference proceedings:
This experience reports focuses on the major technical challenges that arose during the project, especially those challenges that we think can be attributed to the SCRUM methodology. For each of them, we try to identify the consequence and the cause, and then follow up with any solutions we tried, and an analysis of whether the problem was successfully solved or not. The session paper lists three major examples of such problems.
Then, I got accepted a lightening talk as well: "Agile Methods may Discourage Quality". However, since I have to be attending a customer at the time, Morten will be presenting this instead of me.
Agile methods, and in particular scrum, have a very strong focus on productivity and immediate business value. The developers are encouraged to complete their tasks in due time, and this may lead to quick and dirty solutions. Thus, a quality assurance system is required to ensure that technical quality is within required bounds. This system may be implemented through pair programming, code review, design review etc. It is crucial that whatever QA systems one choose, it has strong enough authority to inflict a decrease in focus factor, or even a postponed deadline.
Cheers and good luck to you all in Trondheim! See http://xp2010.org/
mandag 10. mai 2010
Technical debt in agile projects
I'll be presenting my opinions on technical debt in agile projects at Communities in Action 2010 tonight.
The presentation can be found at slideshare but I'll let you in on my three "lemmas" as a tech lead:
The presentation can be found at slideshare but I'll let you in on my three "lemmas" as a tech lead:
make it simple and easy to report a technical shortcoming
don't let it backfire on the whistleblower
decide the matter in a setting with both technical expertise and executive power
mandag 5. april 2010
NDC 2010 accept
Against all odds (?) - Mortens and my paper ("Modularization, Testing & Technical Debt in a Large Agile Project") was accepted for the Nordic Developer Conference 2010. Well then, even though it's experiences from a Java project presented at a .Net conference, both sides has the agile dimension in common.
But it's still somewhat comical to present in "the dragon's lair". The presentations is scheduled for day 2, track 2 at 11:40 - in parallel to Eric Evans .. yikes.
The abstract reads:
In addition, my colleague Filip van Laenen was accepted with his presentation "Distributed Computing 2.0". See http://www.ndc2010.no
But it's still somewhat comical to present in "the dragon's lair". The presentations is scheduled for day 2, track 2 at 11:40 - in parallel to Eric Evans .. yikes.
The abstract reads:
This experience reports focuses on the major scrum–related technical challenges that arose during a 120 000 hour scrum controlled project. For each of them, we try to identify the cause and the consequence, and then follow up with any solutions we tried. Finally we sum up and assess whether the problem was successfully solved or not.
In addition, my colleague Filip van Laenen was accepted with his presentation "Distributed Computing 2.0". See http://www.ndc2010.no
torsdag 29. oktober 2009
Scrum and Technical Debt
This years Smidig-conference is over, and I've had a week to digest the impressions. Overall it was a great experience. Lots of lightning talks, open space discussions and even some beer. My talk on Scrum and Technical Debt created some fuzz in the following open space discussion, so I guess it must have stroken s chord in some of the listeners :)
Janniche from Bekk challenged me on my claims, and frankly I think she may have a point. She argued that if tech debt seems to hide away in scrum, we are using scrum in the wrong manner. Technical debt should be up front, and thus decrease the focus factor. It requries developers to be honest and professional about their craftmanship. So maybe we should spend some hours on tutoring instad of repairing old defects ..
The presentation is unfortunately not available on video, but the slides can be found at http://www.slideshare.net/harals/scrum-skjuler-teknisk-gjeld-2277766
Janniche from Bekk challenged me on my claims, and frankly I think she may have a point. She argued that if tech debt seems to hide away in scrum, we are using scrum in the wrong manner. Technical debt should be up front, and thus decrease the focus factor. It requries developers to be honest and professional about their craftmanship. So maybe we should spend some hours on tutoring instad of repairing old defects ..
The presentation is unfortunately not available on video, but the slides can be found at http://www.slideshare.net/harals/scrum-skjuler-teknisk-gjeld-2277766
Abonner på:
Innlegg (Atom)