Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!

Daryl Kulak

Greenhorn
+ Follow
since Sep 17, 2018
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
3
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Daryl Kulak

Jeanne,

Hong Lii is actually one of the authors.
Sure.  Shu-ha-ri works well for skills that you are teaching where people progress quickly, like with structuring code a certain way to suit a prescribed architecture.

Shu - don't question what I am teaching, just trust that this might work
Ha - work to master what I've taught you
Ri - now you understand what I've taught you and you've internalized it, now we can talk about "why" we do this, and you can even modify it

I think this works well if the coach and the coachee progress through this cycle in, say, an afternoon. However, in our view, shu-ha-ri is often applied to longer term activities, like enterprise agile transformation.

This is a problem. Transformations must be customized to the situation on the ground. And the experts about that business situation are not usually the coaches, but the people being coached. So some coaches use shu-ha-ri to say "don't question my teachings, just follow it and later we will explain why and you'll be allowed to change things." This saves the coaches the hassle of being questioned, but it does not result in a sustainable solution.

Transformations need to be customized from Day One.

Our alternative comes from the International Institute of Rural Reconstruction (www.iirr.org). They have a credo that is a much more empathetic approach, interested to customize right from the start. This is what we use for enterprise transformation.

http://iirr.org/about/vision-mission/

Let me know what you think.

Daryl




Junilu,

Yes, you make a great point and even have an excellent name for it - "Conservation of Knowledge."

We talk a bit about this in our book in the software craftsmanship chapter (Chapter 9 - Flipping the Run/Build Ratio). I've sometimes described TDD and BDD to clients as "executable requirements." It is great if you have a big Word doc that describes the requirements for this app. But it goes out of date, as we all know. However, if you put those requirements into automated tests instead, and the tests are continuously run as part of code check-in, then those can never go out of date.

The biggest value to having requirements is that you can know the "why" behind the design decisions months or years later. With the Word doc, it is an outdated why. But the tests have the up-to-date why.

Sounds like you need to write a book too, Junilu! I like how you explain things.

Daryl




Germ├ín, that is a great observation.  You are right, many Agile teams say that they deserve special treatment or that things that were once necessary can now be dismantled because "We're Agile!"

We even have a term for this in our book.  It is called "Agile Illth."  Illth is the opposite of wealth. Agile teams can cause good things to happen (wealth), but they can also cause a lot of bad (illth) if they are not careful.

For us, enterprise architects will always be necessary.  However, as we mentioned in another thread, architects need to be true coders.  They should play guest roles on teams every so often, living inside the decisions they've made as architects.  "PowerPoint Architects" are not very useful. We have several recommendations for how Agile teams can "play nice" with enterprise architecture groups, and also how the enterprise architects can themselves become more Agile.

You can tell this is an important topic for us. Thank you for the question.
Junilu,

Hi!  Yes, you are right, we are advocating "architects who code."  In our experiences, we've too often seen the "PowerPoint architect" who has a great ability to create architectural visions and lovely-looking diagrams, but doesn't have any appreciation for what developers really need, nor what is practical.  Then these "visions" get crammed down people's throats and we have a mess.  CORBA, data warehouses, SOA - there are so many examples of misusing these technologies in a "too big" way.

However, architects who *can* code and who also *do* code, in guest spots on teams, etc. are really valuable.  Now you have someone who has a bigger picture view, but who also has to live with their own decisions in the depths of the code. Even better, limit the number of enterprise architects in the company and allow the teams to make decisions together about standards and architectures, etc.

Daryl
Ayub, yes Agile practices can be used beyond software and have been successfully many times.

However, that is not what our chapter is about, the one called "HR Agility." We focus on how HR departments can change the way they support Agile software teams to improve the success of those teams.

The concept you are talking about is often termed "Agile HR" in the HR industry.
Hi Everyone,

Hong and I will be happy to answer any questions or comments that come up here.  It will be nice to get acquainted with you.

Daryl