Holding the role of technical lead on a software project involves many discussion with business stakeholders about features of a software product and extensions to an existing platform. In such circumstances I see software as an enabler of business processes.
Features
I have worked on number of both SCRUM and non-SCRUM projects. In non-SCRUM projects, with an awareness of the technical integrity of the product or platform, I found myself in the role of a gatekeeper - the guardian of the product vision, if you will. This introduced the hint of an adversarial relationship into my interactions with business stakeholders. I found myself either saying 'No' or having my opinion overridden by someone higher up in the 'food-chain'. This often leads to compromising not only on the technical integrity of the product, but on the business functionality as well - an unsatisfactory outcome for both parties. This is partly a result of having no visibility of the long-term vision for the product and the business.
I have found that SCRUM facilitates a much more positive atmosphere. You can say 'Yes' to the feature requests and put them in the backlog, where they are prioritised by the product owner according to business considerations and product vision. When the feature is implemented, it is implemented fully (as described by the product owner) and it can be implemented properly without comprising the technical integrity of the product. No compromises, everyone is happy.
Please don't misunderstand me, I don't mind saying 'No' when the occasion requires it, but we need to remember that there is a reason someone is asking for something. Understanding the fuller picture as the product owner does, facilitates this, and ensures that the products grows in a balanced way.
Commercial realities
SCRUM works really well, with time and materials based products, but it can work for fixed price projects too. You can charge based on the estimation, either when something is added to backlog (with float time added) or when it is estimated as part of Sprint planning (for a more accurate estimation). Or you can schedule 'n-days' of additional feature requests at x-amount and allow the client to choose how to spend them.
Time scales
SCRUM puts the product owner/project sponsor in control too. Forcing to releasable quality at the end of every Sprint means the product "as it was at the end of the last release" can be shipped. It is simply up to them to decide. The technical team might be running behind schedule, but it is someone else's decision whether to release on time with fewer features, or release later.
Quality
Forcing to releasable quality early and often keeps the defect levels 'low' and stops the 'clean-up job' list some developers build from growing to an inordinate length. The earlier a defect is found, the more quickly and cheaply it can be removed.
Change control
We also know that people change their minds about what exactly they want in the course of a project. Instead of a heavy change control process, it is simply a matter of feature prioritisation. "We can include that feature - you just have to choose whether to delay the release or remove another feature (of equal effort) from the schedule. What would you like to do?"
Empowerment
As I see it, SCRUM informs business stakeholders, gives them flexibility and the ability to make business oriented decisions. Additionally, the technical personnel are empowered to make technical decisions and given clear steering about business priority and feature requests. Everyone has the ability to influence the things that concern and affect them. This facilitates a positive, constructive, and creative teamwork environment.
Features
I have worked on number of both SCRUM and non-SCRUM projects. In non-SCRUM projects, with an awareness of the technical integrity of the product or platform, I found myself in the role of a gatekeeper - the guardian of the product vision, if you will. This introduced the hint of an adversarial relationship into my interactions with business stakeholders. I found myself either saying 'No' or having my opinion overridden by someone higher up in the 'food-chain'. This often leads to compromising not only on the technical integrity of the product, but on the business functionality as well - an unsatisfactory outcome for both parties. This is partly a result of having no visibility of the long-term vision for the product and the business.
I have found that SCRUM facilitates a much more positive atmosphere. You can say 'Yes' to the feature requests and put them in the backlog, where they are prioritised by the product owner according to business considerations and product vision. When the feature is implemented, it is implemented fully (as described by the product owner) and it can be implemented properly without comprising the technical integrity of the product. No compromises, everyone is happy.
Please don't misunderstand me, I don't mind saying 'No' when the occasion requires it, but we need to remember that there is a reason someone is asking for something. Understanding the fuller picture as the product owner does, facilitates this, and ensures that the products grows in a balanced way.
Commercial realities
SCRUM works really well, with time and materials based products, but it can work for fixed price projects too. You can charge based on the estimation, either when something is added to backlog (with float time added) or when it is estimated as part of Sprint planning (for a more accurate estimation). Or you can schedule 'n-days' of additional feature requests at x-amount and allow the client to choose how to spend them.
Time scales
SCRUM puts the product owner/project sponsor in control too. Forcing to releasable quality at the end of every Sprint means the product "as it was at the end of the last release" can be shipped. It is simply up to them to decide. The technical team might be running behind schedule, but it is someone else's decision whether to release on time with fewer features, or release later.
Quality
Forcing to releasable quality early and often keeps the defect levels 'low' and stops the 'clean-up job' list some developers build from growing to an inordinate length. The earlier a defect is found, the more quickly and cheaply it can be removed.
Change control
We also know that people change their minds about what exactly they want in the course of a project. Instead of a heavy change control process, it is simply a matter of feature prioritisation. "We can include that feature - you just have to choose whether to delay the release or remove another feature (of equal effort) from the schedule. What would you like to do?"
Empowerment
As I see it, SCRUM informs business stakeholders, gives them flexibility and the ability to make business oriented decisions. Additionally, the technical personnel are empowered to make technical decisions and given clear steering about business priority and feature requests. Everyone has the ability to influence the things that concern and affect them. This facilitates a positive, constructive, and creative teamwork environment.
Comments
Post a Comment