In my 35+ years of tech we’ve come a long way in Engineering organization and methodology. Development and QA/Test apart and together, combined with and separate from Product Management, Engineering distinct from Operations, and now DevOps to deal with Cloud deployments. Coupled with this we’ve had structured programing, rapid development, agile, etc. We’ve focused intensely on market needs, product definition, software/hardware architecture modeling, design specs, functional specs, project plans, agile sprint tracking boards, Kanban boards, and all sorts of stuff in between. If anything annoys me, it’s the notion that all things must be done the same and that adherence to a particular discipline must be an all or nothing commitment. Really? Who dictated that requirement?!?
Make Process Fit the Team and Objectives
The fact is that organizations – and the people that comprise them – are unique company to company, and team to team. They have different objectives, abilities, and cultures. There can’t possibly be one and only one way to accomplish goals! In fact, even where processes are well defined, I’d argue that they will naturally change over time as factors like headcount, project resource requirements, time, product needs, etc. change.
Candidly, I’m not a process guru. I’ve read lots of books and articles, worked and led many product organizations, and participated and driven many significant projects. I don’t claim to be an expert at piecing together organizations. I do excel at working with people, defining requirements at various levels, and forming processes which evolve over time to enable teams of people to exceed objectives; but really, this isn’t about me. I’ve got no particular genius. This is about unleashing team member passion, smarts, and energy … and ensuring that process slavery doesn’t constrict individual or team potential.
Focus on Results and Not Just the Process
Personally, I like agile scrum in general as a process so long as the team is not a slave to the process. I have yet to witness agile scrum executed, where I work or elsewhere, as academically described. Sure, everyone keeps the team size small, performs daily standups and sprint planning/reviews/retrospectives; but, depending on the nature of the product and deployment model, there is generally some amount of waterfall to ensure best possible product quality. It may not be long, but we all know the cost of fixing things after release and the harm that could do to company reputation. Worse still… none of us wants customers to suffer.
How well does a tailored and evolving agile scrum process work? Here at DNN Corp. we’ve gone from a single team focus to concurrently addressing multiple products/projects, hitting important timelines, and meeting functionality requirements and quality in the form of impactful products. We can do better … and will as we continue to improve our stride. We’re still in the early days of defining ourselves, realizing our potential, and recognizing that the limits we perceive are only bounded by our own narrow perspective.