How to Apply Time-Limited Extreme Agile Method (TEAM) to Deliver Software On Time
Our company Imonology is an agile software developer that has built online games, cloud surveillance, IT systems, and blockchain applications.
When we started in 2011, Scrum was our main agile approach, and we built systems based on the spec our partner/client specified when projects started.
The projects were executed in 2-week sprints involving “planning > execution > integration > testing > review”. We also adopted the Scrum principle of “protecting the team from spec change” during a sprint, so that developers can focus on the biweekly goal without distractions.
Yet we were never really able to finish projects on time, as we tried to address various arising issues: technical difficulties, communication gaps, team member’s health or emotional issues, etc.
For one project, we were on an 18-month schedule, yet a major technical difficulty costed us much delay, and the system wasn’t completed on-time. We missed the valuable time-to-market, and the project had to discontinue.
Even though the tech issue was finally resolved, the project was overall a business failure.
That and other similar experiences led us to re-examine our approach, and we realized that there are three fundamental issues faced by most software projects:
1) Unclear spec
Often a project started with a vision to a future where if certain software is built, the world will be better. However, when laying out the spec, unless the team has done something very similar, the spec likely will contain some technical or user interface challenges.
It’s then hard to document the vision fully during the “design phase”, as not all information is available, and some design flaws or technical difficulties simply cannot be foreseen.
2) Communication gap
Communication is hard! You can test this by go tell someone to do a task, then ask the same person to repeat what you just said. Chances are it’ll be 70% or maybe 80% correct, but an important detail or two would be missed.
In a typical project, from the idea initiator, to the designer laying out the spec, to the project manager, to the actual developer, communication gaps exist at all levels. The gap exists regardless of how well-intended, hard working, or professional the team is.
A divergence in understanding starts when development starts, and often gets corrected only when the idea initiator (product owner) has seen what’s been done, which can range from a week to a month, or perhaps longer.
3) Changing spec
One unchanging aspect of life is that it changes. Many things can go wrong during a software project, especially if the project is long. This is well documented in the book “The Mystical Man-Month” by Fred Brooks.
There can be unforeseen technical difficulty, human problems and errors, or simply a change in the spec direction due to business decisions or external environments.
So if the above are the “givens” in a software project, what can we do about it?
During one particular project, an interesting side experience caught my attention: as we were stuck on one difficult tech issue and had to seek outside help, we hired another firm for their consulting services.
The service was really expensive, costing about USD 1,000 / day for 5 days, and it had to be prepaid. As not seeking help could cost us potentially months of extra time, we decided to give it a try.
As time was really limited and valuable, we used every minute well. There was just a 10–15min sync-up at the beginning of each work day, where we specified what goals should be pursued for that day.
The consultant team was really professional, and after just two full workday’s work, our technical issue was already resolved! Ahead of our expectation!
Reflecting back on this experience, I wondered besides specific technical difficulty, will the approach also work for software development in general?
In other words, instead of promising on spec, what if we promise on time? Also, instead of just simply selling hours, if we provide “daily deliverable” of working systems, and let the client see the system’s evolution, would that change the development process?
I toyed with the idea at the end of 2016, and started to test it with some small projects. Namely, we would adopt the work mode of a consulting firm: confirm daily with client what’s the most essential, and deliver a day’s worth of working system for feedback.
We asked clients to hold daily sync-up with us, to review and provide feedback on last day’s work. Thus development efforts ended up matching closely to what was demanded.
After a few test runs, it became apparently this work mode, which may be called Time-limited Extreme Agile Method (TEAM), as a few benefits with regard to the inherent software development issues:
1) Unclear spec
As there’s a continuously and incrementally improved system that the client can operate upon, specific spec details about functionality and user interface, become apparent early on. And we could focus on building the most critical parts as the end user or product owner tries the system.
2) Communication gap
Yes the gap still exists, but it would take at most one development day to discover any divergence and have it fixed, so that any difference in spec understanding has minimal negative effect to the project.
3) Changing spec
Our team attends the daily sync fully expecting any change to the spec, even a major change in direction, as we always verify with the client what’s the “currently most pressing feature” they would like to see. So changes in spec no longer need to be argued, but can actually be embraced.
There are interesting side effects to this approach too, just to name a few:
1) the client values the developer more
As the client pays for time and not spec, the clock is ticking as soon as work begins. It would be counter-productive to blow up or change the spec necessarily. This way the client focuses more on what’s actually important and necessary, instead of what’s “desirable” or “nice to have”.
2) development closely matches the requirement
As a corollary to the above, developer time at any given day, is always focused on the most important task as deemed by the client. Valuable development time thus is spent on the most pressing requirement. This is also a result of daily communication sync-up.
3) project gets launched more likely
While individual projects still differ in their degrees of completion when the time’s up. Whether the project can launch is really constrained by how serious or pressing the client is about it, as there’s always a working system ready for launch. This benefit only becomes apparent after a few projects.
When I later compared what we’re doing with the 80/20 Pareto Principle, I found striking similarities. Essentially our approach is applying the 80/20 rule to software development, which states that 80% of the results come from 20% of the efforts.
By confirming with the client daily on the “most important next step”, we’re essentially re-focusing the project on the most critical 20% at any given time, effectively applying the 80/20 rule, which exists more or less as a natural law at all time spans, be it a month, a week, or a day.
Although we’re still learning, initial results have been promising: the prototype of a blockchain voting system was done in one week, and converted from web to mobile in 2 weeks without prior experiences. A crypto index fund’s was prototyped in 3 months, and launched later at the expected month.
While the specific technology we use help somewhat (we’ve built up a node.js JavaScript open source framework specifically targeted at fast API/server development), I do believe the general principles could be beneficial to any software project, using any language or tech tools.
At the end of the day, the spirit of agile is good cooperation and co-creation between the client and the dev team. Working systems that help solve real-world problems for real people, that’s what agile should achieve! By respecting each other’s expertise and roles, we’ve found that it’s doable!
If you’re interested to learn more, please visit our official site and / or checkout Agile Bootcamp!
