Agile - it ain't our culture revisited...

Thanks for all of the responses to my last blog "It ain't our culture..." - I obviously hit a bit of a nerve.  I'm not the only one who's getting fed up with the "Corporate Clone" culture where we think that everything will work out ok if we just keep trying the same thing again and again... 

Other examples that I've had sent to me include:

Confusing

"Your problem is that you're too focused on delivery and that's just not the way that we do things around here..."

"We don't manage stakeholders... we control them..."

Downright sexist

"Don't get me wrong... Proper project management needs a strong manager - I think that Agile is more fluffy and people focussed - a more female way of delivering projects..."

Misguided

"You've been lucky in the past because we know that you can't deliver anything if you're going to concentrate on business value.  I mean if the customer is part of the project team and they just deliver what they want you wouldn't need project managers would you?"

The problem as I see it is that people are struggling with the changes needed to get Agile working.  It is different, you do need a different attitude and the change to make it work at an Enterprise level is significant.  As luck would have it there are two people who can explain far better than me.

The first is by Gregory Smith - Creating an Agile Environment  and the second is Kane Mar - Impediments to Enterprise Agile.

Two very different articles but one clear message.  You need to look at your own attitudes, views and approaches and change them fast.  If Agile "ain't your culture" then you'd better make sure you make it your culture soon if you want to keep up with your competition. 

It ain't our culture...

I had a long conservation yesterday about interviewing and interviewees that made me stop and think.  We'd just interviewed an excellent candidate who ticked all the recruitment boxes - great CV, demonstrable successes, clear references and a very credible candidate with gravitas.  However, they turned him down because "he great - the best we've seen - but he won't fit with our 'company culture'"  I was also told that "the problem with this Agile approach is that it delivers things too quickly - can't you slow the team down a bit?"

Now part of that I'm sure was due to a blinkered HR approach that seems to be centred around "harmony" and employing "corporate clones" to develop some mythical perfect culture.  But, "harmony" doesn't mean "balanced" - if an organisation isn't delivering what it should it seems to me that they should be looking for something or someone different to make things happen.  A good team has a balance of people with diverse views & attitudes.  Conflict, managed properly, delivers innovation, competition and fun.  Employing the sort of people that "won't upset the people who are already here" seems very short-sighted.  In fact, it can only lead to stagnation and blandness.

Agile depends on creative conflict to deliver effectively, but then does proper corporate management.  Is the drive for "consistency" leading to the death of Agile?  

Agile - why doesn't it work except in the "trial" period?

I've spent a lot of time over the last few weeks talking about the problems of change.  Now I'm thinking that Agile is always going to struggle because of the "siloed approach" that organisations innately adopt.  It's covered really will in this article "Challenges of managing change in a siloed organisation"

The biggest challenge that Agile has is the capability of an organisation to deal with it the decentralised approach.  When Agile is trialled at a local level it seems like the answer to all of those inertia problems that projects seem to produce.  Of course we tend to forget that the trial project has a lot of support, gains the best possible resources and is given the highest priority so it's pretty likely to success regardless of the methods that are employed.  However, at a local level - it all goes well - a fact that many Agile Consultants rely on when they promise to help you "mobilise Agile".

But as we start to ramp up the process across the organisation the cracks beging to appear.  They're not inherent problems with Agility but rather that the approach & mindset in Agile brings the flaws that already exist in the operating model into focus.  There are two ways for the cynic to look at this:  "Agile doesn't work for us" or "Agile doesn't work in the real world".  However, the real problem is that many projects & programmes would have suffered regardless of the method being used - it's the corporate culture that's wrong.

People talk about being "Open and Honest" but aren't really that keen when everyone actually is... we like a bit of wriggle room where things can be glossed over.  Perhaps Agile should stop "making everything sooooo transparent" and concentrate on dealing with the Siloed organisation issue and it's politics.  If we can make Agile work in a siloed environment we may really be onto something exciting...

Mike

Agile Certification - something's missing isn't it?

More and more companies are looking for certification or accreditation in Agile or SCRUM methods.  As Agile becomes more mainstream there is a need to distiguish between one CV and another.  One way of favouring candidates is to look for those that have been vouchered for by some certification body such as the Scrum Alliance and the famous Certified SCRUM Master or Product Owner "qualifications"

Now Agile is a very practical skill that demands a great understanding of how to influence & manage the expectations of the SCRUM team and the various stakeholders that surround development.  Far more, I'd argue, than Traditional Project Management.  However, looking at the marketplace at the moment it seems that every Agile training course is concentrating on understanding & managing the process of SCRUM not the people that are involved.

That leaves me with a concern.  I thought that the Agile Manifesto made it clear that we should favour "Individuals & Interactions" over "Processes & Tools" but from my perspective that exactly the oppostite to the approach that the mainstream certifications seem to be taken that tell me about the process and sweep over the people skills.  That's a mistake that Project Management bodies made in the 80's & 90's and it's only in the last 10 years that they've started to realise that knowledge is only part of the equation and that capability must be demonstrated.

SCRUM lends itself to a skills or vocational based certification approach.  Potential SCRUM Masters need to demonstrate that they not only understand the process (and let's be honest that really doesn't take two days of training) but can apply it in the real world.  To quote the Agile Alliance position "employers should have confidence only in certifications that are skill-based and difficult to achieve" Which is exactly where current qualifications fall down.  They only give employers confidence that a person has been exposed to a specific set of knowledge not that they can then apply that in the workplace.

The APM in the UK seem to be taking a stronger line along with the PMI.  Although I still struggle with the concept of Agile Project Management I respect both of these organisations in the way that they carry out and maintain the credibility of their qualifications.  They also offer "Practitioner" and "Expert" levels to their offerings that require demonstration of skills - that's a move I fully support.

However, I'd still like one of the main UK bodies take on the vocation approach - perhaps an NVQ in Agile & SCRUM for SCRUM Masters and Product Owners?

I'm looking at certitication & accreditation in the UK right now and any support would be welcome to help me bring it to fruition.  Leave me comments

Mike

What comes around....

Now I realise that I've probably been in the delivery business too long or I'm getting old. 

I've got used to the fact that fashions keep changing but keep coming back to the same styles.  Rock music that I loved in the 70's and 80's is becoming popular again - well at least with my teenage daughters. 

So nothing really changes - everything just goes in cycles - around and around and nothing really new is invented.

Now Agile is maturing it's under threat from a new approach - Kanban.  If you're not sure what Kanban is then have a look at this great Kanban 101 guide.

I read this article and I thought - "Hang on a moment - I remember Kanban from 30 years ago when I first started out as a Manufacturing Consultant". I was implementing 'Just in Time' and the 'Theory of Constraints' in JCB, Texas Instruments, Caterpillar and other organiations.  It was the latest thing at the time and the subject of the famous book "The Goal" Now 30 years later I'm being told it's "new" and the "in thing"!

Looking on my bookshelf I've still got all of the white papers, articles and stuff that I created all that time ago.  Maybe I should dust it all off and get ready to write the "Forget Agile it's old hat - implement Kanban - you know it makes sense" novel.  Alternatively I could just call it - "Common sense - it just doesn't get old" Unlike me :-)

Mike

Long break - has it affected your sprints?

After the long break that we've all just enjoyed I'm reminded that I often get asked if teams should have a break between sprints to recover and prepare for the next sprint.  My answer is always the same.  One of the core principles of SCRUM is "sustainable development" and so no I don't think that there should be a break between sprints.

Breaks between sprints lead to a constant need to build momentum and that's just an ineffective way of operating.  The team velocity constantly keeps changing.  So the sprints should be run back to back and we need to make sure that the development effort is sustainable, workloads properly balanced and that SCRUM & innovative remains fun approach not a constant burden to carry.

Of course, a number of companies don't operate real SPRINTs at all.  They run small three/four week waterfall projects that deliver something at the end.  You know what I mean... One week for design, one week for development and one week for testing rather than integrated design, develop & test activities. 

The problems this causes is identical to their Waterfall big brother:

• Testing being squeezed at the end of the cycle and either not completed properly or causing "delays"
• Everyone rushing at the end to complete things that can't really be completed in the time available
• Everyone working extra hours & weekends to deliver what they promised
• Everyone getting increasingly stressed as the end of the SPRINT looms large.

Of course this isn't a problem if it's just a one-off at the end of a project - but if it's happening every three weeks then it's going to make development harder & harder to complete.

Add that to the "technical" debt that SCRUMs slowly develop over the first few sprints without automated testing or integrated development and you've a recipe for serious conflict!

So look honestly at your SCRUM process during your next retrospective.  Are you really running small waterfalls?  Is your team getting stressed?  Can your team get better at working together on parallel design, development & test?

I promise you it'll make everyone's life so much better and you'll deliver so much more.

Mike