• Liked Vijay Bandaru
    keyboard_arrow_down

    Scrum Master Experience Report

    Vijay Bandaru
    Vijay Bandaru
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    This presentation brings a different perspective for the Scrum Masters and helps them to become more powerful Scrum Masters through their enhanced soft skills. I am going to cover how the teams evaolve, how the change is resisted, how the teams behave, how Scrum Master can handle all these effective to make the teams deliver working software every sprint continuously.

    The information explained below is from my experience as Scrum Master and Coach. Below are the points that will be covered in the presentation:

    Primarily I am planning to cover the anti patterns that will push the teams back and where the Scrum Master can support the teams with his knowledge, experience and interpersonal skills. For example please find below some scenarios:

    1. In effective sprint planning: Team might miss some of the tasks while doing the sprint planning part 2 so they will anyway identify them during the development of the stories so these tasks take additional time which is not budgeted. So they will have to miss some stories which will impact the sprint goal. So I encourage the scrum masters to collect all such unidentified tasks on a separate colr sticky notes and during retrospective discuss with the team to see how much % of the capacity is gone for that tasks. At the same time are there any tasks in that list can be repeatable tasks (Eg: Code review) so this will help the team to come up with a tasks checklist which will help the teams to do effective sprint planning part 2 

    2. Partially ready stories pushed into the sprint: Sometimes product owners push the stories that are not fully ready and the team cannot say "No" in this case either the story gets changes during the sprint or it cannot be finished due to unknown factors. So Scrum Master to encourage the team to have a proper DOR (Definition of Ready) and get a working agreement between the PO and team so that they will work around it whilst they understand "Responding to change over following a plan"

    3. Cross functional behavior: Team generally does not want to become cross functional because they are fine with what they are. Scrum Master has to bring a change in their thought process and get them agreed to become cross functional. For this it takes time so SM has to also manage the management expectations with respect to set the expectation in the dip in productivity

    4. Pale retrospectives: This is another area where Scrum Master has to provide support to teams and get the liveliness and make the teams high performance teams

    5. Timeboxing: Most of the teams do not respect this important guideline. Again SM has to get the importance of this characterstic in to the teams and get them aligned towards this. So there are some examples which I can quote such as if different people arrive at different timings, how much time is wasted and how many times we need to recap on the points already discussed, how much gap created etc

    6. Stop starting and start finishing: This will cover to complete the stories/tasks that you are working before you pick up something. In general the teams pick up many items at a time and complete them close to 100% but not 100% so this will impact the sprint goal. In such case the SM has to provide inputs to the team to pick as few as possible but close them as soon as possible so this way the value delivery at the end of sprint is guaranteed

    7. Lack of importance for quality: In the hurry of completing the stories the team at times give less or no importance to the quality. So the probability of escaped defects or getting rejection for the stories is high. So the Scrum Master has to educate the teams to strictly define/refine/follow the Definition of Done for each story. I saw many teams having their DOD in the tools like VersionOne but not infront of their eyes. 

    8. I know when I see it: Information radiators. This will be the key for the teams to adjust their pace as per the principle #8. So creating big visible information radiators and updating the underlysing details frequently will bring attention in the team and they naturally tend to adjust their delivery mode as per the requirement 

     

  • Liked Ashish Parkhi
    keyboard_arrow_down

    Techniques to Speed Up your Build Pipeline for Faster Feedback.

    Ashish Parkhi
    Ashish Parkhi
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    We would like to share our experience and journey on how we brought down our Jenkins build pipeline time down from over 90 minutes to under 12 minutes. In the process, we would share specific techniques which helped and also some, which logically made sense, but actually did not help. If your team is trying to optimize their build times, then this session might give you some ideas on how to approach the problem.

    Development Impact - For one of our build job, below graph shows how the number of builds in a day have increased over a period of time as the build time has reduced. Frequency of code check-in has increased; Wait time has reduced; failed test case faster to isolate and fix.

    Business Impact - More builds leading to quicker feedback and faster story acceptance and less story spill over.

  • Liked Asheesh Mehdiratta
    keyboard_arrow_down

    Tales of (not so) successful Dev-Ops

    Asheesh Mehdiratta
    Asheesh Mehdiratta
    Debbie Wren
    Debbie Wren
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Advanced

    Welcome to the crazy world of Dev-Ops, where the tales span the spectrum from gruesome, grizzly to the heavenly and flowery bliss!

    The silo’d structures, the agonizing buy v/s build debates, the departmental handoffs, tooling and of course the cultural barriers, which all add fuel to the story unfolding in our brave new dev-ops world. But sometimes there are silver linings and the heavens part way for the shining stars to reveal their true glory.

    Join our session to listen to the tales of our (not so) successful dev-ops, and learn the lessons from our experiences.

  • Liked Ravi Kumar
    keyboard_arrow_down

    Attaining Agile Fluency: Coaching Techniques - Focus on Goals Over Process

    Ravi Kumar
    Ravi Kumar
    schedule 2 years ago
    Sold Out!
    60 mins
    Experience Report
    Advanced

    What is coaching?

    “It is helping to identify the skills and capabilities that are within the person, and enabling them to use them to the best of their ability” — wikipedia

    "Individuals and Interactions over Process and Tools"

    The above is first of the 4 values espoused in the manifesto but yet it is common to see many agile coaches engage with teams and organisations advocating more and more processes. This is a common sight with new teams and also with teams on the path of agile transition from few months to few years irrespective of the competency, skills and maturity of the teams. Agile Fluency model created by Diana Larse and James Shore highlights the focus on value over compliance and practices at any given level

    “ Team fluency depends on more than just the capability of the individuals on the team. It also depends on management structures, relationships, organizational culture, and more. Don’t make the mistake of blaming individuals for low team fluency, or assuming that one highly-skilled individual will guarantee high team fluency ”

    An agile coach responsible for building high performing teams will need right set of powerful tools and techniques to leverage while working with teams and also to set the right expectations to both management and teams. This talk will draw from experience using few such powerful tools mentioned below while coaching teams attain fluency.

    1. Deliberate Practice
    2. Driving Empowerment & Self Organisation: Working Agreements
    3. Scaling Agile Transformation: Creating a Learning Org 
    4. Driving Commitment: Key Measures Highlighting Self Organisation

    This is not a beginner level talk and assumes participants having experience in leading agile teams and transformation initiatives in your respective organisations.

  • Liked Mikael Lundquist
    keyboard_arrow_down

    10 times better quality with agile transformation. How we did it!!!

    Mikael Lundquist
    Mikael Lundquist
    Fredrik Hedlund
    Fredrik Hedlund
    schedule 2 years ago
    Sold Out!
    45 mins
    Experience Report
    Beginner

    Abstract

    In 2011 the Ladok section at ITS had serious quality issues, resulting in dissatisfied customers. At the beginning of 2012 the section started an agile transformation, in steps, throughout the whole section. One year later the whole section had transformed and currently the section now eats, sleeps and breathes Agile. The quality has improved remarkably and our customers are understandably much more satisfied. Besides satisfied customers, our employees are happier.

    The ideas to try agile came from the people working in the project and we think that was an important factor for the success.

    We are going to talk about our experiences of this transformation and how the transformation contributed to the remarkable increase of the quality. The talk will cover the background, our roadmap, the result of the transformation and the factors of success.

    We have identified two key factors of our success that we will promote a little extra during our talk.

     

    Presentation technique

    We are going to perform this presentation in an agile way, in the way we interpret scrum. This means that we are going to interact with the audience and we expect them to influence our presentation.

    The point is to not just talk of how we did, but also show it on stage. We also think that this is a good way for the audience to really get the most out of the presentation.

     

    We want you to prioritize the presentation parts

    We consider the different parts of the presentation as the presentation backlog. We want the audience to prioritize the parts of our presentation, in advance. Prioritize here.

     

  • Liked Karthik Kamal Balasubramaniam
    keyboard_arrow_down

    It's not an Agile story

    Karthik Kamal Balasubramaniam
    Karthik Kamal Balasubramaniam
    schedule 2 years ago
    Sold Out!
    45 mins
    Experience Report
    Beginner

    Having worked with multiple Agile teams, I realize that most problems the teams have to deal with are often related to issues that are beyond the scope of any Agile framework. These issues are often related to people and the surrounding eco-system. The success of any Agile implementation is largely dependent on this H(uman)-factor which is intrinsic to any team/organization. This H-factor has always been a pandora's box, that we would like to avoid owing to  the amount of complexity and the uncertainty involved.

    Here is my humble effort to try and identify few common traits that I have observed with people across Agile teams and organizations. The idea here is not to stereotype people, but to present an approach/strategy to accommodate different kinds of people in an Agile eco-system.

    In this talk, I would like to present 5 characters in a fictional story and the various strategies I have adopted to coach them.

    After all one size doesn't fit all!

  • Liked Gautam Rege
    keyboard_arrow_down

    Don't test your code!

    Gautam Rege
    Gautam Rege
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    Testing is overated. Let's correct that statement - "Manual Testing is overrated". In this this talk, I plan to take you on whirlwind tour of why an Agile outfit does not need manual testing at all and how to get fantastic Quality Assurance without manual testing.

    In this talk - I outline a agile process with a difference - everyone is a developer and a tester. However, there is no dedicated QA people. In fact, this process does not require anyone other than the developers and one process/product owner.

    Development using a central repository like Github that is integrated with a Continuous Integration service (like Travis, CircleCI or Semaphore) and further integrated with a Code Quality checker like Code Climate or Pull Review is part of the automation trick. Then comes the development processes like pull request between branches (enabling peer code review) and Automated Deployment to a staging server.

    Finally, the pixel perfection or meeting product specificaiton via Project Management tools (which are integrated with the Code repository) gives the product owner (or the client) complete confidence in not just the functionality but also the quality of the code. 

    This approach can be applied to evolving products too and I discuss how to work in short sprints that always keep changing and guarantee that "The product owner gets the money's worth and the development team gets their works worth!".

     

  • Liked Tathagat Varma
    keyboard_arrow_down

    From Waterfall to Weekly Releases: A Case Study in using Evo and Kanban

    Tathagat Varma
    Tathagat Varma
    schedule 2 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    In 2003, we had a major problem to solve - our products had far too many open field defects, and the bug arrival rate was moe than the closure rate. We tried to fix using our process which involved shipping quarterly service packs, but that was not only elongating the lead time, it was also not very amenable to changes. The process for customer specials (specific features, etc.) was not any better, and invariably it led to exec-level escalations just to get some deal-blocking customer escalations into the service packs mid-way in the quarter.

    In 2004-05, we experimented with a pull system that limited the work in progress and created a more smoother flow of value. The result of this system was that we were able to significantly reduce the defect backlog, and were able to bring down cadence of features and bugs to a weekly cadence. The experiment was so successful that in about 6 quarters, we had fixed most of the field defects (brought down individual product's defect backlog to single digit) and we had to disband the team as there was no work left for them!

    We were inspired by Tom Gilb's "Evo" method and experimented with it to create a weekly cadence. However, we found that the nature of field defects and customer specials was stochastic in nature and didn't lend itself very well to a timeboxed framework like scrum. However, there were no off-the-shelf methods available back then that were a viable alternative. Hence, we experimented with various methods and blended-in elements form various methods to create out our very first kanban by limiting work in progress.

    In this talk, I will explain our first kanban experiment, and also compare and contrast with the later-day Lean Kanban by David Anderson.

  • Liked Niranjan N V
    keyboard_arrow_down

    Mr.Agile Leader - “ Develop People or Solutions”

    Niranjan N V
    Niranjan N V
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Based on my experience of coaching/ training agile teams for 5 years, one of the important reasons for agile teams are impacted, is the personal leadership style of Agile Leaders(Scrum Master, Senior Managers etc) . I have summarized following, factors or impediments for creating effective agile teams

    • The agile teams effectiveness depends on personal leadership style of agile leaders(Scrum Masters, Senior Management etc)
    • Often Agile leaders focus more on “delivering solutions” than “developing people”.
    • Agile leader need not specify work requirements, all that team needs is - empowerment, autonomy to work.
    • The agile team needs more support through mentoring, coaching from agile leaders to exhibit the culture “Being Agile” than “Doing Agile”.
    • Agile leaders need not be an Expert to coach agile teams.
    • Agile teams needs to be taught on Identifying Problem, Problem solving skills and corrective actions and demonstrate steady, small and continuous improvement.

     

    My inspiration to write here, is derived from the book “ Managing Excellence” by David Bradford and Allan Cohen, and reading blogs, articles along with my own experience.

     

    The entire presentation will be done in “Pecha Kucha Style” with less words and more background pictures, in each slide. The most of the message is conveyed through pictures. The presenter will talk maximum 30 secs on each slide. The slides keep changing automatically after 30 secs, so that presenter continues the discussion in the next slide automatically

  • Liked Biplab Roy
    keyboard_arrow_down

    Assembly Like SDLC Based on Agile Practices - with Experience Report

    Biplab Roy
    Biplab Roy
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Considering today’s dynamic business environment, where solutions are expected as quickly as possible, adopting only few Agile practices may not help the business in a significant way. This situation becomes further complicated where user experience matters most. From software service Organization perspective, it is further complicated where one has to consider few more parameters like Customer Collaboration (& time), Contracting approach, Domain level standards, Development maturity Standards, etc. Also as usual, productivity loss in transitioning work product from one resource to another. 

    A small step in resolving these pain areas and strike a balance between various needs & constraints, at Altimetrik, we have devised a SDLC framework – based on the concept Unified Resource and various best practices from Agile, Waterfall, Prototype driven development, Assembly approach etc.

    We have been using this approach for our various customer projects and have seen significant benefits.

    In this experience report, we will discuss about the various pain areas of existing development models and how they are overcomed through this customised SDLC framework for some of our clients. 

  • Liked DEBASHIS BANERJEE
    keyboard_arrow_down

    Agilists - Detect, Protect and Celebrate IP Created During Sprints

    DEBASHIS BANERJEE
    DEBASHIS BANERJEE
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

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

Sorry, no proposals found under this section.