DevOps Automation

 View Only
  • 1.  Piloting an agile transformation

    Posted Tue September 05, 2017 05:23 PM

    What do you think is the best way to pilot or proof a  transformations into Agile/DevOps for your customers who may want a change but are hesitant to flip a switch and convert? How long on average did they last? What were the success measurements/metrics for these pilots or proof of concepts?



  • 2.  RE: Piloting an agile transformation

    Posted Wed September 06, 2017 08:49 AM

    Two key things in my experience: reporting and education. The education is critical to ensure that all "players" understand what it is they are converting to. I've seen organizations assume that a tool supporting Agile is all it takes to BE agile, and that certainly is not the case. Reporting is critical to providing the results that will tell you how successful the transformation is over time. The tooling obviously comes into play here. There are standard metrics that you can rely on, well documented. I would recommend you look at the Scaled Agile Framework metrics as a good starting point. You can find them here: http://www.scaledagileframework.com/metrics.

    How long does it take? Depends on the scope. For a team or a team of teams, could be 3-6 weeks to really launch a first iteration based on agile and lean methodology. For an organization as a whole, could be 6-18 months. I assume you're talking about a team level transformation.



  • 3.  RE: Piloting an agile transformation

    Posted Wed September 13, 2017 11:31 AM

    Amy, you are 100% right.  And all the commenters are. 

    Agile is more than toolsets and practices, and after buzzwords, management must get to know what the underlying changes and improvements are going to be.  And get to learn what real world experiences are like.

    That is why local groups like our AgilePhilly.com here in Philly that try to bring the good news ( and the hard reality ) of Agile Practices to IT managers, developers and staff.  Besides far-off conferences, we are local resources with monthly meetings to move people past the questioning stage of "What about . . " to actually trying things differently with their processes and people and start to ask "What if . . . " 

    Our group like most are free, no-charge endeavors, and autumn is the time of the world wide Agile Tour http://at2017.agiletour.org where in cities across the world, local groups try to supply education to the uninitiated but curious.  If in Philly on Oct 23rd, let us know.



  • 4.  RE: Piloting an agile transformation

    Posted Wed September 13, 2017 09:10 AM

    HI Eileen, this is a common scenario in business today. IT shops are hearing all the buzzwords, agile, design thinking, garage method, etc, and are hearing about the benefits of these and want to cash in. The biggest hurdle teams face is how to customize the Agile methodology to the way they do their business. No two teams or companies are alike. What works for one company could be disastrous for another. 

    We have helped several of our customers convert to the agile methodology, some adopted more than others. Generally speaking, we suggest a 1wk feasibility assessment and if it is determined that you are capable then we develop a road map to the pilot followed by general steps to rollout enterprise wide. After the feasibility assessment, two weeks of onsite in-person training for teams who are brand new to the methodology. Its during this two week training period that the framework becomes customized to the customer. Things like deployment times, environment swimlanes, continuous delivery, team rules, and tool selection are all accomplished during this training period if not during the feasibility assessment. Once the training is over, we suggest a minimum of 6wks to conduct the pilot.

    How you measure success is up to the organization. Some customers choose to count deployment artifacts, others count business functionality bits, and others count the velocity of defects resolved - its all dependent upon what your goal of the pilot is. However this is the biggest business value and what is driving the conversion. It is crucial that all stakeholders are in alignment with the goal and the metrics being measured. 

    I'd be happy to discuss this in more detail as we have aided agile transformation with several customers and it continues to be a hot topic with our customers all over the globe. I have assets that were intended to be presented at IBM WoW on this topic last year that I can show you. You can email me at philip.cheshire AT asponte.com and I'd be happy to connect with you to discuss this in more detail. 



  • 5.  RE: Piloting an agile transformation

    Posted Wed September 13, 2017 11:03 AM

    Eileen, in my experience (20 years in system i CM) a lot of our customers are already adopting Agile techniques without a pilot. Where the pilot comes into play is when the existing tools are a limitation and new tools must be adopted. This is also a good time to look at the current overall workflow to take advantage of appropriate tools.  As the other responders have pointed out, the goals of the transformation should be identified as early as possible so the pilot is accurate.

    From my perspective, coming from a traditional IBM i centric Change Management background, the pessimistic change management tools for native i source that most companies are using now are limiting for concurrent development. I will include our own CM tool in that group. It's hard to be responsive when you can not easily manage concurrent development.

    Our toolset was integrated with a true source control tool (Rational Team Concert) over 6 years ago and now integrates with the current commonly used tools, Git, Jenkins, JIRA, even TFS. So when we do a pilot we are handling the automation side of things to support the desired agile workflow out to deployment/testing of artifacts. Our metric for success is that we have a consistent and successful process with the desired outcomes.

    However that is a functional pilot (as is my normal focus) and as other responders have pointed out there is also a cultural shift involved that must be 'piloted' as well. 

    I have successfully implemented a functional workflow just as the customer management requested only to have the development staff so resistant to their changed role and functions that it was rejected from the ground up during training or the bare minimum was done by the developers on an ongoing basis making the reporting side of things nonfunctional.

    So I'll say 2 things.

    First, you must have development staff involved with the design of the target agile workflow (and not just the early adopters) and there must be some positive results for the developers (better tools, increased automation which streamlines their interventions) so they buy in.

    Second, you must also look at a pilot as an opportunity to refine the agile workflow, such that the first pilot might be perceived to fail so the second pilot can be successful. This means you can NOT live and die by target dates.

     

    Our first customer for true source control is a good example of this. After over a year of using RTC for their native source they were getting frustrated with the initial branch (called a stream in RTC) design and we went back and spent a week re-implementing their branch structure and developer workflow and training developers. This was a painful decision but the outcome was positive.

    Thanks Jeff Tickner

    CTO North America

    Arcad Software