Monday 26 May 2014

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,
John.

Thursday 22 May 2014

Why Should I use a Framework to Scale Agile?

In my career and that of many Agile coaches and consultants that I have worked with scaling of Agile to the Enterprise level has come up while working with customers and companies.  The idea of scaling Agile is not new, but approaches to do this are quite honestly not very mature.  This question is frequently on the minds of IT and business leaders that I have worked with from Software VPs, to CIOs, VPs of PMO to business executives.  They hear about the benefits of Agile, maybe in an industry publication, or from a colleague or peer in industry.  But then the concern turns to how (and if) Agile can work in their enterprise, with hundreds or thousands of people and multiple locations (often in different countries and time zones).

Agile is well defined at a team level, Scrum, Kanban, and XP as well as other variants have been around for a long time, and there are many trained and skilled practitioners.  However, when it comes time to scale to say a company with development teams in the US, Asia, and Europe things become a little more unclear.  We can use Scrum-of-Scrums to scale up to handle multiple teams.  In terms of running the necessary programs, budgets, contracts, and team coordination there are allot of questions that generally are not prescribed by simply scaling using a Scrum-of-Scrums approach.  The team then enters uncharted territory for team level Agile.

In some smaller organisations that already use Lean Startup and related Agile practices this may not cause too much of a problem.  However for a large Financial Services, Entertainment, or Manufacturing multi-national this is much more of an issue.  How do they track the progress of multiple Agile teams?  How do they ensure that the budgets allocated by the executive team are being  well spent?  How do they have teams in multiple time zones 12 hours apart, or 8 hours apart work together in a stand-up?  The questions go on and on...

Basically in my experience enterprises end up making up an approach as they go along, a "home made" approach to scaling Agile.  While this is a road that enterprises can and do choose to go, it is not necessarily the best one.  I have been part of teams that have done this and it is quite stressful for the teams and the leaders, making it up as they go along.  I am sure this has caused many managers and execs quite a few sleepless nights worrying about what to do next, and if they will succeed at all.

Having recently spent time looking at several pre-defined approaches for enterprise Agile, such as DAD (http://disciplinedagiledelivery.wordpress.com/introduction-to-dad/), Agile Path (http://www.ebmgt.org/Agility-Path-Framework), SAFe (http://scaledagileframework.com/), LeSS, Spotify, and several others I think that in many cases it is a better approach for an enterprise to adopt or adapt an Enterprise Agile Framework rather than making up their own.  There are several reasons: First it saves companies time, second it allows managers and leaders to find something proven that other companies have used, and third enterprises can reference other companies, case studies, and practitioners for guidance.

Of the frameworks I have been impressed with SAFe as it matches allot of what I have seen when large companies have created functioning approaches to scaling Agile (for instance the Team, Program, and portfolio distinction within SAFe matches what I have seen in large enterprises).  I also like that there are many references to companies that are already using the framework, and there is a path to certification which I think is useful for enterprises.

In fairness, I have spent more time working with SAFe recently than any of the other Agile Scaling Frameworks.  Also, I do not think that any of these frameworks fully defines every step that a company will need to take to implement a Scaled Agile Program (though SAFe does admit that not every aspect of implementation is covered - http://www.scaledagileframework.com/implementing/).  Finally SAFe is still relatively new, though the concepts underlying it have been around for a while.

However, from what I have experienced along with my discussions with other Agile practitioners, it is my opinion that Enterprises are better off to start with a framework for scaling Agile (whether SAFe or another framework), than to go it alone and make up their own.  The key is to make sure that the Enterprise Agile Scaling framework you choose is implementable in your particular business context and matches up with the way that you do business (more on this in future posts).

All the best, from Singapore,
John.

**Note:  My latest series on comparing Agile Scaling Frameworks here (LESS vis-a-vis SAFE) may be of interest to readers of this post.

Friday 16 May 2014

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.
John.

Wednesday 14 May 2014

The company where Agile was a "Four letter word"

In my prior experience at the US offices of an Asian car manufacturer (we'll call them Acme):  My consulting company was developing the opportunity to do a new project with Acme.  I had newly started the Agile practice and was keen to identify initial customers.

We started meetings with the auto financing group of the Acme to discuss the project. The leaders of the Acme Project Management Office (PMO) seemed to want to know all about Agile methods.  After several meetings (and many questions about Agile) it seemed everything was lining up well.  

After talking informally with a few friends and colleagues though I became a little concerned.  It seemed this division of the company (and it's PMO) actually had a reputation for being very anti-Agile.  Sure enough the people who had seemed very interested in Agile during our prior discussions soon indicated that they did not want to use Agile methods at all!

The project did go forward, but without the involvement of our Agile services group.  After analyzing the situation in retrospect I realized that the financing group had almost no exposure to outside market pressures.  Because of this they had no concern about getting to market quickly or satisfying their customer.  Their customer was the auto manufacturing division - and their customer wasn't going to switch to another finance company! 

This led to a key learning for me:  Companies (or divisions) that have little exposure to market pressures have almost no motivation to be Agile.  Instead, in some cases an anti-Agile "status-quo" mentality dominates.  An important consideration before starting down the road of Agile with a company - Are they really concerned about the market at all?  

I am interested if others have seen similar scenarios, where a company / division had no interest in Agile because they had very little direct exposure to the market?  Maybe a captive finance company, government contractor, or other protected company with high barriers to entry.  Maybe a company you work for now ...

Signing off from Bangkok.  John.

Sunday 11 May 2014

Welcome to Auspicious Agile

Auspicious Agile is all about using Agile successfully in the Enterprise, in business, as a leader and adapting Agile methods for Asia.  So first a little background on me:  My name is John Okoro, I have worked in the technology and consulting space for nearly two decades, and have used Agile methods for roughly seven years.  I started my career working for a Big 6 consultancy (now Big 4) and have seen a wide range of projects in numerous industries.  Throughout my career I have been responsible for leading projects and teams.  In this blog I hope to bring insights that I have developed throughout my career, as well as valuable insights from the many colleagues and peers I have worked with along the way.

Agile as discussed here refers to the combined group of methods that derive from the Agile Manifesto (http://agilemanifesto.org), Lean principles, and related methods.  These include but are not limited to:  Scrum, Kanban, XP, and SAFe.  One consistent theme that I have encountered with these and other Agile methods is the need for an approach to leverage Agile at all levels of the Enterprise (from teams up to executives).  The need for Agile leadership principles that align with the use of Agile methods (Servant Leadership, empowering teams, vision casting), and Agile business methods (Lean Start-up, Design Thinking) are also quite consistent.

Finally, Agile methods in Asia call for additional consideration in applying to different cultural contexts from those found in the US and the West.  There is often more hierarchy, and the pronounced need to approach Agile from both a Leadership and Team level to be successful.  Enterprises, in particular in China are often much larger with technology groups numbering in thousands instead of hundreds as is frequently seen in the West.  I hope to address these nuances and promote a fun and lively discussion on these topics as well.

I look forward to highlighting stories, cases, and insights each week that will help each Agile practitioner, agilist, and participant in this conversation to practice Auspicious Agile.  Have a great week ahead.  John.