Before the agile manifesto

Nowadays, if you are in the world of business, especially in software business, and criticize the "religion of agile methods", you are cursed. Scrum must be the method. There must be sprints, coaches, daily stand up meetings, post-its, burn down charts, tribes, masters, retros and other rituals... There is no room for good old fashion, heavy duty engineering and management. Besides, it is very popular to cancel the bad old practices. 

I am always into knowing the essence of the things around, extracting the root idea and being able to improvise for authenticity rather than being the follower of the popular narratives. Moreover, I don't believe that any method can save you. Only you can save yourself. There will be no eternal relief or salvation... I've already explained this in detail in one of my prior posts titled "Forget about failing" so I'm not going to repeat the same things here.

Today, I am going to cite two books for supporting my ideas. The first one is "Fundamentals of Computing II: Abstraction, Data Structures, and Large Software Systems". This book was published in 1993 from McGraw-Hill and used as our lab textbook of software engineering course in Ege University computer engineering department. Please have a look at the sample page below:

In this section of the book, a number of software project management recommendations are given. I am also writing the text to be noticed with my interpretations added:

Bullet 1:

Assign clearly defined tasks organized by functional area. This results in a product that has conceptual unity and does what was intended. It also makes for a more motivated programmer.

For me, this is about defining coherent software products and product development teams accordingly.

Bullet 2:

Use walkthroughs. Some evidence at this point suggests that walkthroughs are the most effective method for software quality control even better than formal verification! So walkthroughs are a critical component of any effective software team.

Here, the authors are stressing the importance of scenario based software proof-reading. Suggestions are similar to extreme programming, pair programming etc.

Bullet 3:

Do not add new programmers to an already late software project; this will only make it later. This statement was first expressed in The Mythical Man-Month by Brooks and since has come to be known as Brook's Law. It's not hard to see why this is true - when new people are added, they have to be trained. This takes substantial time away from people who are already working on the project. Also adding new people to a team increases the possible lines of communication - this can reduce everyone's productivity.

This refers to the autonomous and preserved development teams.

Bullet 4:

Include representatives of all user groups on the development team. Until the past few years, an analyst would interview users, and that would end users' involvement until they tested the final product. This was often unsatisfactory as users frequently do not know what they want until they have tried the software. Recall that prototyping is a software development technique in which the user interface is designed first and iteratively refined by working with users even before a full scale design is undertaken. Thus prototyping helps fulfill this guideline. Beyond prototyping, however, receiving user  input throughout the development process ensures a higher level of user satisfaction with the final product.

This portion is the heart of the message. In the early 1990s, authors were saying that "...Until the past few years, an analyst would interview users, and that would end users' involvement..." by using the past tense :) And they are suggesting to add users in the development team from the beginning, to follow iterative development with continuous user testing and feedback collection. They are not using any term like MVP which is, I think, the most ambiguous abbreviation coined ever but they are recommending to use software prototyping. After many years, software industry re-invented the wheel and called it MVP. Anyways... Let's keep reading...

Bullet 5:

Provide a supportive environment. Adequate workstations, technical support, and secretarial help make a team far more productive.

:) Impediment removers, fancy cubicles, SCRUM rooms, wall boards, post-its, markers... What more can I say?

As you can see, it was always there for the ones who have open minds and eyes.

The second book I am to share is "The Martian Principles for Successful Enterprise Systems: 20 Lessons Learned from NASAs Mars Exploration Rover Mission" by Ronald Mak. Professor Mak also wrote a chapter in the famous book "Beautiful Code", never miss it. I have chosen the book referring to the NASA practices because the projects managed by NASA are the triumphs of  humanity. The optimal combination of science, technology, engineering, general management, team building, performance tracking, project management etc. can be found in the works of NASA. I am now pasting a screenshot from the book, very sharp lesson:

Very neat indeed, nothing more to say.