• Naresh Jain
    Naresh Jain
    schedule 1 year ago
    Sold Out!
    45 mins
    Keynote
    Advanced

    On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.

    It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.

    In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.

  • 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.

  • Liked Ellen Grove
    keyboard_arrow_down

    Everything Is Better When We Stick Together: Building Team Working Agreements

    Ellen Grove
    Ellen Grove
    schedule 1 year ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    Whether a team is brand-new or seasoned veterans at working together, explicitly defining and/or refining a team working agreement will help the team to align on how they will work together effectively to meet their common goal. In this fast-paced hands-on session, participants will go through the process of building a team working agreement using LEGO Serious Play (LSP).

    Creating a team working agreement helps team members set the stage for effective communication and high performance by making assumptions about ‘what really matters to us’ and ‘how we will work together?’ explicit and negotiable.  Great working agreements address some difficult topics - what values do we share? how do we want to deal with conflict when it comes up? how will we handle problems within the team? - which are often challenging to discuss openly and honestly, especially when a team is first assembled.  

    This session will show you how to use LEGO Serious Play to encourage a frank and fearless discussion in order to kickstart these discussions so that a team can quickly create a powerful set of simple guiding principles for working together.  Participants will learn about the importance of team working agreements in creating team cohesion and common understanding of shared values and operational guidelines, and experience hands-on how to use the LEGO Serious Play cycle of build-share-reflect to have a participatory discussion to identify shared values, explore reactions to conflict, and build a set of simple guiding principles.

     

  • Liked Chris Edwards
    keyboard_arrow_down

    The Value Uncertainty Game

    Chris Edwards
    Chris Edwards
    Sean Dunn
    Sean Dunn
    schedule 1 year ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    In this highly engaging workshop attendees will experience estimating, planning and delivering a new product and product features. The uncertainty in value and costs will be resolved through rolling dice based on the stories that the team selects and prioritizes.   The teams will run through 3 iterations of story cost, value estimation, and product feature delivery. Points will be scored for delivering product features and meeting release and iteration commitments.

    Dealing with uncertainty is one of the largest challenges that teams face. The simulation aims to have levels of uncertainty in value and delivery that are commensurate with those found in software development. Some of the key tools for dealing with uncertainty are integrated into the simulation.

    Attendees will come away with a better understanding of the challenges of working with uncertainty in software projects, and will learn some of the tools that are at their disposal for managing this uncertainty.

  • 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.

  • Liked Dipesh Pala
    keyboard_arrow_down

    7 Things Agile Executives Should Do Differently

    Dipesh Pala
    Dipesh Pala
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Executive

    One of the keys to a successful enterprise agile transformation is the support of Executive Leadership, which is more than simply providing approval. The Agile Executive enables, empowers and engages rather than controls.

    According to one recent survey, more than one in three organisations claim that the lack of Executive Leadership engagement within their businesses is plaguing current journey towards sustainable organisational Agility.

    With a special focus on Executive teams, Dipesh will be drawing upon more than a decade of Agile transformation experiences across multiple organisations, and share real-life case studies and insights to illustrate the following key things that Agile Executives need to do differently:

    1. Stop Starting, Start Finishing
    2. Slow Down to Go Faster
    3. One Team, One Dream
    4. Foster Fully Capable Teams
    5. Fail Early & Fail Small
    6. Deliver Business Value, not just Projects
    7. Servant Leadership

    Awareness of the above principles is important and may sound simple; however turning the awareness of these elements into the inner workings of our daily routine takes discipline. With that in mind, all attendees will also be given ‘The Agile Leaders Checklist' that will assist them in making such behaviours habitual.

    If you are an Executive or a Leader of an Agile team, this session will provide clear implications for where to focus your efforts in order to unleash the full potential of Agile methods to gain a competitive edge. You will be inspired by knowing what serves to catalyze and nourish progress – and what does the opposite.

  • Doc Norton
    Doc Norton
    schedule 1 year ago
    Sold Out!
    480 mins
    Workshop
    Beginner

    Even high functioning teams occasionally have a hard time making decisions or coming up with creative ideas. There are times when the conversation seems to drag on long after a decision is reached. There are times when we have too many people involved in the discussion or the wrong people involved. There are times when we’re not sure whose the actual decision maker. And there are those times when we just seem to be out of synch with each other. This creative collaboration workshop provides tools that help resolve all of these issues. Come have some laughs with Doc, play with new friends, and learn one or two new techniques you can try at home.

  • 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 Balaji Ganesh N
    keyboard_arrow_down

    Doing Agile vs Being Agile - Sins and epiphanies from my agile journey

    Balaji Ganesh N
    Balaji Ganesh N
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Beginner

    There are so many organizations and product teams that are embracing agile implementation methodologies as a means to accelerate product development for competitive advantage and customer delight. Agile is now more than a fad or a buzzword.

    Despite all this pervasiveness and penetration, there are only some teams for whom agile works well, whereas it doesn't work so well for some of the other teams and it fails for the rest. 

    But, is the problem really with adopting agile or is it something else? After all, agile is a mirror.

    As Leo Tolstoy once said, "All happy families are alike; each unhappy family is unhappy in its own way.” There is a lesson to learn from every failed implementation.

    From the 9th "State of Agile" survey done by VersionOne in 2014, in cases where agile projects were unsuccessful, 44% of the respondents pointed to lack of experience with agile methods.

    Drawing from my experiences through my journey as a lean agile coach, this is an attempt to collate the anti-patterns (sins) associated with "lack of experience with agile methods" within the teams implementing agile and possible solutions (epiphanies) to overcome them. I believe that addressing these anti-patterns and preventing them from happening in your teams would significantly enhance the probability of succeeding with your agile implementations. Establishing the purpose and aligning the teams with the organization strategy is one of the key determinant of success. Due to time constraints, I would be focusing on 3-4 anti-patterns (points 1,7,8,9)  that are commonly seen while touching on the rest of them briefly.

     Details are given below:

    1. Square pegs in round holes- These are role anti-patterns and arise by looking at Scrum Master / Product Owner as positions to fill rather than identifying and assigning the right person for the job and abrupt transitions from PM / architect to SM / PO creates this anti pattern. It is important to ascertain the fitment and identify the right person with the attributes of a servant leader who can influence the team without authority, empathize, ask the team the right questions which would empower and enable them to become more self-organizing and step back when required. In cases where a transition is involved adequate training / coaching needs to be provided to smoothen the transition.

    2. Ineffective retrospectives - Retrospectives are treated more as a ritual with no feedback loop to the planning process. Ineffective retrospectives are good at addressing the person and not the problem, creating actionable without owner(s) and timelines, have no focused outcomes and create a "blame game" culture.

    3. Sub-optimal local execution - This is reflected in product teams / modules / component not aligned at the global / program level and is primarily due to misalignment of the teams during planning, no vertical slicing, poor dependency management,  inability to create cross functional teams, no single product backlog, infrequent touch points across the teams with no day to day interaction. This typically results in teams following the sprint cadence but not creating any working deliverable at the end of the sprint.

    End to end optimized execution is possible only through creation of flow across the entire product line. As a first step, it helps to visualize the workflow and understand the work in progress across the various sub-systems to surface the bottlenecks. Cumulative Flow Diagram (CFD) is one of the powerful tools that help identify bottlenecks across the system.

    Some general techniques that help address bottlenecks are identifying the right features (Kano model and user satisfaction matrix) and then vertical slicing to create a working deliverable every sprint, having a single Chief Product Owner (Scaled Scrum) who owns the overall product backlog and ensures priority and value alignment with each team's backlog, synchronizing the iteration time-boxes to ensure that dependent user stories are delivered in the same sprint as much as possible, investing in building relationships and trust among teams (investing in kick-off meetings and face to face engagement), creating a scheduled daily cadence for points of alignment like daily scrum of scrums (weekly inter-team sync-ups would be a killer for teams working on 2 week sprints), usage of tools like Design Structure Matrix (http://dsmweb.org/) for the right development sequence during planning / accurate impact analysis and complexity assessment alleviates this anti-pattern to a large extent.

    Other aspects to address include the team structure and alignment. Executing cross skilling plans levels out workload and integrating business + dev + QA ensures that the right product is built right and reduces failure load significantly.

    4. Dysfunctional team  - This typically happens due to trust deficit. There is typically no daily engagement with the team and team is comfortable with conflict avoidance. Understanding the team (Use tools like Pat Lencioni's 5 dysfunctions of a team), managing conflicts effectively, creating conditions for constructive confrontation, rewarding team collaborative behaviors goes a long way in creating trust, confidence and collective responsibility.

    5. Dis-engaging Daily Standups - Typical anti-patterns here include scrum meetings that overrun significantly beyond stipulated time, team members reporting status to the Scrum Master and not the team, impediments not raised in the meeting, dis-engaged team members. Visualizing the work, raising and tracking impediments, being sensitive to the time zone differences and accommodating them, investing in technology that helps enhance the engagement / involvement levels of the complete team helps make the daily scrums more effective.

    6. Unaligned Process model - Team members frequently pulled into firefighting and production support activities with no regard to the commitments made. There is a need to introspect if time boxed sprint is the right way to go for teams in this case or would a different approach like Scrum+ Kanban (ScrumBan) work better ? There are also cases where heavy weight ALM tools are used for short duration engagements or small teams just because of the availability, without any training or regard to the ROI.

    7. Product Owner - Team misalignment: This is typically manifested in busy product owners (Example -: product owner spending time in too many  discussions with the client, Product Owner for multiple teams) for whom this is an additional responsibility apart from their day jobs, mismatch between the product owner's expectations and the team's expectation, disruptive product owners who do not appreciate or understand the team's challenges, team's velocity not factored in release planning by the product owner. Ensuring that a product owner is not assigned for more than 2 teams, business analysts in the team interfacing with clients to see what the market needs leaving the responsibility of the technical product to the actual product owner, proxy product owner who is empowered to take decisions in the product owner's absence are some of the strategies that ensure enough bandwidth is available for the POs to collaborate effectively with the product team and focus on effective product delivery.Appropriate budgeting for PO during the pre-planning phase, sensitizing the product owners through more face time with the team, identifying  chief product owners for alignment across multiple teams (scaled scrum), proxy product owners are also additional strategies that can address this situation.

    8. Not building the right thing - As Drucker said "There is nothing so useless as doing efficiently that which should not be done at all". . Appropriate widely used techniques / frameworks (Value Stream Mapping, Value-Risk mapping, Risk Based Testing, Design Structure Matrix, Product-Market fit decision frameworks, Kano model) for identifying the right thing to implement, prioritize and eliminate waste would help tackle this antipattern.

    9. Cultural anti-patterns - Typical issues observed here includes -Teams not aligned to the organizational goal / purpose of the program,  non-collaboration across teams, offshore team treated as a "B" team,lack of T shaped skills, inappropriate performance / R&R systems that reward individual success over team success, irregular or inconsistent sprint cadence, student syndrome, using velocity as a tool to compare performance across teams, abrupt transition from project manager to scrum master role, management looking at agile as a tool to overwork the teams, poor ALM tooling strategy and non-alignment across the teams.

    Why is alignment important ? Because one of the important components of ownership is knowing "What to own ?". In surveys with the top management misalignment of the team's goals with the organizational goals comes out as a top response.

    Some symptoms of a poorly aligned team include: poor or failed execution, lack of clarity about priorities, low morale, absence of healthy debate, lack of ownership or follow through, underground communications (gossip, “us versus them” thinking)

    Usage of surveys like the team alignment questionnaires, Scrum Butt questionnaire, team assessment versus the 12 agile principles surfaces points of mis-alignment and dysfunction across the teams

    Some solutions to address cultural dysfunctions include usage of purpose alignment matrix and four questions (who do we serve ?, What do they need and want most ?, What do we do better than anyone else to meet those needs and wants ?, What is the best way to deliver these products / services ? ) to establish the team's purpose, creating cross-functional teams that can get to “done” in each location, recognizing and rewarding adaptive collaborative change behaviors (cross skilling, taking initiatives in supporting team to overcome impediments, helping others cross skill, breaking boundaries for effective problem solving) to reinforce these behaviors,  assessing current project managers and ensuring an effective transition into agile roles through 1:1 coaching (for transforming  smoothly from command and control to servant leadership), effective management of time zone differences in distributed teams to ensure appropriate rotation of meetings / discussions so that one of the teams does not burn out, top down approach to sensitize management and make necessary changes to the organizational structure and career roadmap  for accommodating agile roles like Product Owner, Scrum Master, agile program manager etc.. , adopting objective metrics like Time to Market (TTM) and business value accrued to measure effectiveness.

    As Eliyahu Goldratt once mentioned "Tell me how you will measure me and I will tell you how I will behave". Therefore, look into your performance systems first if you come across any dysfunctional behaviors. One cannot expect a person to display collaborative behavior, if the performance system encourages and rewards individual success over team success.

    10. Surfeit of Metrics  - Team tracks too many metrics that are not relevant and are inherited from waterfall mindset. There is also an obsession for effort tracking at the individual level and % complete’s. Burn-up charts, velocity, committed vs achieved ratio, defects per sprint are just enough metrics for effective tracking.

    11. User story anti-patterns - Teams do not put in efforts to refine the product backlog as it is seen more as a cost than an investment. There are multiple product backlogs and definition of ready is not agreed between the PO and the team. This results in large user stories that cannot be completed in a sprint, wait times for clarifications and things getting put on hold a few days after implementation due to lack of adequate inputs. Agreeing on a Definition of Ready (DoR) and coaching the team / PO on patterns for splitting user stories helps overcome these barriers

    12. Agile Manifesto Delusion - This typically manifests as no documentation, no Definition of Done, multiple disruptions during the sprint to accommodate changes etc... Helping teams understand and interpret the agile manifesto and principles in the manner in which they were intended creates clarity and helps obliterate this anti pattern. 

    At the end of the day, it is all about delivering valuable working software in an incremental manner. Hence principles should always take precedence over practices and tools. We, from the agile community have a big part to play in helping to realize the above and breaking the above barriers for successful agile adoption. 

  • 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

  • Krzysztof Czajka
    Krzysztof Czajka
    schedule 1 year ago
    Sold Out!
    20 mins
    Experience Report
    Advanced

    What is it about?

    This is a story about building appreciation and feedforward culture in the organization.

    I am going to talk about a bottom-up experiment based on Jurgen Appelo's Merit Money, conduced in the biggest e-commerce company in Poland - Allegro Group. It is a story about learning throughout an Agile experiment to get the most out of it. Primarily the experiment was intended to challenge the existing bonus system based on forced ranking. It turned into appreciation and feedback system with some sweets involved. 

    This feedback system has grown to more that 230 people involved from 3 different physical locations and still grows virally. We made a structure in which there is a coordinator in each location. If at least part of scrum team plays the game, SM is the first line contact. He distributes credits and exchanges them for sweets. Also cooperates with coordinator who is responsible for making sure system works well in his location.
    Iterations are now 2 weeks. We introduced a requirement that credit has to be filled in with short description what you thank for, in order to be exchanged. This was to promote written thank you’s and avoid situations where people hand over credits just to get sweets.
    Also every quarter we change credits appearance so that the previous credits cannot be exchanged for sweets. This is to set a time box and “flush the system”.

    Is it for me?

    Do you feel your team could be more engaged in their work? Trying to get rid of silos in your organization? Then this is for you.

    Get inspired by this simple game, in which there are several instant feedback loops, fun, gambling and sweet prizes.

    Oh, I forgot... and you'll find an answer on why we call it Fudge Candies.

  • Ardita Karaj
    Ardita Karaj
    schedule 1 year ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    Many Agile teams focus on Velocity as their measure of progress. They build burn-up charts to track it over time and make it the focus of much of their discussion during Sprint Planning and Retrospectives. Is the strong focus on this metric truly in line with the principles of Agile Software Development?

    Join Ardita as she leads us through a hands on workshop to explore this question. In this workshop you will discover how a focus on Value first, instead of Velocity, changes how the team approaches the work to be completed. Through a series of structured activities you will work with a Story Map for a fictitious project and assign value to the discovered stories. You will learn the practices and skills necessary to track Earned Value on your project and also learn the valuable lesson on how to discover what not to build. The outcome will be a set of new skills that you can take back with you and immediately apply to your current team development planning efforts. This session will be fun and educational. This is one workshop you don't want to miss.

  • Simon Cohen
    Simon Cohen
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Beginner

    If you've never worked at or seen a high performing team, it is difficult to know what to do to get yours started. This talk will give you a basic recipe for forming the working agreements that can lead to a high performing and self managed team. By weaving together both theory and the practical experience from Spotify's way of doing things, we will go on a journey that will give you both the ingredients and the techniques to get cooking. 

  • Liked Craig Brown
    keyboard_arrow_down

    Prioritizing backlogs across diverse stakeholders simply and easily

    Craig Brown
    Craig Brown
    schedule 1 year ago
    Sold Out!
    20 mins
    Talk
    Beginner
     
    Can we get 100 people to agree on what to prioritise to the top of a backlog? Sure we can. Can we identify a reliable systematic system we can use to get this done in just a few minutes? Of course we can.
     
    Requires 100 people to meet the claims in the session, but we can run this with ANY amount of people from 3 (Easy!) to 300 (Equally easy!)
     
    I learned this one from Alistair Cockburn in a pub. It's a neat trick.
Sorry, no proposals found under this section.