Implementing Agile
Agile for the Technical Team and Agile for the Business are two different perspectives on the subject.
Agile for Business is about the result. It's about the product from a market perspective, about the brand, and much more. Agile for the Team is about the process. How the code is written, how it is checked, how deployment is done, what means are used to ensure the availability of services, etc.
The problem is not only that the team and the business focus on different things. In general, the process does not guarantee the result, just because the input data can change. In a reality of constant changes, it will be at least very difficult to build a process that will always provide the business with the required result.
From a practical perspective, Agile for the Team is a specific implementation of tools, mastering which, the Team will be able to reduce entropy within its project against the background of constant external changes.
But in order to use these tools correctly, the Team needs to establish a connection with the Business. That's when the agile approach makes sense.
Principles
The values and principles of Agile are a common basis. From project experience, I've got several practical points that help to keep focus and continue moving in conditions of uncertainty.
-
Time is the most important resource
Lead Time, MTTR, Time-To-Market - are time metrics of the process. But time is not just a metric.
With a fixed Team capacity, time becomes practically the only resource that the Team can manage.
What activities take time in a sprint - this is what is really within the Team's control zone. -
The Quality of the Process should be confirmed by the Metrics of your Service
Your application is the important part of the product. But it's not the whole Product.
The product is also about the level of service; how accessible the application is to the user, how fast it is, the quality of releases, how support tickets are resolved, and so on.
What the Team does within the development process must necessarily find its confirmation in service metrics. -
Costs and Deadlines connect you with the business.
The first principle of the SAFe Framework is - Take an economic view. For the Team it's important to remember that the money for the Project comes from the Business.
In a highly competitive market, 4-6 weeks is a decent term; investors monitor the Product's movement along the roadmap and want a predictable return on their investments.
What does this have to do with Agile development?
By answering the question "How?", the Team decides how expensive the solution will be and how long the implementation will take.
Look for less expensive and faster solutions. -
Expertise and Competencies - resources that affect the Product
The obvious thought is that a lack of necessary competencies will get the Team down. Another important thing - the renewal or increase of project expertise requires Team resources.
That is, on the one hand, without competencies and knowledge of the business domain, it is impossible to build a good Product. On the other hand, to compensate for the lack of expertise, Team capacity is required, which will inevitably be bitten off from Business Features.
Take these costs into account and maintain the right balance. -
Changes and Constraints are constant and objective
The only thing you can be one hundred percent sure of is that the situation around your Project will change and you will always lack resources.
These are the conditions in which business operates. Take this as part of objective reality.
Look for ways to anticipate changes and start acting in advance.