{"id":19939,"date":"2024-06-13T10:30:16","date_gmt":"2024-06-13T08:30:16","guid":{"rendered":"https:\/\/www.mews-partners.com\/?p=19939"},"modified":"2024-06-13T14:56:50","modified_gmt":"2024-06-13T12:56:50","slug":"agility-at-scale-what-pitfalls-should-you-avoid-part-2","status":"publish","type":"post","link":"https:\/\/www.mews-partners.com\/en\/agility-at-scale-what-pitfalls-should-you-avoid-part-2\/","title":{"rendered":"Agility at scale: what pitfalls should you avoid? [part 2]"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

In the first part<\/a> of our series of 3 articles, we focused on the risks associated with the deployment phase of an agile framework at scale.<\/p>

In this second part, we’ll be looking at the involvement of stakeholders, be they sponsors or players in the agile transformation, in particular to put in place an innovation process that we consider as essential.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t
<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

Pitfall #3: Innovation is not an option<\/h3>
\u00a0<\/div>
Innovation is one of the pillars of the Agile (& Lean!) mindset. It can even be a differentiating factor in getting the best performance from an Agile project.<\/h6>

A point of view is available on Mews Partners\u2019 website on the theme of “Agility and innovation, from myth to reality”:<\/p>

    1. Agile and innovation, enemy friends<\/a><\/li>
    2. Barriers to innovation: demystifying them through agile thinking<\/a><\/li><\/ol><\/li><\/ol>

      Unfortunately, it is all too rare for adequate room to be left for an innovation approach, whether structured (IP Innovation in the SAFe\ufe0f framework) or more opportunistic and disjointed.<\/p>

      The most blatant example, which we have come across time and time again from the manufacturers we have worked with, is quite simply not implementing these innovation and planning iterations in the name of securing a roadmap to which the team or management is committed.<\/p>

      \u00ab Why wasting my time working on these issues, which are secondary to the value I need to deliver in the short term from my project? \u00bb<\/em>\u00a0<\/span><\/h3>

      The articles above can highlight the virtues of this approach.<\/p>

      For our part, let’s focus on the recommendations we can make to secure this innovation process.<\/p>

      Obviously, the easiest way is to implement this structured innovation approach during each PI (Planning Interval ), systematically including innovation iterations. This ensures that the teams have dedicated time to address these issues, which will often be close to their hearts, and give them the desire to surpass themselves.<\/p>

      In our view, three prerequisites are necessary:<\/p>

      1. The teams need to feel free <\/strong>to come up with ideas that are innovative, disruptive and sometimes even completely outside the scope of MFTs. Delivering the backlog and its commitments is the priority for the teams, and this can generate pressure, which needs to be relieved as much as possible during these innovation phases. Dedicated time must therefore be sacrosanct, and taken into account in the backlog estimate, whether during PI Planning (SAFe-type scaled agility), or during iteration planning (Agile Scrum).<\/p>

      2. Specific support, often external, which can take the form of an idea “agitator”<\/strong>: innovation is not a trivial task, and teams are sometimes not very familiar with the concept. There are specific methodologies for getting the best out of teams and their skills, such as Design Thinking, Lean Startup and Open Innovation.<\/p>

      3. Make it an element of recognition <\/strong>for the team, and even for the individual. This is a tricky element, but it can be kept relatively simple: ensure that the team has the opportunity to present the subjects it has worked on at least to its peers, and ideally to a panel of decision-makers. They could then choose to invest time and resources in the most interesting proposals. Setting up an innovation process, or even a dedicated hackathon-type event, requires time and experience. That’s why specific external help may be needed.<\/p>

      4. Finally, this innovation process must take into account the integration and deployment <\/strong>of the selected initiatives, so that they do not remain unanswered, which would be a demotivating factor for the participants, and would compromise the renewal of the experience.<\/p>

      Let’s face it, it seems simpler to have a global innovation approach in a software development logic than a hardware one, quite simply because the results are often instantly visible and therefore generate immediate value and satisfaction. However, as mentioned in this article<\/a>, innovation can take many forms, and does not necessarily consist in a technological breakthrough.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t

      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t
      \n\t\t\t
      <\/div>\n\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
      \n\t\t\t\t
      \n\t\t\t\t\t\t\t\t\t

      Pitfall #4: insufficient involvement of customers (or Business Owners)<\/h3>\n

       <\/h6>\n
      The SAFe framework is not a self-sufficient ecosystem, hermetically sealed off from outside interaction. .<\/h6>\n

      It cannot evolve properly without the contribution of the Epic & Business Owners (BO)<\/strong>, who represent the end customers, guide prioritisation and judge whether the product delivers the expected value. Given that their responsibility is at stake, they must actively participate in discussions with the teams and the Agile Release Trains (ART) and take decisions that directly commit them. However, the lack or absence of BO involvement is often the cause of failure in the development of a product or service that does not meet expectations.<\/p>\n

      This can be explained by the fact that they are initially poorly identified, with the wrong level of responsibility, knowledge or investment (both financial and technical). It is therefore essential to pay particular attention to identifying BOs, by asking questions such as:<\/p>\n