• Liked Pramod Sadalage
    keyboard_arrow_down

    Ten Patterns of Database Refactoring

    Pramod Sadalage
    Pramod Sadalage
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Over the life of an application as requirements change, application usage patterns alter, load and performance changes the need to change database and database architecture is inevitable. There are patterns of these changes such as

    1. 1. Encapsulate Table with View
    2. 2. Migrate method from database
    3. 3. Replace method with views
    4. 4. Introduce Read only table
    5. 5. Split table
    6. 6. Make column non-nullable
    7. 7. Drop column
    8. 8. Add foreign key constaint
    9. 9. Merge columns
    10. 10. Replace columns

    In this talk we will discuss the above database refactoring patterns and different implementation techniques to enable blue, green deployments, allow for legacy applications to work with fast changing database and enable the teams to effectively refactor the database to fulfill the changing needs of the organization.

  • Liked Michael Heydt
    keyboard_arrow_down

    Applying Lean UX to Capital Markets - Lessons From a Year of Lean UX on Wall Street

    Michael Heydt
    Michael Heydt
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    The Lean UX approach to interaction design is a spectacular model for defining and implemented what is needed in appications to support the users in their jobs, as compared to technical deliverables that in the end often do not meet the needs of the users.  In this talk, I will go over strategies for applying lean UX practices to capital markets projects, adapting UX to agile processes, including executing user interviews, rapid UX design, mockups to UI prototypes, and rapid implementation through continuous delivery and end user experience / acceptance testing.

  • Liked Mukesh Bhangria
    keyboard_arrow_down

    Continuous Refactoring at Amazon: A Case Study

    Mukesh Bhangria
    Mukesh Bhangria
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Between the project deadlines, we always feel there is code which needs to be improved

    Usually Developers have the following 3 options:

    - Bite the bullet and do the refactoring as they go along.
    - Park the issue and address it later.
    - Allocate special time when the project gets out-of-control.

    As customer facing stories take higher priority, usually Developers are forced to choose the last option.

    However a team at Amazon took a different approach. Attend this session to listen to their first-hand story of how they changed this typical behavior to achieve Continuous Deployment on a critical service.

  • Liked Todd Little
    keyboard_arrow_down

    Mythbusting Software Estimation

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

    Estimating software projects has proven to be particularly challenging. Over-running schedules happens frequently in our industry. Todd will look into some of the reasons for these challenges by exploring a number of myths of software estimation and then setting out to validate or bust these myths.

  • Liked Jez Humble
    keyboard_arrow_down

    Why The Project Paradigm Kills Innovation, and What To Do Instead

    Jez Humble
    Jez Humble
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Projects were invented as a vehicle for managing civil engineering projects. But software has completely different characteristics from, say, a bridge. In this talk I'll explain why the use of projects causes significant dysfunction, and how to build innovative products and services at scale based on lean principles.

  • Liked Richard Kasperowski
    keyboard_arrow_down

    Self-management and Self-organization: Agile Games with Motion

    Richard Kasperowski
    Richard Kasperowski
    schedule 3 years ago
    Sold Out!
    45 mins
    Workshop
    Beginner

    Self-management and self-organization are important themes in Agile software development, but what do they actually look like?  We pontificate about worker empowerment, but then we revert to command-and-control: our product owners mandate project scope and deadlines, and our Scrum Masters assign tasks to team members.  Why can’t we let teams be self-organized and workers be self-managed?
     
    These activity-based learning activities are kinesthetic learning games.  Players learn by playing fun, physical games of movement.  These games create a social atmosphere and a full body and mind experience that make it easy and fun to learn.  We’ll play five games, including Line Up, 60 Paces, Triangles, Human Knot, and a special surprise game.
     
    In this session, we explore and experience self-management and self-organization via Agile games.  You will leave with a deep internalized understanding of self-management and self-organization and an appreciation of how they work better than command-and-control.  You’ll be able to share these games with your coworkers.

  • Liked Howard Deiner
    keyboard_arrow_down

    Pivoting Your Organization to Become Agile Testers

    Howard Deiner
    Howard Deiner
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Many organizations struggle with transforming from the old style teams consisting of members with specialized silos of skills into Agile teams consisting of generalized specialists.  This results in sub-optimal Agile adoptions in Agile/Scrum environments, which is where most organizations transforming to Agile are advised to start.

    We will start with a look into the real role of QA in the organization, and where they truly add value in the production of quality code to allow the business to move forward. Piggybacking on the role of QA, we will then speak to exactly what QA needs to do to add value to the software development process, and how they integrate in the DevOps model that is a contemporary solution to an age old issue.  And, finally, we will speak to some uncomfortable truths, and draw conclusions into the skills that Agile Testers must be expected to master to allow the organization to pivot successfully into a truly Agile development group.

  • Liked Nitin Ramrakhyani
    keyboard_arrow_down

    Lean Roots to Grow, Wings to fly!

    Nitin Ramrakhyani
    Nitin Ramrakhyani
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    A lot has been said about Kanban and how these can be implemented in Software development, but the learning remains superficial till we go deep down to its roots to understand the core underlying practices and principles and why/how these practices evolved over a period of time. Infact the roots of most of the Agile methods can be traced back to Lean/Toyota Production Systems, a set of practices and techniques used by Toyota to build great set of cars with limited amount of resources. Even though building software is much different than building a car, there are many lessons and practices that can be learnt and applied nonetheless.

    In this interactive and visual talk, we'll take a virtual trip to Japan and learn some of the best practices/concepts that originated at Toyota for building "world-class" cars and see how each of these can be applied to software development. Learning about the roots of Lean should help the attendees in sowing the seeds of Lean improvement in their organizations and would help in building better software and improving the efficiency of the software delivery lifecycle.

  • 45 mins
    Workshop
    Beginner

    There is a level of "assumptions" that each one of us work with, while we deal with any system. Here in this case the system could be a team member, the manager, the management, or the entire organization. While we work with assumptions, the conversations or the discussions or the work we do, can seem like getting nowhere because of the conflicts, and a sense of frustration piles on .This is a common situation and a very common feeling amongst Coaches/Scrum masters/Project Managers or anyone dealing with project management scenarios. That is where "contracting" helps us get our way through!

    Contracting is a concept of "Transactional Analysis" school of psychology. Eric Berne defines it as "an explicit bilateral commitment to a well-defined course of action". Sometimes contracts will be multi-handed - all parties to the contract will have their own expectations. In the unusual event that these are all congruent, then fine. However, if not, then discussing everyone's expectations will lead to greater understanding and therefore to a clear contract. The risk in not doing this is that problems in completing the contract will emerge at some stage.

    3 Categories of contracts are administrative, professional and psychological.

    Administrative contracts deals with the operational agreements- like fees, who has to do what, time, frequency, attendees etc.

    Professional contracts deals with the expectations from each role and clarifies the essential setup required to achieve the same

    Psychological contracts talks about how we work as people and help to understand how we express our comforts/ discomforts       

    Amongst the three contracts psychological contracts are very essential and often ignored in projects. This type of contract will help us co-create any assignment and it’s a powerful tool for Agile coaches while they work with their teams, managers, organization etc.

    Further to agree with any contract, both the parties should operate from a space where there is mutual trust and concern (I am Ok , You are Ok).

    This report will discuss in detail about these contracts with examples from Agile projects, in an activity based sessions. We will also discuss the life positions based on 'I am OK, You are OK' theory.

    Note: Please note that this presentation is not about the business/financial contracts that most of us are aware of. However, the framework of contracts could be applied in any situation including the business/financial contracts.

  • Liked Shashank Teotia
    keyboard_arrow_down

    Polyglot Programming and Agile Development

    Shashank Teotia
    Shashank Teotia
    Pramod Sadalage
    Pramod Sadalage
    schedule 3 years ago
    Sold Out!
    45 mins
    Demonstration
    Advanced

    Polyglot Programming as a technique is not new and as a paradigm was coined in 2006 by Neal Ford. In today's world, we often architect solutions which need to be highly scalable, secure, efficient, have an engaging GUI, be extensible with low technical debt in parts or whole. To work with a single tech stack promotes a sense of mono culture which is detrimental and limiting the way a solution can be designed. Moreover, with multi-core machines available, processing now can leverage parallel processing and it maybe make more sense to use a language which takes away the overhead of the intricacies of multi-thread programming.

    In other words, in many cases, engaging in Polyglot Programming helps you focus more on the domain and adds to developer productivity.

    On the flip side, increasing the moving parts also means that if not designed well, Polyglot Programming could be a double edged sword and produce more mess in the way different pieces interact with each other.

    In this talk, we will showcase an ecosystem we built, involving a desktop device configuration backed, an OS-agnostic desktop GUI, a cloud service, a cloud cluster configuration tool and how we used the Agile principles, namely TDD, Continuous Integration and the works to be able to keep the polyglot ecosystem sane.

    Name wise, the languages/tools/etc which we used in our Polyglot case – Google Go, Node-Webkit, JS (Knockout/RequireJS), Ruby, Cucumber, RIAK, Chef, Lisp, Jenkins

     

  • Liked Arlo Belshee
    keyboard_arrow_down

    Agility: Step 1: Discipline; Step 2: Make Awesome

    Arlo Belshee
    Arlo Belshee
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    What comes after Agile? That depends on what you did for Agile. We will start by talking about the practices - and results - that only the top 2% of agile teams do. For most teams, this is what is beyond their Agile. Then we'll talk about patterns in the things that these top 2% are trying. Everything comes from the insane disciple Agile teams possess; let's look at how they capitalize on it.

  • Liked Todd Little
    keyboard_arrow_down

    Mythbusting Software Estimation

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

    Estimating software projects has proven to be particularly challenging. Over-running schedules happens frequently in our industry. Todd will look into some of the reasons for these challenges by exploring a number of myths of software estimation and then setting out to validate or bust these myths.

  • Liked Jez Humble
    keyboard_arrow_down

    Why The Project Paradigm Kills Innovation, and What To Do Instead

    Jez Humble
    Jez Humble
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Projects were invented as a vehicle for managing civil engineering projects. But software has completely different characteristics from, say, a bridge. In this talk I'll explain why the use of projects causes significant dysfunction, and how to build innovative products and services at scale based on lean principles.

  • Liked Mukesh Bhangria
    keyboard_arrow_down

    Continuous Refactoring at Amazon: A Case Study

    Mukesh Bhangria
    Mukesh Bhangria
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Between the project deadlines, we always feel there is code which needs to be improved

    Usually Developers have the following 3 options:

    - Bite the bullet and do the refactoring as they go along.
    - Park the issue and address it later.
    - Allocate special time when the project gets out-of-control.

    As customer facing stories take higher priority, usually Developers are forced to choose the last option.

    However a team at Amazon took a different approach. Attend this session to listen to their first-hand story of how they changed this typical behavior to achieve Continuous Deployment on a critical service.

  • Liked Nitin Ramrakhyani
    keyboard_arrow_down

    Lean Roots to Grow, Wings to fly!

    Nitin Ramrakhyani
    Nitin Ramrakhyani
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    A lot has been said about Kanban and how these can be implemented in Software development, but the learning remains superficial till we go deep down to its roots to understand the core underlying practices and principles and why/how these practices evolved over a period of time. Infact the roots of most of the Agile methods can be traced back to Lean/Toyota Production Systems, a set of practices and techniques used by Toyota to build great set of cars with limited amount of resources. Even though building software is much different than building a car, there are many lessons and practices that can be learnt and applied nonetheless.

    In this interactive and visual talk, we'll take a virtual trip to Japan and learn some of the best practices/concepts that originated at Toyota for building "world-class" cars and see how each of these can be applied to software development. Learning about the roots of Lean should help the attendees in sowing the seeds of Lean improvement in their organizations and would help in building better software and improving the efficiency of the software delivery lifecycle.

  • Liked Karthik Sirasanagandla
    keyboard_arrow_down

    When Agile becomes Fr-agile..learn your lessons the fun way!

    Karthik Sirasanagandla
    Karthik Sirasanagandla
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate
    So you have heard of "Code Smells". Did you hear of "Agile Smells"? Yes or No; then this session is for you (us).
     
    In this session, Karthik intends to talk about the very many things that go wrong in companies that attempt to be or become Agile.
    But fault-finding is the easiest thing. Can Karthik provide concrete solutions? Yepp, he intends to share the solutions as well for most if not all the problems.
    And in same breadth seeks to know what others has to offer from their experience.
     
    Piquing your interest? Are you wanting to get a taste of some of the Agile smells? Below are some of them:
    * Belated Stand-ups
    * Non-participative stand-ups
    * War-zone Retrospectives 
    * Unfruitful Sprint planning meeting
    * Zero-Test development
    * Inverted Test Pyramid development
    * Gate-keeper QAs
    * Hierarchical Roles
    * Velocity Driven Development
     
  • 45 mins
    Workshop
    Beginner

    There is a level of "assumptions" that each one of us work with, while we deal with any system. Here in this case the system could be a team member, the manager, the management, or the entire organization. While we work with assumptions, the conversations or the discussions or the work we do, can seem like getting nowhere because of the conflicts, and a sense of frustration piles on .This is a common situation and a very common feeling amongst Coaches/Scrum masters/Project Managers or anyone dealing with project management scenarios. That is where "contracting" helps us get our way through!

    Contracting is a concept of "Transactional Analysis" school of psychology. Eric Berne defines it as "an explicit bilateral commitment to a well-defined course of action". Sometimes contracts will be multi-handed - all parties to the contract will have their own expectations. In the unusual event that these are all congruent, then fine. However, if not, then discussing everyone's expectations will lead to greater understanding and therefore to a clear contract. The risk in not doing this is that problems in completing the contract will emerge at some stage.

    3 Categories of contracts are administrative, professional and psychological.

    Administrative contracts deals with the operational agreements- like fees, who has to do what, time, frequency, attendees etc.

    Professional contracts deals with the expectations from each role and clarifies the essential setup required to achieve the same

    Psychological contracts talks about how we work as people and help to understand how we express our comforts/ discomforts       

    Amongst the three contracts psychological contracts are very essential and often ignored in projects. This type of contract will help us co-create any assignment and it’s a powerful tool for Agile coaches while they work with their teams, managers, organization etc.

    Further to agree with any contract, both the parties should operate from a space where there is mutual trust and concern (I am Ok , You are Ok).

    This report will discuss in detail about these contracts with examples from Agile projects, in an activity based sessions. We will also discuss the life positions based on 'I am OK, You are OK' theory.

    Note: Please note that this presentation is not about the business/financial contracts that most of us are aware of. However, the framework of contracts could be applied in any situation including the business/financial contracts.

  • Liked Puneet Sachdev
    keyboard_arrow_down

    Biting the Bullet - CMMi Level 5 Assessment for Agile Programs

    Puneet Sachdev
    Puneet Sachdev
    schedule 3 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    CMMi Level 5 assessment has been a necessity and a hygiene factor for any service organization. Our organization has been assessed at Level 5 continuously since 1999. However, with spread of Agile methodologies in offshore scenarios we were faced with a question of ensuring CMMi compliance in Agile programs.

    This session will delve into details of our CMMi journey for Agile programs and how NIIT Technologies successfully got re-assessed at CMMi Level 5 with Agile in August 2013. The session will talk about various mapping of agile practices with CMMi process areas, identified gaps and how these gaps were addressed to ensure a successful assessment without diluting the Agile promise. 

    Some examples of how various process areas have been mapped to various agile practices. The session will be mostly example based and experience sharing. 

    Example 1 (Level 2 Maturity)

    CMMi Requirements Management PA talks about bidirectional traceability. If you go to sub practice (SP 1.4 of Requirements Management PA) level then there are three requirements: 

    • 1) Maintain requirements traceability to ensure that the source of lower level (i.e., derived) requirements is documented.
    • 2) Maintain requirements traceability from a requirement to its derived requirements and allocation to work products.
    • 3) Generate a requirements traceability matrix.

    Looking at the above, we managed this through requirements management being done in Agile projects using tools like Rally, TFS (agile templates), Jira Greenhopper and NIIT's internal agile management tools. These tools provide traceability from Epics --> Stories --> Tasks --> Test Cases --> Defects. This fullfils the intent of the PA. Hence we do not explicitly generate any RTM especially for agile projects (3rd bullet above) as the intent is already met. 

    Example 2  (Level 2 Maturity)

    CMMi Project Monitoring and Control (PMC) PA talks about a goal "Manage Corrective Actions to Closure" (SG2). This has 3 separate sub processes

    • 1) Analyze Issues
    • 2) Take corrective Action 
    • 3) Manage Corrective Action

    All these have been covered through the Agile practice of having "retrospectives", which happen regularily in Scrum. Retrospectives is where the people point out issues amongst other things, discuss what actions can be taken to improve and/or address the problem at hand. These action items coming out of retrospectives are then tracked as they would normally  have been done to closure. We do not mandate any specific format/tool for capturing and tracking this information.  

    Example 3 (Level 4 Maturity)

    CMMi Organization Process Defintion PA, has a goal for "Establishing Performance Baselines and Models" and a Sub Practice "Analyze Process Performance and Establish Process Performance Baseline".

    Here instead of taking traditional  metrices like productivity (hrs/FP), schedule slippage etc. we have taken metrices which are more close to the agile process. Examples of these are: 

    • 1) UAT Defects per Engineering Effort Unit
    • 2) Velocity Improvement over time
    • 3) % of story point change to measure requirements stability   
  • Liked Arlo Belshee
    keyboard_arrow_down

    Agility: Step 1: Discipline; Step 2: Make Awesome

    Arlo Belshee
    Arlo Belshee
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    What comes after Agile? That depends on what you did for Agile. We will start by talking about the practices - and results - that only the top 2% of agile teams do. For most teams, this is what is beyond their Agile. Then we'll talk about patterns in the things that these top 2% are trying. Everything comes from the insane disciple Agile teams possess; let's look at how they capitalize on it.

  • 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 Zaheerabbas Contractor
    keyboard_arrow_down

    Applying Agile Practices in the Refurbishment/Modernization of my housing society

    Zaheerabbas Contractor
    Zaheerabbas Contractor
    schedule 3 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    In the rush to be a proud owner of a large independent penthouse apartment in a huge housing society I did not realize (or did not want to) the actual reason behind this good bargain!

    I ended up being party to the following list (product backlog) of pain areas (or business needs) of the society members:

    • 1.Need of Generator backup to cater to the frequent power cuts at least for the common areas and lifts (I had bought my condominium on the top floor and could realize the pain!) – Must have and High Cost
    • 2.Modernization of the ageing lifts across 18 buildings (thanks to the substandard quality lifts which I realized when I started staying there L ) – Must have due to high risk however huge Cost
    • 3.Need for the CCTV Camera – Must have considering the frequent untoward incidents
    • 4.Seepage and septic tank upgrade
    • 5.Pavements, speed breakers
    • 6. And the list goes on….

    This resulted into the society being least valued in that area and no ROI for the members who had invested in the society.

    The society committee members were clueless on where to start (prioritizing with business value) with the given evolving budget and how to manage the timeline.

     Through this report, I intend to share how I utilized following Agile practices to overcome the challenges faced by the society members for its refurbishment and converted the society into one of the most sought out society over the period of few milestones (releases)!

    • 1.Prioritization(MoSCoW) of the backlog by agreeing up urgent need of the society in the given budget
    • 2.Continuous planning and re-prioritization of product backlog
    • 3.Outcome(Value) based agreement with various vendors
    • 4.Managing discipline in the acceptance criteria and retrospection (i.e. PWD lift inspection and approval for lifts functioning with the given municipality specifications and taking learning to replicate the same for future enhancements)
    • 5.Delivering end to end(INVEST) in the production in short releases ( i.e. one lift modernization end to end and commissioning of Diesel Genset end to end through incremental approach)
  • Liked Vinay Krishna
    keyboard_arrow_down

    Effective 9 Practices to minimize technical debt

    Vinay Krishna
    Vinay Krishna
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Often we find it difficult to incorporate any changes in a software project during later phases of its development, or during post-delivery maintenance. Primary reason for this is inflexibility in design and code which makes it difficult for changes to be incorporated. This inflexibility substantially increases the cost of making changes and this metaphor has been termed as Technical Debt.
    While Technical Debt cannot be eliminated completely, its burden needs to be reduced. Many agile practitioners have suggested some practices to avoid or eliminate Technical Debt.
    In this session I shall discuss about a method to get relief from Technical Debt and talks about nine proven practices that a developer can follow to minimize Technical Debt. These practices help to:

    • Change the coder's mindset so that they should use technical practices i.e. various refactoring techniques to reduce technical debt in code and design
    • Developers to plan and manage the time to pay down the debt i.e. determine your living budget
    • Take minimal technical credit in design and code

    These practices have been used and found to be effective when implemented in projects which will be used as a case study.

  • Liked Maris  Prabhakaran
    keyboard_arrow_down

    Coaching Mantras for Agile Team

    Maris  Prabhakaran
    Maris Prabhakaran
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    15 valuable Mantras which will crate value for Agile Team .

    These mantras are implemented and created value for the Agile Team

    Mantras for Product Owner

    Mantras for ScrumMaster

    Mantras for Agile Team

    Mantras for Agile Coach

    Learn Global Mantras from the session.

     

     

     

     

     

    10

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

  • Dipesh Pala
    Dipesh Pala
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Once upon a time, Martians and Venusians met, had happy relationships together and accepted their differences to work towards delivering a project. Then came Agile and amnesia set in! ScrumMasters and Product Owners forgot they were from different planets. All of a sudden, Product Owners, ScrumMasters and the team members found themselves sitting around a table discussing user stories and potential solutions.

    This unprecedented access and communication created a whole new set of challenges… Sometimes it feels like our team members are from different planets, as if one is from Mars and the other is from Venus. You may have heard of Mars and Venus in the bedroom but this presentation will be talking about Mars and Venus in the team room.

    Based on my many years of experience in coaching and working with people in these roles, this presentation will describe why and how ScrumMasters and Product Owners react differently to various situations in a team room. The key is in understanding how ScrumMasters and Product Owners think and operate.

    And if ScrumMasters and Product Owners are from different planets, does it make sense for the two roles to be performed by the same person? Or does every Agile team even need both of these roles? Attend this talk to find out!

    This talk will further explore how we can counteract the differences in the communication, the emotional and the business needs of the two roles, and tips and techniques to promote a greater understanding between these two of the most important roles in any Agile team.

  • Liked Karthik V
    keyboard_arrow_down

    Revving up Scrum with Blitz – Collaborative workshop to organize the Epic backlog

    Karthik V
    Karthik V
    schedule 3 years ago
    Sold Out!
    45 mins
    Case Study
    Beginner

    Most features have a lead time before Requirements, Architecture and Epic Backlog is available to the scrum team. There is a misconception that these Sprint zero, or planning Sprints are the way of Scrum but are actually waterfall methods. Also this approach doesn’t essentially lead to team empowerment of the product backlog during sprint execution.

    Blitz – brings in a time boxed intense collaborative approach with involved stakeholders and scrum team agreeing on requirements, architecture, acceptance criteria and product backlog priorities. This is part of the Scrum execution cycle rather than a Sprint 0/Planning exercise.This brings in a parallel and lean approach to expedite a refined development ready product backlog.

    This is an approach executed at various projects to reduce the feature delivery timeline and understand/minimize the unknowns.

  • Liked Sheshadri Shekhar
    keyboard_arrow_down

    Facilitating truly effective "Individuals and Interactions"

    Sheshadri Shekhar
    Sheshadri Shekhar
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    The Agile Manifesto is largely predicated on communication within the project context. Truly effective communication is a function of trust and empathy. 

    This presentation shows the use of a behavioral assessment model in the context of “individuals and interactions”. We first trace the formation of a behavioral-type (or pattern) and then see typical behaviors exhibited by the 15 types identified by the model. We examine the role of behavioral-pattern in creating trust within the team.

    Following this we examine the response of each personality-type to "change". As agile coaches, we have noticed that the response to the change varies from active-support to passive-resistance to active-resistance. We use the DISC model the interpret the reasons for the response.

    Finally, we try to interpret behavior of the "team" using the DISC model.

     

  • Liked Raghavendra S
    keyboard_arrow_down

    Continuous integration and delivery for Better predictability

    Raghavendra S
    Raghavendra S
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    The successes of agile software development lies in delivering the workable unit of application with quality as per accepted sprint timelines and receives feedback on the shipped deliverable and incorporate the changes in the current sprint to ensure greater customer satisfaction and trust. Believing in the fact that catch early and fix issues leads to a greater predictability in software deliverable, it becomes imperative to enable developers with set of tools and accelerators which can be leveraged during development. A well-defined continuous integration and delivery process plays a vital role in enabling project teams to leverage all the tools and accelerators during development and automating the testing processes.

    However, configuring and managing a CI system at an organization level for each project is a cumbersome task. Also, writing build scripts to automate build actions requires considerable scripting expertise and time. A centralized CI platform that can abstract the complexities of configuring, managing a CI workflow along with the build scripts can ensure greater predictability of software delivery at a far lesser time. Such a platform enables automated build definition creation, to execute build application at regular interval with list of validation embedded along with the compile and build operation. The platform intended to deskill the build definition creation, ensure compliance to continuous integration process. The list of validations that could be part of the continuous integration are automated code analysis, unit testing, code coverage, deployment to multiple environments, functional, performance, security testing, etc. and organization specific validations.

  • Liked Jayaprakash P
    keyboard_arrow_down

    Agile doesn't improve quality. Can we release a world class product?

    Jayaprakash P
    Jayaprakash P
    schedule 3 years ago
    Sold Out!
    45 mins
    Tutorial
    Intermediate

    There is a common concern by management that Agile doesn’t make a difference to the product quality. How do we release a product of world class quality?

     Problem is two folded:

    1. 'Definition of Done' is not created with Quality in mind, nor is it measured against the quality set at the beginning of the project.
    2. Quality Goals and subsequent adherence ensures quality is met and not just meeting 'Definition of Done' (DOD) criteria. For example DOD may be met, but quality may still be poor if not managed appropriately. How – lets discuss this through the session.

     Once the quality goals are defined for a project, Definition of Done should align with these quality goals.

    At McAfee, we have released world class quality products through Agile Methodology and Quality Best Practices together. One exceptional method we practice is by defining and tracking "Effective Quality Goals" for each sprint, and at every release.

    By driving agile projects through quality goals, we have products with ZERO defects deferred / logged by customers, 90+% code covered through automated test, 70% defects found early through development practices. This magic was not in just one project, but close to a dozen projects in the last 3-4 quarters.

    In this presentation, we will explain about how we changed the paradigm in the last 2 years and released world class quality products in a short span of time.

  • Liked Pramod Sadalage
    keyboard_arrow_down

    Ten Patterns of Database Refactoring

    Pramod Sadalage
    Pramod Sadalage
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Over the life of an application as requirements change, application usage patterns alter, load and performance changes the need to change database and database architecture is inevitable. There are patterns of these changes such as

    1. 1. Encapsulate Table with View
    2. 2. Migrate method from database
    3. 3. Replace method with views
    4. 4. Introduce Read only table
    5. 5. Split table
    6. 6. Make column non-nullable
    7. 7. Drop column
    8. 8. Add foreign key constaint
    9. 9. Merge columns
    10. 10. Replace columns

    In this talk we will discuss the above database refactoring patterns and different implementation techniques to enable blue, green deployments, allow for legacy applications to work with fast changing database and enable the teams to effectively refactor the database to fulfill the changing needs of the organization.

  • Liked Michael Heydt
    keyboard_arrow_down

    Applying Lean UX to Capital Markets - Lessons From a Year of Lean UX on Wall Street

    Michael Heydt
    Michael Heydt
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    The Lean UX approach to interaction design is a spectacular model for defining and implemented what is needed in appications to support the users in their jobs, as compared to technical deliverables that in the end often do not meet the needs of the users.  In this talk, I will go over strategies for applying lean UX practices to capital markets projects, adapting UX to agile processes, including executing user interviews, rapid UX design, mockups to UI prototypes, and rapid implementation through continuous delivery and end user experience / acceptance testing.

  • Liked Shashank Teotia
    keyboard_arrow_down

    Polyglot Programming and Agile Development

    Shashank Teotia
    Shashank Teotia
    Pramod Sadalage
    Pramod Sadalage
    schedule 3 years ago
    Sold Out!
    45 mins
    Demonstration
    Advanced

    Polyglot Programming as a technique is not new and as a paradigm was coined in 2006 by Neal Ford. In today's world, we often architect solutions which need to be highly scalable, secure, efficient, have an engaging GUI, be extensible with low technical debt in parts or whole. To work with a single tech stack promotes a sense of mono culture which is detrimental and limiting the way a solution can be designed. Moreover, with multi-core machines available, processing now can leverage parallel processing and it maybe make more sense to use a language which takes away the overhead of the intricacies of multi-thread programming.

    In other words, in many cases, engaging in Polyglot Programming helps you focus more on the domain and adds to developer productivity.

    On the flip side, increasing the moving parts also means that if not designed well, Polyglot Programming could be a double edged sword and produce more mess in the way different pieces interact with each other.

    In this talk, we will showcase an ecosystem we built, involving a desktop device configuration backed, an OS-agnostic desktop GUI, a cloud service, a cloud cluster configuration tool and how we used the Agile principles, namely TDD, Continuous Integration and the works to be able to keep the polyglot ecosystem sane.

    Name wise, the languages/tools/etc which we used in our Polyglot case – Google Go, Node-Webkit, JS (Knockout/RequireJS), Ruby, Cucumber, RIAK, Chef, Lisp, Jenkins

     

  • Liked Richard Kasperowski
    keyboard_arrow_down

    Self-management and Self-organization: Agile Games with Motion

    Richard Kasperowski
    Richard Kasperowski
    schedule 3 years ago
    Sold Out!
    45 mins
    Workshop
    Beginner

    Self-management and self-organization are important themes in Agile software development, but what do they actually look like?  We pontificate about worker empowerment, but then we revert to command-and-control: our product owners mandate project scope and deadlines, and our Scrum Masters assign tasks to team members.  Why can’t we let teams be self-organized and workers be self-managed?
     
    These activity-based learning activities are kinesthetic learning games.  Players learn by playing fun, physical games of movement.  These games create a social atmosphere and a full body and mind experience that make it easy and fun to learn.  We’ll play five games, including Line Up, 60 Paces, Triangles, Human Knot, and a special surprise game.
     
    In this session, we explore and experience self-management and self-organization via Agile games.  You will leave with a deep internalized understanding of self-management and self-organization and an appreciation of how they work better than command-and-control.  You’ll be able to share these games with your coworkers.

  • Michael O'Reilly
    Michael O'Reilly
    schedule 3 years ago
    Sold Out!
    45 mins
    Demonstration
    Intermediate

    Test Requirement Driven Development(TREDD) places a renewed emphasis on quality and accountability, and provides the insight to allow your product development and management teams to make the necessary changes in order to produce outstanding quality products on schedule, in a cost-efficient and highly collaborative manner.

    What separates TREDD from other development methodologies like TDD (test driven development), ATDD (acceptance test drive development), or BDD (behavior driven development), is the status of the test requirement when the product development lifecycle concludes.

    Test Requirement status is the breakthrough element that allows test requirement to provide an objective measurement to the quality of the product development team, so that adjustments can be made for subsequent product development iterations that will ensure quality improves, as well as increase the effectiveness of the product development team.

    Come and learn how your TREDD will catalyze your SCRUM team toward greater capabilities, quality, accountability, and satisfaction!

  • Liked Naveen Nanjundappa
    keyboard_arrow_down

    Why not estimate? Think different for story point estimation.

    Naveen Nanjundappa
    Naveen Nanjundappa
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    The Agile Community talks a lot about Estimation and need for it. A large majority have different opinions, but when it comes to teams and organizations that are transforming to Scrum, mostly suffer in group estimation and story point estimation technique. 

    Agile primarily focus on value based deliver and that doesn't need estimation. 

    This presentation enrich those audience who need estimations for their project/product development, with details that make estimates better. At the same time it doesn't advocate estimation as a must have for product development.

    Following 4 aspects will be connected to story point estimation and help audience understand the story-point estimation.

    1. Concept of Accuracy and Precession

    2. Cone of Uncertainty

    3. Story point Estimation scale

    4. Group Estimation and Relative Estimation

    Teams struggle in estimating the product backlog items. Composition of estimation: any estimate is a mix of "the known, unknown and complexity". The presentation shall also connect estimation thoughts to product backlog and the cone of uncertainty

  • Liked Naveen Nanjundappa
    keyboard_arrow_down

    4 Quadrant: Focus Area based Team Retrospective.

    Naveen Nanjundappa
    Naveen Nanjundappa
    schedule 3 years ago
    Sold Out!
    45 mins
    Tutorial
    Intermediate

    The Regular and most popular retrospectives end with action items on the specific person in the team. 

    while the retrospective's primary goal is to enable the team to reflect onto themself and tune their behaviour for becoming more effective. In order to provide such a platform I practiced and coached 4 quadrant, focus area based retrospectives.

    In which the team focus on the over all improvement and not just an action item. this is truely the team's behavioural change and their actions to become more effective. 

    Based on many successful coaching experience, i would like to present this activity based session.

    Summary:

    The team identify the focus areas for improvements, then identifies the small delta improvement in that focus area that is measurable. then they decide on if they need external coaching or internally the team can achieve the goal.

     

    Focus areas | Coaching/Training

    _________________________

    Measurement | Self / team 

  • Liked Johannes Brodwall
    keyboard_arrow_down

    Bare-Knuckle Web Development

    Johannes Brodwall
    Johannes Brodwall
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Can you go faster with less weight?

    We have all learned the benefit of reusing application servers like JBoss, ORMs like NHibernate or dependency injection frameworks like Spring that "solve all the plumbing code for you", but how real are these benefits really? Most developers struggle using techniques like test-driven development and refactoring effectively in their day to day project. Many developers spend a majority of their day finding out which magic incantations will make your framework solve your requirement.

    Yes, frameworks probably will reduce the size of your code base. But will their reduce the time it takes to develop that code base? And perhaps even more pressingly: How certain are your estimates when you know that a the majority of your work is to find out exactly which few lines of code you need to change by debugging, reading documentation and searching for answers on stack overflow?

    When I was first learning math, my dad told me that I didn't to use a calculator before I could do the math without it. In the same tradition, this talk builds on the premise that you shouldn't use a framework that you can't do without: I will create, live, a realistic web application without generators, without frameworks and without bullshit. Instead, I will use test-driven development to ensure steady progress to a solution with no magic.

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

  • Liked Howard Deiner
    keyboard_arrow_down

    Pivoting Your Organization to Become Agile Testers

    Howard Deiner
    Howard Deiner
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    Many organizations struggle with transforming from the old style teams consisting of members with specialized silos of skills into Agile teams consisting of generalized specialists.  This results in sub-optimal Agile adoptions in Agile/Scrum environments, which is where most organizations transforming to Agile are advised to start.

    We will start with a look into the real role of QA in the organization, and where they truly add value in the production of quality code to allow the business to move forward. Piggybacking on the role of QA, we will then speak to exactly what QA needs to do to add value to the software development process, and how they integrate in the DevOps model that is a contemporary solution to an age old issue.  And, finally, we will speak to some uncomfortable truths, and draw conclusions into the skills that Agile Testers must be expected to master to allow the organization to pivot successfully into a truly Agile development group.

  • Liked Arijit Sarbagna
    keyboard_arrow_down

    Quality in Code not in Management Slides

    Arijit Sarbagna
    Arijit Sarbagna
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Advanced

    Agile has always challenged people with the question on how much to design upfront! It doesn't end there, it even flows in the day-to-day work of the developers & the associated Engineering Practises. We do understand the need to have a scalable design, rigid code quality checks - but who is eventually driving these? How are the architects coping with the changing dynamics of development methodolgoy? Are we really driving those practises in reality or are they finding place in management slides only?

    This session is an attempt to project how the practise of architecture is getting mis quoted/mis understood in most of the ongoign Agile projects & what has been the root cause behind them.

    We also try to come to an agreement as what should be the ideal approach towards setting up an Agile Architecture.

  • Liked Tamizhvendan S
    keyboard_arrow_down

    Intellisense for your intimidating data

    Tamizhvendan S
    Tamizhvendan S
    schedule 3 years ago
    Sold Out!
    45 mins
    Demonstration
    Beginner
    A growing trend in both the theory and practice of programming is the interaction between programming and rich information spaces. From databases to web services to the semantic web to cloud-based data, the need to integrate programming with heterogeneous, connected, richly structured, streaming and evolving information sources is ever-increasing.
     
    No matter what technology we use for accessing data, someone, somewhere needs to somehow specify how to map data from the source to a structure that can be used in the programming language.
     
    With F# 3.0 you now have a tool that massively simplifies information-rich analytical programming. F# 3.0 provides integrated support for F# Information Rich Programming, a new and powerful way of integrating data and services into your programming experience.
     
    This talk would demonstrate what F# 3.0 specifically offers in the area of Information Rich Programming (IRP), but also look at how information-richness makes us reconsider programming language and tooling design more generally, and take a look at the themes that recur in this kind of work.
  • Liked Prerna Kale
    keyboard_arrow_down

    Cent Cent Business Value! A Sneak Peek at sprints from evolving design/UI, getting right priorities to delivering $$

    Prerna Kale
    Prerna Kale
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

     

    We want to share experience of working on a complex project, with deadlines set upfront and all players distributed. Perhaps argued as a complex combination to have but yet we were right there, on time enabling the new tool there. Reporting systems often have evaluation cycle that have imperative timelines to start and freeze, hence working for a huge system was not easy. Right agilist mindset with right agile practices helped us meet this. As a Product owner I jostled with eight experts using one system with some variation for their own service lines. We want to show how we leveraged the benefits of distributed teams balanced the challenges, kept the UI flexible enough to accommodate 8 expert reviews, and how our evolving architecture designed a system that had the most used and important features for the users to try hands on..

    Introspecting and sharing how we ensured Cent Cent business Value:

    - Kick off the project with eight stakeholders that got the ball rolling
    - Identifying the 30 % that was core to the business
    - Inspecting, and adapting to constant changes with modular designs
    - Getting stakeholder agree on priorities
    - Release Backlog with stories and design with validated acceptance criteria
    - Managing challenges and ensuring meeting needs seamlessly with truly distributed teams (Distributed PO/Designer/Architect/ Team/ Stakeholders)

    How important is it to dig the core 20-30% in projects with deadline upfront and ways to do that.. Prioritization techniques that enabled mutual agreement on the needs. Backlog with designs that reduced the development time. How work effectively with distributed teams, by building trust, keeping motivation and sharing the definition of done- yes we lived it and did it! We want the audience to explore it all with us and be open to take up and successfully meet the projects with distributed agile teams and tight deadlines yet agile :)

  • Liked Pradeepa Narayanaswamy
    keyboard_arrow_down

    WORKSHOP- Defining Behaviors as a team

    Pradeepa Narayanaswamy
    Pradeepa Narayanaswamy
    schedule 3 years ago
    Sold Out!
    45 mins
    Workshop
    Intermediate

    In lot of agile teams, often times, all the team members will be doing the grooming and planning exercise as a team. Often times, defining the behaviors is either ignored, overlooked, skimped or done by individuals on their own without a common understanding as a team.

    To solve this problem, I have used this hands-on time-boxed activity for all of my teams to define behaviors as they move along in the sprint. This will help all the team members to have a shared understanding on their users and their behaviors as it relates to their user story. This is an activity that any agile team member can take and implement the next day at work.

     

     

  • Liked Pradeepa Narayanaswamy
    keyboard_arrow_down

    Agile Testing- What is my success mantra??

    Pradeepa Narayanaswamy
    Pradeepa Narayanaswamy
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    As more and more organizations are transitioning to agile, it’s inevitable that Agile testing is not just a concept any more. It is also not just about placing a tester in every team. What is so radically different now? How to be successful at agile testing? How to be an effective cross-functional team that embeds and honors all specialties including testing?

    In this presentation, I am going to share my teams’ success with Agile testing and how we incorporated these 3 aspects – people, process and tools/techniques. This talk will benefit any members in an organization who has a stake in the product quality. It is also highly beneficial for those agile testers (from aspiring to veteran) to understand the 3 main aspects as it relates to testing and why we need to embrace- not just one, not two, but all these 3 aspects to be successful in Agile testing. 

     

     

  • 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 Sudipta Lahiri
    keyboard_arrow_down

    Forecasting with confidence

    Sudipta Lahiri
    Sudipta Lahiri
    schedule 3 years ago
    Sold Out!
    45 mins
    Demonstration
    Advanced

    Forecasting has always been a subject of interest to all project management teams. Team have used multiple methods (from detailed MS Project scheduling to Earned Value Management) to try and estimate when a project will finish. People spend a lot of effort to come with one precise hard date knowing fully well how their past predictions have failed, how their assumptions have been invalidated, etc.

    If one were to discuss further with a Project Manager, they will understand that there is a level of confidence that a Project Manager associates with this date.  Perhaps, he is very confident (90% - it is rarely 100%)! It could be even as low as 60-70% depending on the number of issues and risks in the project. In other words, an end date is always associated with a probability, which we in our management talk and presentations, ignore or fail to highlight. In reality, a Project Manager would like to say - I am 70% confident that can deliver this scope of work within the next 3 months but 90% confident that I can deliver this in the next 4 months.

    Kanban systems predict the future by extrapolating current throughput on the present backlog. Most Kanban tools use the CFD for the same. This gives you the gap between the rate at which you need to finish your work versus the rate at which you are finishing work at present. Like MS Project, it also gives one date when this backlog will finish, assuming current throughput.

    Fact is that future is not definitive! Project risks change, requirements change, team resources change... the list goes on! So, just like this inadequate for traditional tools, it is inadequate to limit ourselves to this analysis in the Kanban Method also.

    This session, using Kanban Tool, will demonstrate:

    1. The use of probabilistic theory to have a confidence % associated with a particular delivery date
    2. Once you know the gap between the current throughtput and the desired throughput, what resourcing changes can be done to bridge this gap. While it is understood that resourcing is not the only option to bridge the gap, it is perhaps the most commonly used method. 

    This approach has been vetted by David Anderson and has been presented in the LSSC 2013 conference by one of my colleagues.

  • Liked Tania van Wyk de Vries
    keyboard_arrow_down

    Agile metrix: How do you measure the success of your agile implementation?

    Tania van Wyk de Vries
    Tania van Wyk de Vries
    schedule 3 years ago
    Sold Out!
    45 mins
    Case Study
    Advanced

    Humans are creatures of habit and agile is really challenging that part of our existence everyday. I have seen many teams thinking they now get agile and they take what they learned and just practice it everyday without really reflecting on where they are at or the fact that they are not really moving forward. So in order to say your teams and organisation are really becoming more and more agile everyday you need some metrix to measure against.

     

    The collection of the metrix are 2 fold:

    1. Metrix are tracked through the agile project management tools teams use. We have defined the below set of metrix to interrogate our data to tell us how we doing.
    2. Some of the metrixs are done by getting feedback from teams and clients through surveys.

     

    Some of the metrix include:

    1. Measurement of quality
    2. Measuring customer satisfaction
    3. Measuring team happiness
    4. Measuring continuous improvement in process and technical practices
    5. Measuring time to market
    6. Measuring ROI
    7. Measuring productivity
    8. Measuring overall project progress
    9. Measuring change and improvement