Category Archives: Coaching

Keeping up Technical Chops

Got asked to do this for a Coaching job.  It was nice to do.

There is an important and underestimated place for technical excellence.  Heck, it’s a principle!  Combine it with the others 🙂  Standing on the shoulders, Thanks Beck, Rainsberger, Meszaros,  Fowler, Wake, Prag Programmers and  many more unnamed.  It has 36 commits to demonstrate the process.  Feel free to take a look at it.  #agile #tdd #quality #emergent

https://github.com/nzdojo/spellchecker

Read the notes:

https://github.com/nzdojo/spellchecker/wiki/Notes-on-Implementation

‘Keep hands on, that includes the code!’

 

Advertisements

The Importance of Shared Purpose

My latest blog is actually one written for my employer here in the United States, Code Genesys.

You can take a look at it here and is on the importance of shared purpose.  Keep practicing that because it’s hard for first timers and anyone whose experienced for that matter.  Well worth the investment in time 🙂

I have an example of a company who go to great lengths to maintain their purpose.  An old blog article written 2 years ago.


Is the Nassi-Schneidermann Still Used

Thinking back to when I was learning programming in the 1980’s the instructors taught us about program creation by a visualization technique called Nassi-Schneidermann diagrams. Here’s a nice summary from breezetree.com.

I thought it was an excellent way to visualize program flow for a novice. It’s only needed for a short time and learners can quickly move to pseudo code. Most programmers can move beyond pseudo code as well.

Knowing the importance of visualization in the Kanban Method, I wonder if new students to programming are being taught via the Nassi-Schneidermann?

Can we use it to increase engagement with the people we are delivering software to?  I suggest we can.  I’ll leave you with this example from breezetree.com and ask can you understand the flow of the program?

nassi-shneiderman-diagram

 


Agile before it was cool

This is a page from a great book by an important author in the software development field, Tim Gilb, called Principles Of Software Engineering Management.  It came out in 1988.

20160119_202722

The language is reminiscent of the time and the practices that were in place then, but it was ground breaking in that it talks a lot about what we call Agile Values today.  In fact Tom Gilb invented his ‘Agile’ and ‘Iterative’ EVO methodology in the early 1970s.  It’s mentioned in the book as well.  This was well before Agile became what it is today – a business.   Tom was so ahead of his time, I remember back then that Iterative development was never ever mentioned in schools and in the workplace.

And therefore, I think this Bill of Rights still holds relevancy.  I made the challenge on twitter and some thought point 9 was not relevant, rather a relic of the past.  I tend to think it’s misinterpreted in the twitter response.  Here’s the link to the twitter feed and a snap shot below.

 

There is power in this for the worker here, even on performance.  Leaders can use this to create an ethos of transparency.  Looking back to look forward.


Where’s the teamwork when we can’t see each other

I’m an Australian working in the USA coaching highly distributed teams. We speak English but even then there are slight differences, like Australian English and American English and even within America like from South to North.

We find it’s hard to get people to use video cameras. They are cheap however the culture tends to not encourage use of them. It’s always hard to collaborate at the best of times and distribution would be a good excuse not to do that.

Seems most distributed companies can’t get past just the phone and a little screen sharing.  When we use just these, we can’t see each other’s facial expressions and body language.  It’s hard to know how to react to feelings and we have to assume or turn up our intonation sense when listening (perhaps even speakers and listeners can make more us of their voice to relay feelings).  Another big issue is having attention – where I work inattention is called ‘multi-tasking’ and we know that don’t work.

Overall, this is more a problem around the difficulties in collaborating and the fears around that.  We’ll need to work on that to allow the tools to be useful.  Make it safe.  Create the culture and camaraderie of teamwork and reward that.  Highlight even when people are doing things that harm teamwork via a team working agreement.  Realization can quickly occur after that and a team can self correct.

Then there is technology, my friend Agile Bill Krebs, is teaching and coaching on tools to assist the distributed work place.  There are simple tools like join.me which is down the low end of the spectrum through to immersive environments like Minecraft.

The technology is there – it just needs a willingness to try using it and adapting to use it to it’s utmost advantage.

Your last resort is to abandon the distributed model.  That can be avoided I suggest.

 


The Ladder of Leadership and Kanban

Here’s a comparison of David Marquet’s Ladder of Leadership which derives from his work as a nuclear submarine captain and writing his book Turn the Ship Around and then subsequent workshops and writings and the Kanban Method.

The Kanban Method says start where you are.  Other frameworks require a more explicit transformation to new roles and ceremonies.  The Kanban Method also says Improve Collaboratively and Evolve Experimentally (using models and the scientific method).  Of it’s 9 values it also states Leadership.  Acts of Leadership from every level.

A model that you can use to improve and create leadership from everyone is called the Ladder of Leadership (although not explicitly steeped in the scientific method, it is a model).  It starts where you are.  Everyone, and this doesn’t matter what position one holds, is looking to be told what to do.  This is where mostly everyone is.

The Ladder of Leadership recognizes this.  Everyone can use the model as a frame to help each move up the ladder to become more intentional.  By recognizing where someone is on the ladder whilst in conversation, a colleague can frame a question using the next rung on the opposite side of the ladder.

The Ladder of Leadership – Capt. Marquet

Measurement of success comes via a proxy from other measurements like faster cycle times, better quality (less failure demand) and people should be happier and if they aren’t something is still awry.

It takes some time to achieve this.  One must be prepared to stay the course despite the bumps in the road.  If it doesn’t work on one occasion, reflect upon that.  Realize we are humans, have a laugh and try again using what you’ve learnt.  The ultimate aim is to create leaders not followers.  Leaders can relieve bottlenecks and fix problems quicker and with more knowledge than someone further away from the problem.


Edits to my Personal Manifesto

I documented my personal manifesto originally in this link.  It was useful to get it down on paper rather than a tacit understanding.  I think I should sharpen it up a bit.  It’s the same mostly – some wording has been modified.  I’m asking people to call me out when I err.

G(enuine) – Be honest, forthright and fair rather than vague, fake and invulnerable

R(espect) – Actively listen and respect (not necessarily agree with) the views of others rather than jump to hasty conclusions

I(ntegrity) – Uphold good human values and principles and avoid situations that are opposite to these

T(ransparency) – Be open about why, what and how rather than obfuscate, obscure or opaque

S(incere) –  Mean what we say via actions rather than being glib, hollow and lack of follow through.

Whilst we try and be all things on the left we sometimes recognize we fall into the poor behaviours on the right and seek to correct that.