Nexus Guide, the Arabic Translation

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.

Salam,

Writing About AngularJS: 237 downloads!

We are now over 10,000 words and almost 80 pages into our book about developing an Enterprise Application frontend in Angular!

Being loyal to Lean principles, we didn’t have much planning in advance, we planned the first two or three articles/tips and we started experimenting with the writing process.. As of today, we have 237 downloads which is better than what we expected!

We are planning the coming chunk of tips, we think that we may need to rearrange the book content in a way that tips build on each other so readers can start from first tip and continue reading.

We also think that we may cover all the materials we want to cover in around 30-40 articles, so at some point the title “101 AngularJS Tips and Tricks” might need to be refactored!

Salam,

Yaser

Writing about AngularJS

There is a famous quote by Reid Hoffman, the founder of LinkedIn, that says: If you are not embarrassed by the first version of your product, you’ve launched too late. 

I guess I am not too late then 🙂

Allow me here to present my latest writing experiment!

https://leanpub.com/101-ng-tnt

101 AngularJS Tips and Tricks! is humble try to share the experience we gained, I and my team, while working with this fantastic JavaScript framework.

So, even if JavaScript or Angular does not interest you, I will be glad if you download this Early version of the book, but if either one does, then I will be grateful if you try some of the content and share with me what do you think, any suggestions, corrections, or recommendation are absolutely welcome!

Salam,

Yaser

Publishing as a Scientific Experiment

Lean thinking started in manufacturing in Japan around a core  idea of eliminating the “MUDA” or “Waste”! Any Lean leader will tell you: Don’t think if you can do something but rather if you should do it at all ? and hence focusing on value adding activities only.

From manufacturing, Lean Thinking spared to all domains, two interesting examples are software development thanks to the effort of Mary Poppendieck, and Lean Startup for developing businesses which is becoming a worldwide movement since presented by the work of Eric Ries.

Interestingly enough, Lean Thinking appeals to business leaders, software engineers and entrepreneurs alike because of how it handles uncertainty by the means of scientific experimentation.

Say you have this crazy idea of a new product that you think will change the world! we are all that person, aren’t we ? But think for a minute, can you really know for sure if your ideas will succeed or not ? You actually can’t! No matter how hard you plan, the odds that you will fail are very high!

So what to do then?

Actually you do nothing! Well not really nothing, you probably need to build only the product box or just design the product flyer then reach for potential customers feedback and use this feedback to plan and shape the next minimal product and so on, every time, you are actually experimenting with your idea based on the available information you have at the moment and some hypothesis of what will be attractive to your customers until you find what would really work!

Recently, I also discovered leanpub.com and it seems that lean thinking is applicable to publishing as well!  Leanpub.com is an innovative platform that provides tools to write books, publish them and solicit readers feedback to clear the path where the writing process should follow.

Although lean publishing and leanpub.com have their share of criticism, I and couple of my colleagues decided to give it a try, so in a next blog post I am sharing with you our first publishing experiment!

salam for now,

Requirements: Defining The Terms

It is important for anyone taking the responsibility of requirements development to set a communication framework in order to organize and facilitate requirement gathering, classification, documentation and dissemination job.

This framework should include a communication plan, set of templates, set of textual and graphical models…etc.

It may sound self-evident, but I often find it necessary to start this effort by first agreeing with stakeholders on the definitions of terms we will use in describing requirements. I frequently find this basic step necessary due to the disparate professional and educational backgrounds of project team members, also because of the overloaded terminologies we use when we talk about requirements.

To reach this common understanding, I usually start the analysis meetings by presenting the terms from reference sources such as Karl Wiegers books and discuss them with the team to come up with agreed on definitions.

From the last time I did this exercise  the stakeholders group discussed the following set of terms : Scope, Constraint, Assumption, Acceptance Criteria, Business Requirements, User Requirements, Project Requirement, Functional/Non-Functional Requirement , Feature, Use Cases, Actor, Metadata, Scenario, User Story, Business Process, Business Rules, SMART Requirement, Activity Diagram, Interaction Diagram, BPMN, Context Diagram, Entity Relation Diagram, Priority, MoSCoW Requirements, Artifact and Deliverable.

Discussing and agreeing on the meaning of such terms and other terms specific to the business domain will lay the groundwork required for streamlined and productive requirements development engagement.

Scrum Plus

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.

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.

Salam,

Self-organized Teams in Makkah

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 location, 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!