Auspicious Agile

auspicious agile logo

The Director that loved to shuffle his Agile Team

At a multi-national entertainment company that had adopted Agile at a large scale ($1 billion USD program, with ~500 developers plus shared services teams) I worked with the Director of a group that was adopting Agile.  The Director was a huge proponent of Agile which really helped with adoption within the team.  Our team actually used a Kanban variant (actually “Scrumban” aligned with the cadence of the other team’s on the project which used Scrum – why we chose a Kanban variant is a story for another time) to deliver.  From an Agile practices perspective the team and the organisation overall were becoming quite mature.

However, this is not an Agile process story, but rather a story about Agile leadership and people.  You see even though this Director (we will call him Ed) was a great supporter of Agile within his team and his group he had one leadership habit that often sabotaged our efforts.  Ed loved to switch his team members from project to project.  He would spend the day “wheeling and dealing” with the other managers, Directors, and VPs at the company about who would work on what project.  I think this was one of his greatest joys.

In one example of how this affected the team, Ed  came merrily into the office one morning as our team was headed toward an important delivery milestone.  Different aspects of the included stories had been in-progress for some time in the continuous flow and we were nearing completion.  Ed then decided that day that he would move a key team member (we will call her Mary) who had been dedicated to this particular project.  Mary came to let me know that she was being moved to another project, which I immediately checked with Ed.  He confirmed that he had other “Important Work” that he needed Mary to do, and someone else would need to to backfill for Mary.

Now Ed and I were both aware that using an Agile approach whether Scrum, Kanban, or “Scrumban” it is not desirable to move team members frequently, and especially not mid-sprint / mid-strory.  The features based on the stories that Mary had been working on languished, as no one had the background that she did to ensure completion.  Mary also seemed very demoralised at being removed from the project and team at such a key point just before we could finally deliver.

Subsequently about one to two months later Mary left the company to pursue another opportunity.  While she never told me if this was in part due to being moved from project to project like a “cog-in-the-system”, I suspect that this was a large part of her decision to leave.  Mary had shared with the team that she had been on the fence about leaving for some time.  It is likely that the demoralising move and not being treated as a person, but rather a “resource” to be shuffled on a whim contributed to her decision.  The Agile moral of the the story is that in Agile leaders need to have the respect for team members and teams to let them complete their work, and to treat team members as people instead of replaceable “resources”.

Signing off from Singapore.


The Worst Agile Boss I Ever Worked For

So as we continue to look at Agile Leadership and what makes a great Agile leader, I would like to talk about the worst Agile boss I ever worked for.  Several years ago I worked for a company in a group that was responsible for custom software development and custom interfaces.  Two of the original leaders of the group had left, one to another division in the company and another to start a new venture.  The manager that remained (we will call him Bob) was very power hungry and led the team by fear.

Now the VP in charge of our group indicated that he would like for the teams in our group use an Agile approach for software development.  This Agile approach came in the form of adoption of an Agile tool, and doing daily stand-up meetings with the teams.  So Bob decided to start doing daily stand-ups with our team.  Bob would have us sit down in a meeting room first thing in the morning (~8am) and interrogate us about what work we had done.  If he was not satisfied with the answer he would prod and question and demand the answer he wanted about the work.  I imagine Bob would have considered himself to be the ScrumMaster.  However, this was far from the servant leadership / coach role that a ScumMaster is supposed to play.

I remember in one particular “Stand-up” with Bob, he interrogated and questioned one of my team mates to the point that he was in tears.  I can honestly say that in all my working career this was the only time (and still is) that I have seen a grown man break down in tears in a meeting at the office.  Bob seemed to get great satisfaction in intimidating team members and having unquestioning adherence to his program.  Unfortunately nothing about Bob’s approach was Agile.  An Agile leader serves their team, not intimidating them and leading by fear.  An Agile leader empowers their team, and helps them to do their best work, and to self-organise.  Bob did none of these things.

An Agile leader provides vision that the team can work towards and be inspired by.  Bob provided no vision, and in one meeting when asked what the vision was for the team, his only answer was awkward silence.  Bob was actually threatened by his team members doing well, and wanted to make sure no one rose above him, so he used fear and intimidation.  An Agile leader looks to bring out the best in their team, and by doing so brings out the best in themselves.  Indeed Bob was an objet lesson in how NOT to be an Agile Leader, whether ScrumMaster, Product Owner, Agile Manager, or executive!

If there is any key lesson here for me it would be:  As an Agile leader don’t be like BOB!  In fact when I think back on my time working on Bob’s team it helps me to be very clear what I NEVER want to do to my team or others as a leader!

Until next time, Stay Agile!



If You enjoy Auspicious Agile you can support us on Patreon –

Also support the Auspicious Agile blog by shopping on Amazon using the links below!

Hugo BOSS T-Shirt (Amazon)

 POST-IT Note Value Pack (Amazon)

 Five Dysfunctions of a Team book – Patrick Lencioni (Amazon)

%d bloggers like this: