Introduction
"You'd better stay late tonight. Our boss is angry about the progress." -- An ambitious but worrying project manager
Agile, a word once standing for agility and speed, has become one of the sexiest but seemingly abstruse jargons often mentioned by software developers in the IT industry over past 20 years. Agile Development is the primary option of project management methodologies for many teams, because it is simple, agile (literally), and more importantly implying "fast". Think about countless programming labors who are willing to work overtime voluntarily because of hard deadlines.
Agile = Deliver Fast?
When your dev team suffers deferred releases, product quality degradation, poor team moral and fading customer relationship, your friends probably will recommend you using agile development, "Hey, buddy. I heard that agile is pretty awesome. You should probably take a shot." However, after your team has been practicing agile for a while, you are very likely to find it not good enough: loads of bugs after production releases, increasing number of overtime hours, and endless new requirements each of which is the highest priority. You are trembling with fear in the regular meeting with your boss who may ask, "I heard that you guys are improving our capability of delivering with Agile. This is great! So can those important features be available next week?"
"Agile is the same as delivering fast", this is one of the biggest myths from many agile practitioners. Literally, Agile doesn't necessarily mean fast; instead, introduction of Agile will lead to more work and therefore lower delivering speed. Yeah, you are right. Technically speaking, Agile will reduce the speed of delivery. For example, Extreme Programming (XP, one of the most popular agile frameworks) requires unit test cases to cover all features and functions, which would result in 1-2 times of extra code.
So, why do people claim that Agile works great in software development? As it can neither increase development efficiency, nor does it reduce workload, what on earth is this thing useful? This is a typical and the most critical question for Agile practitioners. If you cannot provide timely answers that is satisfied to the team, they will ultimately drop Agile and head back to their old way.
What is preventing success?
As a project manager who have experience of large complex projects, project failures seem to sound quite usual. In 2022, according to TeamStage, the percentage of failed projects is 70%, and it is 55% for overspending; more than 75% project managers are unconfident about the project success. It seems fine that your projects might fail sometime, but it is a serious issue if your long-lasting project failures cause resource wasting, talent lost, and even bankruptcy.
If you have passed PMP exams or learnt project management, you should be familiar with the above graph. Every project is mainly constrained by the 4 factors (dimensions) below:
- Time: delivery deadline, work duration
- Cost: human resources，project budget
- Scope: functional modules，areas of influence
- Quality: defects, stability, performance
Imagine a software project to be delivered in March, with overall budget at $100k and requirements to support 1k users concurrently. The constraints mentioned above are fixed. It looks fine so far as everything is executed as planned. However, once the client asks to add a new important feature, the project scope will be increased, and the team have to compromise by changing other dimensions.
If you are the project manager, how would you justify your balance?
- Time: "This feature is so important that we have to work overtime this weekend."
- Cost: "If you wouldn't be able to do it, I can ask somebody else to help you."
- Quality: "I haven't done the test, but it has to be push to live now. The schedule is so tight!"
Sound familiar? As a developer, you might not be able to find out what exactly happened. Actually, the major reason is that the shape formed by the 4 factors is changed significantly, which ultimately has resulted in a series of problems.
What is Agile exactly?
With the analysis in above sections, we have understood that the real issue of project failures is the deformation of 4-factor changing constraints in projects. Traditional waterfall project management mode maintains the time factor unchanged (ensured by fancy Gantt charts), but other factors are quite different, so the symptoms appear as overspending (cost), defected products (quality) and endless new requirements (scope).
Empirically speaking, successfully projects are made upon quality-first mindset, which implies that deliverables must be usable, easy-to-use and valuable. This is one of the core concepts in Agile. It requires fixed constraints in quality, time and cost, with flexibility in scope. For instance, in Scrum, a popular agile framework, user stories in a sprint is changeable before the sprint starts. Each agile team normally keeps the same quality (regression test required), team size (no more than 12) and delivery window (bi-weekly sprints). The only thing that is different is the list of deliverables promised in the sprint. As as result, the team can maintain strong stability, high quality and continuous deliverables. Furthermore, the agile team is self-adaptive to improve themselves.
I don't expect that this article alone can thoroughly justify the benefits of agile development, not to mention the promotion across the whole organization, which is impossible to be done overnight. But I am sure that appropriate agile practice can reduce overtime work and low-quality delivering effectively, which is also the pain point for most IT people.
Agile = Driving
If you often drive, you can easily realize the fundamental actions when driving: watching, pedaling and steering. Based on the road condition, you can reach any destination in the city by repeating the 3 simple actions. If you don't watch carefully or you mindlessly drive fast, there could be fatal accidents.
The same is for Agile, which is a development process of receiving feedbacks, making adjustments and trotting carefully. This feedback-loop-focused process can increase anti-fragility of the team to allow them survive and prosper in the volatile and changing competitive market environment. It is cultural process focused on human, innovation and freedom.
Yet Agile might not be suitable to ambitious entrepreneurs. They often drive a scooter pretending to be driving a supercar, so they need hardworking horses to peddle it to run fast, or they may be push down to the mountain. Admitting to be driving a scooter is difficult for them, but it is only possible to make the real supercars if they are willing to slow down and innovate.
Top comments (0)