How to coach or mentor software craftsmanship

[Ashok Guduru]

Hi,

 

I don't know whether asking this question in this group is good idea or not but I'm posting here because it is related to software craftsmanship.(SC). My question is as the title says... What is the best way to teach/coach/mentor/train to the developers within an organisation? 

I recently joined a new software development organisation as technical architect. There are many isolated teams working on different projects on different technologies like .NET, Java et.al.  It's almost 4 months passed joining me and I worked closely with one team and occasionally got involved with other teams when solving a particular problem. I clearly noticed the same problems they're facing due to deficiency of SC. There are mixture of developers with different age and years of experiences. Even with different title like Jr. Dev, Sr.Dev, and Tech-Lead etc. but I see this SC is clearly missing in them.

I know much about SC and I do practice & care about it. In my career I clearly saw huge advantage and gain in speed of the development and quality. I tried 3 to 4 times to explain & train them by assembling few teams in a conference room but not able to swallow them this SC thing!. For example, I saw in their regular meetings & conversations they frequently use 'Refactoring' word. When I asked what do you mean by that? I stumbled up on hearing their reply. They use it for something completely different purpose. I saw they don't know the real meaning, activities it involves the names and the smells etc. One day I took one session to show what is real Refactoring is. I pulled one of their code-base picked-up a method in a big class and did Refactor!. There are almost 19 lines that method and when completed there are only one line remained!. They said they'll do it when they find Time!!!  - lol...

I see there are many problems from management side also. So what would be the best way to induce these skills in them. I would want to make think about the importance of the software quality, importance of the internal quality as the quality of external visible things. Be passionate about the quality in things they do daily. Be professional about their profession.

Thanks.

[Sleepyfox]

This is a question that you should ask *your own* mentor.

Nigel

--

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.
Visit this group at http://groups.google.com/group/software_craftsmanship?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Matteo Vaccari]

Hello Ashok,

this is a very big question.  What I would probably do if I was in your place is to start coaching the team I work most closely with.  Coaching the whole organization will take a lot of work; I would first try improving one team.

For instance, you say that you try to explain what refactoring is and why it is important, and yet it seems they don't get it.  Can you imagine a different way to show why refactoring is valuable?  One idea is to amplify the current discomfort.  If there is a problem like too many bugs, or development not being as fast as desired, or parts of the system that are unpleasant to work with, can you try to get them to see the connection with poor quality code and smells and refactoring?  Other things that have worked for me are pair programming and technical reviews.

Matteo

[Caio Fernando Bertoldi Paes de Andrade]

Hello Ashok,

I am new in the Software Craftsmanship movement, but if I have learned something out of it, it is:

You teach by example.

Example in this case isn't putting all of them in a lecture/meeting/conference room and giving a talk about how they should be coding. Neither is refactoring a piece of code in front of them all. Example is applying the stuff in real everyday work. Pair with each one of them individually, working in real everyday work, show them what practices and principles your are applying, how and why you are applying while coding. Humbleness is highly needed in pairing, I believe you should introduce the SC practices as well-sold suggestions to improve the quality and both pairing programmers have to agree to use them. All changes are gradual.

I believe that pairing is the best way to exchange knowledge, because craftsmen exemplify their principles and practices.

I believe that peering is the best way to mentoring, because becoming a peer means resigning to be higher-status, as becoming a friend means resigning to be a parent. We almost never listen to our parents.

Cheers,

Caio

[J. B. Rainsberger]

On Fri, Apr 12, 2013 at 12:39 AM, Ashok Guduru <ashok...@gmail.com> wrote:

 

I don't know whether asking this question in this group is good idea or not but I'm posting here because it is related to software craftsmanship.(SC). My question is as the title says... What is the best way to teach/coach/mentor/train to the developers within an organisation? 

There isn't one.

Based on what you've said here, I strongly recommend that you buy and read "The New Strategic Selling" by Miller and others. You want to undertaking a "complex sale" to a wide audience of people, and until they strongly believe in the value of what you want to teach them, the whole endeavor will likely have no significant effect.

Good luck.

--
J. B. (Joe) Rainsberger :: http://www.myagiletutor.com :: http://www.jbrains.ca ::
http://blog.thecodewhisperer.com
Free Your Mind to Do Great Work :: http://www.freeyourmind-dogreatwork.com

[Emily Bache]

There's been some good advice in this thread already, but no-one has mentioned the idea of Coding Dojos, so I thought I should :-)

You could encourage teams to set up their own Coding Dojo meetings, where they can discuss and learn skills. Software Craftsmanship is not only about a change of attitude/social pressure, but also about having skills in Test Driven Development, Refactoring etc. In the dojo you can address both kinds of issue. There is a place in these meetings for demonstrations, such as the one you did to show Refactoring. There is also much benefit from getting people to learn by doing - setting up Kata exercises so they can gain insight themselves from their own experience.

You could take a look at my book :-)

https://leanpub.com/codingdojohandbook

Regards,
Emily Bache

[Michael Nash]

Ashok:

I see you got some great replies below to your initial question, but I thought I'd share my previous experience, if not as a good example, perhaps at least as a horrible warning? :)

I worked with a group within a company, and got one team to truly change their level of practice, I believe. Craftsmanship was starting to build, and the practices you often see with it were doing well - we were TDD-ing, we were pairing, teaching each other as we learned new things, and doing some great work. I was very happy with the result.

Then we finished the project we had come together to do, and were ready to mix into other teams and help spread some of the techniques this group had been exposed to. That's where problems started.

The other teams in the company perceived the team as being isolated, and not focused on delivering results. They found some of the team members hard to work with, and resented the attempt to share what was learned with the rest of the group.

Developers from the other teams stuck stubbornly to their own approaches, mostly focused around a "bang out whatever works the fastest", without much regard to our long-term velocity (which was dropping like a rock). Even something as simple as introducing TDD was being rejected with claims of "we can't test this" and "this isn't worth testing".

It seemed that coaching craftsmanship with a "seed" group had, so far, failed with this particular organization.

Maybe the project we tried it on went on too long, in too much isolation from the rest of the company? It also turned out to be a project that didn't have a lot of value to the company, even though we thought it would when diving in. This helped make the perception that the improved techniques we were doing were "overengineering" or "gold plating" (both of which were quite false, in actuality).

Now we're stuck with one group that wants to improve and learn and do better, and a larger group that wants nothing to do with them, and is reverting most of the techniques we've pioneered.

Has anyone seen a situation like this before? Input much appreciated :)

Regards,

Mike Nash

JGlobal Limited

http://jglobal.com

[Edson Chavez]

hi all.

first: sorry about my english, i know: is bad.

How do you split the original team? maybe if you send one member is easy say: "bang out whatever works the fastest"  but maybe, if you split the team in two groups and adds new members (in little number) example: 4 members original team + 2 new members, maybe new members feel group pressure, and impelling to respect the way on the original team work and to end project they are convinced about the techniques and now are ready to spread them in another teams

i have similar situation on my job: i'm part of new team starting to spread software craftsmanship on the company :) but we are in first stage yet.

regards

Edson 'Grubhart'
http://www.sindominio.net/ayuda/preguntas-inteligentes.html
http://soyfreakytambiengeek.blogspot.com/ <-- Mi Blog ^^
@Grubhart   <-- Twitter!!

2013/9/15 Michael Nash <michae...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "software_craftsmanship" group.
To unsubscribe from this group and stop receiving emails from it, send an email to software_craftsma...@googlegroups.com.
To post to this group, send email to software_cr...@googlegroups.com.

Visit this group at http://groups.google.com/group/software_craftsmanship.

[Nigel]

I'll repeat @jbrains - there is no 'best', 'best' is for 'shu'-level or apprentices.

Although @emily is right, and as founder of the London Code Dojo I'm about as rabidly pro-dojo as a person can be, the reality is that setting up a code dojo is no use if nobody is interested, or worse if they view it as 'more unpaid work'. 

It's been said already: leadership is by example, if you live according to craftsmanship principles, then those people who the approach appeals to will want to follow your example. 

Fox

--