Agile or FrAgile?

I haven’t been a Certified ScrumMaster very long though if you meet me you’d think I had been.  Maybe it is because of my limited exposure to traditional waterfall projects that’s been my saving grace; I agonise at the thought of a project that makes the day to day grind seem like wading through sludge for the development teams.  If you, like me, have a goal in mind you want to swim as fast as possible to that goal.

What do roadblocks lead to?

On my journey through various roles in various companies, I have come across so many projects which have hit various roadblocks along the way.  The only way I have been able to circumvent disaster is to ensure adaptation and flexibility was at the forefront of the minds of the talented people executing the projects.  Be it authoring custom business intelligence reports or producing an eCommerce website, all projects have so much room for improvement.

Being naturally Agile…

This naturally led me to adopt Agile principles without ever having formalised the approach; working in an Agile way made sense to me.  No, I didn’t have Sprints or Daily Scrums or any other artefacts and activities defined when I started off; I didn’t know about these as such back then.  I was not a scholar of XP, Kanban or anything of the sort.

What made the way I worked Agile then?  I’d say it boiled down to:

  • Being part of a team that was self-organising, that I could respect and trust
  • Being transparent if things were not going according to plan; communication is key
  • Focus on getting the projects delivered to client satisfaction
  • Being flexible

Missing the point is messing it up.

I have friends who work for large governmental organisations and various other companies where legacy systems are in place and it’s insane how so many businesses are resistive towards the changes around them.  Even those which are actively pursuing change start waxing lyrical about their move into Agile, but are walking head first into what I believe is a trap.  The trap is that they think engaging in Agile activities, such as daily stand ups, will be the be-all and end all of getting them working more efficiently.  They actually end up reducing efficiency my friends ensure me.  Agile used only on the face of it is probably more of a pain than it is a tool.  This is because Agile is bandied about as a term and treated as magical solutions to all their problems.  It is not.  It is supposed to be a way of being; a set of principles that should be followed.  The activities and artefacts are a means to an end, and that end is covered in The Agile Manifesto so simply.

Where can I find that missing magic?

It’s in the Scrum Development team.  The team needs to be respected, trusted and encouraged to become self-organising.  It’s tough, because in a lot of cases management don’t understand how to be Agile, nor are they committed to the processes required.  This requires something bigger than Scrum alone to tackle which we will talk about later; Scrum is simply a framework for getting potentially shippable iterations via Sprints; the teams within this will provide the missing magic you need once they are a stable team that works efficiently.  The Scrum Master’s role is to facilitate this whilst protecting them from extraneous requests from the Product Owner and others.  At the same time transparency is required for trust to develop as well as individual team members’ confidence levels and skill sets.  Working towards this develops a team which is Agile, not just practises the activities.

What’s “being” Agile like?

Daily Scrums become second nature, Sprint Planning becomes realistic and achievable and the Sprint Review in turn yields an iteration which hits that definition of done.  Teams become proud of their work and that they have set out realistic commitments which they then stick to and deliver upon.  Planning Poker sounds less like a game over time and becomes a valuable tool for gauging what can and cannot be committed to in a Sprint.  On the flipside, fun increases.  Team trust and understanding increases and the members of the team edge closer to being truly cross functional.  Individuals pick up skills whilst working on various Sprint Backlog items and in turn use them in future sprints.  Each team member becomes more valuable daily.  Impediments are tackled easier and the increased communications means the Scrum Master is truly in the loop and helps the team out.  In turn the development team begin to understand business needs in business terms; as they become ingrained into the company; they begin to understand the Product Owner’s needs as a champion for the end users.  That’s the ideal anyway.

Management still don’t understand…

Any company can have multiple teams.  The problem we find is when teams turnaround or outsourcing occurs regularly.  The ideal scenario is to have teams who know the company, understand the product vision and critically, are still around once a project is over.  If they can then be used on subsequent product development the teams are much more valuable.  In fact, having multiple teams is a realistic scenario which needs a larger framework to scale Agile into larger enterprises.  There are many approaches to this developing and in 2014 you’re seeing some big schools of thought about to shout out about this, the most notable of which is Dean Leffingwell’s Scaled Agile Framework (SAFe).  Overall understanding and appreciation takes time and results.  Scrum aims to deliver results in product increments to the minimum viable feature set.  A good Scrum Master will facilitate the continuous improvement required by the teams to get to their potential and in time truly being Agile at the smaller scale will result in an easier job scaling it.  Practising Agile activities and having Agile and Scrum artefacts without truly utilising them as they are meant to be used will result only in inefficiency. This is what I refer to as being FrAgile.  This is why management, in those cases, will never understand.

Continuous Improvement is key

Striving for improvement is the aim.  Improvements in quality, speed, processes, output.  The self-organising team will aim for this.  They will be protected from interference during a Sprint, but be able to adapt and be flexible for subsequent Sprints.  They will have enough respect to be listened to if they give their opinions of what can and cannot be done during a Sprint.  They will be trusted to get on with it and expected to communicate if they have impediments.

We’re all human; we want to have fun, we want to enjoy life.  We also want to be recognised for our efforts, to be respected and to be trusted.  This goes for the amazing talent behind so many development teams.  It’s their continuous improvement that is key for a very good reason: without it, agility becomes fragility.

Advertisements