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

Agile Qualifications...

I've always been a little worried about the current clamouring for Agile qualifications.  With the PMI, SCURM Alliance and APM all trying to get in on the act my concern was that we're going to end up with a whole pile of conflicting qualifications - just like Project Management before it.

Now it seems that I was right to worry.  I've never really been a fan of the Certified SCRUM Master which seemed to be given out on courses for just turning up in some cases.  The same has been true of some project management certificates.

Apparently that's all going to change.  However, what I wonder is why anyone thinks that a "paper based" examination really gives any idea of the skills of an individual - and yet that's what we seem to keep getting.  Moving towards a more Vocational Qualification approach would not only challenge people to get the right sort of training but also encourage the use of methods & ideas back in the workplace.

If you want to see the latest comparison on Agile Qualifications then give the following article a good read.  It seemed very interesting to me!  Check it out by clicking What's the latest in Agile Project Management Qualifications?

Happy Easter

Mike

Agile isn't just for software!

Just stumbled on this Declaration of Independance site by accident - but I'm really pleased that I did.  I really believe that Agile applies to all project environments - not just software.  In some ways it reminds me of project management that, for many years, was entrenched only in the construction industry and so called "hard" projects.  Now, 20 years later, project management is found in just about every industry and organisation.

Now I'm not a real fan of the concept of "Agile Project Management".  I think that the mindset of most projects is completely different to that of an Agile implementation.  Until we can change the mindset of Leaders & Managers we're always going to struggle to make Agile work effectively.

The Declaration of Independence is just one of those starting points.  It takes the Agile Manifesto and widens it's application to a range of other possibilities and demonstrates how Agile can be applied outside of software development.

Take a look - and become a signatory if you think it's worth pursuing.

Have a great Easter

Mike

Agile & Communication

After the success of the Agile & Stress and Agile & Empowerment handouts I've now uploaded the Agile & Communications presentation.

Communications is often an undervalued part of dealing with others - especially when leading teams to deliver change.  Most of us are taught some of the basic skills of reading & writing but schools tend to forget the importance of active listening, non-verbal communciations and how to deal with the barriers that stop it happening effectively.

Our ability to be able to communicate is key to other management skills.

Without effective body language reading skills or an appreciation of what people are really trying to tell our ability to negotiate, deal with conflict & motivate others is immediately impacted.

Looking at all of the projects that I've had to turnaround in the last few years I would say that 90% of my success has been due to getting people to communicate more effectively and, making sure that I'm communicating well at the same time.

In follow-up blogs I'll deal with Negotation, Conflict Management and Consultancy Skills.  If anyone would like copies of the exercises that I use on the courses feel free to drop me a line.

Thanks for taking the time to read :-)

Mike

Agile and Empowerment

Carrying on the presentation series from yesterday's Agile & Stress I've uploaded another session on Empowerment.

Now for me I don't really like the word "empowerment" - I prefer the word "trust".  I don't "empower" my teams I "trust" them to get on with the job they've trained for.  It reminded me of a presentation I onced attended by the then CEO of Unilever.  He had already listened to the HR Director explaining how they recruited, trained and then empowered people in Unilever.  He explained that "That's what I dislike about HR.  We don't recruit we attract.  We don't train - we develop and we don't empower we trust our people to get on with the job that we pay them for".  I'm not sure what happened to the HR Director afterwards but it seemed like a pretty strong dressing down to me in front of the Top Unilever Management.

Empowerment is covered really well in Zapp!: The Lightening of Empowerment by William C Byham. The book is written as a readable story in the same way as Goal! a process of on-going improvement and The Noah Project.  This approach makes it easy to read and appreciate the ideas without a lot of "consultancy speak".

Today's link is part of my Agile People Skills presentation and covers Empowerment in an Agile environment.  Tomorrow I'm thinking of uploading Agile & Communications (verbal & non-verbal) which most people say is the most useful part of the entire training session!

Leave me some comments if you'd like me to cover some other Agile topics as well

Mike

Let me know your comments...

Agile and Stress

For the last two weeks I've begun to realise the degree of stress that the Agile transition builds in the Project Team.  Changing from Command & Control to Servant Leadership is a difficult thing to do especially for someone who's been trained in APM or PMI.

To try and address this balance I'm going to be sharing some of my resources that I use for training SCRUM Masters and Product Managers.  Specifically I'll be uploading presentations on Conflict Management, Negotiation, Consultancy, Communications and Stress Management over the next few days.

To start us off I thought that Stress would be a good topic given the week I've had :-)

I really believe that people underestimate the impacts that stress have on project failure but most of us have seen if first hand.  This first presentation highlights the psychology of stress and where it comes from.  As anticipation is a major contributer to stress I'll mention that I'm loading the next in the series tomorrow... Empowerment.

Look here for the Agile & Stress presentation

Mike