• Liked Johannes Brodwall
    keyboard_arrow_down

    Practice agile programming with coding dojo

    Johannes Brodwall
    Johannes Brodwall
    Buddhima w.wickramasinghe.
    Buddhima w.wickramasinghe.
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    A Coding Dojo is a fun and social way to become a better programmer. Johannes is an experienced coding coach who will guide you through a few hours of programming that will transform your understand your craft and yourself as a programmer. In the workshop you get to try out pair programming, test-driven development and continuous refactoring for yourself and you get lots of recommendations on how to improve your coding and testing. You will need to bring your own computer with a development environment of your choice. Recommended for Java, Ruby, JavaScript and C# developers.

    This is what previous participants say about the workshop:

    • What did you learn? New tools, pair programming and fun exercises; Ide tricks, programming language basics, testing tools, using tests as a reasoning tool; you can comfortably pair with strangers.
    • What surprised you? Small steps work better than planning; It's easy to get started when you pair program; Pair programming is nice
    • What do you plan to do next? Using TDD every day; Listen to partner more carefully - he may already have solved the problem.
  • Liked Sreerupa Sen
    keyboard_arrow_down

    Changing our Rhythm: Our Ongoing Journey towards Continuous Delivery

    Sreerupa Sen
    Sreerupa Sen
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Annual software release cycles cramping the agility of the team? Too many hot fixes reducing the efficiency of your organization? Customers waiting impatientlyfor  the next cool features hot off the press? These are some of the painful and common problems faced by development teams worldwide. In today's world, most things get outdated or out-of-fashion very fast - and software is no different. Users cannot afford to wait for the next cool set of features for a year. They want a steady stream of cool new features that they can adopt and use immediately.

    My team follows a development model that we like to call Open Commercial Development - where we're always connected to our stakeholders, our plans are out in the open, and we're always gathering feedback and reprioritizing. We used to have yearly releases of our product - a sort of big bang release with a host of new featres. Based on our stakeholder interactions, however, we figured that our software delivery wasn't agile enough for our customers. Users wanted new features incrementally throughout the year. They especially didn't want to wait a year for a feature that they'd requested that was critical for their business.

    So began our journey to Continuous Delivery - an interesting one for sure. It's not easy to deliver new features, manage technical debt, collaborate with users and incorporate their feedback into the new features - once every quarter. To do it consistently, with quality and on time, you need to have a framework in place - a combination of planning, process, automation and team organization - that lets teams focus on the right things to get to DONE DONE for their new features, and at the same time manage their quality and tecnical debt. Over the past year, we like to think that we've put that framework in place, and that is what I'd like to talk about in this session.

  • Liked Tathagat Varma
    keyboard_arrow_down

    Designing agile feedbacks for agile learning - an experience report

    Tathagat Varma
    Tathagat Varma
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Feedback is perhaps the most important aspect of the overall agile lifecycle. If the feedback is too wide and shallow, it won't give enough actionable feedback. If it is too narrow and deep, it might fail to register feedback outside its focus area. So, how does one go about designing feedbacks that enable agile learning. We call them agile feedbacks.

    In this brief session, we will share an experience from designing agile feedbacks for agile trainings and workshops. The objective was to get most critical feedback in shortest amount of time to enable quick action planning. We created feedback that took a maximum of 5 minutes and enabled the most important learning in both, focussed as well as open-ended manner that allowed us to focus on the most critical items. We employed elements of Design Thinking and Rapid Iterative Testing and Evaluation (RITE) to improve the process and quality of feedback themselves. We will also be touching up these concepts and how effective they were.

  • Liked Vinod Purushothaman
    keyboard_arrow_down

    Hurdles: The sprint with impediments on the way to Automation

    Vinod Purushothaman
    Vinod Purushothaman
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Since the inception of Agile, practices has improvised and changed drastically. Continuous Integration and Continuous Delivery are few among them. I have practiced these methods and it really helped the team to deliver quality working software.

    Most of the team are working hard and trying to deliver on time. Automation leverages the team to make this happen through Continuous Integration and Continuous Delivery. We all know changes are really hard, and we have to surpass several challenges to succeed.

    We all are familiar with Sprints, here I am going to share the Hurdles I pass through to implement build and deployment automation. 

  • Liked Sreerupa Sen
    keyboard_arrow_down

    Changing our Rhythm: Our Ongoing Journey towards Continuous Delivery

    Sreerupa Sen
    Sreerupa Sen
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Annual software release cycles cramping the agility of the team? Too many hot fixes reducing the efficiency of your organization? Customers waiting impatientlyfor  the next cool features hot off the press? These are some of the painful and common problems faced by development teams worldwide. In today's world, most things get outdated or out-of-fashion very fast - and software is no different. Users cannot afford to wait for the next cool set of features for a year. They want a steady stream of cool new features that they can adopt and use immediately.

    My team follows a development model that we like to call Open Commercial Development - where we're always connected to our stakeholders, our plans are out in the open, and we're always gathering feedback and reprioritizing. We used to have yearly releases of our product - a sort of big bang release with a host of new featres. Based on our stakeholder interactions, however, we figured that our software delivery wasn't agile enough for our customers. Users wanted new features incrementally throughout the year. They especially didn't want to wait a year for a feature that they'd requested that was critical for their business.

    So began our journey to Continuous Delivery - an interesting one for sure. It's not easy to deliver new features, manage technical debt, collaborate with users and incorporate their feedback into the new features - once every quarter. To do it consistently, with quality and on time, you need to have a framework in place - a combination of planning, process, automation and team organization - that lets teams focus on the right things to get to DONE DONE for their new features, and at the same time manage their quality and tecnical debt. Over the past year, we like to think that we've put that framework in place, and that is what I'd like to talk about in this session.

  • Liked Bhuwan Lodha
    keyboard_arrow_down

    Building a Team Backlog: The Power of Retrospectives

    Bhuwan Lodha
    Bhuwan Lodha
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    “Inspect and adapt” is one of the basic tenets of continuous improvement, and agility in general. Holding retrospectives is one of the core processes that allows teams to look back and reflect on their progress. However, over time, teams may focus only on the product work and lose interest in their own improvement as a team. Kanchan Khera and Bhuwan Lodha believe that one approach to solving this problem is to bring the rigor, structure, and discipline we use for maintaining healthy product backlogs to team improvement by creating a “team backlog”—items the team needs to do to improve itself. The team backlog introduces three keys to successful and sustainable team improvement—a structured framework, visibility of its impact, and creative ways for building the backlog. Just as a healthy backlog is the basis for a great product, so a healthy team backlog helps create great teams.

  • Liked Prashant Kutade
    keyboard_arrow_down

    How should be a Sprint Retrospective ?

    Prashant Kutade
    Prashant Kutade
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Beginner

    Sprint Retrospective

    Sprint Retrospective is a meeting that happens at the end of each Sprint that usually occurs after the Sprint Review. This practice involves the Scrum Master and the team members to discuss what went right and what went wrong in the practices adopted during the Sprint. Thus, it allows modify some practices to maximize the positive and avoid negative points. This meeting provides a moment for greater interaction among the members and allows the team to self evaluate and propose the necessary changes, thereby strengthening the sense of teamwork.

    Like the other meetings in Agile, the Sprint Retrospective requires many adjustments. In the experience reported in one of the Sprint Retrospective in John Deere TCI(Pune, 2013), someproblems that were faced related with the presence of all members at the meeting and related with the tool support. The first trouble was to find a time when everyone could attend, since this meeting was initially scheduled one day after the Sprint Review. The solution was to hold the meeting after the Sprint Review and limit the maximum duration for two hours, so this is not tiring. The second difficulty is the need for multiple tools for holding the meeting, the techniques to be followed to drive the meeting and raise the positive and negative suggestions, as well as project management tool like Rally for presenting data from the project’s progress, such as the Product Burndown.

    Despite the importance of the presence of all team members in the Scrum meetings, in some situations, for example, a project with many distributed teams, a remote meeting with all members becomes impractical which should be avoided. Thus, for those situations, this proposed approach suggested to do a Sprint Retrospective by team, and saving the information collected at each meeting. This information collected should be shared to all members, allowing them to analyze the improvements suggested by other teams.

    One last modification is to hold a meeting among each Scrum Master, similar with Scrum of Scrums, to discuss the Sprint Retrospective done by each team, and with that, it is possible to align the dependency among them. This meeting may occur the day after the Sprint Retrospective of the teams, and it is crucial that each Scrum Master considers the points raised by other teams before the meeting between them, in order to optimize its duration.

  • Liked Karthik Kamal Balasubramaniam
    keyboard_arrow_down

    7 Deadly Sins of 'Agile- But' Teams

    Karthik Kamal Balasubramaniam
    Karthik Kamal Balasubramaniam
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    This report is based on the analysis of the epidemic called ‘Agile-But-Teams’ in services organization. The presentation would cover the following 7 anti-patterns in such teams,

     #1 Fix ‘everything’ in your contract (definitely no breathing space) 

    Sign contracts with fixed scope and penalties. Ensure you include at least 30 metrics with fixed targets without accounting for team’s capability.

      #2 Don’t groom your requirements, make them look beardy and scruffy 

     Ensure your product backlog grooming is either not taken seriously or not done until the first day of the sprint.

     #3 Be a salary thief and never change a thing 

    Freeze your process steps in the beginning of the project and create checklists that would ensure compliance on a monthly basis. If possible, include mechanisms for tailoring and deviation, but never change the process.

     #4 Be loyal to the law of averages 

    Set organizational baselines for Agile teams and measure them periodically. Also, get RCA’s and reasons for missing the organisation targets.

     #5 Trust the pyramid and mummies 

    Adhere to the team pyramid structure and give the product responsibility to the identified leads.

     #6 Never Tell, Only Ask 

    Never change your product development/testing practices empirically instead implement industry ‘best’ practices based on case studies from other projects.

     #7 Make Self-fulfilling prophecies 

    Constantly discuss about, how Agile is not the right model for your project. Ensure your prophecies are fulfilled and there is no redemption whatsoever

     The presentation would also cover the possible antidotes for the scenarios and explain in detail about the behavioral sciences behind such patterns.

  • Liked Karthik Kamal Balasubramaniam
    keyboard_arrow_down

    Anatomy of a Self Organizing Team

    Karthik Kamal Balasubramaniam
    Karthik Kamal Balasubramaniam
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    What does it mean by a ‘Self-Organizing team’?  Or it’s just an euphemism for something else? Or even worse-it’s just a fancy term?

    This particular entry is a result of my relentless pursuit in search of a ‘Self Organizing’ team. I have always doubted the existence of such mythical teams, however my perseverance made me search for them whatsoever. In this short presentation, I would like to present the experience of my journey and observations on the anatomy of such teams. However reluctant I was, I decided to add some data points to my personal journey to make it more sellable. Fortunately, few of the observations are not very different from the accepted reference points. Hence I would also refer to the group behaviors explained by various psychologists like Sigmund Freud, Eric Berne etc in this short talk.

  • Liked Johannes Brodwall
    keyboard_arrow_down

    Practice agile programming with coding dojo

    Johannes Brodwall
    Johannes Brodwall
    Buddhima w.wickramasinghe.
    Buddhima w.wickramasinghe.
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    A Coding Dojo is a fun and social way to become a better programmer. Johannes is an experienced coding coach who will guide you through a few hours of programming that will transform your understand your craft and yourself as a programmer. In the workshop you get to try out pair programming, test-driven development and continuous refactoring for yourself and you get lots of recommendations on how to improve your coding and testing. You will need to bring your own computer with a development environment of your choice. Recommended for Java, Ruby, JavaScript and C# developers.

    This is what previous participants say about the workshop:

    • What did you learn? New tools, pair programming and fun exercises; Ide tricks, programming language basics, testing tools, using tests as a reasoning tool; you can comfortably pair with strangers.
    • What surprised you? Small steps work better than planning; It's easy to get started when you pair program; Pair programming is nice
    • What do you plan to do next? Using TDD every day; Listen to partner more carefully - he may already have solved the problem.
  • Liked Tathagat Varma
    keyboard_arrow_down

    Designing agile feedbacks for agile learning - an experience report

    Tathagat Varma
    Tathagat Varma
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Feedback is perhaps the most important aspect of the overall agile lifecycle. If the feedback is too wide and shallow, it won't give enough actionable feedback. If it is too narrow and deep, it might fail to register feedback outside its focus area. So, how does one go about designing feedbacks that enable agile learning. We call them agile feedbacks.

    In this brief session, we will share an experience from designing agile feedbacks for agile trainings and workshops. The objective was to get most critical feedback in shortest amount of time to enable quick action planning. We created feedback that took a maximum of 5 minutes and enabled the most important learning in both, focussed as well as open-ended manner that allowed us to focus on the most critical items. We employed elements of Design Thinking and Rapid Iterative Testing and Evaluation (RITE) to improve the process and quality of feedback themselves. We will also be touching up these concepts and how effective they were.

  • Liked Sreekanth Tadipatri
    keyboard_arrow_down

    Help teams succeed, so that your business succeeds

    Sreekanth Tadipatri
    Sreekanth Tadipatri
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    This presentation discussess some of the factors that are critical to the success of the teams.  Successful teams is a prerequisite to a successful enterprise.

    What would help the team succeed?

    What would hinder the teams?

    What are some things that might work for the team, but might not work for an enterprise?

     

    The above is an example of what will be discussed during the session.

  • Liked Yashasree Barve
    keyboard_arrow_down

    Why can’t Enterprise have all the Fun? –Tales from Enterprisy DevOps Land

    Yashasree Barve
    Yashasree Barve
    schedule 3 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    In the age of continuous deployments, where Googles and Facebooks of the world push newer features every now and then, without any down time to millions of users! Enterprises and Users of internal IT systems within Enterprise are still stuck with old time consuming processes that take ages to churn out new features to business. Why can’t Enterprises have this fun!


    This is a story of an Enterprise that adopted and got mature in its Agile Adoption. The sponsors could see value every sprint, but it took time to translate this value to end users. Drive to sustain agility as well as getting things out to end users quickly needed to take a great momentum.


    Experimenting with DevOps came as a natural extension to this Agile-Scrum adoption. We would like to talk about the how the idea of DevOps implementation in this Enterprise originated, the various challenges met at the initial stages, carving the road map and our journey. We would highlight the benefits that we reap out of this effort as well as share best practices from what we have learnt.

  • Parimala Hariprasad
    Parimala Hariprasad
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    Business stakeholders are always looking for ways to generate more business, and hence earn great revenues (or find the perfect exit strategy). Paying for testing comes last on the expense tracker. Some businesses work without testing teams because they see testing as mostly a drain on time and money. The typical executive perceives testing as a key bottleneck to product releases.

    In this session, Parimala Hariprasad shows how understanding the business model and business goals helps you test products better. She explains how to educate stakeholders about business risks. She explores ways testers can catch business blockers through early testing, and alert managers so they can be addressed quickly. This type of business information helps managers make better-informed decisions about the product early on. Some managers raise their eyebrows when first asked about their revenue models. Happily, once they see the value of business testing and how it could improve their revenue, they engage enthusiastically.

  • Liked Vinod Purushothaman
    keyboard_arrow_down

    Hurdles: The sprint with impediments on the way to Automation

    Vinod Purushothaman
    Vinod Purushothaman
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Since the inception of Agile, practices has improvised and changed drastically. Continuous Integration and Continuous Delivery are few among them. I have practiced these methods and it really helped the team to deliver quality working software.

    Most of the team are working hard and trying to deliver on time. Automation leverages the team to make this happen through Continuous Integration and Continuous Delivery. We all know changes are really hard, and we have to surpass several challenges to succeed.

    We all are familiar with Sprints, here I am going to share the Hurdles I pass through to implement build and deployment automation. 

  • Liked Janardhanam Venkat
    keyboard_arrow_down

    DevOps - In an Enterprise from Cradle to Grave

    Janardhanam Venkat
    Janardhanam Venkat
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Beginner

    Commercial software development teams that practice Agile are confronted with daunting challenges in optimizing operations. In particular, the primary challenges faced are in shorter development sprint and bottle neck at QA gates for operations. The session will provide insight of DevOps building block and its business benefit. The session demonstrates signs that you need DevOps. This session is focused on how CollabNet’s engineering and operations team is overcoming these challenges and thus delivering faster and with a much better fit to enterprise customer requirements. The session touches upon the ops involvement from the beginning of the release till go live of the product development and briefly cover few real world examples.

    CollabNet is a leading innovator in software development tools and in agile practices. Its Chennai development facility collaborates with teams in the USA, South America and Europe on large, production-grade software development projects. Venkat will provide a real-life case study of how CollabNet leverages a unified collaborative infrastructure to drive practices like continuous integration and DevOps to meet customer requirements.

  • Liked Suresh C R
    keyboard_arrow_down

    Using Kanban for synchronization & governance in multi-team Agile programs

    Suresh C R
    Suresh C R
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    One of the fundamental reasons why management teams are eager to adopt Agile in large programs these days, is the discomfort that is caused by long gestation periods before anything tangible is delivered to the Business, and the risks associated with it. They hope that the practice of the principle of “Frequent Delivery of valuable working software” that Agile espouses will help them address these risks. However, in the Agile Transformation of such programs, a key challenge that emerges is in synchronising the output of the various teams in the program in order to deliver working software every sprint. This problem gets especially compounded with geographically dispersed teams.

    The following experience report shares the experience in guiding an agile transformation engagement for a program involving geographically dispersed teams of a global BFSI player. The work products went through three stages – creation of the technical workflows required for the desired services by the product owner & SMEs, completion of proofs of concept / technical feasibility of core components of the services, and lastly the actual development work including user interfaces. The development teams were spread across two locations and SME’s were in two different locations. Due to pressures from business, the first priority for the program was to start delivering value by means of usable functionality available to the end users.

     

    Kanban as well as Scrum was used in the transformed process to ensure that smooth and regular flow of functionality was delivered at the end of every sprint. The aspects of Kanban used were Pull based scheduling across the various stages, Making the work Visual and Limiting the number of services which were WIP. How these elements of Kanban drove the Synchronization efforts as well as overall governance betweeen teams, while the teams used Scrum for managing engineering activities within the team, will be detailed in the presentation. How this approach can be extended for better management of MMF’s/ Epics will also be explained.

  • Prajakta Thakur
    Prajakta Thakur
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Beginner

     

    Scrum Team’s success depends totally on how the Product Owner, the Scrum Master and the Scrum Team perform their responsibilities well.

    Product Owner’s is a multi-faceted role. A PO undertakes a range of responsibilities like maintaining product backlog; prioritizing items as per business value or return on investment; conveying vision and goals to the team, engaging customer, participating in scrum ceremonies, monitoring product progress, liaising with team for effective delivery and so on.

    Scrum Master has the onus to protect the team from outside interference, help the team resolve impediments , guide the team and PO to effectively adopt Scrum Processes, monitor the project without command and control

    Whereas a cross functional Scrum Team of Developers, Designers, Architects, Testers,etc. have to undertake functions like Analysis, Estimation, Design, Development, Testing, Deployment in an effective manner. They have to self-manage and self-organize to achieve committed deliverables and hold accountability for the success of each iteration

    Type of product, product lifecycle stage, project size, domain knowledge of the team are various factors which further govern what all responsibilities a Scrum Team needs to shoulder. With such huge gamut of responsibilities to be managed, it is bound that a Scrum Team commits mistakes.

    This session attempts to showcase some of the common mistakes, which Scrum Teams commit and ways to avoid these mistakes. Awareness of these common mistakes or lessons learnt will help teams to prevent such scenarios and ensure effective delivery.

  • Niraj Bhandari
    Niraj Bhandari
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    This talk is my self-reflection as a Product Owner (PO) over the last year and a half. Coming from a technical background where techies “don’t talk much” and “work with their headphones on”, I too was more of a good listener into discussions and spoke only on select occasions. We are always taught to listen first and ask only if you are not clear. Especially in Indian context, asking questions are not encouraged much, and even in colleges profs are happy if you don’t engage them in discussions. And on top of it, if you belong to the tribe of introverts like me then you have had it. A combination of these factors ensured that, I too spoke little and only when needed and banked heavily on my work to do the talking.

    If it seems like a familiar script, either of yourself or of somebody you know then I recommend that you attend the session.

    This talk is centered on my learning and the move from a silent PO to an assertive PO, the challenges and the opportunities. The role of a PO is very delicate one and the person needs to have a very balanced approach. He/She can’t be a silent observer, and at the same time he/she can’t be an aggressive participant. “Silence is Golden” doesn’t applies to POs and the tribe needs to maintain the balanced communication channels while engaging all the stakeholders for the success of the project and that is what we will be focusing on in this session.

  • Liked Swarnalatha Ashok
    keyboard_arrow_down

    Performing Advanced Research in IT Topics using Agile methodologies

    Swarnalatha Ashok
    Swarnalatha Ashok
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    This paper summarizes the experience & outcomes derived out of running  an Advanced Research elective using agile methodologies for MTech (Software Engineering) students of ISS – NUS. Using Agile way of development for exploratory research work is a unique idea using which we successfully deliver several student research projects every year. The paper would document the results of applying various agile management approaches ( like SCRUM) and engineering techniques ( TDD, Continuous Integration, Refactoring) to exploratory research work and argue on the benefits of using agile approach as against traditional software development approach for academic student exploratory research work. Evidences to show how agile techniques successfully help in doing exploratory projects would be produced. Further, the interesting aspect of how Agile techniques could be used in academic teaching work to stimulate student interest in the subject would be explored.

    Takeaways for participants attending this session:

    • Understand how agile methodologies can be used to perform exploratory research work
    • Provide a framework for conducting applied research work using agile methodology
    • Critique the suitability of Agile techniques for student research work
    • Explore opportunities for expanding the scope of agile methodologies to performing research work in industry.
  • Liked Sanjeev Prasad
    keyboard_arrow_down

    Scrum Adoption in Outsourced Multivendor Scenario

    Sanjeev Prasad
    Sanjeev Prasad
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

     

    In the last couple of years Agile methodologies have gone from strength to strength and gained tremendous popularity as well as following within the software industry. From amongst all the Agile methods Scrum is by far the most popular and has become the de facto industry standard today. However, during the course of this journey Scrum had to contend with another stalwart of the software industry, namely “Outsourcing”. And to survive and prosper Scrum has had to evolve and adapt to the biggest challenge that Outsourcing posed – “Multi-Vendor, multi-location teams”. However an outsourced multivendor distributed landscape is still viewed widely as a potent recipe for Scrum failure; and acts as the primary deterrent to Scrum adoption across many organizations.

    This paper shares the experience based on the practical challenges faced by IT Services Organizations on the adoption of Scrum in multivendor distributed scenarios as well as the benefits perceived and realized; by presenting various scenarios faced by them in their daily business cycle.

  • Liked Musarrath Jabeen
    keyboard_arrow_down

    Advanced Engineering Practices to achieve higher Agility Quotient

    Musarrath Jabeen
    Musarrath Jabeen
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

     

    We intend to share our experience through this report on the typical challenges experienced in adopting Agile in a complex telecom product with existing huge code base and our recommendation to overcome the challenge. We also will bring out the advantage and cost of quality reduction achieved through disciplined XP engineering practices and thereby improving the customer satisfaction to a great extent and thereby improving our Net Promoter Score.

    Through this experience report we plan to share how the Agile practices helped in achieving the higher business value and quality product with the given engineering rigor. In a typical complex telecom domain product development, the success criteria in terms of team capability in the domain, quality of product and end use satisfaction can be achieved through applying the strategy upfront with disciplined engineering practices through scrum approach.

    Also we plan to uncover the pitfalls which would result into diluting of scrum model after initial few sprints resulting into issues of sustaining the best practices.

  • Raj Anantharaman
    Raj Anantharaman
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Beginner

    Steve Jobs once called Intel the "heavy steam iron" ship - to mean that Intel tends to be slower, less flexible and more difficult to change direction. In the past 2 to 3 years, Intel has worked hard in transforming its Traditional Waterfall methods and processes to be more nimble, more Agile, and has seen positive business results - in many cases improvement in quality and work-life effectiveness, in fewer cases TTM. In my session - I'd like to share Intel India's experience in this transformation - the before and after. 

  • Jayesh Kadam
    Jayesh Kadam
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

     

    Across all industries, organizations are looking for ways to achieve highest business value through faster time-to-market for their products with short development cycles.   In an era of highly competitive environment, it has become critical for business to monitor emerging trends and closely collaborate with IT through continuous feedback mechanisms. Gone are the days of Quality Assurance (QA) teams getting involved towards later stages of a project with primary focus being finding defects.

    This has resulted in a paradigm shift in testing function’s objectives with the group being an equal stakeholder in achieving one-common goal of delivering value to end-customers by achieving early-to-market release of products with best quality.

    Through this paper, we intend to share typical challenges faced by testers as they embark on Agile journey, and the change in mindset required to overcome those challenges, especially from IT service organization perspective.