Two weeks ago, I was invited to deliver a talk and a workshop at AgileAfrica 2014. In fact, this year's edition of the conference is amazing. It is very well organized, the venue is great, and most important, the content of the conference was very well selected.
Joburg from the conference hotel roof. A place full of life!
Failure to adopt the agile mindset: Successful agile transformation requires a mind-shift from traditional/fixed mentality to responsive/adaptive mentality. This is why I say that agile adoption is a transformation project of persons, not processes, tools, or customers! If persons fail to change the way they think about software development, it is likely they'll fail to apply scrum, use tools, or convince their customers to be more collaborative.
Failure to adopt some agile practices: Even if people are succeeding in adopting the adaptive and agile mentality, they may still fail in adopting practices. The main reason in my opinion is that the team does not grasp the value of practices. The second reason is implementing one practice while it will never succeed except with another practice. I called this twin practices.
I have also conducted a one-day refactoring workshop, which I used to deliver in Egypt for many years now. However, in South Africa, I have introduced several changes to the way the workshop is delivered. This, in my opinion, was a turning point in the workshop effectiveness!
In this edition of the workshop, I tried to resolve many issues faced in previous rounds. For example, issues with tools setup, being overwhelmed with the too many questions and issues faced by trainees, unable to track the progress of individuals doing the exercises; sometimes, I completely lost several attendees who check out from the exercise due to issues they face.
Working in pairs was a great enabler. Even if you are a genius, you will need someone to remind you with a missing semicolon or an open bracket!
A task board for every pair, in which they show their progress with the workshop exercises. This gave me visibility of progress and problems, and enabled me adjust the pace accordingly.
On-Wall Reference. A technique that I used to help the trainees. They can instantly get help about possible refactorings that they may apply to work with exercises.
I have also introduced several key enhancements in the workshop, like writing detailed step-by-step guidelines, adding breaks in which I explain key concepts in between exercises, working in iterations, and some other enhancements in the training content.
Great workshop. would be advantageous if it was spread out to two days. This would allow people to put to practice the tools and material learn. We then could see how we've absorbed the material better.
Very instructive course. I have learned how to refactor a code using modern tools than manual refactoring.
Awesome workshop. Thanks Amr !!
Actually, it was amazing to receive all this positive feedback al7amdulillah (thanks for Allah). Soon inshaAllah, I will plan several other public rounds in Egypt and the Middle East.
What Makes Maintenance Goes Awry?
"Careers in programming typically begin by maintaining computer software . Maintenance is considered a relatively harmless activity where entry level programmers can become proficient in the craft (Gorla 91; Rombach 91)"
This, in my opinion is the basic assumption, which makes things go awry with maintenance, which is maintenance is relatively easy and does not need experienced programmers to perform.
"While in maintenance, programmers are expected to obtain a thorough understanding of the department's software conventions, the idiosyncrasies of computer equipment, and the company's culture and methods of operation. Programmers in maintenance are aware that they are at the bottom of the professional hierarchy and look forward to leaving their present assignment. Maintainers demonstrating superior ability advance into more creative positions, such as development programmer, systems analyst, or information specialist. Other's migrate to different positions within the company, or gain employment in another concern where rewards and opportunity for professional growth are more promising. The rest have maintenance as a career."
"That leaves the task of keeping software properly functioning to programmers who are poorly motivated, have low esteem, and possess marginal skills (Glass & Noiseaux 81)"
There are almost no planning which takes place. This opens the door for a lot of up's and down's in the maintainer's work. This in practice creates a non-sustainable career.
Maintainers usually does other tasks which are marginal an even less important than programming (in their opinion) so that to fill the gaps in their free time.
This is the title of my first article on infoq.com: How Kanban Works, published on July 31st 2014. In this article, I have tried to explain using examples and case studies how (or why) kanban works in software development.
Have a look at it and let me know your opinion.