Integrating Agile in a Waterfall Practice (Part 4): Implementing Your Strategy
As we continue our series, we will follow the last article, Describing Your Agile Strategy, with some thoughts on implementing your strategy.
In Agile the value is in the delivery. Organizations who do Agile well see increased productivity, realization of benefits earlier in the cycle, and higher degrees of customer satisfaction. However, it can be a very disruptive way of delivering projects especially if the organization is accustomed to hierarchical decision making. For Agile to create the most value, it is when the team can work most directly with the customer in a decentralized decision-making organization.
Preparing Your Organization for Agile
Understand and communicate the Agile Manifesto. Agile is all about value centered delivery and to best understand the values of Agile you need to understand and speak to the values described in that document. If you sit back and take those four parts, the value is in the humans and human interactions more than anything else. At its core Agile is about people and bringing perspectives together to collaborate on delivering value to the customer.
Be reasonable with objectives. Whether you have a top-down mandate to integrate Agile or you are an ambassador within your organization building buy-in, you will have to start with some clear and measurable objectives you’d like to achieve. Set expectations according to what you want to achieve and how you plan to achieve it. Benefits will come once the behaviors required by the methods take root, so patience is required.
Organize product ownership. More so than any other role in an Agile organization, the product owner role is the most important, and can also be the most difficult to do well. Like all other roles, they are customer-focused but also must be the advocate for the needs of the product to do this well.
Establish Agile coaching. The primary objective with coaching is to improve performance. One of the key indicators of a healthy Scrum (Agile delivery team) is the amount of work completed in each successive sprint. The work throughput is called velocity, or which will be discussed more in part five of this series. Like with sports teams, a coach is there to help the team focus on the fundamentals first, and continue to build the team’s capabilities to the point where they can handle increasingly more complex tasks which results in a higher overall velocity.
Build automated testing capabilities. If we are to deliver early and often in an Agile delivery system, we will be running through testing cycles much more frequently. The Scrum is designed to deliver fully functioning software by the end of the sprint, which means the introduced functionality does not break any existing functionality. Automating your regression testing is paramount to ensuring stability for the existing platform without introducing a drag on velocity.
Determine how you are going to track and report costs and schedule. There is going to be a continued demand for estimates and costs for the scope in your project, so be aware reporting doesn’t go anywhere. And if you are going to report on your project’s performance, then controls will need to be established in your overall project plan. Sometimes “going Agile” is misinterpreted as removing controls, but one could argue it’s implementing controls more frequently in concepts such as spring planning, demonstrations, number of sprints, etc. In the last part of this series we’ll explore this a bit more.
Clearly define the Agile roles and responsibilities. Before you can implement your Agile coaching, you will need to determine your organization’s roles to be implemented. Already we’ve spoken of product ownership, which is critical to creating and managing your backlog, but also consider how you want to describe what you want from your Scrum Masters and coaches.
Launching Your Agile Strategy
Choose an initial project with a natural fit for Agile. Agile is fruit from the minds of experienced software developers. If you have a project which is a development effort or something similar, that is the best place to start. Secondarily, having a system integration project can also be a good one to start with, although you may have more trouble securing 100% allocation to your project team.
Secure full allocation of your team resources. As reflected in the Agile Manifesto and mentioned previously, Agile is about the people. For the people on the team to interact most effectively they need to be free from distractions and dictated priorities in order to form into a self-organized, self-directed and self-correcting delivery team. Some organizations describe 100% allocation to a project as only six of the eight work hours in a day, however this is not consistent with Agile principles. Managers – let them go!
Start with shorter sprint durations. You may at first think it would be better to start with relatively longer sprints so that you can show more work being done. However, the team needs to practice the scrum structure and all the associated behaviors. As with all things, the more practice the better. So, consider frequently practicing backlog grooming, story point estimating, task creation, daily stand-ups, product demonstrations and – most importantly – sprint retrospectives at a frequent pace. My recommendation is to start with two-week sprints with the goal of refining your team behaviors before attempting to increase your velocity.
These are just a few of the considerations for your Agile strategy implementation. Using the time-worn adage of “People – Process – Tools” is a great way to think in implementing the strategy. Make sure you have a plan for each of these areas and you will be in good shape!
In our next and final part of the series we will discuss some helpful tools you can leverage to help your Agile processes and the launch of your strategy.