Back From South Africa! Successful talk and Excellent Workshop

 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!

How to Fail with Agile

My talk was about How to Fail with Agile. Several years ago, I have written an article about this topic at Scrum Alliance, which listed some failure patterns in agile practice adoption. But, after more years of experience, I have designed this talk into two parts:

• 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. 

Sustainable Legacy Code Refactoring Workshop

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.

These are some of the ideas I tried:

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.

Here are some of the written feedback which I received from the workshop attendees:

• A very enlightening workshop! The importance of refactoring code was greatly realized during this workshop 
• A very informative workshop. Very useful. Will try to incorporate the lessons learned 
• 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. 
• Helpful workshop. Fully appreciated the importance of code refactoring techniques 
• 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?

An excellent analysis of the maintenance profession in Dennis Smith's book: Designing Maintainable Software. According to Dennis, the profession of maintenance makes programmers working on maintenance feel that they are inferior to their colleagues working on new development, and they are generally perceived to be less competent and doing less important job in the software team in general. According to Dennis, this positively complicates code because this process selects the most junior and least competent programmer to maintain code in an unprofessional and improper way, which makes code become poor, if not already very poor:

Here is a book excerpt on page 8 describing the problem:

"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."

Then, he says the result of this approach:

"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)"

This is an excellent articulation of one of the problems that we face in this profession. There are other major differences which he lists among comparing working for maintenance or new development:

1. Maintainers usually work individually while new development work in teams
2. 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.
3. 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. 

How Kanban Works

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.