• Liked Prasad Kunte
    keyboard_arrow_down

    Implementing Agile Engineering Practices in Legacy Codebases

    Prasad Kunte
    Prasad Kunte
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    Afraid of legacy code? Don't be!!!

    Most successful product companies are confronted with the problem of legacy code.

    What is a legacy code?

    • A code which is in production for several years.
    • A super-complex, hard to understand code base, written by different set of developers. 
    • Outdated Technology stack.

    But the most hurting reality is:

    Lack of confidence in the code due to zero or poor test coverage.

    Due to this reality, developers are often scared to touch it. They have very little confidence that "their code change wouldn't break the existing application in production."

    Recently at IDeaS, we came across such situation, where we needed to enhance one of our products containing legacy code. We started looking into the code and soon figured out that it was developed in 2007, hardly ever touched (& still working in production :)). The original team, which has worked on this product, could not be traced anymore.

    As this product has expanded to attract new customers, we had to change it significantly in order to support new customer's specifications. We had to make sure that the product was backward compatible and supported the earlier specifications, while we enhance the new specification.

    One simple option was to COPY PASTE every single method which needs to be modified and use an if-statement to decide which method to call. This certainly seems like an easy method, since the chances of breaking existing code is very little. 

    Today we all know this is a BAD option!!!

    Instead, our team decided to refactor the existing code to support plug-and-play approach for different specification. But before we started refactoring code, we had to build a safety net of tests around the existing code.

    How do we put the safety net? Ideal way would be to implement the Test Pyramid first. But, that would have taken significant time to be ready with the pyramid before we start touching the legacy code. And obvious, we would have missed the business goals.

    What do we do?

    Instead of building the entire test pyramid, we decided to attack different layers of the test pyramid, one at a time. Along the way, we followed the following approach:

    1. Re-structuring the Project code-base
    2. Establishing a baseline database: After taking a dump from the production database, we cleared out surplus data from the DB and setup a seed database with automed scripts
    3. Creating/fixing the build script 
      1. Setting up an auto DB deploy tool and integrating it with build scripts
    4. Set up basic CI pipeline
    5. Write a few work-flow tests to capture the system's flow from user's point of view
      1. Find the inception point in the code from where we can exercise the code
      2. Restify the application at the inception point (one service at a time)
      3. Setup authorization for production and test environment
      4. Build minimal test-data set for different environment 
      5. Create a few work-flow tests via the inception point (Test itself should not be coupled with the underlying database or implementation level components)
    6. Write business logic acceptance test to capture various complicated business rules
    7. Test drive the new enhancement or bug fixes
    8. Every time we touch legacy code, refactor the code and improve test coverage at unit level

    This really helped us test driven the new code and implement all the layers of the test pyramid.

    If you've a similar situation, join us, as we share our experience on how to confront legacy code.

  • Sachin Natu
    Sachin Natu
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    60 mins
    Case Study
    Intermediate

    Adopting agile development practices and continuous delivery is becoming a norm in the software industry. Time to market and frequent releases have drastically reduced time available for regression testing. Inspection is considered wasteful. Faster feedback cycles during development is crucial. These have created lot of challenges for testing community, which traditionally relies on manual testing assisted by UI based test automation.

    This is an experience report of transforming testing practices across organization, which decided to embrace Agile. Today our testers are not trying to find defects, instead they collaborate with product management and developers to prevent them in the first place. In fact, during the appraisal process, the defects found by them is ignored, instead we focus on how much time they are able to dedicate to collaboration and exploratory testing. The boundaries between developers and testers have faded away and today quality is whole team's responsibility.

    We started with less than 20% of our testers with automation skills (mostly UI automation) and rest of them relying on manual testing. However, today, all our testers practice BDD. They have picked up Java & Groovy programming skills. They are able to contribute Workflow tests, Integration tests and Business Logic Acceptance Tests. Early collaboration and pairing is the norm. By the time developers are done with their tasks, all checks are already automated and hence we are able to deploy software every fortnight to production.

    Are your testers finding it hard to make this transition to an Agile mindset? This session will give you some concrete ideas based on our transition at IDeaS.  

  • Liked Pooja Uppalapati
    keyboard_arrow_down

    Scaling Agile in a Mainframe Product Development Organization

    Pooja Uppalapati
    Pooja Uppalapati
    Ravindra Chebiyam
    Ravindra Chebiyam
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Agile transformation in any organization will go through myriad of challenges that involves people, existing organization culture, technology/domain etc. Instead of seeing these challenges as obstacles, if you view them as opportunities to grow and improve, transformation will be more impactful and long-lasting. If neglected, the very same obstacles would severely damage the motivation and trust of employees.

    In this experience report we would like to walk you through the agile transformation journey in a Mainframe product development enterprise by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. Specifically we would like to touch upon 

    1. Self-organizing teams
      • Resistance to change
      • Culture shift
    2. HR
      • Lack of role clarity and
      • Effective R&R in agile space
    3. Agile Engineering Practices adopted in Mainframe product development
      • Unit test automation
      • Continuous Integration

    Along the presentation we’ll highlight few anti-patterns and the effects of ignoring them.

  • Liked Vinod Kumaar R
    keyboard_arrow_down

    Build it like sports teams

    Vinod Kumaar R
    Vinod Kumaar R
    schedule 2 years ago
    Sold Out!
    20 mins
    Talk
    Intermediate

    Is it easy to get a crash course in football by Pele or Maradona for a week and produce a world cup winning football team?

    Answer is NO. Then why do lots of people in the corporate world think of hiring scrum trainers & expert developers to train their team for a week and then expect their team to undergo a transformation at a magical scale?

    German football team made it a point to transform their team and it took them a lots of years before they were able to reach the pinnacle. A quick side by side comparison of what is causing agile transformation to fail.

    Vision

    Football: Someone was there owning this entire transformation, the German football association spent a lot of time identifying talent in their teens and groomed them.

    Office: In the corporate world switching jobs every few years have become common, but there is no passing on of the context, resulting in the new person taking charge, starting from all over again, as well as frustrating existing good performers who have to rebuild the perception.

    Infrastructure

    Football: Players expecting state of the art training facilities, fitness programs and new shoes are not a luxury, it is a necessity.

    Office: Computers have become so cheap compared to the salaries, yet the policy of providing the best tools and good work environment are archaic.

    Coach vs Management

    Football: Coaches are given their due powers to help the team achieve the goal. It is very easy for anyone to comment on how professionals should play their game, there would be no use adhering to the metrics if the team cannot win. Winning is the only measure for management.

    Office: Often coaches are seen as part of the management or management tries to heavily influence coaching which results in a team which will work either for metrics or to please higher ups without the actual result that it had aimed for.

    Training

    Football: Just the ability to kick the ball does not make a footballer. Training will be introduced to increase physical strength & stamina, better mental wellness, injury prevention, tactics and strategy.  A heavy investment is made in the training facilities.

    Office: In the software industry a generation is about 2-3 years. Computer science degrees are nowhere near what is state of the art in the industry. At many places the on boarding process is either very shallow or not up to date with the recent developments, leaving people to learn most of the things hard way. Given too many things to learn and the information overload, this results in inefficient learning and application of knowledge on the job. We need to prepare people to find answers that are not available on Google.

    Team composition

    Football: Rookies don’t learn by watching greats from the bench, instead they play along with the veterans. Every sports team makes sure to have the right composition with a mix of rookies, emerging players and veterans. That is how they sustain a winning team.

    Office: Architects and Leads often do not code or are not part of the team every day, this means that most of the time the team just looks up to for advice or waits for reviews. There should be a good mix of people at all experience level so that there are enough people to try new things, enough people who have mastered few things and enough people who challenge change.

    Above all – Persistence

  • Liked Ashish Parkhi
    keyboard_arrow_down

    Gamifying Agile Adoption - An Experiment

    Ashish Parkhi
    Ashish Parkhi
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    While having a chat with Naresh Jain, he suggested me to go through the Ted Talk – “Gaming can make a better world” by Jane McGonigal. I found the title very weird and was wondering how is that possible? After going through the talk though, I was amazed. I started wondering if I can use the gamification technique in Agile Adoption, in our Products, in Performance Management Systems, in Employee Engagement Programs?

    Dhaval Dalal introduced me to Prof. Kevin Werbach’s definition of Gamification – “The use of game elements and game design techniques in non-game contexts.

    For our 4th ShipIt Day, organized on 25th/26th Sept 2014 at IDeaS, I decided to explore the idea of using game elements and game design techniques in the context of Agile Adoption. The idea was to create a gaming system which will automatically collect data, i.e. without explicit user intervention,  from multiple sources like Jenkins, Rally and manually from individuals and offer Star’s for positive behavior and deduct Star’s otherwise.

    The aim was to help the team get continuous visual feedback on how they are doing, adopt agile practices, visualize sense of accountability, visualize sense of achievement, drive positive behavior, create healthy competition, create a culture of appreciation, help performance tracking and create transparency.

     

    Landing Page

    User Profile

     

     

     Update - 

    1. Deducting points seems to be bothering the individuals. Now we are experimenting with getting rid of negative points and introducing short lived badeges instead e.g. "Build Breaker". 
    2. We have now added more badges to recognize individual efforts in various categories.
    3. Working on open sourcing the core app at https://github.com/IDeaSCo/rockstar
  • Liked vinaya muralidharan
    keyboard_arrow_down

    The Snowball Effect - From Team Kanban to Enterprise Kanban

    vinaya muralidharan
    vinaya muralidharan
    Sutap
    Sutap
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    About two years ago, we embarked on our journey towards Agility and Kanban was our vehicle.

    But Kanban had people worried.

    How can we not have detailed plans?! How can we limit WIP when we have so many things to work on?!

    We have due dates to meet! And so on.

    We would like to share one of the approaches that we adopted to help move the change along.

    In addition to focusing on the Kanban implementation at the project levels, we adopted another route – to work through the individuals and the teams – a grounds up approach. We encouraged people and teams to use Kanban boards to manage their daily tasks.

    You have difficulty in managing personal stuff? We’ll help you manage better!

    You have issues in managing team level priority? Look what we did within our team- we have a Team Kanban and we are now much better organized!

    One by one we saw people getting interested. The movement gathered steam - we worked directly with a handful of people and they in turn got their peers onboard. And we saw various flavors like Personal Kanban, Team Kanban cropping up all over the place – even in our Travel Office and Corporate Office. What this did was give people a safe, controlled environment to experiment and learn in.

    As they got used to the ideas of limiting WIP, pulling work, visualizing work and “stop starting, start finishing”, it gave them the confidence to work this way at the project level too. And it made our lives as change agents just a wee-bit easier!

    We welcome you to come hear our story about nurturing the change towards Agility by making it a grass roots movement.

    A brief introduction to Amdocs - Amdocs is a leading provider of Customer Experience systems and services in the telecommunications domain, typically doing large scale transformation projects.

  • Liked kavita kapoor
    keyboard_arrow_down

    Hacking the Sales Process with Kanban/Agile

    kavita kapoor
    kavita kapoor
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    The sales process is hard. As a business owner, you spend your entire time doing it. Often wishing you were back, cutting code. If you are successful you might have a raft of sales people closing deals under their own process while your product people deliver under Agile. Your worlds are split and often, it breaks.

    Change that. Apply Agile and Kanban to supercharge your sales team. Get your developers and scrum master in on the action. Unify your company.

    Kavita has spent the last two years changing the global process of a leading Ad Agency while based in Delhi. Now at Fifty based in London and Barcelona she has created a unified Product and Sales team from scratch. Turning her work over the last 6 months into a case study, get a fresh of the presss step by step break down of hacking the sales process from both the CEO, developer and copy writer perspective. Kavita will be transparent about mistakes and the open about the recipe for success.

  • Jeff Patton
    Jeff Patton
    schedule 2 years ago
    Sold Out!
    60 mins
    Keynote
    Intermediate

    How organizations are learning to value learning and not just velocity!

    We all hate wasting time and money.  In the pursuit of cutting out waste, we've learned to systemically fool ourselves – to convince ourselves with very little evidence that the activities we're engaged in add value.  And, further, activities that don't result in a product we can deliver are waste.  But, the biggest leap of faith I continue to see most companies make is in believing that people want their new product, feature, or idea.  They likely don't.

    This talk is about the rise of learning as a valuable activity.  I'll give examples of organizations that invest in experiments that take the cooperation of developers, testers, product mangers, infrastructure, sales, and marketing.  At the end of these experiments organizations are left with no deliverable product and only the knowledge that the product they're thinking of should or shouldn't be built at all. 

  • Liked Francis Kelly
    keyboard_arrow_down

    6 Fixes to UnSAFe Starts

    Francis Kelly
    Francis Kelly
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Scaling Agile is now proven in a multitude of Fortune 500 companies. From the case studies and presentations, it could look easy -- just follow what everyone else is doing, right?

    But just as the anti-patterns of Scrum can maim the team, false starts at scale can paralyze the enterprise. Which six appear most often?  In this session, Francis discusses how to be proactive in these unSAFe situations:

    • Managers not thinking Lean and teams believing in chickens and pigs
    • Alignment as lip service
    • Prioritization as a game
    • Building a portfolio practice without strong program execution
    • Using Agile to build bad code faster
    • Never looking back

    We know that bullets may not be silver and fixes may not be quick... but knowledge is key to enterprise safety!

  • Liked Todd Little
    keyboard_arrow_down

    Stand Back and Deliver - A Leader's Guide to Accelerating Agility

    Todd Little
    Todd Little
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Leadership is a dance of stepping up to provide guidance and then stepping back to let the team deliver.  This is easier said than done.  As one of the co-authors of the book “Stand Back and Deliver,” Todd will demonstrate some of the tools that he has used to help with this leadership dance.  These tools include:

    • Purpose Alignment Model
    • Context Leadership Model
    • Business Value Model
    • Trust Ownership Model
  • Liked Sean Dunn
    keyboard_arrow_down

    Building a Self-Sustaining Agile Organization: An Exercise in Leadership

    Sean Dunn
    Sean Dunn
    schedule 2 years ago
    Sold Out!
    60 mins
    Talk
    Intermediate

    A successful agile transformation is a challenge - so how to ensure that these gains will be resilient and sustain over time? How can one be sure that the agile values and principles will be passed on to future generations? What charactaristics differentiate the agile organization that is successful today and the one that will continue to be successful well into the future? 

    This lecture leverages Sean's 13 years of military experience to explore how leaders deliberately build great self-sustaining organizations.  Leaning on first-hand case studies from coaching dozens of agile teams, learn about the leadership behaviours that build self-sustaining cultures, and those which fail to see beyond just the methologies. 

  • Liked Raja Bavani
    keyboard_arrow_down

    Detect and Eliminate Bureaucracy in Geographically Distributed Large Agile Teams!

    Raja Bavani
    Raja Bavani
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    One of the many great things about working in Agile teams is the lack of bureaucracy. Agility and bureaucracy do not and cannot coexist. In general, bureaucracy is a system of government in which most of the important decisions are made by state officials rather than by elected representatives.  

    Management guru Gary Hamel says,

    “Strategy gets set at the top. Power trickles down. Big leaders appoint little leaders. Individuals compete for promotion. Compensation correlates with rank. Tasks are assigned. Managers assess performance. Rules tightly circumscribe discretion. This is the recipe for “bureaucracy,” the 150-year old mashup of military command structures and industrial engineering that constitutes the operating system for virtually every large-scale organization on the planet. It is the unchallenged tenets of bureaucracy that disable our organizations—that make them inertial, incremental and uninspiring.”

    In our context, bureaucracy is with reference to geographically distributed teams working together to run Agile projects. When there is bureaucracy in geographically distributed teams, you will find powerful forces setting the rules, defining practices and mandating criteria. And there will be several followers who are ready succumb to the pressure. When this happens one may witness specialized definitions, measurement criteria, and rituals that define the software lifecycle to be followed by distributed teams. Decision making will move up in the hierarchy. Teams will practice practices just for the sake of practicing. Many of the team members will eventually forget the purpose, essence and sprit of processes. That is a slippery slope! In geographically distributed teams – especially when multiple organizations and powerful leaders come together, it is very difficult and challenging to guard against bureaucracy.   When that happens, we cannot have true Agile enablement.

    This session will present the ground realities seen in distributed Agile projects and techniques to overcome bureaucracy in geographically distributed teams.

  • Evan Leybourn
    Evan Leybourn
    schedule 2 years ago
    Sold Out!
    60 mins
    Talk
    Intermediate

    You’ve started on Agile project. You've probably got IT management on board. You've read the manifesto. You've got a wall covered in post-its. You’re probably not using pair programming but you’re following most other Scrum and XP practices. But now you have a problem. Operations, HR and finance can’t keep up. Ops is having problems (or just refusing to) deploy each iteration. HR won’t let you form self-organising teams and don't know how to write KPI’s to support collaborative work practices. And finance wants a 3 year budget with fully costed initiatives.

    Like many cultural problems, change comes from understanding. This presentation will explain how non-IT business functions operate and why they have legitimate problems with Agile delivery.

    We won’t stop there however.

    By understanding your business, this presentation will provide you with the tools you need to align your corporate business functions to your agile development approach. From improved communication integrated sales, rolling budgets, agile KPI’s and aligning to revenue drivers. You will learn how to build a truly agile organization.

  • Liked Jeff Lopez-Stuit, CEC
    keyboard_arrow_down

    Exploit Core Agile Practices at the Program Level

    Jeff Lopez-Stuit, CEC
    Jeff Lopez-Stuit, CEC
    schedule 2 years ago
    Sold Out!
    45 mins
    Workshop
    Intermediate

    Core Agile practices establish visibility, remove impediments, and promote collaboration at the team level. Standup meetings, physical task boards, and focus on clearing impediments are well known practices to keep a team focused on the work, and establish a sense of flow towards frequent, tangible, and sustainable results.

    What about an entire program, when a large number of teams are involved? How can a large organization exploit the same core practices when there is highly interdependent work, and when there may be hundreds of people involved? How can Scrum be used to improve delivery times, increase quality, and promote sustainable development at a program level? How the can practices provide executive leadership the visibility they need into program progress?

    This workshop will introduce valuable, proven Scrum practices for large programs. Among the topics that will be discussed are:

    • What program management challenges are ripe for improvement through Agile practices?

    • The Program Impediment Board: Visible impediments, dependencies and milestones at a program level

    • The Program Stand-up: Lightweight activities to promote visibility, clear impediments and collaboration across the program

    • What does it look like when it’s working?: Improve delivery time, increase quality, and establish collaboration across the organization.

  • Liked Venkateswaran NS
    keyboard_arrow_down

    Experience Report: Agile Transformation & Implementation at Cisco Video Business

    Venkateswaran NS
    Venkateswaran NS
    Anil Thattil
    Anil Thattil
    schedule 2 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    The objective of sharing this experience report is to showcase how disruptive changes in the market place have driven the execution strategy for transforming a traditional waterfall organization to Agile. 

    It also contains a narration of our transformation journey so far and challenges we faced to understand the Key word "Value" across the business value chain.

    However for embedded systems & solutions many believe that Agile is not going to work, "our product is so complicated and distributed" (Is this supposed to be a quote?), their nature of business is so unique etc.. and if you ask about scaling then "Forget it".

    Hence my session is going to share the practical challenges we encounter and interesting stories of the transformation journey.

  • Liked KK Sure
    keyboard_arrow_down

    First Amongst Equals - Can UX be there?

    KK Sure
    KK Sure
    Sheril Jebasingh
    Sheril Jebasingh
    schedule 2 years ago
    Sold Out!
    20 mins
    Case Study
    Intermediate

    Traditionally, in software development, user experience (UX) wasn't valued as much as developing of the software itself. But this has changed rather radically. However, creating an enriching user experience in an agile fashion is still challenging. Most of the agile engineering practices in use are around building software but seldom address UX. When building a product in an agile fashion, UX in an incremental fashion becomes important.

    In this talk, we will present our experience of creating UX in an incremental fashion for a virtual wallet. We will also talk about the different challenges we faced such as, educating various stakeholders on the value of incremental UX, building collaboration between developers and experience designers and abstracting design components, along with the solutions we devised to tackle these challenges.

  • Ankur Sambhar
    Ankur Sambhar
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    We all know the importance of validating a feature before committing to getting it built. Validating assumptions help in avoiding the most frustrating and common problem – building something that nobody wants. However, validation is easier said than done. Building the right feature before we think of building the feature right is the key.


    Being Agile, we always try to leverage the quick feedback loop and adapt based on the end-user feedback. That’s good but it should not be used to validate the assumptions and that too after implementing a feature based on that assumption. It’s very expensive smile

    A more powerful and productive technique is to leverage Specification-by-example in defining and discovering requirements collaboratively with end-user, even before start working on the feature.

    This talk will focus on highlighting key aspects of effectively adopting SBE technique based on my own experience leveraging it successfully over and over again. It not only helps in grooming the feature requirement to tell a clear , simple and compelling story but it also helps in removing what is not needed.

  • Liked Lance Kind
    keyboard_arrow_down

    Using Fiction to Motivate Change

    Lance Kind
    Lance Kind
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Since the late nineties, the Agile books in the non-fiction aisle have steadily increased in number. It's common to see a book or three about Agile on a colleague's desk. It's also common to see such a book look practically new, the book spin showing no sign of having been opened. Non-fiction books are great at providing bullet points of things to do and reasons why. But non-fiction books are poor at:

    • inspiring,
    • creating emotional attachement (so the reader finishes the book), 
    • creating a full sensory environment for the reader,
    • describing a holostic environment, or
    • 'intriguing' a reader who is un-interested in the topic. 

    (This bullet list above is a good example of how non-fiction can excite thoughts who already know the story behind the bullets, but doesn't inspire much if the reader hasn't any context or background.)

    Fiction is well positioned to do the above because its number one job is to give pleasure and entertainment.  It can't be successful if it can't do this. The oral tradition of fiction has been part of human culture for millions of years, since a Cro-Magnon passed on a story to another, and upon re-telling some details were forgotten and the storyteller had to make them up.  Fiction is in fact is the most successful format for culture change as this is the format of the world's religious works and is responsible for guiding or changing the behaviors of billions of people.  The CIA and the Pentagon use fiction to develop scenarios which are used to create simulations to test preparedness.

    What force could be stronger than fiction for giving an individual the courage to initiate an organizational change in the face of uncertain co-workers and often antagonistic corporate environment?  What tester, developer, PM, director could not use the courage of knowing a "David verses the Goliath," "Legend of the IpMan," or "V for Vendetta" to not only understand the bullet points, but to have the stedfast to sustain in the face of resistance because they believe in the change as if they've lived that life, due to reading stories which placed them in one or many virtual versions of that world.

  • Liked Diana Larsen
    keyboard_arrow_down

    Coaching for "Best Fit" Agile: Applying the Agile Fluency(™) Model

    Diana Larsen
    Diana Larsen
    schedule 2 years ago
    Sold Out!
    480 mins
    Workshop
    Intermediate

    Agile has a problem. When we started out with Agile, people used it because it made their lives and products better. Now people complain that Agile is about meetings, top-down mandates, and wasting time. We can do better. It’s time for a change.

    In response, Diana Larsen and James Shore developed The Agile Fluency™ Model and Martin Fowler published it, “Your Path Through Agile Fluency” (http://agilefluency.com). The model describes how teams grow in their understanding of Agile over time. It's a descriptive model, because it reflects what happens in the real world, and in it's an aspirational model, because you can use it to understand how to invest in improving your teams.

    We've found the model very useful for helping teams, managers, and executives understand what they can get from Agile and what they need to invest in order to get those results. The model's emphasis on concrete outcomes means executives are open—even eager—to devote the effort needed. Leaders appreciate being able to see the tradeoffs and make a strategic decision, and teams thrive when given meaningful goals and the time and resources needed to achieve them.    

    In this workshop, led by Diana Larsen, together we’ll dig deeper into the model, including:

    -       Agile Fluency Model Overview

    -       Bringing Agile Fluency into your organization

    -       Examples of Agile Fluency in real-world teams

    -       Examples of organizational investments

    -       Supplemental materials for metrics and assessments

    -       Agile principles and practices in the model

    -       New directions and support for the Agile Fluency Model

  • Dhananjay Pershad
    Dhananjay Pershad
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    In my previous role as the leader of the of a products group, leading one-of-its kind agile transformation initiative, we tried to fundamentally change how value is delivered to customers in legacy technologies. In this experience report, I would like to share my insights about the agile transformation journey by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. To complicate things further, implementing agile in a mainframe technology stack is extremely challenging because people working with legacy technology/code-base, have a mindset that it is not possible to introduce modern tools/technologies or a different way of developing software in this environment. Specifically I would like to touch upon the following areas to drive agility across the organization:

    1. The need for Agile transformation initiative
      1. Time to market - Long release cycles; Impact on release feature relevance;  - Need for reducing release cycle as well as the need to build what is relevant
      2. Rapid changes in Data Center requirements as well change in direction for technology stack – Heterogeneous platforms, On Premise to Cloud, Web and Mobility driving different usage patterns – driving the need for more and faster innovation
      3. Lack of customer involvement in product roadmap and release plans – Need for early feedback and validation
      4. R&D - Lack of understanding of customer environment; Siloed functional groups inhibiting collaboration;  - De-risk knowledge levels within the organization; Improve cross functional team behaviors; improve engineering practices and usage of productivity tools
    2. Challenges faced during the journey – Communication; Expectation Management; Changing culture and behaviors; HR – role of HR, systems, processes, performance management, job titles/description, Rewards and Recognition; Skills – Technology as well as softer skills; Engineering practices and tools;
    3. Organizational changes introduced to make the transformation successful
      1. Communication and expectation Management
      2. Culture and behaviors – soft skills workshops, move from an I to a WE, emphasize on team thru team goals and team success, team based rewards and recognition; changed job description of managers to get effective participation and right behaviors as well as how they can contribute to the team success; Enabled cross functional skills (T skills / Generalists)
      3. HR – Systems/processes, introduction of new job titles and changes to job description, Team based quarterly performance goals and reviews, multi-rater feedback;   Moved from Individual performance reviews to team based quarterly performance reviews
      4. Engineering excellence – enabling skills and tools for continuous integration, build and deployment to provide faster feedback as well as shorter release cycles; improve quality;   Moved from waterfall to a daily integration and build model;  
      5. Value Delivery – Requirements voted to understand high priority needs; reduce release cycle; customer involvement during roadmap and release planning, sprint review feedback;   Release cycle reduce from 18 months to quarterly incremental releases

    Due to the nature and complexity of the change, the impact and touch points involved in this transformation, it is very critical to have an active and deeper participation from the leadership team to effectively plan change management to make the transformation successful.   Since it was a multi-year transformation initiative as well as continuous improvement journey, we had taken a phased approach to implement the overall transformation plan so as to take benefit out of learning coming out from each of the phases.

     

Sorry, no proposals found under this section.