Agile Methods Start with Agile Code,
Why Process is about effective execution, and why practices work together.
Methods and techniques are concrete and seem easy for managers and developers to address, so many conversations about being more agile focus on them. Since the most powerful part of an agile process is collaboration any real moment toward being more agile needs to consider the interactions that happen between methods and techniques and between coding, planning, and integration.
It’s About Construction
The “development ecosystem” and “process” can sound abstract and perhaps not relevant to you as a developer. Testing, code reviews, and deployment are things you touch every day and can have an influence on, but “process” seems abstract at best and wasteful at worst —getting in the way of building things. But process matters.
I became interested in Software Configuration Management (SCM) and Agile Software Development when I realized how much time I and other team members spent struggling against the wrong process .. When the planning and code line processes don’t work well and add overhead, that makes it harder to deliver, and we notice then. We tend not to notice when the process works well, but when it does, my team and I can focus on doing the things that add value: coding and delivering features.
Rather than focus on process, let’s focus on facilitating construction and delivery.
Agile Methods
Agile methods acknowledge uncertainty and manage it with techniques that facilitate transparency, inspection, and adaptation, with an emphasis on working software. The goal of agile methods and practices is to create an environment that allows teams to adjust goals in response to delivery issues, changes in current needs, or future technical or market forces.
Agile methods such as eXtreme Programming (XP) and Scrum promise that teams can be more responsive and more effective at delivering value. But the processes aren’t complete, While XP focuses on technical practices and Scrum focuses on project management practices, they both need planning and execution components:
Good planning makes it easier to execute in an adaptive, agile way.
Agile plans can only be effective if the team follows good engineering practices that give you the feedback that you need to inspect and evaluate and a codebase that will allow you to adapt.
While there are frameworks and guides to specific planning and implementation mechanics, at the core, all you need is some basic practices that let you:
Identify what to work on,
Apply good engineering practices without over-engineering.
Agile Practices
Some of the practices agile projects use fall into these categories:
Planning: User Stories and prioritization set the stage for delivering incremental value.
Coding practices: testing, test-driven development, good design, and continuous refactoring keep the code in an adaptable state, enabling the plan to change.
Integration Practices: Code review mechanisms, continuous integration, continuous delivery, code lines, and branching approaches help maintain a tight feedback loop you need to make decisions.
These practices support each other, as the following diagram illustrates.
The best technical execution only adds value if you know what to build.
An agile plan can change direction based on feedback only if your code Is easy to change safely and quickly.
Code only adds value when it’s integrated quickly and can be deployed reliably.
Agile Code is essential for Agile (software) teams; Agile code comes from design and implementation approaches that provide feedback, such as Test Driven Design/Development(TDD), which can yield more modular, testable designs in addition to basic feedback from automated tests.
Underneath all of this is a culture that supports feedback and collaboration Being agile isn’t just the planning process steps or the technical execution; it’s the result of those steps.
What You Can Do
Changing the problem from “fixing a process step” to “working across the system” makes it see daunting. While it’s fortunate when people across the organization, from management to product management to engineering, understand the value of being more agile and support change, change can be hard, and sometimes you may be constrained by someone outside your team. As a development team, there is still a lot you can do after you fix the things in your immediate control:
Plan development work to be small tasks. This facilitates rapid feedback and delivery. (You can do this independent of the product backlog items).
Use good testing practices, write tests early, and ensure that the code you write is testable. This keeps the code in an easily changeable state as business requirements change.
Collaborate with product owners to help them understand how sizing Product Backlog Items affects the ability to meet commitments. This helps the team deliver value and create trust from other stakeholders.
Central to this is a shared understanding of product value and engineering costs/benefits. While there might always be some specialization between product owners and developers, you can work to bridge the gaps:
Product owners can work to understand the value of technical tradeoffs in terms of schedule and features, as well as the value of deployment and testing infrastructure.
Developers can build a mindset that’s more feature-focused, learning to collaborate with product owners to understand what the smallest, simplest thing to build that will have value is.=
Being more agile takes discipline, and a transition can take time. Changing techniques in one part of the system can help you figure out what to do. Unless you work to change the system, you might get stuck.