Orchestrator vs. Leader

Jan 08

ErinGarbage, Top of my head, Work , , No Comments

I came across a leadership podcast a few weeks back wherein there was a description of leadership that seems to fit the type of leadership that a ScrumMaster or agile advcocate needs to exude. I lost my notes on which podcast it is for the necessary attribution but the notes that stuck with me contains the following (paraphrased) content:

During a performance show, an orchestrator (conductor) is somebody whom everybody in the group looks up to, following every flick of the wrist for the correct entry into the symphony. The choreographer on the other hand only teaches the vision of the dance, corrects any mistakes during the practice sessions, and then sits back in the audience to see the dance troupe interpret the visions, sometimes in ways that even exceeds what was practiced.

conductor-baton

Image credits goes to freerangestock.com

The choreographer aspect seems to fit what the agile advocate needs to do. This follows the mandate that in an agile team the scrum master is a servant-leader, a person who influences without any direct mandate. For those who finds that hard to comprehend, it is the same type of authority that friends form over their experiences, wherein a select few of the pack is looked upon for inputs on what to do next. That only comes with trust that the “choreographer” knows what they are saying and that they will not lead the pack into ruin.

The only resistance is the inherent inertia that most of the corporate organizations still pine for the command-and-control structure which gives the “feel good feeling” that everything can be boxed into a specific plan. This makes organizations make more open to the idea of putting seasoned managers as conductors of delivery in order to control every aspect and cadence of the team. They are not entirely wrong but the unpredictability of the human mind and real life means they are also not entirely right.

The conductor can still be a person of trust but normally the conductor’s authority is proportional to their perceived reputation. The reputation is a double edged sword as that can be the initial hump that the team needs to overcome to start being comfortable with having the “conductor” as part of the team.

Definition of Done

May 26

ErinWork , , No Comments

I came across this simple definition of done in my inbox:

A good working definition of “Done”: Someone’s need was met.
– Mike Burrows (@asplake) , January 29, 2016

Someone in this context should be taken as everyone that has a stake on the feature/user story:

  • The Product Owner’s Acceptance criteria are met.
  • The Business need will be fulfilled by the developed feature.
  • The Quality Champion’s criteria for well tested feature are met.
  • The (future) Maintenance team would be able to handle any required fixes or maintenance on this code without any difficulties.
  • The Build Integrator will not find any issues with the generated package.
  • (insert your other stakeholder group here together with their concern)

The definition of done (DoD) need not be a list. What is needed is for the team members to understand that Done means the feature is useful for everyone who is interested in it, may it be directly or indirectly. If that is not possible then the team needs to make sure they arrive to that point as part of the Inspect & Adapt mandate of agile methodologies.

I am Human

Oct 01

ErinGarbage, Work , , No Comments

I woke up on the wrong side of the bed today so I need to vent out and nitpick… 🙂

I want to reiterate the advocacy of minimizing the use of the word “resources” when referring to members of your team.

A resource is a finite, inanimate stock or tool. A hammer is a tool therefore it is a resource. My time and skills are resources but I don’t want to suffer the indignity of being categorized as a tool. I am neither a tool nor a resource; and I would appreciate not being abstracted to the same level as a computer. Computers are dumb, they can only follow instructions.

Use FTE to refer to the workload unit, but use team member, colleague, personnel or employee when referring to the human being. Respect the person doing the work. The IT industry may be being overhauled and optimized with automation, but this remains a creative industry and not a place for human automatons. Each member is unique and brings something special to the table.

ciao!