10 golden rules for successful Agile projects

Using agile management approaches such as AgilePM on projects has become very popular in recent years. There are many success stories from organisations who have embraced the new ethos.

However, some projects have been more successful than others. This newly updated presentation describes the ten golden rules you need to adopt to increase your chances of success.

These rules will help you turn your projects from being ‘ok’ into projects that are ‘excellent’.

Rules for successful agile projects

1. On time. Every time.
2. Collaborate. It’s a team game!
3. Let ‘Inspect and Adapt’ become a mantra.
4. Wear sensible shoes.
5. Create a rich communication environment.
6. Play with the SCOPE and nothing else.
7. Measure it.
8. Get appropriate ownership of your agile.
9. Understand what self-organising is not.
10. If it is complicated, treat it as complicated.

Video

Some of these topics are covered in an Agile Project Management course but for more details, we recommend you listen to the video by Keith Richards (Lead Author of AgilePM).ide

In the video, Keith identifies:

• How to get a project off to a good start.
• How to identify the important characteristics of the people involved on the project.
• What you need to look for so that you can read the vital signals coming from the project team.
• The importance of time and how it is being used to control the rest of the project.
• How to embrace the inevitability of change (but also making sure it is the right kind of change!).
• How to communicate in the right way most of the time and not just some of the time.

Watch the video by clicking the button below.

https://youtu.be/P84PqqJV7Es

Further questions

When this webinar was recorded, there were several questions which couldn’t be answered in the webinar due to a lack of time. These can be found below.

What is your definition of SCOPE?

People have different interpretations of the word scope and this can vary quite a bit between different industries. The definition I would use in an agile context is that it is the features, functionality, or requirements that the product is trying to deliver/satisfy.

Any tips to get business to adapt to going agile?

The two most important things to do are firstly to engage with the business and secondly to listen to them to see how agile could help them. Do not try to sell them agile.

The best way is to listen to their problems, explain what agile is, and see where there are benefits in using agile.

Our company wants to adopt Scrum for the SDLC process and keep waterfall methods for other projects. Must project managers also be Scrum Masters and what is the best way to transition without a training budget?

Crikey that is a big question! Only using Scrum in your SDLC (Software Development Lifecycle) is fine but then your agile is then limited to just the delivery level and software in particular. Wrapping this with a waterfall methodology can (and probably will) cause problems.

The secret is to blend the two together. agileKRC has a lot of experience of blending traditional approaches with agile and the trick is to get a good balance.

What is the minimum set of team member roles to make Agile work?

At agileKRC we see agile as being applicable to the smallest and quickest of tasks and to the largest and most complex of projects. Therefore, we do not see there being a minimum although if there is only one or two of you it is very difficult to see how you could call this a team.

Even so even if you are just an individual you are probably part of a bigger picture. Therefore, I think agile can work in any situation.

What is the role of a project manager in a Scrum project?

Well according to Scrum you don’t need a project manager and therefore you don’t have one! This to a certain extent is true if you are in a situation where there is one product owner and one product and one team.

At agileKRC we believe that as soon as you move into more complex situations such as multiple Scrum teams somebody needs to manage the situation, and this is where you need the role of the project manager.

We have a whole video and presentation about the difference between a Scrum Master and project manager.

Would setting up a proof of concept phase in a large-scale product development be agile?

Yes. You could run this phase in an agile way as well. Unfortunately, there are some messages out there in the agile community that the best way to build something is to start very quickly and let the solution and architecture emerge. I find that this thinking does work in many situations but from my experience this will not work in the majority of situations/organisations.

Note from Keith

For many years now I have enjoyed presenting at conferences and seminars and one of my favourite presentations is the one presented in this webinar. I have received lots of favourable feedback on this presentation and I have always been happy with the way it has stood the test of time.

But one thing that is making me think long and hard these days is the feeling I have that far from Agile slowing down and stabilising I think it is evolving as much as it ever was. Admittedly some areas of Agile that were seen as new and ground-breaking over a decade ago are now seen as commonplace. User stories would be a good example of this. But as some ideas and techniques become stable, new concepts also appear.

I recently attended a Lean and Kanban conference where one of the topics covered was Cynefin by Liz Keogh. Most of the attendees had not heard of it and even some of those that had heard of it, didn’t know how to pronounce it! But Cynefin was different and was bringing something new to the agile party.

So, I began to wonder if the fundamentals ever change and do my golden rules in particular need to change?

Pretty quickly I decided that golden rules and pearls of wisdom do change over time albeit the changes are gradual.

I think Agile demands slightly different points of focus nowadays, more than it did a decade ago and even beyond that when the agile manifesto was first created.

I do think it is one of Agile’s big ironies that the agile manifesto advocates responding to change, yet it hasn’t changed one iota in 13 years! Not even embracing the idea of changing the word software to solution which is where the larger view of Agile now exists.

To give one example of where I think the demands placed on Agile have changed is in the area of speed of delivery and time to market. 10 years ago many people were getting into a new way of working that involved timeboxes and sprints in order to gain control of the work they were doing. However, as time has moved on, many people are now finding artificial time boundaries can be a little restrictive as they have evolved their working practices to a more flow-based philosophy.

So, the 10 golden rules that I have presented to hundreds if not thousands of people over the years is in need of an upgrade and this latest presentation below contains those upgrades.