• Liked Vivek Ganesan
    keyboard_arrow_down

    Developer 2.0 - Redefine the Role of Developer to achieve Success for All

    Vivek Ganesan
    Vivek Ganesan
    schedule 1 year ago
    Sold Out!
    60 mins
    Talk
    Intermediate

    Gone are the days where developer was responsible for just writing clean code. Traditional definition of developer affects the individual developers more than it affects the organization. The developer tends to concentrate on getting better at just the area of coding and ends up not learning the nuances of building a successful product. As a Developer 2.0, the developer performs all of the following roles. 

    1. Coder 

    2. Devil's advocate 

    3. Code Reviewer 

    A developer can work in multiple stories but cannot do more than one of the above tasks for the same story. For example, the same person cannot be both the coder and Devil's advocate. A team at Gainsight worked with this improved definition of developers and saw higher product velocity, better awareness about product and increased responsiveness to issues. This session will take the audience through the improved definition of the role of developer and present some thought-provoking questions to the audience to make them realize that the traditional definition of role of developer is just not enough.

  • Liked Vijay Bandaru
    keyboard_arrow_down

    Scrum Master - The Team Spirit Guardian

    Vijay Bandaru
    Vijay Bandaru
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Lord Krishna was our first Scrum Master who helped "Pandavas" to win the "Kurukshetra" war without using a single weapon. On top of it, he was the almighty with so many invisible powers, but he still guided the "Pandavas" through his servant Leadership.

    Inspired by this concept, I have created a session to highlight the role of a "Scrum Master" and how can we make a Scrum Master a true "Servant Leader" without so much depending on authority or tools rather concentrating on simple things that can make his contribution to the team a true differentiating factor.

    In this task, I am going to cover the following topics:

    - Understanding the team formation stages

    - 5 dysfunctions of teams

    - Gauge the team members' behaviours

    - How a Scrum Master can make his team GREAT

    - Soft skills for Scrum Master

    - How a Scrum Master help his team in various situations

    - Importance of learning for a Scrum Master

    - Scrum Master's backlog for his team's improvements

    - Scrum Masters checklist

    I will also cover anti-patterns of Scrum Master in this session along with suitable remedies.

  • Liked Krishnamurty VG Pammi
    keyboard_arrow_down

    Do you get equivalent value for the price you pay? What is missing?

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    schedule 1 year ago
    Sold Out!
    60 mins
    Talk
    Beginner

    Price is what you pay. Value is what you get. According to the Standish Group research, 20 percent of customer application development features are often used, 30 percent are infrequently used, and 50 percent are hardly ever used. This means that a major percent of the performing organization's effort does not correlate to value generation.

    Of the projects that met triple constraints, Standish Group research showed that only 13 percent yielded very high value, and 27 percent of the projects yielded high value. This means that about 60 percent of the projects yielded average to low value. And this means that, in the words of the study, "Sometimes you pay the price for a project but do not get the value."

    What is missing? - I reflected on this experience and also reached out to teams to learn what can bridge this gap. Interestingly, I got collective feedback that stated, "Either we fail to understand end-user experience, or we do not give much weight to it."

    User experience highlights the experiential, meaningful and valuable aspects of human-product interaction. Take the iPhone, which was launched in 2007. The phone’s unmatched user experience made its competitors out of the game; it set a new standard for smartphones. One of the secrets behind its success is the narrow set of customer needs Apple selected. Building customer satisfied products in the domain “internet of things” are becoming difficult and interesting now-a-days compared to other domains because gauging user experience in internet of things is quite dynamic and thus becoming quite challenging.

    When developing a product with agile, planning takes place at multiple levels. Agile projects involve planning upfront and throughout the entire project. This way, agile teams perform adaptive planning at last responsible moments by incorporating the then risks, issues, assumptions and constraints into consideration.  This will enable teams to change their course of action even in scenarios where requirements take abnormal shift or when teams come across unforeseen challenges. Agile planning thus remains more relevant and useful as it can guide teams till destination. Products that are complex, creative and high-risk in nature certainly prefers agile planning approach because traditional approach of “upfront plan the entire work and work the initially set plan for rest of the journey” cannot guide them till  destination.

    Experiential insights: I will unfold my experiential insights on how agile planning events (Vision, Product, Release, Sprint and Daily planning events) propel each other and nurture user experience periodically. I will explain how these adaptive planning outcomes connect each other and align themselves to the goal of delivering customer satisfied products.

    User experience is no longer a choice -- it is a means of survival: You have got to start with customer experience and work back toward the technology, not the other way around. The user experience approach is no longer about usability, it is about value creation. It is no longer the role of one person or department, it is about culture. It is no longer a choice, it is a means of survival. In the words of MarketingTech, "74% of businesses believe that user experience is key for improving sales, conversation, and loyalty." Thus we cannot afford to underestimate the impact of our users' experience.

    User experience does not start at purchase, it begins when the user has a need:  Agile planning events nurture user experience by discovering user needs. Aligning the product road map with user needs will certainly correlate product price to value creation. In fact, going with this approach, we can create situations in which end users perceive more value in our products than the price they pay for them. Google analyzes users' response patterns to their online posts and predicts user behavior even before users understand their responses themselves. It is an interesting journey toward understanding user experience, especially on products that leverage the Internet of Things. It is not an easy job to predict user experience. However, if we champion this aspect, we will indeed correlate product price to value creation.

     

  • Liked DEBASHIS BANERJEE
    keyboard_arrow_down

    Agilists - Detect, Protect and Celebrate IP Created During Sprints

    DEBASHIS BANERJEE
    DEBASHIS BANERJEE
    schedule 1 year ago
    Sold Out!
    30 mins
    Experience Report
    Intermediate

    In the context of continuous and periodic delivery of same day, monthly and agile incremental delivery in both established and startup contexts there is a possibility of teams missing key elements of protecting their IP. Some simple elements such as making your work public prior to protecting it can cause loss of business. Additionally in short sprints filing IP may not be the most important focus within teams (especially in startups or smaller companies where budgets might also be a constraint). In this session it will demonstrate (a) Some key elements of how to keep IP in mind in Agile sprints (b) Some general best practices of how IP can be used as a bond/glue for teaming (c) Some process changes possible to ensure IP becomes a key element of agile delivery. These is based on experience of over 6 years submitting IP self and also having 6 people having approved IP, 20+ people encouraged to submit and 75+ submissions. (d) As a influencer will provide some best practices to Leaders and Product owners to encourage IP. (e) Additionally IP can be a great occassion for team building and bonding and a retention tool.  Note: The session will be generic and will not cover any specific IP process of any company but a general set of practices via experiences

  • Liked Gayathri Naik
    keyboard_arrow_down

    A Fully Packaged Geek is All You Need to be Truly Agile!

    Gayathri Naik
    Gayathri Naik
    schedule 1 year ago
    Sold Out!
    30 mins
    Talk
    Intermediate

    Good developers who are familiar with the entire stack know how to make life easier for those around them!

     

    Full Stack Development doesn't mean that one has to be super fluent in everything that's there in the software industry. It is about having every person in the team, cross functional and much more than just a pure developer.  A team with few full stack developers will become well balanced and will always perform its best no matter what the situations are! 

    In this session. let's focus on understanding why it is important to become full stack developers for every individuals and how it really helps them, their teams and in turn the entire organization as a whole for getting better.  We will have all this presented with our real world experiences and have an open discussion there after!

     

  • Liked Avinash Rao
    keyboard_arrow_down

    From Nominal to Effective Agile: A 3 step process

    Avinash Rao
    Avinash Rao
    schedule 1 year ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    Did you hear about the VP who wanted Agility but got Scrum instead?

    Developing Agility is a transformational process, which requires a gradual and deep change on multiple fronts. However, the IT industry has (for good sales and contracting reasons) presented to clients an Agile ability that is ‘on tap’ – this fundamentally means that the Agile delivered must depend on a shallow rather than a deep change.

    This session will talk about the role of crucibles and shared experiences as the key enabler to any transformation, and show how they apply in Agile transformations.  We use the example of a major US communications client to illustrate. The client adopted a quick-and-dirty approach to kick starting Agile, but progress stalled 6 months later with no lasting improvements. We present the point of view of the Agile Coach and change agent, and the 3 step process used:

    1. Surfacing current beliefs
    2. Finalizing Team Agreements
    3. Realigning words and actions

    The multi-month effort presented will show the changes from a culture of Nominal Agile to an Effective Agile culture. 

  • Liked Saikat Das
    keyboard_arrow_down

    Switch from Sprint Retrospective to Toyota Kata

    Saikat Das
    Saikat Das
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    You have been doing agile for a few years now.

    With a regular cadence you have retrospectives and a lot of problems and great improvement opportunities are raised but nothing seems to really improve. Stop doing retrospectives!


    Can we shift form collecting problems and start improving? Create the habits of continuous improvement.

    It can be done is time to start using Toyota Kata!


    Toyota Kata is two behavior patterns, or Kata’s, that is the foundation in Toyota’s continuous improvement work.



  • Ramesh Lakkaraju
    Ramesh Lakkaraju
    schedule 1 year ago
    Sold Out!
    60 mins
    Talk
    Intermediate

    Active Product Management is about focussing more on the active backlog items, i.e items planned for the shorter increment (Potentially Shippable Increments), rather than focussing on the complete backlog set planned for the whole release.

    Many Organizations over the past few years have embraced agile and have experienced good results. Even after this transition to agile and following for several years, Organizations still face difficulty to release the software to the customers as per the commitments.

    Would like to discuss the general problems with the traditional way of doing release planning and how "Active Product Management" can reduce the risks in delivering the commitments.

  • Liked Madhavi Ledalla
    keyboard_arrow_down

    The essence of Product Ownership

    Madhavi Ledalla
    Madhavi Ledalla
    schedule 1 year ago
    Sold Out!
    60 mins
    Talk
    Intermediate

    Scrum introduces a very vital role called the Product Owner who is the key person responsible for the product success; he is one who is accountable for the customer delight.

     In this session we would be doing a deep dive at this role, the essential characteristics, the prime responsibilities, challenges and how can this role be scaled in a scaled environment where we would be discussing some of the structural and coordination patterns.

    The key take away of this session would be the last part where the participants would build a story map using “Jeff Patton’s” story mapping technique to visualize how a day of the Product Owner looks like.

  • Arshiya sultana
    Arshiya sultana
    schedule 1 year ago
    Sold Out!
    45 mins
    Demonstration
    Beginner

    The session will start with introducing agile estimation (5 mins), and differentiate it from traditional estimation approach and the same will be demonstrated by an activity (15 mins)

     

    Conflict management is a continuation to the agile estimation technique, sometimes due to conflict also we cannot arrive at a useful estimation. How agile coaches handles conflict management (5 mins), we will do an activity to understand conflict management and its resolution (15 mins)

    conclusion and questions (5 mins)

  • Liked Om Prakash Bang
    keyboard_arrow_down

    Agile view of Business Analysis

    Om Prakash Bang
    Om Prakash Bang
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Business Analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. How do we do this in agile?

    This sessions talks about agile view of business analysis in the context of project, program, portfolio, enterprise, and answers to questions such as  Role of a business analyst in agile? Is User Story enough? or do we need any other documentations? 

  • Liked Mohit Jain
    keyboard_arrow_down

    Understanding Story Points as an estimation techniques for Scrum teams.

    Mohit Jain
    Mohit Jain
    schedule 1 year ago
    Sold Out!
    30 mins
    Talk
    Beginner

    A deep-dive session about story point, and why its gaining acceptance over traditional estimation methods.

  • Liked Sekhar Burra
    keyboard_arrow_down

    Raising the Bar: Being a true influential agile leader

    Sekhar Burra
    Sekhar Burra
    schedule 1 year ago
    Sold Out!
    90 mins
    Workshop
    Advanced

    This is a nurturing workshop for Agile Managers to become effective influential servant leaders, to support enterprise agility.

    This is a workshop for Agile Managers and above to help them shed the command and control behavior and be more of a facilitator and coach for their teams. At the end of this workshop, the participants will understand and appreciate the insights and techniques of being an Agile influential leader. The participants also walk out with a concrete action plan on how they support the agile teams and organization. The whole workshop runs on the technique of asking powerful questions to the participants, thus making them think towards the path of self-discovery.

     

  • Liked Sanjay Kumar
    keyboard_arrow_down

    Refactoring Strategy for Big Design Smells

    Sanjay Kumar
    Sanjay Kumar
    schedule 1 year ago
    Sold Out!
    60 mins
    Case Study
    Intermediate

    Agile design or emergent design relies heavily on timely refactoring efforts that aim to improve existing design. Yet often, when the code base grows or when someone else's code is handed over to us, there is a reluctance to refactor existing code - despite an obvious design smell. While the reasons to avoid refactoring may be well-grounded – lack of time, lack of understanding or fear of breaking it – in the long term, delaying code refactoring makes the code rot further. And, as a result, technical debt continues to pile up.

    This session begins by reviewing common design smells, discusses five key features of good code and then discusses a common yet often overlooked design smell in detail – big methods. Using an example of a big method, it proposes a refactoring strategy that will ensure that a refactoring effort does not cause any negative side effects. During the session, participants are walked through a real code refactoring example – step by step.

    Though the session focuses on one particular design smell (big methods), the proposed refactoring strategy should apply equally well to other design smells too.

  • Liked Sridharan Vembu
    keyboard_arrow_down

    Over-selling the "Enterprise Agile Frameworks and Certifications"

    Sridharan Vembu
    Sridharan Vembu
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate
    Agile is only for smaller projects and/or startup organisations - Not Anymore. Taking my own and my organisation's experience, Agile is a proven methodology that is well suited for delivering complex, distributed, multi-year enterprise programs, for many years now.
     
    While this is really a great thing for agile enthusiasts and practitioners, it’s a bit of worrying sign for me the increased recognition and popularity the ‘Agile Certifications’ and ‘Agile Frameworks’ are receiving among individuals and organisations who would like to adopt Agile to stay relevant in current world.
     
    I would like to share my views on the adoption of these frameworks and certifications, why I feel they are not-so-agile and how am I and my organisation are solving similar problems without the need for any of these frameworks and certifications.
     
    I am planning to walk through the complete life cycle of the most recent program that I’m part of (from Inception to Initiation to on-going Execution to Post-Production Support) and bring out the relevant agile principles that we adopted, context based customizations we did and the best practices that we have come up with.
    • For instance, one should know the clear difference between hygienic practices vs context based practices - the first ones are not to be compromised at any cost, whereas the latter ones are to be applied based on the need, not because some framework prescribes it.
    The typical life cycle stages that we follow in any program / project delivery is normally: Discovery - Inception - Initiation - Execution - Transition, whereas the actual set of practices within any of these stages and how they are being implemented could be very different from project to project, team to team. 
    • For example, in the Execution Phase, doing pair programming and following TDD are hygienic practices for us. Having said that, it’s perfectly okay for a pair to split and work on a specific task on a case-to-case basis (we call this Pragmatic Programming) and the pair decides when and how long they would split and when to re-join.
    To give an idea on the complexity, enterprise and distributed nature of the program, some key data points:
    • Started almost 3 years ago, on-going
    • 10 quarterly planning workshops done so far
    • 10+ teams, 7 timezones
    • peak program size: 250+
    • peak team size from my org.: 50+
    • total no of systems: 10+
    • geographical spread: plan: 100 countries, 132 locales launched so far: 53 countries, 56 locales
    • 140 page-views / sec
    • Av. response time: 1.3s
    • Handling 100+K products in the catalog, 15+ K pages , 300+ K responsive images
    • Blue-Green production deployment (zero downtime over 1.5 years)
    • 3 weeks cycle of production releases
  • Liked Rakesh Missra
    keyboard_arrow_down

    Cultural roadblocks in Agile Adoption

    Rakesh Missra
    Rakesh Missra
    schedule 1 year ago
    Sold Out!
    60 mins
    Talk
    Beginner

    Though tech community has by now embraced the Agile methodology, the majority/decision-making stakeholders (who are mostly outside tech boundaries) are yet to accept the Agile philosophy.

    Few of the reasons in this context are:      

    CXOs still believe that agile is just a bunch of practices rather than values and principles, and hence, fail to question and change processes.

    Leadership thought process is more of tactical than strategic nature.

    Leadership layer has yet not adopted a value based approach vis-a-vis their overall business philosophy.

    Failing to take larger part of organization in confidence vis-a-vis Agile manifestation.

    Tendency to go for maximizing/optimizing productivity while staking out other, long-term risks/concerns.

    So on and so forth... 

     

    Hence, while an organization may already be executing Agile projects, the long term benefits won't actualize unless a sustained effort is undertaken to remove the cultural roadblocks that are inhibiting Agile adoption process. 

    This session will discuss such roadblocks at large, and then, move on to discuss realistic measures that need to be taken to remove/dilute these inhibitors.

  • Liked Farhath Unnisa
    keyboard_arrow_down

    Agile Retrospective Innovativeness: How to Do Them?

    Farhath Unnisa
    Farhath Unnisa
    schedule 1 year ago
    Sold Out!
    45 mins
    Demonstration
    Beginner

    The concept of keeping one eye on the past, but the other firmly set to the future.

    To do agile retrospectives it’s important to understand what they are and why you would want to do them. This helps to motivate team members to actively and openly take part in them. Few exercises exist for retrospective facilitators to design and perform a retrospective.

    Teams use agile retrospectives to inspect and adapt their way of working. A retrospective is normally held at the end of each iteration, but teams can do it as often as needed. It focuses on the team and the processes used to deliver software. The goal of retrospectives is helping teams to improve their way of working.

Sorry, no proposals found under this section.