60 years ago or more there was a cost efficient way to deliver change in organisations, a simple effective way it was too. The emphasis was on applying sound common sense across the
organisation and using the experience and capability of the team. This emphasis allowed team members to apply a disciplined and managed approach to deliver to a schedule, agree their deliverables,
report progress on the project and handle rapid unplanned changes midstream.
This approach worked well for many years until a fashionable fanaticism for systems and engineering disciplines emerged. With the arrival of these disciplines came much more
heavyweight project methods and techniques along with a rally call for greater project control.
This was done with sincerity in the belief that this new formality was conveniently and successfully standardizing and improving the organisation.
Regrettably though, this added swell of process drove away all the old valuable and productive rationality and replaced it with some rather lingering inefficient rigidity.
The recent explosion of agile project delivery methods and techniques is a response to these inefficient and inflexible methods of history. But it is a makeshift response.
The new agile methods introduce a chaos and uncertainty that livens and empowers agile teams but they fly in the face of the disciplined meticulous structure of
traditional methods. These traditional methods are often mockingly cited as a sedate old and lumbering way to deliver a project.
All change activity though is ultimately and necessarily driven by a need for certainty, precision and repeatable assured outcomes. A lack of predictability and especially scalability in agile
process and the divergent outcomes that result have created a challenging dichotomy between these two change approaches: old and new. When you consider
the whole change delivery process end to end, they work, in their own ways, but neither works efficiently enough. It is certain that neither is
suitable to successfully deliver very big loads of projects with very little pots of money.
Our change mission is to deliver what is demanded in terms of quality and to deliver that quality output within aggressive time and cost parameters.
This is the challenge that has faced agile projects since the late 90s.
The move towards agile empowerment and collaboration is to be lauded as is the shift of focus back onto real change objectives. These objectives involve delivering what
is required rather than simply delivering what was specified.
However, agile methods do not cover all the activities and do not cover all the costs in the whole change environment.
The heavyweight processes of recent years DO cover all the activities and all the costs but they simply do not offer reliable repeatable results within challenging economic efficiencies.
Current challenges to deliver more for less and to operate an efficient, as well as a rapidly growing, delivery environment with reducing headcount and diminishing budgets are the post global
crisis economic reality. This recent phase shift in macro economics has been very rapid. The reaction to it, by the project change community, has been equally swift and spontaneous. It has generated
a genuine frenzy of eager agile initiatives feverishly searching for easy fix solutions to these divergent change challenges. Agile solutions and methods have a part to play in offering
operational performance improvements and in cost reduction. However, as cost conscious organisations, we must consider the whole cost of any new ways of working. This also applies to agile.
We have to bear in mind that there are elements of our change environment that agile does not embrace. It is crucial that we recognise this fact because these are important elements of our change
environment that have a real cost. This is a real cost that another part of our organisational budget must cover and pick up. It must be considered as part of the whole cost because someone,
in the end, has to pay for it.
By using agile project techniques, it may appear at first sight that we have gone full circle and returned to first principles. It is more complex than that simple statement but it is true that we
have returned to a dogma that minimizes complexity, focuses on priority work, reduces waste and empowers capable individuals. But we enter an enticing era of low latency delivery with evolving
teams who embrace empowering agile methods untarnished by the old overpowering conformist delivery standards. This is a positive step but it has some cautions and some costs to consider.
Contemporary agile projects deliver in isolated functionality-led bursts. However while they operate within a self-regulating environment, these projects inactively delegate governance
responsibility (and therefore hidden costs) to the rest of the organisation. This new agile mix seemed to work for the first adolescent agile projects. Early adopters were happy with the agile
delivery method and their customers were overjoyed with timely business solutions, at last. But wider feedback indicated they were not happy with the lack of perceived management and the singular lack
of management reporting. Those agile projects began to uncover a set of hidden responsibilities and costs that naturally occur between two approaches where one is focussed on high velocity output
and the emphasis of the other is on pre-planned meticulous management.
The space between these two diametrically opposed philosophies is called The Agile Governance Gap.
We attend to the Agile Governance Gap throughout the Toolkit to identify the various disconnects in communication, responsibilities, processes and costs that can occur when introduction of agile takes
place. We start to reconnect those disengaged elements of the project delivery environment between the project and the organisation. This allows an organisation to establish and compare the full
costs of a project. These are costs not normally represented by the average agile project. This lack of consistency in cost composition must bring into question, and in some cases must negate, comparisons of
performance and cost between waterfall and agile projects. This is an important issue to understand if you are running or introducing an agile project inside a waterfall centric organisation. It is
especially pertinent also if your waterfall project is declined funding in favour of an agile solution.
Mind the Gap.
When introducing agile projects, there are other important governance issues to overcome too. The empowerment of teams can create a sort of mini anarchy and some almost fanatical pro-agile behaviour.
This drives agile followers (aka agilophiles) to blindly carry out what they feel is a project revolution. However this can also drive them to blindly ignore the natural needs for communication
and the wider cost management needs of their organisation. The challenge, of course, is to allow and promote empowerment but to have sufficient monitoring to continue effective engagement with the
project. We present and offer solutions to this in the Toolkit so that agile introduction is managed and successful.
It is important to say at this point that agile approaches do work and work really well. They are patently very efficient at small bite sized projects. However an agile approach can be used
on any size of project. It is not limited to very small, low priority or low profile projects. It is not restricted to I.T. projects alone either. Business change and other projects will have
benefits from an agile approach. Although a pick and mix approach is sneered and growled at by dogmatic chieftains of the commercial agile approaches, from experience, you can of course select the
elements of an approach that work and drop the parts that do not work. We all do this all the time in business and in our everyday lives. Agile is no different. But we stress that an agile method must
cover all the costs and all the activities.
Agile project textbooks often concentrate directly on the central development activity whilst they naively ignore wider project activity and responsibilities. This approach assumes the reader will
already have tailored fitting solutions to these missing issues. Or the approach assumes the reader will manufacture some provisional means to overcome these gaps temporarily. That is fine in principle.
However, projects demand more than simple or even complex development. The additional organisational activities though have a cost to the budget. Agile methods may claim to offer a financially more
favourable method of delivery. However, without providing an accurate examination of true activities and costs, they sail close to an unacceptable duplicity. The Big Agile Toolkit returns this integrity
to agile working and helps you to narrow the productivity gap between your organisation and other organisations. This is vital as organisations seek to operate at high efficiency, increasing the
competitiveness of their organisation in the global change delivery marketplace but also to do that with truth and integrity.
If you see a job advertisement for a project management role that states you need full project life cycle experience or you need to have implemented a project from end to end, this will likely mean
you have guided a project from business case through to the cursory acknowledgment of a solution.
Nowadays, this is not enough. Employers demand that you helped shape and guide the original idea from the outset and that you have good understanding of the business driver before and during its
evaluation and assessment.
Furthermore, employers are not elaborately conned with a nodding acceptance from a team selectively chosen to accept your solution, either.
They want to see evidence of a review of the proposed benefits and an assessment of the success of the realisation of these benefits too.
To be a project game changer, you need more than pomp and bluff. You need to be swift, smart and receptive: three key ingredients for agile working. You also need
the tools to deliver your projects successfully and entirely.
Although agile methods have been used for some time now, still we are all used to hearing that projects have overrun budget. We are used to hearing projects deliver late, that a project is about to
deliver something we did not want or is not going to deliver something important to us.
These promises were very easily and very eagerly made, at the start of the project, when the project was allocated the organisations scarce resources.
However, we are accustomed to project failure and familiar with projects stylish and disappointing neglect to fulfil their original promises and pledges.
This is not a surprise to us and it should be. It is a painfully regular
phenomenon and it should not be. There is something wrong with the old way and there are some things that need fixing in the new way.
We seek to look at the whole agile picture not just the individual project or the flavour of agile you choose. When you go to a restaurant for a meal, the choice of soup is important. The size of
prawns that you have with your monkfish and how well these are cooked are also important elements that influence the enjoyment of the meal. The sweet and the choice of drinks and so on are all important
single elements that make up the whole experience. But on an agile project we must concern ourselves with the entire process. Using the analogy, we look from the point at which we request to have
the meal, through the selection of location, the journey to and environment within the restaurant, the service, the products and the process as well as the cost of the whole meal, including tip,
of course. Later, we also conduct a review of the whole end to end experience and even request the opportunity to review the process with all the people concerned to see how we can improve. Agile
is a bigger topic than just which development process you choose. You can choose SCRUM, or Kanban or TikTakToe or whatever your preferred development method is. But that is just the soup. Agile is the
whole meal deal.
In The Big Agile Toolkit we present a full affirmation of the real end to end nature of your projects and provide the structure and techniques to deliver
your projects to time, to quality and importantly to budget. We do this by using techniques that have long standing project management recognition but
with a new and agile twist.
In this Toolkit, we combine best of breed methods to allow you to deliver agile projects to quality, to time and to budget. We look at a philosophy that engenders project delivery, techniques
that enable agile working, practices that are simple to follow and a Lifecycle to support the entire process. We include policies and techniques to ensure the benefits you expected are delivered
and that the environment is ready to develop and deliver interim releases and final shipment. Importantly The Big Agile Toolkit is extensive and, while it can be extended, it seeks to recognise
the far-reaching activities involved in agile project delivery. In this way, you can identify the full scale and evaluate the true costs of an agile project, professionally.
You may come to the end of The Big Agile Toolkit and conclude that its proposals are common sense. This is good. You are not a pioneering astronaut reaching
into orbit heading for Planet Agile. This is not a new or unnatural science dropped in from outer space. Neither is it a religion that asks you to give
up all you used to do, all you used to believe and all you know and trust. Some agile methods though do seem to act like religions that demand some
level of dogmatic subservience or they seek to portray their offerings as a form of majestic magic or splendid science that only a fool would renounce.
Such egocentricity is not healthy and breeds a megalomania that is counter productive. All we ask in The Big Agile Toolkit is that you are willing to
recognise and consider some practical pragmatic recommendations and are sympathetic to some agile ideas. We hope you will try out the techniques, maybe
in a moderate fashion first of all, deliver your first project to budget and start to develop your own agile practice inside your own organisation.
Not everyone is receptive to a new way of working though. In this instance, they require more concrete evidence of process and methods rather than the
apparent chaos and revolution often associated with agile working. The Big Agile Toolkit seeks to provide this order. We know that agile can be made to
work fully and can be made to work correctly. Furthermore, it is reliably the most financially favourable way to deliver projects. This is why we developed The Big Agile Toolkit.
It is a workable
wrapper to SCRUM, DSDM, LEAN and other agile methods and demonstrates project control without stifling the benefits of the agile approach. It enables
you to contribute, make a difference, innovate
and succeed in your projects by doing this with the benefits of agile but by doing this under proper governance and tight financial control.
The Big Agile Toolkit is complete and does not demand intense detailed or lengthy training. It does not require you to leave your office, your home or wherever you are. It does not require you to pay any
fees, to buy any templates or pay for anything else. You have it here. It is a complete end-to-end solution to the challenge of delivering projects to time, to quality and to budget. It is meant for
anyone who works on projects whether you are in a business area or a technical delivery area or you are the person whose responsibility it is to deliver the project, the project manager.
It works and it is simple. If you believe this is not simple, we expect you to e-mail us.
Our email address is
Now if you want your life to change from now onwards and for ever you had better read something else. However, if you want to deliver all your projects to budget from now onwards and for ever then let
us get underway. There are navigation buttons at the top of the page. At the bottom of the page, there are hyperlinks displaying the titles of the previous section and the next section.