Startup Innovation> Able to Reverse Course
Able to Reverse Course
The process ensures constant feedback from co-workers and customers. The resulting code is continuously added to the code base or the product. The result is a very flexible and dynamic development process.
If every employee in the company is aware of most projects because there are no hierarchies, chances are lower that the entire institution realizes too late that a key project or the company strategy is going into the wrong direction. Customers are part of the product development process as well.
This rules out the fate of projects at large companies that regularly embark on spectacular investment failures because decision-makers at the top depend on the information fed through the hierarchy via lengthy planning processes, making large investments projects highly risky endeavors.
This contrasts with companies like Github where updated product code is pushed out to the software development platform several times a day. Developers therefore are constantly interacting with the company’s main product and
its customers, instead of spending months behind closed doors without much customer guidance. Startup companies plan by results instead of relying on the ex-ante linear planning done at large companies with traditional hierarchies.
Agile software development has broken with the mainstream tradition of software development that first documents the requirements of the internal or external customer who has a business need to be addressed instead of launching into
producing code more or less straight away.
In this waterfall model, the direction is planned from the outset and once one stage is closed the project moves onto the next one, just like water is flowing down the different levels of a waterfall without being able to reverse course. Agile
software development does carry the inherent risk that sections of code need to be rewritten when the series of small steps without any larger map have strayed off course, something the waterfall model rules out by capturing and documenting
requirements in the beginning and then designing the project based on that documentation.
But critics say this approach in reality is fundamentally flawed as the de facto requirements can change due to the dynamics in large corporations even when fixed and documented in the beginning. In practice, the requirements do not accurately capture or even get anywhere close the real need of an internal or external customer, as the real nature of the problem is only understood when a solution is presented and tested. The many sections impacted by a new system or piece of architecture vie for influence and try to load their own priorities into requirements, resulting in a laundry list that does not capture the actual business need. The much more adaptive and flexible approach of agile software development is better suited to deal with this.
The constant implementation of new code into the code base or directly into the product virtually eliminates the other major pain of linear development planning as well – the implementation phase. In the more traditional approach to software development, a design is drafted and then produced once the requirements are set. Developers then go about their work for several months. They then implement the code, but when latching a code onto other elements of the architecture of a large corporation there is a high chance of many undetected bugs making this phase a lengthy and painful experience with failures and delays. Often the testing phase has been cut short and major problems only emerge after implementation.
Agile software developers, by contrast, sometimes write the test requirements before even developing the code that the tests are written for. This helps them and the customer to understand what problem the new software or section of code needs to address. With large development projects broken down into chunks that can be swallowed and digested as often as every week, the likelihood of serious mistakes being slipped into the code without anyone noticing is much reduced. Mistakes are likely to be minor and can easily be located and ironed out.
On top of these internal issues, when the product is developed and implemented after 12 or 18 months, parts of the product might already be obsolete due to fast-moving markets or changes at the customers’ infrastructure. But agile development can adapt to changes very quickly as it does not plan ahead in a significant way, it just adapts to its environment as the project goes along.
"Innovation is divided into chunks that can be easily swallowed by corporate bureaucracy."
One often cited downside to this approach of not fixing the requirements at the very beginning, is that the scope of a project can grow significantly beyond the original intent. But practitioners with experience at large corporations say
that in practice this also occurs informally even when requirements are documented at the start of the development process.
Most companies in the private sector are still leaning on the management approach that employees are most productive when given clear directions from above – quite the opposite of the approach startup companies follow.
Customer needs and strategic priorities are mostly identified at the top and pushed down the reporting lines instead. Before product innovation takes hold at large companies, sizable layers of middle management first fight over budgets from top management during year-end strategy meetings setting priorities for the next
twelve months. This leaves innovation at the mercy of a bureaucratic process. Innovation is divided into chunks that can be easily swallowed by corporate bureaucracy, split into project budgets and timelines of creating, developing, testing, rolling out the product. The bureaucracy pretends to know which product will be developed in twelve or eighteen months from now. This puts pressure on teams to have ideas in time and within the allocated budget, stifling creativity. At startup companies, there is no burned-out project manager working himself into the ground between being involved in the actual, technical side of a project, motivating their team members, managing the expectations of upper management and ensuring the project stays on track in terms of timeline and budget.
About the Author
Frederik Richter has worked as a financial journalist since 2004. He has reported from more than 15 countries in the Middle East, Asia and Europe, focussing on the interplay of politics and business in emerging markets and particularly in the Arab world.
For several years, he worked as a Reuters correspondent in the Gulf where he wrote about investment and financial markets.
Having taken an interest in the innovation prowess of social media during that time, he is now based in Thailand as an independent journalist and editor.
SCRUM
One area where the departure of start-up companies in software development from this model becomes visible is their approach to project management. The traditional management approach is centered around the idea that an organization runs most efficiently when the ones at the top set out strategy and manage the implementation by those at the bottom who largely do what they are being told.
Here, a project manager is in charge of his team, issuing instructions on the actual technical work, motivating his team and also acting as the interface between the project and the rest of the company and higher management.
In the software development model known as Scrum, there is no more project manager, but only a scrum master. He is not a manager who others report to, but is responsible for simply ensuring that the development team can focus on its actual task – the production of code -- by managing any distracting influences that might emerge in the team’s environment.
Scrum meetings and managers are part of some significant changes to the structure of software and product development that have emerged and gained traction over the past ten to fifteen years and that the flat hierarchies of software startup go hand-in-hand with.