The Big Agile Toolkit is an amalgamation of agile best practice collected, tested and deployed by our consultants over a period of nearly 20 years.
What The Big Agile Toolkit offers is a proved set of techniques and an approach to the delivery of your projects in a guaranteed agile fashion.
The approach is not a one size fits all solution. No such solution can possibly exist. There will be elements of the Toolkit that you do not need and
elements that are crucial. The more projects you deliver with the Toolkit, the more you will learn about the localisation demands of your organisation.
All organisations change and therefore change and tailor their delivery methods to the specific demands and needs of their organisation. We have tailored
methods over some years with clients and have selected the most frequently requested additions. These more popular additions and enhancements have
been incorporated into the approach, so you do not have to. Assume any changes you need to make for your organisation will be small changes.
We unashamedly target the I.T. project as the example we use within the method for many reasons. Firstly, it is the area of our greatest expertise.
Secondly because I.T. projects are the primary target for any derision when it is aimed towards failing projects. Thirdly, for the many examples an
I.T. project provides to evidence the old failures as well as the new ones and provide us with an opportunity to demonstrate where repairs can take
place. The final reason why we unashamedly target the I.T. project is because of the I.T. sectors capability to famously absorb such vast investment,
to deliver so little, deliver so late then have the nerve to demand more funds to finish the job.
Bear in mind, we are all technicians from the I.T. sector so we have some skill in identifying these failures and a significant will to overcome them, too.
This is why Project Delivery is an area of business spending that demands further scrutiny, especially in the area of cost performance. You can argue,
as we often do, that a lot of project overspend is due to under estimation or keenness on the part of project managers to get a favoured strategy or
This may be the case.
However there are legendary cases of I.T. overspend and some truthfully wanton uses of investment.
This waste and poor investment is viewed as less than comforting particularly in times of money supply deficiencies and financial parsimoniousness.
How to slide your project comfortably between the financial balance sheets of an organisational budget is a perennial challenge and the Big
Agile Toolkit is the route we suggest you use to achieve that goal.
It is a method and a series of techniques that we have used to deliver successful agile projects within budget for our clients. It includes some
practices that you may recognise and some you may not. It includes some practices similar to those recommended within the other agile projects
you have worked on before. It includes techniques based on best practice associated with popular agile methodologies but tailored to avoid the
unnecessary surplus tasks.
All agile methodologies were considered as candidates for the Toolkit but not all were selected. No entire technique is adopted from an agile
approach as we have found there is some redundancy or duplication of methods across the various types of agile project delivery. Finally, the
Toolkit does not contain all of any one of the methodologies because we have found through many project experiences that they all seem to lack
some element or something important and the Toolkit fills the gaps. Furthermore, we have found, some of the popular agile methods have activities
and terms which negatively influence behaviours or make a process unnecessarily complex. These we have removed and, where some replacement was
demanded, augmented the approach with more suitable alternatives.
If you feel we have not achieved this goal, then please email us. We welcome your feedback, certainly.
The Big Agile Toolkit is based upon our years of experience using agile principles and practices. Agile has though, in some quarters, developed a
derogatory reputation. This is precisely what happened to rapid application development in the 90s. Rapid application development (RAD) was a
software development methodology that used minimum planning & maximum prototyping. It was a response to the poor successes of conventional
waterfall application development. It was also an attempt to deliver software solutions faster while allowing the team to change its path and
change its requirements. There were many successes though with some big names and companies involved including Microsoft and IBM.
The success of any application development project will always be judged inside the corporate culture in operation at the time. This judgement
occurred with RAD and it continues today. If a project delivers to time and budget this is good news. If a project delivers to time and budget but in
some way upsets the equilibrium or stasis of a delivery team then this can have a contrary effect. Success for agile projects
challenges the well trodden paths of conventional development. This can have the effect of directly confronting those who wish to continue these paths
and excite a deeper interest in writing off these agile successes than in supporting them. This message is unfortunate bad news. Very
experienced agile practitioners will recognise this conclusion and may have experienced this eventuality themselves.
Any immediate success arouses suspicion and this suspicion will directly follow the surprised and dazed reactions of those who doubted and maybe
publicly denounced this approach. Instantly this creates conflict as both sides have established their positions: one which is supportive to an
agile approach and one contrary to it. To guard and defend their position the various parties will seek to examine their suspicions and begin to
hunt for perceived gaps and superficial misalignments between agile and their normal approach. This hunt, almost certainly, leads to examination
and debate about whether the gaps are perceived or real and whether the misalignments are superficial or important and so on.
This examination will very often
take place at a personal level whereby individuals are questioned over the precise nature of their involvement on the project. Often this is done to
understand the precise nature of the benefit of the approach to the organisation and their empowering influences over the project. This
examination is also enacted to bring into scrutiny the way that quality is embedded within individual work and output.
When this is examined in the light of business agreed
and successful agile outcomes this is a positive analysis and positive results are evident. However, when this is compared to conventional and
often much more lengthy and costly waterfall techniques it is done to demean the agile technique, deride the approach and discredit the value of
the success. This again is unfortunate bad news, especially if you intend to roll out the approach across your organisation.
This doubting scrutiny happens in some form or another more regularly than you would imagine.
In larger organisations, it can become a project in its own right: to examine the organisations
agile approach and unpick the differences, challenges, plusses, minuses etc. between the agile approach and the current standard approach. Yet,
this process itself, we find, often drifts into an inquisition rather than an examination. In some ways it mirrors the process of unpicking a joke.
It was E B White who said: "Explaining a joke is like dissecting a frog. You understand it more but the frog dies in the process." This is the
It is an understandable next step to explore, examine and recognize the process that just took place. But it stifles the impetus of the team. In
their view, they have successfully delivered a challenging project to time and budget. Then they are often them immediately hauled into an inquisition
where their experimental and evolutionary can-do, just-do-it, do-just-enough ethos is examined by scientific, research-based, methodical scrutiny.
Moreover this scrutiny seeks to compare swift practises performed in an agile ethos with similar techniques performed in a lengthy, costly and intensive
It is bad enough that your organisation will seek to dissect the method and kill or let it die as a delivery approach within your organisation.
This is often done even though it delivered what your organisation
wanted, when you wanted it and for a cost that you agreed up front. However, to compare it with a different method that rarely achieves these
eagerly sought outcomes is not a fair comparison. A frog is an amphibian. A Caecilian is an amphibian. They are both amphibians. A Caecilian has no
limbs and resembles a slowworm. A frog has limbs, we know. They are a culinary delicacy. A Caecilian burrows slowly beneath the ground and a frog leaps
almost effortlessly from pond leaf to pond leaf or from tree branch to tree branch. They are the same but different.
Most frogs have large protruding eyes while a Caecilian has small eyes and is treated as almost blind.
The Latin word caecus from which caecilian derives means "blind". They are in the same Latin named class of fauna called Class Amphibia but they
have very different distribution, lifestyles, diets and well, this is not a biology textbook and we have communicated the unfair comparison of the
differences using this analogy we feel.
This is the place where two approaches collide and they will often collide with damaging impact. It is, in our belief, one of the major reasons why
agile methods have not been accepted especially in larger organisations. An inquisition that compares one project delivery method against another
can very easily drift into a mechanism that supports the current approach and then seeks to demonstrate an entrenched justification for the status
The determination, impetus and culture change to be delivered in agile transformation is simply too daunting a challenge for many organisations.
It should not be.
Those projects that run the gauntlet, attempt a first few agile projects and successfully breach this scrutiny are very fortunate. They will almost
certainly operate in corporate environments that accept and welcome new process and change. This is not the norm, in our experience. Entrenched
views from internally influential cabals who maybe also have long standing historic reasons to deny change to enable them to retain their local
corporate power or influence are regularly seen. Influences such as this are often well established and almost fixed.
In our view it is not worth the effort trying to change them. It will likely be easier to find a way to work with them and more successful to seek
a mutual relationship between the host and the entity living within it. In this way, both the host and entity continue to survive and the
liaison is reciprocated, beneficial and shared. This is the sort of interaction and partnership that biology calls endosymbiosis. It is a big word for
a simple process that will be worth the effort if the approach appears to be a collision that will be difficult to survive.
The Toolkit encompasses this approach to organisational agile transformation and treats the relationship as shared. In addition we will treat the
agile transformation itself as an agile project. A transformation project has objectives, scope and benefits to be realised. It has change and it
has delivery that needs to be deployed. The solutions it delivers require marketing, active promoting and training for the techniques to be used
and to gradually become the established team activity. The project will also evaluate the RAG status of operational projects to establish which the
successful agile projects are and which need extra work.
So. It is about time we got into the meat of the approach and started to explore some of the concepts in more detail. A deeper understanding of the
whole subject can come later as we explore the various strands of the approach. But for now, let us look at agile and give the topic an Introduction.