Agile practices made their way into my company about 10 years ago and have become an integral part of our operations ever since. Our clients have had many different reactions to Agility, and a lot of them weren’t great. In particular, stakeholders want predictability without accumulating a backlog and developers aren’t quite fond of the discipline that being Agile involves.
As time passed, we settled on SCRUM for development and Kanban for maintenance. Those who are still denying their benefits generally fall into two categories. Either they are teams that are too small to really take advantage of these methodologies or they are companies bleeding out money that are stuck in a continuous cycle of poor performance.
Agility only works if Agile discipline is actually respected. As long as Agile discipline is followed it can work in both offshore and remote collaborations. The idea has been spreading around that Agile methodologies cannot be practiced remotely. This is completely farfetched, the total percentage of the technical population using Agile practices is much higher in Eastern Europe than in Western Europe and there is a high prevalence of remote work in the East.
All of the American technology that is dominating the planet is largely developed offshore. Completely refusing nearshore or offshore as options is cutting off an opportunity. One day or another companies need to meet their deadlines and achieve their financial goals.
Not industrializing a product on time will result in definitively missing the opportunity to achieve hyper-growth. Doing it too early means dying, doing it too late equals planned agony.
The solution is to set up an offshore-based framework of controllable and scalable Agile practices; a software factory that provides good activity management solutions like Jira, a code auditing tool like Sonar, a velocity and skill management dashboard are the prerequisites of scaling up towards Agile.
Providing an Agile management framework to avoid another crisis
These sterile conversations sometimes transformed into real crisis situations that were completely avoidable. This no longer became acceptable as we began reaching 100% Agile project management with the Pentalog Software Factory (taking into account that in 2017 we will deliver around 300 products for our clients). In 2010, 25% of our projects were already working in Agile mode, which augmented to 70% in 2012 and 100% in 2014.
After facing 3 or 4 crises in our clients’ projects we have been able to structure our thoughts and to define a real Agile collaboration framework:
We’ve met the client who didn’t want to see the project’s progress in order to be able to renegotiate terms.
We’ve had the Pentalog team that wouldn’t reveal their weaknesses.
We’ve experienced the lack of Agile discipline shared between both parties.
We’ve had KPIs giving the green light to continue with further engagements while the CEO was (honestly) completely uninformed because he couldn’t understand anything and objectives were poorly shared.
To put it in a few words, I longed for, I fought for, and I imposed on our teams an Agile management framework as an incontestable tool, based as much as possible on “physical measurements” and even worse, on comparisons between projects. At first, certain Scrum Masters thought of stabbing me discretely in the hallways, some others were leaning towards Voodoo or poison in my coffee.
Our managers, especially Cornel, our CTO, took sick leave due to Burn Out. Well, that’s not true, I’m just kidding! That Anglo-Saxon obsession of always clearly stating when you are joking is annoying.
Comparing projects was the main taboo, as developers felt that different projects were incomparable to one another. In a normal environment, like software publishers with less than 10 projects, this idea might stand. But in our case, there are over 300 products under development (media, E-commerce, IoT) just this year and close to 400 more have been developed during the past two years. All of these projects provide a pretty serious base for comparing projects by type and maturity.
In 85% of our projects we have deployed a unique set of KPIs, a one of its kind list of metrics that links together:
Technical debt, with measurements and comments
Measured technical competence
The cost of a story point and its evolution
Here is the good news! At this moment we are able to make our first comparisons between projects of a similar maturity level. Multiple diagnostics and improvement scenarios have been automatically demystified and made available to all of us:
The top management
The results of this deployment are quite impressive in terms of development performance. Operations have become much more serene. The top management’s confidence stemming from these results disrupts our confidence in using R&D software and its capacity to aid in budget allocation.
If all that has been said makes you want to meet Cornel to exchange more on this subject, or one of our Agile consultants for a presentation of our Agile management framework, don’t hesitate to contact us.
We have no intention of stopping here when there is such an interesting path to take and so many new improvement opportunities to seize.
Read more about Agile practices: