8. Decide to Continue or Re-Evaluate
At this point on any iteration you may find that there are no changes that can be made where the value of the change justifies the cost. There are times early in the process where we have found that we should delay development and wait for other organizational changes to complete before we make the investment in software, and other times late in the process where we have a set of nice to have features that are expensive to implement and provide lower value. In either case, at this point you should delay or cancel further development on this project, as more software will not deliver more business value.
9. Implementing Changes
Delivering Software: The Scrum Team
The primary rule for forming a scrum team is that it should be able to deliver the software that gets prioritized. In large or growing organizations this becomes increasingly more difficult. For example, in organizations with a central systems administration team the scrum team must rely on this outside team to provide the servers where the software will run.
Chatham currently has central database administration, devops, and quant teams that are outside of the scrum teams that I work with and that my scrum teams rely on to deliver software. Each of these outside dependencies decreased the speed and effectiveness that a scrum team can deliver software, but each may be necessary due to other organizational constraints or requirements. These constraints, which are captured as inputs in the model of your organization, may be necessary but should be minimized.
Whether it is a scrummaster, product owner, or project manager who owns the backlog and sets priority for the team, this person needs to be available to the team as the majority of their job. When a team is in the details of development there will be a million questions that they need answered. If developers make guesses to these answers your software will suffer. Remember that most developers are not trained to do business and requirements analysis. Finally, at least one tech team member should be designated to help clear technical impediments.
Delivering Software: Release Strategy
Carefully planning your release strategy allows you to plan for the integration of the new formal Your organization’s leadership team should be aware of the release and change plan and understand how the software will change the other components of the organization. processes into the organization.
Releasing features when the organization is unprepared to use these features will only cause misalignment in your model of the organization and make your software look ineffective.
Org Changes
While software is released at a point in time, many org changes have a transition window. If a team member needs training to operate some new user workflow, this training is not instant and may have a different duration from the software development timeline. Policy and formal process changes are better received when they are communicated well before they go into effect to give teams time to prepare and handle any secondary or tertiary effects of the change.
10. Remeasure Outputs
Once changes have been implemented and software is released the organization can begin to measure the impact of these changes. Some outputs are simple to measure and provide real time feedback, while others are naturally delayed. Managers should try to continuously evaluate performance and their organization evolves. Each release will cause a small change. If you let these changes build up without remeasuring your outputs, then you can’t be sure that you are still making the highest value investments.
11. Iterate
Finally, Agile Congruence is an iterative process. The outputs will naturally feed into your inputs and create new resources and history. Iterate and focus on making small, measurable, incremental improvements.
Leave a Reply