Friday, September 14, 2018

I am Groot … I am Scrum

Disclaimer: They are imaginary conversations resulting from my own understanding of real conversations I have had with different people and teams.

What method / approach do you use?


Do you use the X, Y, Z …  practices?


Sorry, but without these practices this is not Scrum.

It is Scrum. Our way of using Scrum!

We are using Sprints!

What features do you have delivered last Sprints?

We have delivered some requirements specification.

That is not a Sprint. The Sprint was explicitly defined to end with a set of potentially releasable features.
Our collaborators use Scrum and they call that a Sprint. 

Another team and another context …

How often you deliver?

Sometimes daily and usually after few days.

What method / approach do you use?


You are much close to Continuous Delivery. Why are you saying that your approach it is Scrum? They do not deliver more often that one week. They have a ceremonial to support a potential release that cannot fit in less than a week. More, this is the Scrum competitive advantage: if they do not deliver in less then a week and could prepare in advance the work for that week/weeks (Sprint), they will have a superior velocity. This is the explicit intentions of the Scrum creator.

I do not want to talk about him. He does not offer a good approach for software. 

Maybe you are right, but he had provide the Scrum definition, and this is what the whole world understands by Scrum. If you have found a better but different approach in your context, this is a good hybrid, but is no longer Scrum.

The message/intention problem - maybe you do not believe it, but also in software development different practices and methods have names and definitions.
You are not Groot! You cannot use whatever practices in your context and put the label Scrum. You will transmit the wrong message to anyone outside to your team, but also inside to your team.

Interface problem – the main aspect that it is visible outside the development side, it is the proposed interface - the life-cycle - between development and customer and development and other enterprise teams. When you say Scrum, I know which kind of “contracted” interface - life-cycle - you are proposing. You cannot have your local convention that override industry well known definitions. You can have any kind of process you need/want but is honest and professional to use the right label in order to transmit the right message.    
Some teams use Waterfall and put the Scrum label on it …
Some teams use Continuous Delivery and put the Scrum label on it …
Some teams use Lean Exploratory Startup and put the Scrum label on it …

How could be that right? How could you differentiate the different approaches that you will use in different contexts? How you could differentiate the context of different teams and different products?

I am Groot!

Saturday, August 18, 2018

Specificity of homo sapiens. Part 2 - Knowledge Work & Software Development

Know thyself - Temple of Apollo, Delphi; Socrate; Aeschylus
Nosce te ipsum! – Cicero
Man, know thyself, and you are going to know the gods - Luxor, External Temple

You may be asking what was the purpose of the previous post "Specificity of homo sapiens. Part 1 - Evolution evidence" in an agile (software development) blog. 
Software development is knowledge work, where the most important factor is the people. Do we, people, use our full potential in this kind of work? We have some industry experience and personal experience but we still struggle with basic things. Where can we find some "hard" evidence about what is important to use full human potential? Evolution. We have the evidence of evolution steps of Homo Sapiens and his predecessors in  thousands of years or more.

I propose a little game - to compare some knowledge work process approaches and what really helped humans to make significant steps forward in their evolution.


Process story - I am somehow sad when I saw this kind of phenomenon: a development team with "no improvement", in fact too few improvements in a long period of time (years). There is an individual improvement, there is some adaptation to a specific context, but is no real improvement for the team/organization work approach. When they discover better ways of working, these improvements are not distributed and adopted enough. Yes, they could adopt new and better external tools, but that is like exploiting a natural oasis, not like making an existent hard context livable.   

Evolution - Homo Erectus was "strong and skillful" but <<Not only were they lazy, but they were also very conservative," Shipton said. Their tools stayed the same in both size and composition as the environment around them changed>>  (See Biblio 1)  The problem of H.E. was not really the laziness, but a limited cognitive capability while comparing to us, Sapiens.  

Comments - So, there is a huge waste to have a team that activates in knowledge work area and has too few improvements for long periods of time. That is a waste of talents in Toyota Production System but here is applied not only to professional talents but to most basic human capabilities.


Process Story - Domain experience: in knowledge work you need people with cross-functional skills that work collaboratively. There is a pragmatic profile that seems feasible and gets good results: the Generalizing Specialist (explicitly explained by Scott W. Ambler and Disciplined Agile, see Biblio 7). There are still cases where organizations are trying to use specialist-only teams for software development (and silos) and, their results are more than questionable.

Evolution - the "very Sapiens niche" was the one of "generalist specialist", that means to it was able to <<colonized a diversity of challenging environments, including deserts, tropical rainforests, high altitude settings, and the palaeoarctic, but also specialized in its adaptation to some of these extremes.>> (see Biblio 2)

Comments - when the context is complex: diverse, fluid and extremely adverse and you need to use knowledge to win, you cannot be only "generalist" or only "specialist". You can rely on specialists, but you cannot have only this skills profile or live with the hope that could work well in isolated teams (see below). 


Process story - There is a correlation between the collaboration level and the result of a team. Teams with rather sporadic collaboration will not use their full potential and their results could be always much better. Just observing the level of direct interactions between team members during a working day you can tell if something is wrong or not.
Evolution -  what was different in the case of Homo Sapiens comparing with other human species? Why was able to "conquer the world" and live in all kind of environments even from his early prehistory?  Here are the main factors (see Biblio 2)
  • "extensive cooperation between non-kin individuals"
  • "accumulating, drawing from, and passing down a large pool of cumulative cultural knowledge, in material or idea form, may have been crucial in the creation and maintenance of the generalist-specialist niche by our species in the Pleistocene"  

Comments - what was the fundamental strength of Sapiens from the very beginning ? "extensive collaboration" and management of the knowledge: accumulate, sharing of "a large pool of knowledge". Ignoring collaborative work it is like ignoring that people are Sapiens.


Team, team, team .. this is what you heard from most Agile coaches and gurus. Yes, a team of collaborative individuals will perform much better than the same individuals working alone. What about isolated teams? We can have an organization with many teams, but with no interaction between them and not shared knowledge. 
Evolution - around 11000 years ago, we, Home Sapiens, have started an accelerated development after 200000 years of very slow evolution. We have done that without a genetic improvement and without any E.T. intervention. At that time people start to live in larger communities where they can better share and accumulate their knowledge (see Biblio 3). It was also easier to value the "specialists", the special talents, that could build communities of practice per "profession". 

Comments - process guidance & methods have highly disregarded the inter-team collaboration and knowledge/experience sharing. It is rather strange and sad: extensive collaboration, communities of practices and inter-team experience sharing was the main factor that starts human civilization (see Biblio 3) after 200000 lost years in isolated small groups and .... we still use the isolated groups approach. 
Isolated teams: that is old prehistory!
There is only one significant exception in process methods for this aspect: Disciplined Agile, where you can find guidance about more levels of collaboration (Delivery, DevOps, IT, Enterprise), guidance about communities of practices, reuse engineering and other aspects (See Biblio 4, Biblio 5, Biblio 6).  

Bibliography and References

[Biblio 1] 
A. Laziness May Have Driven Homo Erectus to Extinction, By Yasemin Saplakoglu, Staff Writer,  August 10, 2018  
B. Acheulean technology and landscape use at Dawadmi, central Arabia, by Ceri Shipton, James Blinkhorn, Paul S. Breeze, Patrick Cuthbertson, Nick Drake, Huw S. Groucutt, Richard P. Jennings, Ash Parton, Eleanor M. L. Scerri, Abdullah Alsharekh, Michael D. Petraglia. PLOS,  Published: July 27, 2018 
[Biblio 2] 
 A. Homo sapiens developed a new ecological niche that separated it from other hominins, July 30, 2018
 B. Defining the ‘generalist specialist’ niche for Pleistocene Homo sapiens, Patrick Roberts & Brian A. Stewart, Nature Human Behaviour; volume 2, pages542–550 (30 July 2018)
[Biblio 3]  - Previous posts related to human evolution and behavior pattern
[Biblio 4]  - The Scope of Disciplined Agile (~ levels of collaboration)
[Biblio 5]  - Disciplined agile - Communities of practice
[Biblio 6]  - Disciplined agile - Reuse Engineering

[Biblio 7]  - Disciplined agile/Agile Modeling - Generalizing Specialist