Tuesday, July 14, 2015

Lean CMMI - My Presentation at Agile2015!


First and foremost, I'm so grateful and thankful to Allah (God) for helping me getting through this research paper. Not only that, I got it accepted in the Agile Conference 2015; the biggest Agile conference in the world.

I have published several papers before, but they were all industrial reports. Industrial reports (aka experience reports) document useful experiments done in the industry. As opposed to research papers, industrial reports do not necessarily use a scientific method to prove something.

My personal opinion, Industrial Reports are very useful, and probably more valuable than research paper. They reflect real experience and one can draw benefit from it right away. So, if your audience are software practitioners, then research papers are not the right means to communicate your experience to them :)

If this is the case, why did I write a paper? Two reasons:
  1. The first reason is that I had data! and found it interesting to experiment writing a paper.
  2. The second reason is to write a proof that incremental approaches in process improvement is better that holistic approaches. 
Here is a link to the abstract of the paper: Lean CMMI: An Iterative and Incremental Approach to CMMI-Based Process Improvement.

In this paper, I'm comparing results of process improvement in Configuration Management process area of CMMI. The first group of results are based on traditional process improvement effort (one process area at a time). The second group of results are based on the 'Process Increments' method, an iterative and incremental approach for software process improvement. This model divides improvements into small chunks as in the following model:



These Process Increments are dynamic. You can add, remove, re-prioritize them as needed. It's like user stories in software projects.

The results of the study are in the following diagram. It's a box plot of SP ratings in semi-formal CMMI appraisals. As you see, the ratings in the second group of companies are much higher than ratings in the first group of companies. is as follows:


Those who knows six sigma or has experience in research would know that these results are real proof that iterative and incremental methods works better!

Saturday, April 25, 2015

8 Months of Being Self-Employed!

Today is my 8th month after resignation from SECC and becoming self-employed at Agile Academy. This was a challenge full of new experiences, problems, obstacles, failures and successes :)

It's like any new startup experience, in which you're doing everything which you used to get them done by whoever else! Many things changed in my life like being with my wife and children for a longer time, setting in front of my laptop for a longer time, thinking about business and opening new opportunities. It's an experience in itself, not to be expecting any income at the beginning of every calendar month .. :(

One thing I noticed is that what Allah gives you cannot be compared to your effort. Of course you have to exert all what you can so that Allah give you, but it's always Allah's will, and I felt so relieved when I finally understood that Allah will not let you down as long as you are doing all what you can .. Al7amdulillah.

One very important thing to consider is that you have to always do what you like and what you know. Both are important. Then, الرزق will come along the way, whether through direct work you produce or through any other route.

One more thing .. It's not appropriate to work day and night. You have other obligations in life which you have to fulfill, like your parents, your wife and children, your own self, and before all of that, your Lord Allah SWT.

Friday, March 13, 2015

My Article about Technical Leadership

My second article published at infoq is for Technical Team Leaders. It's a post which I filled for many many years, and I have collected all my observations about what should a TTL be doing with the team in this article.

http://www.infoq.com/articles/technical-leadership-overseen

good read :)

Sunday, December 14, 2014

Tragedies of Performance Evaluation of Software People

I'm constantly having conflicts with managers who insist on backward methods of performance evaluation for agile teams. It is one of the miseries of software teams, because in most cases, such methods demotivate individuals and undermine team values. The issue is serious to the extent that Professor Edward Lawler wrote a recent post in Forbes magazine titled: Eliminating Performance Appraisals. In this post, prof. Edward questions whether organizations should stop doing performance appraisals altogether, because they “do more damage than good”, and “when poorly done, they create a multitude of problems”!
I felt I have a moral obligation to write something in this regard. My contribution in this post is a collection of resources and an attempt to structure the topic into three high level subtitles:
  1. What's evil about performance appraisals
  2. Should smarter people be rewarded more money (as a means of motivation)?
  3. Using process data for the sake of individual performance
If you are a smart person suffering from a performance evaluation scheme from the middle ages, send your HR manager this post, and let him read the resources mentioned below. May be (I'm not sure) it may help.

1. What's evil about performance appraisals


First, this is an article: Should I Rank My Employees? from the Wall Street Journal. It mentions the following interesting survey:
"Stanford professors Jeffrey Pfeffer and Robert Sutton are among the most fervent critics. They cited a survey of more than 200 human resources professionals from companies employing more than 2,500 people that found that even the more than half the companies used forced ranking, the respondents 'reported that forced ranking resulted in lower productivity, inequity and skepticism, negative effects on employee engagement, reduced collaboration, and damage to morale and mistrust in leadership.' … "
Another blog by the famous software engineering management author: Esther Derby titled: Should a ScrumMaster (or any coach) Give Performance Appraisals? In this blog, Esther asks how would it be good while "psychologists know that 80 percent of people believe their performance is above average"

The topic of performance appraisal are very controversial to the extent that one of the so famous books in management in the last years is called: "Abolishing Performance Appraisals: Why They Backfire and What to Do Instead"

2. Should smarter people be rewarded more money (as a means of motivation)?


We need to change our believes that a merit system will not work unless it ranks employees into classes and every class is motivated by some more money.

This is a must-see master piece by RSA Animate: Drive: The surprising truth about what motivates us:

In this short animation, they attack very strongly the idea about motivation using financial incentives when it involves cognitive and knowledge work. At minute 1:50 till 4:15, this animation sites the results of a study done by three top universities in Engineering and Technology: MIT, University of Chicago, and Carnegie Mellon university:
"As long as the task involve only mechanical skill, bonuses worked as expected (higher pay = better performance). But, once the task called for rudimentary [basic or simple] cognitive skill, a larger reward led to poorer performance!"
Also, one of the most important books in software engineering history is Rapid Software Development: Taming Wild Software Schedules by Steve McConnell. This book was named the best Software engineering book in the year by Software Development magazine's Jolt Award. Please refer to this book to understand what motivates Software engineers. Chapter 11: Motivation is the best reference I read about motivating software engineers. In page 262, you'll find this quote: 
"At least two-dozen studies over the last 30 years have shown conclusively that people who expect to receive a reward for doing their jobs successfully don't perform as well as those who expect no reward at all (Kohn 1993). The work itself is the greatest motivator, and the more a manager stresses an external reward, the less interested the developer becomes in the work itself, and the more potential motivation is lost."
The author makes a very clear alarm that incentives has many forms which are non-monetary like:
  • Dinners with company executives
  • Vacation-time bonuses
  • Gifts of appreciation (theater tickets or dinners for two)
  • Sincere praise directed at a specific accomplishment
  • Team T-shirts, polo shirts, rugby shirts, watches, pins, mugs, posters,
  • Humorous or serious awards in the form of plaques, certificates, trophies, and the like
  • Special events to celebrate significant accomplishments; depending on your team's preferences, and event might be a dinner at a favorite restaurant, a show, a trip, a ski day, or a dinner at the boss's house (or, for maximum effect, the boss's boss's house)
  • Exceptions to company policies for the team, such as casual-dress Friday, a Ping-Pong table in your team's section of the building, free soda pop in the team refrigerator, and so on
  • Special courses (outside the local area)
  • Sponsorship at conferences that the organization would not ordinarily sponsor
  • Grade-level promotions
You can download this book from this location.
One more article called One More Time: How Do You Motivate Employees?, which sold more than a million reprints making it the most popular article in the history of the Harvard Business Review. In this diagram, notice the particular position of the salary and it's weight as a demotivator rather than a motivator. 
Motivators and demotivators - Notice that salary (money) is not among the motivators, but rather a demotivator is not enough
Actually, what this diagram tells us is the same exact phrase mentioned in the RSA movie above at minute 4:50:
"If you don't pay enough, people won't be motivated. Pay people enough to take the issue of money off the table"

3. Using process data for the sake of individual performance


Forcing managers to use process data, like feature estimates, number of bugs, reported actual hours, etc. to evaluate team members will blow up the process metrics themselves. This, in turn, has a drastic effect on the process itself, making the team process-blind (not being able to improve the process based on process metrics) Being process-blind is the direct result of exploiting process metrics and reuse them as Targets, and as per Goodhart's law: "When a measure becomes a target, it ceases to be a good measure."
Why this happens? To understand the dynamics, let's recall the general rule put by Tim DeMorko, the author of the great book: Peopleware: Productive Projects and Teams's, a book which had an impact on the whole industry; the general rule is known as DeMarko's Principle:
"Effort moves towards whatever is measured"
This can happen subconsciously or even consciously; and this is considered one of the major pitfalls of measuring, as explained the this article: The seven pitfalls of performance measurement which considers: Risk of manipulation of performance data as one of them. When it comes to individual evaluation, use of process metrics becomes a real risk, and opportunity of manipulation is so widespread. Writers have been noting this again and again, to the extent that some writers like Eli Goldratt, the father of Theory of Constraints says:
"Tell me how you measure me, and I will tell you how I will behave!"
In summary, using process metrics to evaluate individuals distorts the metrics and after a while, the metrics lose their meaning and cease to reflect real process data.

A Final Word


Finally, I have to say that this topic is vast and needs a lot of effort to make a shift in the mindset of project and HR managers of software in Egypt. It is not easy, but impossible is not on my dictionary :)

Monday, October 20, 2014

Integrating Jenkins and ConQAT to Enable Continuous Clone Detection

One of the great features of ConQAT is its ability to detect code clones (duplicates). On the other hand, CI servers like Jenkins enables you to automatically check for code quality attributes. If we can merge both, this will become an invaluable tool for technical team leaders and will save them a lot of review effort.

Here is how you can do this:

Step 1: Define Your Policy of Preventing Code Clones

This is done by specifying the ConQat Run configuration files (.cqr) using eclipse. That is, create a cqr file which detects kinds of duplicates that you don't want to see in the code altogether.

For example, you may define a cqr file which detects exact code clones of length greater than 10 lines of code. This is a screen shot of a cqr file which does exactly this job:

ConQat Run conf file with parameters

Step 2: Invoke ConQAT cqr from Jenkins

Ant can do this using shell scripts or command lines, as follows:
cd  <ConQat Location>\conqat\binconqat -f <cqr file location>\JavaCloneAnalysis.cqr
 Note: Make sure that you specify the output directory in the configuration file appropriately, because Jenkins will be accessing it later in the next step

Step3: Introspect the clones.xml file, and fail the build if it has clones

Let Ant check the clones.xml file generated. This is an ant target that does this job, add it to your build.xml file:
<!--=========================================================================
Check the file named in the property file.to.check (the clons.xml file) to see
if there are any clones.

The way this works is to find all lines containing the text "cloneClass" and put them into a separate file.  Then it checks to see if this file has non-zero length. If so, then there are errors, and it sets the property clones.found. Then it calls the fail-if-clones-found target, which doesn't execute if the clones.found property isn't set.
-->
<target name="check-clones-file"
        description="Checks the file (specified in ${file.to.check}) for clones">
       <property name="file.to.check" description="The file to hold the clones" />
       <copy file="${file.to.check}" tofile="${file.clonecount}">
              <filterchain>
                     <linecontains>
                           <contains value="cloneClass" />
                     </linecontains>
              </filterchain>
       </copy>

       <condition property="clones.found" value="true">
              <length file="${file.clonecount}" when="gt" length="0" />
       </condition>

       <antcall target="fail-if-clones-found" />
</target>

<!-- Fail the build if clones detected-->
<target name="fail-if-clones-found" if="clones.found">
       <echo message="Code clones found - setting build fail flag..." />
       <fail message="Code clones detected during ${codeline} build.  Check logs." />
</target>

<!-- ================================================================== -->

Note: In order to pass parameters to the ant script, click on the advanced button and add parameters as in the following screen:

Passing parameters to Ant

Monday, September 29, 2014

Becoming a Technical Team Leader (TTL)

2003 I was appointed a senior position at IBM and became a technical team leader. This appointment was based on two things. First, I have spent 3 years in development. Second, I was an excellent developer! Are these enough criteria to become a technical team leader? I've already experienced the answer myself. I have led the team the worst way one could imagine!

Since then, I have been thinking about this topic, and read the excellent book of Gerald Weinberg, Becoming a Technical Leader. After years and years of leading technical teams, the idea became very clear in my mind about what it is like to be a technical team leader; what's expected from you, what's your necessary qualifications and what's you main responsibilities?

This is an attempt to answer this question:

Technical leadership core responsibilities
Technical Leadership Core Responsibilities


A Technical Team Leader (TTL) should demonstrate capability in three main areas:

First and most important: Team Support. He can motivate the team, he has the ability and art of facilitating team activities, and he can organize team work into a process oriented manner. 

Second, a TTL is responsible of nurturing/enforcing and monitoring the product technical excellence and high quality. More specifically, the TTL is not responsible of doing this, but he is responsible of making sure this is realized by the whole team. To be more clear, if the TTL has developed an excellent product by himself while the team is doing nothing, then he is still failing in this regard. 

Finally, a TTL should sponsor innovation in the team. This is different from technical excellence. It is related to the team spirit and desire to experiment and try new things and unconventional solutions. This is different for problem solving, because you can solve a problem in a dumb way! What the team needs here is someone to sponsor the activity whenever it is needed and make sure a problem is solved in an innovative, not dumb, way.

In all of these responsibilities, there is a common component of organization. The TTL is responsible to organize accumulated knowledge and information gained by the team, and make it available and easy to find and use when necessary by any team member. Also, organizing the team process, which is a responsibility which may take a lot of time and effort to monitor and foster.

If you are going to become a TTL, make sure you get enough knowledge about these topics above. It is your responsibility to become knowledgeable, or else you will spend years or fumbling in the darkness and learn by trial and error!

Saturday, August 30, 2014

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. 

Monday, August 18, 2014

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. 

Sunday, August 3, 2014

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.

Sunday, May 18, 2014

Detect Code Duplicates Using ConQAT

Finally, I had sometime to do this simple and invaluable tutorial on your first steps with ConQAT to detect code clones.
  • Open eclipse with conqat enabled
  • From the file menu - New - Other - ConQAT - Run Config:



  •  Select a parent project to create the conqat config. This may be any project or folder, even an empty project. 


  • Fill the missing parameters, then click the launch config link as in the next screen shot: 

  • After the run completes, and xml file containing all the clones are generated in the output folder. To view the clones, , goto clone detection - open clone file. 

  • Here you are:

  • Don't forget to open the clones perspective. This will help you visualize the clones.