• Vishal Prasad
    Vishal Prasad
    schedule 1 year ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Consider an agile utopia executing a lean build-measure-feedback loop for software development. How would you feel if your biggest strength of receiving early feedback from your end-users turns out to be your Achilles heel? Recently I faced this dilemma where my end-users unfortunately were a group of introvert individuals. This led to Monger project’s MVP almost declared as a failure since it did not fulfill the end-user’s requirements. 

    Many a times, projects transform their delivery mechanism from traditional models to agile with a myth that agile is a recipe for success. In reality many projects fail since agile is not well understood by the teams. A few times (like in this case) the agile process falters not due to incorrect implementation but due to incorrect participants responsible to execute a part of the process.

    Experience with me what happens when your end-users falter your feedback loop just because of the nature of individuals. If you’ve ever been a part of a group (or may be in the future) where your end-users are introverts, learn from this experience report how we overcame this problem on the Monger project by strengthening our anemic reviews. At the same time, if you as a participant have been there and done that, I would love to hear about it.

  • Venkatraman L
    Venkatraman L
    schedule 1 year ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    The role of Leadership in organisation's Agile transformation is a critical piece. Yet many organisations struggle to find the right balance between top-down vs. grass-root transformation. I would like to share an experience where we were able to achieve fairly good grass-root movement, but had serious challenges building the agile mindset at the leadership level. While the leadership was trying to help with the best of their intentions, certain actions, behaviours and patterns did affect the spirit of agility. If you are keen to hear about typical leadership anti-patterns during agile transformation and some pointers on how to avoid them, this session is for you.

  • Liked Dipesh Pala
    keyboard_arrow_down

    Unleashing the full potential of your Distributed Agile Teams

    Dipesh Pala
    Dipesh Pala
    schedule 1 year ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    Are you interested in succeeding with Agile in large, complex distributed development projects? Being Agile in a distributed environment has been a subject of controversy over the years, which is not surprising given the importance placed on face-to-face communication in the twelve principles of the Agile Manifesto.

    This workshop will address the opportunities, challenges and concerns that are commonly faced by organizations in keeping to this manifesto when their Agile teams are geographically distributed.

    Agile teams need to work together very closely as cross-functional teams, instead of silos with hand-offs after long project phases. Agile teams also need to engage customers and stakeholders frequently to ensure that they are meeting customer needs, adapting to changing requirements and delivering high-quality software. The transparency inspired by Agile makes any challenges related to this level of daily communication, collaboration and teaming, painfully obvious to teams and individuals. However, many large-scale and distributed Agile teams are successfully and boldly rising to meet the challenges with great success.What makes the difference between thriving versus just merely surviving?

     In this session, we will explore how organizations can create cultures, nurture individuals, and build teams to create high performing Distributed Agile teams in a globally competitive world. Dipesh will also share some innovative ideas in addition to tricks, tips, and proven methods that have inspired and helped people and organizations to 'be Agile' rather than just 'do Agile'.  The Agile Manifesto puts more emphasis on individuals and interactions over processes and tools and we want to keep it that way no matter where they are!

    Bring your greatest distributed teaming challenges and and be ready to be inspired during this active and engaging session.

  • Doc Norton
    Doc Norton
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Among the traits that distinguish a good team from a great team is their ability to innovate. Despite the rhetoric in favor of innovation, most organizations are stuck in an implementation mindset, stifling creativity, excellence, and the resultant innovation. The experimentation mindset frees us from self-imposed constraints, allowing us to continually learn and improve. In this session, we'll talk about how we learn as individuals and how we learn as organizations. We'll take a look at some examples of the experimentation mindset happening in the agile community today and we'll talk about how you can foster such a mindset in your own organization.

  • Liked Steve Holyer
    keyboard_arrow_down

    Requirements Engineering for Agile Product Owners: Hunting value with structured conversations

    Steve Holyer
    Steve Holyer
    Pavel Dabrytski
    Pavel Dabrytski
    schedule 1 year ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    Hunting value through conversations. This is a skill that helps Product Owners when working with stakeholders, analysts and requirements engineers. Start with identifying your project partners, and use the 7 Product Dimensions (user, interface, activities, data, control, environment and quality attributes) to uncover correct requirements for your product. Understand how you can use it to focus on value, deliver value and optimise value.

    Unfortunately all too often, many Product Owners do much of their work alone. We want the participants to experience the power of the conversation structured to hunt value through a specifically designed dojo, and we want to create better awareness of good requirements engineering practices. This session is intended to help Product Owners and Business Analysts create better requirements and to help them have richer and more powerful conversations. The session is based on the work of Ellen Gottesdiener and Mary Gorman’s “Discover to Deliver” as well as the work of James Shore and Diana Larsen’s Agile Fluency Model.

  • Shane Hastie
    Shane Hastie
    schedule 1 year ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    A number of agile brands downplay the need for business analysis and requirements management on agile projects, putting large store in the role of the Product Owner.  This paper tackles some of the problems this misconception can result in and shows how effective product ownership almost always requires a team with a variety of skills and backgrounds to be effective.

    Product Ownership requires clarity of vision, alignment with organizational strategy, understanding of the development process and the ability to communicate with a wide variety of stakeholders across all levels both inside and outside the organization.  The complexity of the role is most often more than a single person can (or should) cope with – effective product ownership requires a teamwork approach covering a variety of skills and knowledge.

  • Liked Leena S N
    keyboard_arrow_down

    Deliver with Impact

    Leena S N
    Leena S N
    schedule 1 year ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    One common problem any delivery team struggles is to have a common understanding of "why" a product or feature is being built. The documents such as Project Charter, vision document etc. tries to solve this problem, but it’s common to see such documents exist in the repository, hardly known or read by anyone in the team. And this document rarely gets updated too. Ask your team members what is the goal of the project? You may be surprised to know how many actually know about it.

    The so called "vision" or "goal" usually rests within Product Manager/Owner or any other stakeholder. There is no forum to converse about these goals or ideas as a team. The planning meetings [iteration or release planning] are supposed to take care of this, but there is no standard guidelines defined which would help to brainstorm these in a typical release/iteration planning meetings.

    This is where Impact Mapping comes into the picture. It is a "Strategic planning technique", defined by Gojko Azdic, explained in the book Impact Mapping. It is a very simple technique based on the idea of "asking the right questions" which are:

    • Why are we building what we are building? i.e., Goal(s) of the product
    • Who we think are the actors who’ll get impacted?
    • How do we expect to change the actors’ behavior?
    • What are we going to do to create the impacts? i.e. the feature list / deliverables

    Finally, by connecting the deliverables to impacts and goals, a map shows a chain of reasons that leads to feature suggestion. 

    Fundamental of Impact Mapping is that Impact means a change in behavior of an actor which usually results in a positive impact either by Reduction in the Cost or Improvement in ROI for the business.

    If you closely watch the sections in Impact Mapping, what to build i.e. the features or the so called backlog comes only at the end, whereas in the typical planning meeting we usually start with a backlog.

    The above questions need to be answered by the entire team [the IT team, the business people and any other stakeholders, if any], and avoids the common anti-patterns during planning meetings:

    • Ad-hoc planning
    • Wrong Assumptions
    • Pet features

    The hands on workshop will cover the above mentioned concepts of Impact Mapping in detail along with exercising the same.

    Below are a few comments that we received from our customers after being part of the Impact Mapping session:

    • “It made me think about the real goals my product has to achieve during the initial launch.”
    • “Wow, this is a great way of visualizing”
  • James Shore
    James Shore
    schedule 1 year ago
    Sold Out!
    480 mins
    Tutorial
    Intermediate

    This full-day workshop focuses on applying Agile engineering practices to web development. We'll look at practices such as build automation, continuous integration, test-driven development, refactoring, and incremental design and see how to apply them to front-end web development. We'll cover topics such as cross-browser testing, JavaScript, and CSS.

    Audience: This session assumes familiarity with Agile engineering practices such as test-driven development and refactoring. Experience with JavaScript, CSS, and other web technologies is recommended. Come prepared to code.

  • Kalpesh Shah
    Kalpesh Shah
    schedule 1 year ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    Great teams make great products, but what fuels this greatness? It's the common understanding and passion for the product but more importantly the singularity of purpose and the feedback loop and how the users are responding to the teams work. 

    The new world of product development is no longer about scope management and delivering the project on time and within budget but it's now more about hypothesis validation and learning from the users and their behaviors.

    The dynamics of product development is changing.  As more and more organizations are moving towards maturing their agile software development approach the traditional barriers of roles are being broken creating new opportunities and fostering a shift in the mindset. Instead of being tied down to scope management and delivering the project on time, Agile teams are focused and inspired by hypothesis validation and learning from the users and their behaviors.

    In this case study we will go over how a portfolio of 12 SCRUM Teams adopted a more outcome approach and how they shifted their mindset from project delivery in Agile way to adopting the Experiment-Measure-Learn-Repeat loop which plays a crucial role in teams overall motivation, performance and moved from being SCRUM Teams to "Product Teams".

    We will also see how we experimented with different team formats and how exposing the team members to different events and user research changed the way they perceived the information of the problem they were solving via features and user stories.

     

     

  • Ellen Grove
    Ellen Grove
    Steve Holyer
    Steve Holyer
    schedule 1 year ago
    Sold Out!
    480 mins
    Workshop
    Intermediate

    Using play to build a better beginning through Agile Chartering

    Better teams create better outcomes.  A liftoff (as described in the book Liftoff by Diana Larsen and Ainsley Nies) at the outset of a new endeavour helps teams set the stage for betterness by cocreating a shared understanding of purpose, establishing alignment and understanding the context of the work they will do together.  While the activities to include in a Lift Off will vary according to team and context, the practice of Agile Chartering - collaboratively developing a lightweight yet effective roadmap for the project and the team - is key to aligning and inspiring people to do better work together.

    The purpose of an Agile Chartering workshop is to give all stakeholders of a project a voice and the opportunity to co-create a common understanding of the project dynamics, its purpose and context. It creates co-ownership of the project within the project team and thereby higher commitment to the project goals.

    In this workshop, we will explore the objectives of Agile Chartering and foster a playful approach to doing this work. We'll talk about what kinds of games can be used to cocreate Purpose, Alignment and Context with a team, and run at least one game that can be used for each of the elements of an Agile Charter

  • Liked Tathagat Varma
    keyboard_arrow_down

    Minimum Viable Coaching: an experience report

    Tathagat Varma
    Tathagat Varma
    schedule 1 year ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    In May 2015, I got involved in coaching a products organization in improving their agile practices. This was a unique coaching experience for me because of some interesting experiments that I did:

    • I focused on coaching and literally zero consulting. 
    • My coaching stance was only limited to showing them the way, initially training them on the essence of agility, and later on to simply shine light on areas that needed their attention, and if needed, share ideas from the industry.
    • I spent just 1day every month with the teams to only focus on my coaching sessions, and a few hours during that time to review the progress.
    • The teams and the leadership would decide on what they wanted to do, and how much they wanted to change.

    In ~6 months that I coached them, I found that the team has matured to a very high level of self-organization. They changed their process, their key roles and responsibilities, and self-organized into a very high-performing teams (which was corroborated not just from the high-energy levels of their teams but also the project metrics).

    I call this model Minimum Viable Coaching, and it was helpful in demonstrating how a coaching could be made extremely effective if there is a client who is willing to trust its team in their ability to self-change, with minimal guidance (more of direction than really support) from an external coach. It also requires a coach to think in terms of minimum self-interests (read commercial interests) but focus on what will make the client successful in the long run.

    In this experience report, I will share my approach and experiences, and offer some ideas on how the coaching can be elevated to a true coaching where the enterprise becomes self-organizing on their own.

  • Liked sripriya thinagar
    keyboard_arrow_down

    Forget Agile, Welcome Swiftly

    sripriya thinagar
    sripriya thinagar
    schedule 1 year ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    Picture this - You see a bunch of disgruntled developers, who haven't yet had their caffeine and stumble for what is the daily standups and provide a nice long winded update and never want to ask for help in front of their peers. They are then dragged once or twice a week to a grooming session and some details are given while they are still thinking about the work they are doing for the current iteration. If thats not sufficient, they are asked for estimates and they wonder what makes them go unnoticed. Then there is the planning day when they yawn and wonder why we do the retro every two weeks and do nothing about them or why they are asked to plan when they just finished the last piece of work yesterday.  All of this seems unnecessary if only someone told them what they are driving towards and how to leave them alone and get them to be productive.

    Come join me as i share some techniques that i have used with the teams i am part of, in helping build high performing culture while focusing on engaging customer experiences and delighting your customers.  

    Stop by, sit back, relax and enjoy the show

  • Liked Raj Karunakaran
    keyboard_arrow_down

    Building a Agile Culture - Our experience at Philips

    Raj Karunakaran
    Raj Karunakaran
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

     

    At Philips, we have been focusing on shifting organizational mindset and behavior and incorporating an Agile mindset.

    It is a normal practice for organizations to adapt Agile by first conducting Agile training for teams, adapting Scrum ceremonies and mechanically applying Agile practices. The biggest challenge that an organization faces is on how to shift the mindset of the team and the leaders towards Agile. Moreover how to shift the people practices, that have been strongly aligned to traditional set up.

    It is important for organizations to understand that Agile is a cultural shift and additional interventions should be introduced to make this cultural shift. 

    At Philips we looked at various aspects to bring in a holistic shift in the culture, mindset and behaviors :-

    • The first step was towards building a purpose driven organization with a strong vision that intrinsically motivates people towards creating customer value – rather than being too focused on financial results and internal metrics.
    • Secondly, for Agile teams to be successful, focus is on mowing the ownership to the teams. This includes teams to not just acclimatize Agile values and principles but also to start driving the change. This involved creating change practices and interventions that facilitated this process.
    • A culture change is a transformation in team behavior and competence. The team should be able to adapt and give feedback to each other on these competencies. Feedback souk is now getting embedded as a regular ceremony.
    • To shift the ownership to the team, the traditional organization structure needs to change. Traditional hierarchical structures represent flow of control and authority that is top down. Lateral Career paths are making way to Career Lattice. Managers have started playing the role of facilitators and performance coaches. 
    • The people practices like hiring, performance management, learning and development, recognition practices, decision making process are getting transformed to allow a bottoms up approach.

    We are seeing that the real shift in culture happens when organization become truly external and customer  focused and shifts its focus from internal controls to more flexibility.

  • Liked Angel Diaz-Maroto Alvarez
    keyboard_arrow_down

    Being Agile to become Customer Centric

    Angel Diaz-Maroto Alvarez
    Angel Diaz-Maroto Alvarez
    schedule 1 year ago
    Sold Out!
    90 mins
    Workshop
    Intermediate
    The first principle of Agile manifesto says "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” But, Is our highest priority to delight our customer, or to delight our sponsor. Do we understand who the real customer is and behave accordingly?
     
    I’ve often seen Agile teams producing software aimed to delight: another departments within their organization, an external organization hiring their development services, their management or even their Product Owners. But, are those the ones to be delighted by the product in development?
     
    I believe that software is awesome when it helps creating awesome experiences to the people the organization is serving. To create those delighting experiences is very important to understand who your real customer is and empathize with him. This session is aimed to create that awareness and to introduce some practical tools that can help creating a "Customer Centric” Agile implementation and culture in organizations.
  • Liked Timothy Fitz
    keyboard_arrow_down

    Continuous Deployment: Moving Past Continuous Delivery

    Timothy Fitz
    Timothy Fitz
    schedule 1 year ago
    Sold Out!
    45 mins
    Keynote
    Intermediate

    Continuous Delivery is a amazing practice when compared to slower release cycles. But it shouldn't be the end goal. Continuous Deployment, safe automatic deployment of frequent small commits, is the next step. To get to a fully automatic release process the way that your team writes and releases features will need to fundamentally change. The tools, learnings and techniques presented will be widely applicable regardless of how far along adopting continuous practices you are.

Sorry, no proposals found under this section.