Agile Tag

To compete in the world of dynamic and disrupted digital markets your organization needs to develop the right technology and IT strategy for success. Here are 5 steps to building a better IT strategy for your organization:

1. Traditional or agile?

You’ve heard time and time again the difference between agile and traditional approaches, but do you know which method your organization needs?

Traditional IT Strategy

The traditional approach to developing a new technology strategy involves a structured and sequential process that produces a long-term view of the organization’s technology requirements together with a plan for meeting these needs. Technology strategies developed using the classic approach have a 3- to 5-year time horizon in line with your organization’s vision and business strategy. But focusing purely on long-term goals and plans could actually limit the organization’s ability to respond to the inevitable changes in its markets that will happen over much shorter timescales. Long-term technology plans run the risk of diverging from the actual business needs, which inevitably change and evolve over time.

It’s important to acknowledge, though, the traditional approach to technology strategy has many strengths, and it can serve your organization very well if used in the right circumstances.

Agile IT strategy

The agile approach to technology strategy is based on many of the same activities as the traditional approach but with some key differences that take into account the need for speed and flexibility. The agile technology strategy requires a collaborative and interactive approach with IT personnel working side-by-side with staff from other areas of the business during every step of the process. Additionally, architecture plays a key role in this approach – it’s assumed that the organization’s current architecture is already documented and maintained as changes are made and that architectural principles and standards are established and are used to guide decisions made about technology initiatives.

2. Create your IT mission

IT missions are a great way to highlight cultural points that are of particular importance to the IT department. When formulating an IT mission, remember:

  • It should align with your defined corporate mission.
  • Create a set of simple guiding principles that will drive daily decision making. A great IT mission ought to be used in the recruiting process to gauge cultural fit; it should be used as part of the evaluation of staff; it should even be used to gauge fit of strategic vendor partners.
  • It should be created with at least a five-year time horizon in mind.

 

3. Work with your enterprise

No industry or organization exists that isn’t impacted by technology. Moreover, there is no division of the company that doesn’t need technology to implement its strategies. So, it’s essential that IT engages the rest of the leaders of the company early enough that the plans can still be shaped.

The best way to engage leaders outside of IT is to talk to them about the future. Remember, the conversations don’t have to be explicitly about technology – technology is the “how” or the means of getting to the ends. It’s more important to address the “what” first. If possible, IT should push department leaders to leverage a common framework so that strategic plans line up at the same level of clarity and granularity. By using a common framework, each department plan can be compared, and your organization’s IT team will be able to identify where common themes exist and suggest single solutions.

4. Develop IT’s own strategy

With IT’s mission firmly in mind, and with the insights garnered from having helped shape the strategies of the other divisions of the company and at the enterprise level, IT must develop its own plan. In addition to the inputs from the rest of the company, IT should conduct research into rising general IT trends such as:

  • More sophisticated and persistent cyber threats
  • The innovation of technology at a staggering pace
  • Clients expecting even more from IT
  • The war for technical talent
  • Industry volatility

 

Once the strategy is created, it is essential that the dots be connected with the initiatives and processes that IT will develop and deploy respectively.

5. Don’t discount the power of change management

“Change is good” is a common statement, especially in the digital transformation era, but you would be surprised by the number of well-formulated IT strategies that don’t end up generating the value anticipated because the plans are not communicated well, leading to only a few people driving the strategy forward effectively.

Change management is critical to the success of business technology programs geared towards realizing the mission and vision of an organization. To encourage positive and sustainable change across your organization’s departments, learn the 6 change management strategies that’ll help you avoid burnout and improve digital transformation adoption.

Unlike the traditional or “waterfall” method of software development, the agile approach does not treat analysis, design, coding, and testing as discrete phases in a development project. Agile has quickly become the standard methodology as businesses see the many advantages of adopting a more flexible approach to software development.

With testing integrated into the development process from day one, agile development often leads to higher quality products, as well as reducing risk. However, making the switch from waterfall to agile can be tricky. Many development teams end up awkwardly straddling the fence between the two approaches, which can make it difficult to effectively manage resources.

To root out any bad habits that carried over when your development team made the switch from waterfall to agile, look out for these warning signs that your team isn’t as agile as you think.

1. No sprint retrospectives

sprint retrospective is a meeting that occurs after a one-month development sprint. Usually held once a month, this is an opportunity for teams to discuss what worked well in the sprint, what could be improved, and what the team will commit to doing differently in the next sprint.

If your team does not hold sprint retrospectives, you are missing out on a valuable opportunity to change work processes in order to improve the quality of the end product. Holding no sprint retrospectives means that problems persist throughout the development process, exposing your business to the risks of waterfall methodology.

2. Long stand-up meetings

Many people resist adopting agile methodology because they think they will spend too much time in meetings. While it’s true that agile development involves a daily stand-up meeting, these should be kept short to avoid eating into everyone’s work time. In fact, the name stand-up comes from the idea that people should literally stand during these meetings so they have an incentive not to let them drag on too long. To avoid stand-up meetings overrunning, have someone with good facilitation skills lead the meeting.

3. Improper product backlog management

product backlog is a list of all the work that needs to be done for a particular product, ordered to prioritize the most important tasks. Sometimes, backlogs can become so large they are difficult to work with. In that case, you need to break the backlog down into short-term and long-term items to make it easier to manage.

4. Failure to deliver product increments after each sprint

One of the principles of agile is that working software is the primary measure of progress. If your team does not deliver a product increment after each spring, that is a warning sign that you are slipping back into waterfall methodology.

5. Urgent tasks that interrupt workflow

When you use the agile approach, your workflows should be regularly adapted to prioritize the most important tasks. If urgent tasks frequently come up and throw your workflow into disarray, that is a sign that the team hasn’t done enough planning to anticipate the upcoming demands of the project. This might be because they are hanging onto waterfall ways of working, such as setting out a roadmap at the beginning of the project and failing to reassess it often enough during sprint retrospectives and daily stand-ups.