Organizations are increasingly producing quality software which has a strong correlation with their systems for value creation and project management. Business’ obsession with efficiency and predictability over adapting and learning really does matter.
Software development is often a learning process, while the command-and-control approach is the traditional way of managing projects. The latter strives to make the best use of established, scaled and repeatable processes.
No major developer activity is repetitive or predictable in software development, for experts would automate it if it was possible. Basically, learning is a random process that involves attempting difficult things as well as those deemed impossible, to see what works and what does not.
Apparent setbacks will always be evident in software development, because things you don’t know will remain in the dark until you try them out, no matter how consistent your progress might be. The setbacks help you understand the system better in terms of what makes it work. They also help developers to know how to increase its usability, and bring the desired results for businesses and users.
The bitter truth is that in software development, no projects exist, and this is killing our teams, software and products. Look at it this way; projects are nothing but drawing imaginary boxes around time and scope, with the aim of “managing things.” The boxes do nothing about the inbuilt complexity. All they offer are scientific management of wild fascinations.
Are you looking for an awesome software developer? Visit us at freelancer.com, for affordable services from our experts.
Instead of easing the process, the imaginary boxes only increase the existing friction complexities, making you pay more attention to the box instead of the product or problem. This is counterproductive, and brings the temptation to lose focus once the developers begin dealing with the following harmful delusions:
-
Playing along with the schedule is paramount to success
-
It is desirable and possible to optimize and measure for estimation accuracy
-
The plan guarantees success because it is perfect
-
Dissolving and composing teams cost nothing
-
Functional silo hands-off also costs nothing
-
The more comprehensive and bigger the plan is, the better the results
-
Efficiency and accountability are paramount
The main problem lies in the delusion that traditional management tries to maximize efficiency and predictability. The following proves this fact.
1. Predictability Kills Innovation and Learning
Predictability is not compatible with learning and innovation, as it motivates team players to conceal the truth. For instance, some people complain they cannot understand why everything goes wrong in a project. This is because everything is "fine" every day, and at every stage, until something really bad happens. The truth of the matter comes out, because the people involved cannot hide it anymore.
Consider a typical "successful" project. One might deliver everything within the budgeted time and money, but still fail to satisfy the client. This is because even after following the stipulated procedures, a project might still fail to give what the user wanted or expected.
Such issues arise due to the project concentrating on trivial things that do not count. These could be time, estimates, ceremonies and conformance taking up the time and resources that could otherwise help doing things that really matter, including generation, value, group learning, user satisfaction, team dynamics, innovation, business insights, information gaps and root causes.
2. Regression towards the Mean is Unavoidable
Every organization has the best performing team players, those who love challenges, thrive on innovation and can create breakthroughs for the advantage of the business. Unfortunately, they may decide to pack up and leave if you insist on maintaining this state, as regression to the mean provides for nothing less that conformance.
If you intend to build software that involves no learning, no experiments, and no risks, then you’d do better to buy it or just drop the idea. Predictability will not help you if you’re interested in coming up with innovative software, or in understanding your users or business in a more meaningful and deeper way.
3. Is Project Management Really Bad?
Most project managers do their teams justice by attending to their morale, removing obstacles, improving their skills, helping them maintain focus and mobilizing the resources they need to achieve the target. You should note that none of these tasks deal with estimation accuracy or plan conformance.
For instance, a manager who encourages overtime work with the aim of achieving a sprint's gross story-point target, misses the point and becomes a party to the challenges that arise.
4. Planning
A directional guidance of your destination is a good idea because you can alter it when appropriate and as you learn. However, the final product suffers in an uppercase plan, as it puts all emphasis on the measure of success and the mantle of truth.
Agile teams' retros are a product of the argument that everyone bears the responsibility of improving a process. However, the project mindset creates the assumption that every part of it is perfect, and any attempts at improvement, let alone suggestion(s), lead to serious reprimands.
5. A Good Project Manager (PM)
The most productive PM is the one who removes any obstacles and attends to their teams at all times, sharing the business vision with each team member. They don’t push juniors to do stuff, but they also don’t detach themselves from the daily activities. They do not focus on micromanagement or constantly request a status report, as this might stall the project.
6. Importance of Deadlines
Deadlines are pivotal in business because, as they say, “time is money”. However, most people place deadlines without really thinking about what it entails to complete the task(s) at hand. Pressure from clients, approaching events, uninformed guesses, assumptions, insignificant external factors and the PM’s wishful and arbitrary thinking may at times put the developer's team under extremely difficult deadline pressures.
The developer's team may sometimes express false confidence in the possibility of delivering complete and quality work by the proposed date. This could be because the team is not used to challenging project plans according to the organization’s culture.
7. Degradation of Quality and Architecture by Projects
Too much concentration on projects brings down the value of integrity. For instance, teams working on brief projects have the liberty to avoid refactoring and go for shortcuts. Technical debt is high for them, as the long-term pain that might arise from their decisions is not upon them.
Hand-offs and uncalled for team alterations alienate team members from understanding and delivering exactly what users want. Blame projects if your staff teams keep delivering deteriorating results, as any guidelines, tools and architectural principles will not stop software decay in the long run.
8. Offering Value to Customers is Paramount
One needs to understand that what is developing is a business capability or a product, not a project. Products and customer experience are the only things that provide customers with tangible value. Product-centered teams:
-
Accumulate lots of domain knowledge
-
Persist, without monthly dissolutions and reformation
-
Don’t produce codes fitting the plan, but offer business value and contribute to strategic decision-making
-
Take full responsibility for own support and infrastructure
-
Build strong and long-term relations with customers and businesses
The major concern remains whether to avoid project management like a plague in software development, or not. The traditional concept applies partially in a fruitful manner when it comes to this nature of work. You may want to try a different and innovative way, but it is still important to borrow from the strengths of project management.
Did you find this post useful? Please leave feedback in the comments section below, because we would love to hear from you.
