Archive for the ‘Project Management’ Category

Early last week, I had the chance to complete an Arabic Translation for Nexus Guide.

Nexus is presented by Ken Schwaber as “the exoskeleton of scaled scrum.”

In Nexus, Scrum is used as the main building block however the focus in Nexus is on integration of work products from different participants to form an integrated product increment at least each sprint.

This would enable Scrum to scale well for large teams handling complex projects.

In this translation, and for consistency, I made sure to stick to the same Arabic translation for Scrum terminologies from my prior translation for Scrum Guide.

Feel free to send me your comments, suggestions or corrections.

The full set of translations along with the original English version of Nexus Guide can be found on this page.


Read Full Post »

Scrum by definition and design is meant to provide an alternative project management framework to traditional waterfall method. As one of the most used Agile methods, Scrum is non prescriptive but rather focusing on fostering team collaborative effort to achieve short term objectives following a relentless steady rhythmic work style.

Sprint after sprint team keeps shoving User Stories from the backlog to the development mill rotated by the collective effort of the team.

However, in the rush to finish the current tasks, quality can be easily overlooked and irreversible technical dept may accumulate unless consistently and actively monitored and controlled using a defined process such as the one I suggest here.

Again, four and three, four meetings types and three artifacts are the only rituals the Scrum Guide offers!

In practice, it is necessary to build on the framework offered by Scrum in order to avoid low quality deliverables that may occur by the mechanical application of the basic method.

Engineering practices that focus on quality borrowed from Kent Beck’s Extreme Programming (XP) is a good option here!

From those, Test Driven Development (TDD) , and Continues Integration (CI) are among my favorite recommendation to add to your Scrum practice.

Another example of an aspect of Scrum where the framework provides only a skeleton to be fleshed, is Architecture!

Unlike a method such as Rational Unified Process (RUP) whose “Elaboration” phase focus on realizing architecturally significant use cases producing what is called an “Executable Architecture”, Scrum doesn’t say much about how to Architect for a team that develops using Scrum? All what it says is that the team should decompose the system into shippable pieces, and deliver a piece per sprint.

In the last workshop I attended and organized by Egypt Scrum community, I started a discussion with a colleague about shipping a usable product every sprint and if that is really possible? My colleague insisted that time to market mandates shipping every sprint. I asked what type of projects she was working on, she replied that it is an upgrade for a layer of an existing software.

Oh yes, for such a project where you upgrade parts of the system while you can keep the rest working with old libraries, you can in fact deliver a working product every sprint.

But if you will develop an enterprise application that relies on a thick layer of relational databases and a complex business logic, it is rather difficult to vertically dissect the solution into shippable across-layer pieces that can be delivered incrementally.

In order for that to be possible, a good architecture effort is required in advance and possibly new architecture styles need to be used such as the one described in this white paper.

Microservices and Single Page Application

Keyhole Consultants (www.keyholesoftware.com) suggest that an architecture style based on Microservices-SPA shorten time-to-market for Scrum teams and enables agility and incremental delivery of working software.

So, in my opinion, Scurm alone is not enough for complex software intensive projects, it could be even dangerous! Among other things, you need to make good use of XP engineering practices to deliver quality products, and you need to build good architecture capability into your team to facilitate shipping every sprint which is very important for the success of Scrum practice as a whole.


Read Full Post »

The idea of self-organized teams is simple: autonomous teams are much faster, because they take decisions and solve problems without waiting for gestures or inspirations from the “operation mastermind” a.k.a. “the manager”!

Self-organized teams are much more prone to becoming hyper-productive, and therefore becoming self-organized should be a goal of every team, right? that is easier said than done!

“The employee won’t do what she has to do unless you tell her” is the classical wisdom in a typical command and control work environment. Changing this is a challenge!

Also, there is only little literature that goes beyond the basic definition and merits of adopting this management style to the how part of the story. This is obviously because transforming to a self-organized team is a different journey each time, no one prescription! It depends on work culture, invested time and resources, management support…etc.

My experience in a strict micromanagement environment proves that gradual transition following Deming’s Plan-Do-Check-Act has better chances to succeed.

Pushing team members out of their comfort zone and encouraging them to take the ownership of the work was faced by a lot of resistance mixed with lack of understanding, but things got better with time and persistency.

Also it gets particularly difficult when you try to cross the departmental barriers where you have no authority!

Another tip from El-Ssamadisy’s book Agile Adoption Patterns: A Roadmap to Organizational Success is to educate team members about Responsibility Process.

And apparently relentless leader is mandatory as well for such teams to transform successfully to the self-organized realm.

One more tool that I found useful is to allow the team to share the benefits of their productivity.
By implementing a simple financial incentive policy, team members start to show more self-initiatives and wait less for directions. That is especially useful when this incentive is directly proportional to the overall productivity the team makes measured by visible, transparent and understandable KPI’s

That is my observations so far, I will keep you posted!

A final thought, in Makkah in my last Umrah, I couldn’t help photographing the janitors while they were busy at their daily work in the holy places, hence the photographs accompanying this post.

In their daily work, they follow a specific rhythm, they move among hundreds of visitors and pilgrims, pick a WorkersInHaram-2location, zone the space and start distributing soap, and then sweep it , dry it and then move to another place and so on.

They know what they are supposed to do and they do it! and they deal with the situations they face autonomously, in fact it was very difficult for me to distinguish their leader! And I knew him only because of his old age and because he was carrying the water and showing them the next place to clean.

I am impressed with the systematic, hard, yet steady paced work these men are doing! That is, in my opinion, self-organized team in action!

Read Full Post »

Recently, I had a chance to test Affinity technique to classify a considerably big number of items. The problem was to look into our customers’ data and analyze it to find new ways to provide better services and eventually generate more revenue.

We wanted initially to segment this database according to two main factors.

First: whether the customer is still using one of our products or not.
Second: if the customer has valid M&S contract or not.

A quick export from our CRM system gave me an Excel sheet of more than one thousand row! The list contained customers from the 90’s until today! To make things more difficult, CRM data was in many aspects not complete or up to date! Looking around, it was also clear that no single person knows about all these customers.

But, using Affinity technique and in 4 sessions, 15 minutes each, a team of five members from sales, customer care, and telemarketing managed to categorize the full customer set  into one of five groups, how efficient is that ?Affinity to the max

Three observations from this exercise though,

1- At first, I was telling participants not to talk and move the customers’ cards around the table, then debate about any customer belonging to a specific group at the end. I found that this rule mustn’t be so strict. In fact a moderate discussion is desirable, it would streamline the classification process and eliminate the need for an after session debate or at least reduce it to the minimum. This is provided that no one member dominate the session and all opinions are respected.

2- Second remark was about the maximum number of cards. I found that the 5 members of the team were able to handle a maximum of around 250 cards in one 15 minutes  session. In my assessment, a smaller team would result in less classification quality, bigger team would require more time to finish the job.

3- In one of the sessions we actually crossed the 15 minutes time limit and I started to notice a slow down in team’s performance therefore I stopped the session. It is better to keep session quick while the team energy still high.

Above being efficient, Affinity technique helps reaching consensus, it acts as a team building technique, and it is also fun!


Read Full Post »

Last weekend I read two interesting papers by Jeff Sutherland and others the Shock Therapy and the Scrum: An Extension pattern language for hyper-productivity software development.
In these two papers Dr. Sutherland describes how that although scrum is designed to increase the productivity, team’s success in achieving this goal varies! He refers to some teams that have an increase in their productivity by 400% and describes them as Hyper Productivity Teams. He also enumerates a number of patterns that were evolved by scrum community and are common among Hyper-Productive teams. Couple of other interesting articles about this topic are Group Coherence for Project Teams – A Search for Hyper-Productivity and Scrum Metrics for Hyperproductive Teams

In my opinion, and probably I am not saying anything new here, productivity is dependent on two main aspects of the team, one is organizational and social and that is the human dynamics of the team, the other is technical and methodical and that is related to the process and practices applied by the team. Consequently productivity level is proportional to how good is the communication and collaboration between the team members and how fluent they are in Scrum and Agile practices!

Having said that, and from experience I think maintaining the same high momentum all the time is quite difficult, productivity level would rather fluctuate reaching hyper-productivity state one time and falls back to average or below average productivity before it bounces back and so on.
The most difficult task in my opinion is how to maintain the hyper-productivity state once the team reached it? and how the team can bounce back quickly if it falls to normal productivity?

I am sending this question to Dr. Sutherland and to the community, and I will share with you the responses I receive.


Read Full Post »

This is my article in InfoQ about a proposed process to control Technical Debt in the context of scrum projects.


I titled the article “الحَبْيَقَه” 🙂 which is how one of my friends describes it when he starts to kludge the code for the sake of speeding up the development.

I hope you find it useful.

Read Full Post »

In public bids, we commit to fixed time, scope, and cost. This commitment, at this stage, is a mere guess! A guess that wouldn’t hold for long as change floods the project once project starts.

So, to mitigate the risk, we either pad our estimates generously, or we bid low and count on starting the project with an extensive analysis phase. From analysis, we produce a thick document we call the Software Requirements Specifications and we insist that the customer sign this document before we move on to the next phase.

The result is that we squander a lot of time and effort in the analysis, signing the requirements specifications becomes an epic of meticulous document review and heated debates cause friction and undermine trust among all parties!

This usually ends in one of three scenarios:

1. We force the customer to drop the change request, so we end up delivering something less desirable to the customer.

2. We tell the customer, “We will do it, but we do it only as a favor” and usually quality will suffer greatly as we try to shortcut the effort to preserve our financial condition.

3. Or we force the customer to pay for the change and the customer becomes unhappy and feels cheated.

It is a lose-lose situation!

In my opinion, unless you have a degree of freedom in adjusting one of the project constraints, then don’t do it! It is a death march!

However if we have to accept such a project for whatever reason, then Agile can still help and here is why:

1. Agile gives us the advantage of delivering valuable software early, while in classical Waterfall we may hit the deadline without having any usable software produced.

2. Agile helps us mitigate the fixed-price contract risk because it makes us fail fast! It simply gives us a better chance to cut our losses if we have to lose.

3. It helps us gain the customer’s trust by using tools such as sprint review meetings and demos also by using information radiators and making project progress visible.

4. Agile also engages the customer in the development process, which encourages the customer to share the responsibility of meeting the project constraints.

So, yes, by all means do fixed-price projects in an Agile way. You will have a better chance for meeting the project constraints, you will also know early if you can’t do it, and you can withdraw before you lose too much!


Read Full Post »

Older Posts »