The Agile Tribe

12 Agile Adoption Failure Modes with Jean Tabaka

Author: Renee Troughton (@AgileRenee)

I had the pleasure on the 9th June to see Jean Tabaka in action at the Brisbane YOW night. Topic in reflection: 12 Agile Adoption Failure Modes.

My interest was immediately peaked when the opening question was:

“Ask the four or five people around you what are some of the key causes for an Agile Implementation to fail”.

What we were met with was two elements of failure – 1) at a team layer and 2) at an organisation or enterprise layer. An element of distinction between these two was not really made so I am left to assume most of the twelve failure modes are directed at an enterprise layer.
Read the rest of this entry »

Advertisements
Leave a comment »

Can't see the wood for the trees?

Author: Cara Talbot

Introducing Agile to an organisation, as with any change program, means significant disruption. The way we do things is no longer the same. We no longer have our traditional rulebooks to clearly define what our roles are, how we’re supposed to engage with each other, or how we should go about our work.

This has heightened anxiety to some degree either consciously or unconsciously for almost everyone coming into contact with it. What’s my role now? How am I supposed to know what I should be doing? What if our team fails? What if I fail?

Most have dipped their toes in the water, and have grown in confidence as successes have been achieved. Some have quite radically removed some of the traditional roles altogether and claimed early successes. What risks might have they introduced critics would argue? It’s all a bit too early to tell. Some have turned into what is being coined as ‘Agile Purists’ where they will argue to the death about sticking to process over pragmatism. Perhaps this is because a natural inclination for some might be to seek new (Agile) rulebooks to replace the old; to firm up the ground beneath their feet and feel secure and stable again.

The irony is that debating at this level stunts productivity and can cultivate fear, uncertainty and doubt within their teams by challenging who should be doing what role instead of simply enabling the team to get on with the business of delivery. Teams can lose sight of their end goal.

My observations in attending the recent Agile Australia conference in Melbourne perpetuated this theory. No matter the viewpoint or appetite for risk, discussion threads resulting from the presentations and workshops were often on the following sorts of themes:

  • All design must be done up front/ no upfront design at all; get rid of the Architects!
  • Iteration Managers vs Project Managers. Get rid of the PMs; IMs aren’t really needed!
  • Business Analysts vs Technical Analysts; Subject Matter Experts vs Business Analysts; get rid of the BAs!
  • er… is there anyone left to progress the project?

Of course, there were also the sales pitches about the numerous methods of Agile we should be applying, although Scrum and Kanban seemed to be clear favourites du jour.

Perhaps, it’s a natural evolution of maturing Agile development for organisations. However, there appears to be a tendency to become overly introspective when faced with the challenge of change, rather than focus on what we are trying to achieve by changing. Perhaps we need to reassure people that their base skills are still valid and valued, we just need to work out how and when to apply them to achieve the Agile values of: doing enough to give the best bang for our buck; focussing on delivering benefit to our businesses quickly; being flexible enough to seize opportunities where it is sensible to do so… in other words, projects still need management (albeit there is a heightened, but not new, focus on coaching first, directing second). don’t get mee wrong though we still need to go into design; problems still need analysis; code still needs to be written and tested… and we need to figure out how to do all of this flexibly and collaboratively.

What was most refreshing to me during the conference was to hear the views of Martin Kearns (Agile Practice Lead from Renewtek), Neal Ford (Software Architect from ThoughtWorks) and Nigel Dalton (CIO of Lonely Planet). These three guys appeared to be in the minority in expressing what I feel being Agile is really about –

“…it’s just a guidebook guys, do what works for getting to your end goal.”

With all the Agile methods, tools, techniques and blurring of roles – there are two constants that run commonly between them all – the promotion of genuine collaboration; and of continuous learning. All roles bring value to the way we work. Alistair Cockburn has said: ‘people are highly variable and non-linear’ and as people aren’t software components – it inevitably introduces variability into projects. What’s great about Agile is that it fits process to people, not the other way around. Agile brings a different approach to process: the team is responsible for choosing their own processes, and as such no project will be the same, and no team will be the same.

We need to avoid the trap of holding ourselves up for too long by trying to figure out who does what activity within the project; and instead lift our eyes towards the project’s end goal. What are individual’s expertise – let them get on with it, don’t shuffle activities for shuffling’s sake. What are the team weaknesses? Get the team to collaborate on how to best address any gaps. Don’t introduce any unnecessary complexity. Think – what will success look like, and how can the team best work together to get there?

For those that are still seeking the new rulebook: http://www.Dictionary.com defines Agile as:

  1. Quick and well-coordinated in movement; lithe.
  2. Active; lively.
  3. Marked by an ability to think quickly; mentally acute or aware.

To me, this means that to be truly Agile you have to be agile! The minute you think you’ve got it right, you’re making mistakes. Agile is ever evolving, and what we see as Agile today is likely to bear little resemblance to what it will look like Tomorrow.

1 Comment »

Agile – Beyond Scrum!

Author: Stephen Lawrence, CSM, CSP, PMP, Agile PM Masterclass

As a practising and Certified Scrum Practitioner and ScrumMaster I see tremendous value in the tools and techniques Scrum has given the project world. I also acknowledge that there are more tools and techniques outside of Scrum which can further enhance the value delivered to stakeholders and improve the chances of a successful project.

One example is the use of a concept phase & planning workshops to capture the following essential data is just one example of techniques and tools not taught in Scrum – but vital to understanding your stakeholders needs.

  • Objectives and outcomes a project is to deliver and what changes are necessary to achieve this.
  • What are the trade-off criteria the sponsor and key stakeholders are prepared to move on to ensure a successful delivery?
  • What are the key business benefits the business wishes to achieve?
  • What are the high level features prioritised that will deliver the outcomes – think People process and technology to ensure the objectives and outcomes are achieved – not just a technical solution.

These are all essential Agile tools outside the Scrum toolkit but add significant value to an Agile project. (Thanks Rob Thomsett for these wonderful tools. I highly recommend reading Rob’s “Radical Project Management” for more great ideas and concepts). Another way to add to your toolkit would also be to go to an Agile Academy course to learn how to use these and other tools.

Nor am I a member of the Scrum fraternity advocating the demise of Project Managers. In fact, I am passionately the opposite; I fully endorse the need for PMs but they need to adapt to an Agile world.
Command and control is dead – facilitation and leadership skills are now to the fore!

So the big question is:

How do you empower teams while ensuring accountability, responsibility, openness and transparency?

Unfortunately not all PMs or indeed managers can make this change, nor can all people in a team self-manage. It is an interesting dilemma and one most teams will face at some time. However, to be successful it is important that this issue is acknowledged and addressed. SUCCESSFUL AGILE IS A WHOLE OF TEAM APPROACH – NOT INDIVIDUALS.

Other frameworks such as Feature Driven Development (FDD), eXtreme Programming (XP), Dynamic Systems Development Model (DSDM)(Atern), Crystal, Lean etc. can also add real value to an Agile world. Agile is a framework underpinned by values, processes with a number of tools and techniques that can be used and adapted to best fit.

Feel free to pick and choose not be constrained by dogma. Your stakeholders and sponsor are your customers and you need to ensure you deliver a solution that meets their expectations and achieves the project’s objectives and outcomes.

Scrum is an excellent place to start but don’t let your journey end there.

3 Comments »