- Increase throughput
- Reduce single points of failure
- Maximize individual productivity
- Allow room for developers of all levels
Principals outlined below are aimed at increasing productivity within a small software development team – 10 to 15 developers. Although applicable in large environments, they result from a direct observation within a small setting. Why another workflow? Frankly agile is a bit cumbersome to get right. Meanwhile waterfall is not suitable in today’s market – especially in a startup environment.
PRINCIPAL 1 – ABSTRACT OUT PROJECT INFORMATION FROM TASKS
Do not have developers tied to a project. Project details belong at the business and architectural level. It is the role of the architect to devise how each project is to be realized within the infrastructure. With the help of senior developers and business analysts, projects should be divided into sets of tasks that can be completed independently. Thus, developers should mainly focus on completing these tasks – irrespective of the project they are associated with. This increases velocity and reduces single points of failure. Not to mention, new team members are productive on day one – regardless of their level. While talking about "task", no single task shall exceed a day’s worth of work. It makes code management a nightmare the long these get. While a single developer solely delivering a huge project may seem productive, it’s a liability to the team in the long run.
PRINCIPAL 2 – ARCHITECTURE OVER DETAILS
Do not define tasks before architecture. Contrary to common misunderstanding, software architecture is a dynamic structure - far from static. A considerable effort is needed as new functionalities or constraints are added to the system. Your architecture should never learn about new functionality from ongoing tasks. Architecture is about boundaries and flow. These should remain flexible over the course of your software and dictate the shape of your tasks.
PRINCIPAL 3 – MEASURE
Your Software solution lives and dies by the accuracy of your estimation – or lack of. If you can’t tell how it takes your team to complete a set of requirements within a reasonable range, it won’t take long before your competitor takes over. The ability to measure progress is very crucial. The challenge is always maintaining a high throughput without burnout. Meanwhile, most teams couldn’t tell you their velocity. Charge your team with a sizeable bucket of tasks and let them organize themselves to get the work done within your time constraint. This approach increases team morale and allows developers to work closely.
Top comments (0)