priligy price uk

Agile adoption for data warehouse and BI is on the rise. Agile Analytics can shorten development cycle time, improve quality, and help ensure that you build the right BI solutions for business decision makers. However, conventional IT organizational structures, policies, processes, and procedures are sometimes inconsistent with the tenets of agility. Values like customer collaboration, face-to-face interaction, and continuous delivery of value are often impeded by IT organizational protocols. Here are the top 10 points of friction that I frequently see in companies that I assist in Agile Analytics adoption. While many of these also impact software teams, DW/BI departments are often more directly impacted by them.

  1. Conventional Leadership – Agile expert Jim Highsmith says, “Conventional leaders expect projects to be on-track early and off-track at the end. Agile leaders expect projects to off-track early and on-track at the end.” Agile leaders measure, monitor, and manage in ways that are very different from conventional leaders. Successful Agile adoption involves leadership training as well as technical and project management training. Significant friction occurs when organizational leaders maintain conventional mindsets, habits, and behaviors, while expecting project teams to “go agile”.
  2. Failure to Limit Work in Progress – Friction occurs when IT leaders try to execute too many simultaneous projects. People are saddled with multiple assignments and their time is split between too many activities. This causes significant “context switching” resulting in diminished effectiveness of individuals and teams. The perception that parallel projects will achieve goals faster is false. Cycle times are shorter and results are better when teams focus on one project at a time. Agile leaders prioritize program portfolios and limit the number of parallel projects based on organizational capacity.
  3. Shuffling of Team Members – When IT leaders treat project staffing as a matter of shifting resources between projects based on skillset demands, every project suffers. People are much more than resources with specialized skills. When people are dedicated to a project team for the duration, they naturally develop a sense of ownership of the project. When people are constantly shifted in and out of an Agile project, it is impossible for the team to establish a steady cadence and predictable velocity that can be used for effective iteration planning. Agile Analytics projects should be staffed with a dedicated, cross-functional, self-organizing team.
  4. Functional “Resource Pools” – Friction occurs when developers, architects, modelers, testers, project managers, and others are organized into functional silos or “resource pools”. People are pulled from their functional pool as-needed and returned to the pool when their skill is no longer needed. This organizational structure further contributes to the problems previously discussed. While skills specialization is important, Agile projects benefit from cross-functional teams with a lots of collaboration and interaction. Specialists assigned to dedicated, cross-functional teams naturally broaden their skillsets and become more general-purpose. This serves to boost the performance of the Agile team. Agile leaders seek to deconstruct functional silos and encourage team cross-functionality.
  5. Off-shoring – Agile Analytics favors team colocation, but can still be highly effective in distributed teams under the right conditions. Inhibitors to distributed agility include: large time zone differences, language barriers, and cultural mismatches. Off-shoring in places at opposite ends of the globe introduces all of these characteristics. When considering the benefits of off-shoring, be sure to also consider the cost of rework and the difficulty in team collaboration. Since geographical distribution unavoidable in most companies, Agile IT leaders seek to maximize team interaction by investing in the appropriate technologies and techniques to boost “virtual colocation” wherever possible.
  6. IT Policies and Restrictions – Friction occurs when DW/BI developers do not have unfettered control over their development environments, such as when developers must submit data model change requests rather than making such changes directly in the development sandbox. Such restrictions create undue friction for Agile teams that must deliver business value frequently. Agile leaders seek to strike the best balance between important governance policies where it matters, and the freedom from such policies where it does not.
  7. Shared Services – Many IT organizations have shared services groups to handle activities like deployment, administration, maintenance, etc. These groups are most familiar with conventional phased-sequential projects rather than iterative-incremental ones. Unlike conventional methods in which development is delayed until later in the project, Agile projects call for an immediate start of development. Therefore, support services are needed earlier and in a timely fashion. To prevent the mismatch between shared services’ conventional policies and the iterative needs of Agile teams, Agile IT leaders invest in appropriate Agile training for these ancillary support groups.
  8. Agile is a Project Management Approach – Friction occurs when IT leaders send project managers to Agile training but fail to invest in similar training for delivery teams and management. Suddenly project managers must be the Agile trainers as well as the “enforcers of agility”. Delivery team members lack the context and fundamentals necessary to understand agility, and often resent the disruption that this new change causes. Managers retain conventional habits, which are often at odds with Agile tenets.
  9. Agile is a Technical Method – Friction occurs when IT leaders perceive Agile Analytics as a technical methodology. Some IT leaders believe that if the delivery team receives Agile training, then they will be more productive and able to do more with less. Every project involves management stakeholders, business users, and delivery team members. It is nearly impossible to align the expectations of these constituencies when Agile adoption is relegated to the delivery team only. Everyone must have a shared understanding of Agile Analytics.
  10. Minimal Customer Collaboration – Friction occurs when actual end users of the DW/BI system are not actively involved throughout the Agile Analytics project. Many DW/BI programs rely too heavily on business analysts to be the “voice of the customer”. This is caused by concerns about intruding on busy end users, and users unwilling to commit to frequent review and feedback on new BI features. If a project is worth doing, it is worth doing right – which requires the active participation of actual business users.

How does your IT organization stack up with respect to these points of friction? As an IT leader can you influence chances that will help reduce or eliminate these friction points? If you could only eliminate one of these friction points, which one would produce the greatest benefits to your Agile DW/BI teams? How soon can you get started?

Leave a Reply


I fear that, “agile as the latest magic bullet” has crossed the chasm, but that “agile as a different way of behaving” has not."
- Ken Collier
agilealliance.com
cutter.com
tdwi.org
innovationgames.com
Get Adobe Flash player
Site Meter