• Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    As more and more companies are moving to the Cloud, they want their latest, greatest software features to be available to their users as quickly as they are built. However there are several issues blocking them from moving ahead.

    One key issue is the massive amount of time it takes for someone to certify that the new feature is indeed working as expected and also to assure that the rest of the features will continuing to work. In spite of this long waiting cycle, we still cannot assure that our software will not have any issues. In fact, many times our assumptions about the user's needs or behavior might itself be wrong. But this long testing cycle only helps us validate that our assumptions works as assumed.

    How can we break out of this rut & get thin slices of our features in front of our users to validate our assumptions early?

    Most software organizations today suffer from what I call, the "Inverted Testing Pyramid" problem. They spend maximum time and effort manually checking software. Some invest in automation, but mostly building slow, complex, fragile end-to-end GUI test. Very little effort is spent on building a solid foundation of unit & acceptance tests.

    This over-investment in end-to-end tests is a slippery slope. Once you start on this path, you end up investing even more time & effort on testing which gives you diminishing returns.

    In this session Naresh Jain will explain the key misconceptions that has lead to the inverted testing pyramid approach being massively adopted, main drawbacks of this approach and how to turn your organization around to get the right testing pyramid.

  • Dave Snowden
    Dave Snowden
    schedule 2 years ago
    Sold Out!
    60 mins
    Keynote
    Intermediate

    In order to successful scale any method or practice, it has to have some basis in theory. This presentation will use insights from complex adaptive systems theory and the cognitive sciences to lay a foundation for that theory. Seeing software development as a problem of knowledge management, the theory will elaborate a understanding of applications as the emergent property of a co-evolutionary interactions between technology capability and unarticulated user requirements.

    Having established a basic theory a range of methods and tools will be elaborated. These include:

    - Narrative based approaches to requirements capture (not to be confused with Story telling or story boarding) which gather thousands of fragmented self-signified anecdotes relating to real and imagined needs within a user community and allow interpretation and integration into project planning.

    - Approaches to project planning and implementation that focus on the creation of self-organising teams of specialists and users to create novel approaches, supported by evidence to previously intractable problems. This is particularly relevant to the 5-10% of any major project which creates 95-90% of the grief.

    - The integration of tools such as blogs, wiki's etc into the development environment. Too often corporate environments over-constrain those tools into over rigid structures which destroy their utility.

  • Jeff Patton
    Jeff Patton
    schedule 2 years ago
    Sold Out!
    60 mins
    Keynote
    Intermediate

    How organizations are learning to value learning and not just velocity!

    We all hate wasting time and money.  In the pursuit of cutting out waste, we've learned to systemically fool ourselves – to convince ourselves with very little evidence that the activities we're engaged in add value.  And, further, activities that don't result in a product we can deliver are waste.  But, the biggest leap of faith I continue to see most companies make is in believing that people want their new product, feature, or idea.  They likely don't.

    This talk is about the rise of learning as a valuable activity.  I'll give examples of organizations that invest in experiments that take the cooperation of developers, testers, product mangers, infrastructure, sales, and marketing.  At the end of these experiments organizations are left with no deliverable product and only the knowledge that the product they're thinking of should or shouldn't be built at all. 

  • Liked Tathagat Varma
    keyboard_arrow_down

    Design Thinking

    Tathagat Varma
    Tathagat Varma
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    An intro to design thinking ideas...

  • Liked Naresh Jain
    keyboard_arrow_down

    IAmA (I Am A ... Ask Me Anything)

    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    60 mins
    Keynote
    Beginner

    On Reddit, IAmA stands for "I am a" and AMA stands for "ask me anything".

    In an IAmA post, a person will post what they are, and other people will ask the original poster some questions to gain insights about the experience the person has had.
     
    Ex: I'm Jeff Patton, creator of Story Mapping, Ask Me Anything... OR I'm Diana Larsen, co-creator of the Fluency Model and co-author of Agile Retrospectives, Ask Me Anything...

    We plan to take this concept and apply it to the Agile context. We've few luminaries at the conference and we plan to do an live interview with them using this format.

  • Dave Snowden
    Dave Snowden
    schedule 2 years ago
    Sold Out!
    960 mins
    Workshop
    Advanced

    Make better decisions

    Learn to engage with the unanticipated for strategic advantage. For leaders, consultants and project managers.

    How to manage uncertainty in increasingly complex environments?

    The ability to manage and navigate complexity is a key strategic advantage. However, many organizations are trapped in past practices and structures. Breaking through such inertia requires praxis - theory informed practice.

    The Cynefin framework, and its application in managing complexity is at the heart of this training program.

    The Academy of Management awarded the Harvard Business Review article, Cynefin & Leadership, the "Best Practitioner Paper". Their citation reads:

    "This paper introduces an important new perspective that has enormous future value, and does so in a clear way that shows it can be used. The article makes several significant contributions. First, and most importantly, it introduces complexity science to guide managers’ thoughts and actions. Second, it applies this perspective to advance a typology of contexts to help leaders to sort out the wide variety of situations in which they must lead decisions. Third, it advises leaders concerning what actions they should take in response"

    Cognitive Edge has developed a modular training program that allows participants to understand the theory of complexity and how to put it to practice.

    Crucial new knowledge for:

    • Project management
    • Change management
    • Innovation and development
    • Risk and crisis management
    • Shaping culture
    • Safety management
    • Knowledge management
  • Liked Krishnamurty VG Pammi
    keyboard_arrow_down

    6 X 2 Planning Errors in Scaled Agile Delivery Model

    Krishnamurty VG Pammi
    Krishnamurty VG Pammi
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    2 major errors across 6 agile planning events give us 12. Learning “what not to do”, can sometimes help us identify risks early in the cycle so that, as a team, we can effectively respond to these risks.

    Agile planning happens at multiple levels. In scaled agile delivery model, effective outcome of one planning event can influence the other significantly either positively or negatively.

    Come and learn top 12 experiential insights. These will help you alert your teams on “what not to do” during Scaled Agile Planning events. I tried capturing top 12 errors across 6 planning events namely Strategy Planning, Portfolio Planning, Product Planning, Release Planning, Iteration Planning and Daily Planning.

  • Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    90 mins
    Tutorial
    Intermediate

    In order to achieve my goals, as a buyer of your product, I want awesome feature.

    AT: make sure your users stories don't get in the way.

    Users Stories, the tool teams use to break big ideas into small demonstrable deliverable, are easy to describe and challenging to write effectively. In this hands-on workshop you'll learn how to write great user stories that adhere to the INVEST principle. We'll learn various techniques to slice your stories using the vertical-slicing approach. We will discuss what elements should be included in the stories, what criteria you should keep in mind while slicing stories; why the size of your user story is important and how to make them smaller and efficient.

  • 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 Ankur Sambhar
    keyboard_arrow_down

    Promiscuous Pairing - More the merrier !!!

    Ankur Sambhar
    Ankur Sambhar
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    Being Agile developer, have tried & tested various flavors of pair programming over the years while working in highly motivated self-managed team. Some experiments worked while some worked better :)

    This talk is about sharing the personal experience of practicing promiscuous pairing which allowed the team to be always in the beginner's mind state and being able to push the boundaries consistently.

    This experience sharing talk is based on our successful adoption of the promiscuous pairing technique based on very famous research paper by Arlo Belshee "Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience".

  • Sriram Narayan
    Sriram Narayan
    schedule 2 years ago
    Sold Out!
    45 mins
    Talk
    Advanced

    Good engineering practices and fail-fast, iterative, low-ceremony processes help achieve team level agility. They are necessary but not sufficient to scale agility across the IT organization. In this talk, I'll address what else is needed and why. In particular, I'll address:

    1. Why plan-driven IT projects are a bad idea why we need value-driven projects instead
    2. Why a matrix org is a bad idea for IT and why we need cross-functional teams instead
    3. Why IT budgeting needs to change from being project-based to being team-capacity based
  • Liked Vivek Ganesan
    keyboard_arrow_down

    Congratulations! You are our startup's first Scrum Master! What's next?

    Vivek Ganesan
    Vivek Ganesan
    schedule 2 years ago
    Sold Out!
    60 mins
    Tutorial
    Intermediate

    Do you fancy playing the first Scrum Master of a startup?

    Do you want to live the challenges faced by the first Scrum Master of a startup?  Do you feel that your organization is dramatically different from the 'ideal' organizations, which the Agile workshops project as a basic requirement for doing Agile development?  Do you wish to deliver predictable results while your management is on-the-way to make your organization 'Agile-ready'?  This tutorial is just what you want.

    In this tutorial, you will experience the life of a first Scrum Master of a twenty member startup, which has expansion plans.  Each of the audience will put themselves in the Scrum Master's shoes and try to solve the challenges posed by the ever-changing environment, while the company's management is putting its best efforts to make the organization 'Agile-ready'.  In this interactive tutorial, a gripping story-line will drag you into the world of uncertainties where you would be challenged to take life-changing decisions regarding your product team's daily work.

    Even if you are not in a startup, this tutorial would benefit you because everyone still comes across ad-hoc situations which go against the ideal expectations of Agile world.

  • Liked Prasad Kunte
    keyboard_arrow_down

    Implementing Agile Engineering Practices in Legacy Codebases

    Prasad Kunte
    Prasad Kunte
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    Afraid of legacy code? Don't be!!!

    Most successful product companies are confronted with the problem of legacy code.

    What is a legacy code?

    • A code which is in production for several years.
    • A super-complex, hard to understand code base, written by different set of developers. 
    • Outdated Technology stack.

    But the most hurting reality is:

    Lack of confidence in the code due to zero or poor test coverage.

    Due to this reality, developers are often scared to touch it. They have very little confidence that "their code change wouldn't break the existing application in production."

    Recently at IDeaS, we came across such situation, where we needed to enhance one of our products containing legacy code. We started looking into the code and soon figured out that it was developed in 2007, hardly ever touched (& still working in production :)). The original team, which has worked on this product, could not be traced anymore.

    As this product has expanded to attract new customers, we had to change it significantly in order to support new customer's specifications. We had to make sure that the product was backward compatible and supported the earlier specifications, while we enhance the new specification.

    One simple option was to COPY PASTE every single method which needs to be modified and use an if-statement to decide which method to call. This certainly seems like an easy method, since the chances of breaking existing code is very little. 

    Today we all know this is a BAD option!!!

    Instead, our team decided to refactor the existing code to support plug-and-play approach for different specification. But before we started refactoring code, we had to build a safety net of tests around the existing code.

    How do we put the safety net? Ideal way would be to implement the Test Pyramid first. But, that would have taken significant time to be ready with the pyramid before we start touching the legacy code. And obvious, we would have missed the business goals.

    What do we do?

    Instead of building the entire test pyramid, we decided to attack different layers of the test pyramid, one at a time. Along the way, we followed the following approach:

    1. Re-structuring the Project code-base
    2. Establishing a baseline database: After taking a dump from the production database, we cleared out surplus data from the DB and setup a seed database with automed scripts
    3. Creating/fixing the build script 
      1. Setting up an auto DB deploy tool and integrating it with build scripts
    4. Set up basic CI pipeline
    5. Write a few work-flow tests to capture the system's flow from user's point of view
      1. Find the inception point in the code from where we can exercise the code
      2. Restify the application at the inception point (one service at a time)
      3. Setup authorization for production and test environment
      4. Build minimal test-data set for different environment 
      5. Create a few work-flow tests via the inception point (Test itself should not be coupled with the underlying database or implementation level components)
    6. Write business logic acceptance test to capture various complicated business rules
    7. Test drive the new enhancement or bug fixes
    8. Every time we touch legacy code, refactor the code and improve test coverage at unit level

    This really helped us test driven the new code and implement all the layers of the test pyramid.

    If you've a similar situation, join us, as we share our experience on how to confront legacy code.

  • Sachin Natu
    Sachin Natu
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    60 mins
    Case Study
    Intermediate

    Adopting agile development practices and continuous delivery is becoming a norm in the software industry. Time to market and frequent releases have drastically reduced time available for regression testing. Inspection is considered wasteful. Faster feedback cycles during development is crucial. These have created lot of challenges for testing community, which traditionally relies on manual testing assisted by UI based test automation.

    This is an experience report of transforming testing practices across organization, which decided to embrace Agile. Today our testers are not trying to find defects, instead they collaborate with product management and developers to prevent them in the first place. In fact, during the appraisal process, the defects found by them is ignored, instead we focus on how much time they are able to dedicate to collaboration and exploratory testing. The boundaries between developers and testers have faded away and today quality is whole team's responsibility.

    We started with less than 20% of our testers with automation skills (mostly UI automation) and rest of them relying on manual testing. However, today, all our testers practice BDD. They have picked up Java & Groovy programming skills. They are able to contribute Workflow tests, Integration tests and Business Logic Acceptance Tests. Early collaboration and pairing is the norm. By the time developers are done with their tasks, all checks are already automated and hence we are able to deploy software every fortnight to production.

    Are your testers finding it hard to make this transition to an Agile mindset? This session will give you some concrete ideas based on our transition at IDeaS.  

  • Liked Pooja Uppalapati
    keyboard_arrow_down

    Scaling Agile in a Mainframe Product Development Organization

    Pooja Uppalapati
    Pooja Uppalapati
    Ravindra Chebiyam
    Ravindra Chebiyam
    schedule 2 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Agile transformation in any organization will go through myriad of challenges that involves people, existing organization culture, technology/domain etc. Instead of seeing these challenges as obstacles, if you view them as opportunities to grow and improve, transformation will be more impactful and long-lasting. If neglected, the very same obstacles would severely damage the motivation and trust of employees.

    In this experience report we would like to walk you through the agile transformation journey in a Mainframe product development enterprise by unraveling the challenges and the remediation steps that has helped us in keeping this journey alive. Specifically we would like to touch upon 

    1. Self-organizing teams
      • Resistance to change
      • Culture shift
    2. HR
      • Lack of role clarity and
      • Effective R&R in agile space
    3. Agile Engineering Practices adopted in Mainframe product development
      • Unit test automation
      • Continuous Integration

    Along the presentation we’ll highlight few anti-patterns and the effects of ignoring them.

  • ShriKant Vashishtha
    ShriKant Vashishtha
    schedule 2 years ago
    Sold Out!
    60 mins
    Talk
    Intermediate

    Way back in 2008, when I started working in Agile, there was enough material available on Scrum and. However when it came to distributed aspect of it, people were still struggling with it. Based on working for years in this fashion, I realised that communication, trust, transparency and innovation are the core fundamental values towards successful distributed Agile implementation.

    In other words, as most of the problems were caused by softer aspects of skills (misunderstanding, miscommunication, non-availability of people, mistrust etc), humanizing the distributed team experience looked like the key for successful distributed Agile implementation.

    Based on working with distributed teams over the years, we discovered some distributed Agile patterns. Some of them got blogged from time to time. Those already available in form of blogs are as follows:

    The session is to share the these patterns and more (when to go for distributed Agile and when not etc)

  • Liked Madhavi Ledalla
    keyboard_arrow_down

    Deep dive into RETROSPECTIVES- how do we break the usual norms so that these reflections could be made thought-provoking ones!

    Madhavi Ledalla
    Madhavi Ledalla
    Jerry Rajamoney
    Jerry Rajamoney
    schedule 2 years ago
    Sold Out!
    60 mins
    Workshop
    Intermediate

             Retrospectives are the primary learning, reflection and readjustment techniques on agile projects. A good Agile team is always striving to become better than before. And an effective retrospective enables the team to sieze its opportunity to improve! 

    Retrospectives enable whole-team learning, act as catalysts for change, and generate action.

    R-> Realize where you are and where you want to be

    E-> Engage the teams in fruitful discussions

    T-> Team work to build “We over I” attitude

    R-> Relish the power of Inspect and Adapt cycles

    O->Openness and Transparency to make retrospectives efficient and effective

    In my view, this is not any new concept or a jargon the team needs to really master, but yes in reality sometimes it becomes challenging to keep the momentum lively all times! Over a period of time, we see these symptoms in a retrospective. 

    R-> Repeated issues pop-up

    E-> Engrossing & Engaging discussions are missing

    T-> Team present virtually, loses trust.

    R-> Routine stuff, nothing interests the teams.

    O->Observably gets boring over time.

    To catalyse conversations among team members, retrospectives need to be viewed from a different perspective. This presentaion talks about why the retrospectives efficacy fades off over a period of time and then talks about some very interesting techniques that I used with the teams to make these meetings lively!  Teams need to do out-of-box thinking and appreciate that these short gatherings need not  be done only by using the techniques or methods prescribed in the book but could be done by quoting some situational specific examples that would make the teams really think and speak!

     

  • Liked Vinod Kumaar R
    keyboard_arrow_down

    Build it like sports teams

    Vinod Kumaar R
    Vinod Kumaar R
    schedule 2 years ago
    Sold Out!
    20 mins
    Talk
    Intermediate

    Is it easy to get a crash course in football by Pele or Maradona for a week and produce a world cup winning football team?

    Answer is NO. Then why do lots of people in the corporate world think of hiring scrum trainers & expert developers to train their team for a week and then expect their team to undergo a transformation at a magical scale?

    German football team made it a point to transform their team and it took them a lots of years before they were able to reach the pinnacle. A quick side by side comparison of what is causing agile transformation to fail.

    Vision

    Football: Someone was there owning this entire transformation, the German football association spent a lot of time identifying talent in their teens and groomed them.

    Office: In the corporate world switching jobs every few years have become common, but there is no passing on of the context, resulting in the new person taking charge, starting from all over again, as well as frustrating existing good performers who have to rebuild the perception.

    Infrastructure

    Football: Players expecting state of the art training facilities, fitness programs and new shoes are not a luxury, it is a necessity.

    Office: Computers have become so cheap compared to the salaries, yet the policy of providing the best tools and good work environment are archaic.

    Coach vs Management

    Football: Coaches are given their due powers to help the team achieve the goal. It is very easy for anyone to comment on how professionals should play their game, there would be no use adhering to the metrics if the team cannot win. Winning is the only measure for management.

    Office: Often coaches are seen as part of the management or management tries to heavily influence coaching which results in a team which will work either for metrics or to please higher ups without the actual result that it had aimed for.

    Training

    Football: Just the ability to kick the ball does not make a footballer. Training will be introduced to increase physical strength & stamina, better mental wellness, injury prevention, tactics and strategy.  A heavy investment is made in the training facilities.

    Office: In the software industry a generation is about 2-3 years. Computer science degrees are nowhere near what is state of the art in the industry. At many places the on boarding process is either very shallow or not up to date with the recent developments, leaving people to learn most of the things hard way. Given too many things to learn and the information overload, this results in inefficient learning and application of knowledge on the job. We need to prepare people to find answers that are not available on Google.

    Team composition

    Football: Rookies don’t learn by watching greats from the bench, instead they play along with the veterans. Every sports team makes sure to have the right composition with a mix of rookies, emerging players and veterans. That is how they sustain a winning team.

    Office: Architects and Leads often do not code or are not part of the team every day, this means that most of the time the team just looks up to for advice or waits for reviews. There should be a good mix of people at all experience level so that there are enough people to try new things, enough people who have mastered few things and enough people who challenge change.

    Above all – Persistence

  • Pradeepa Narayanaswamy
    Pradeepa Narayanaswamy
    schedule 2 years ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    In agile teams, it’s inevitable that team members are expected to be more cross-functional and produce high quality products for their customers. How can agile team members become more cross-functional and take ownership of quality? Often times there seems to be a scarcity of testing talents in agile teams. How can agile teams create high quality products when working with very few or no testing talents?

    For agile team members to take ownership of quality, Pradeepa Narayanaswamy exposes the power of “Pair Testing”, a technique that promotes rapid feedback to produce high quality products. For the scarce testing talents, an effective way to become more cross-functional, one approach is for team members to pair up on various (unit, integration, exploratory and several others) testing efforts that emphasize the shared eye on quality and learning. Pradeepa talks about several options for pairing opportunities between various specialties on an agile team. She also talks about some new opportunities to pair with DevOps, Operations, Sales, Marketing and Support members to name a few.

    As a new or an experienced agile team member, learn how to spearhead this technique in your team at various levels to generate buzz on other teams. As a tester, learn how to get the non-testing talents excited and experience the value of pair testing. 

    This session includes a fun Pairing activity and a Group discussion. 

  • Liked Ashish Parkhi
    keyboard_arrow_down

    Gamifying Agile Adoption - An Experiment

    Ashish Parkhi
    Ashish Parkhi
    Naresh Jain
    Naresh Jain
    schedule 2 years ago
    Sold Out!
    45 mins
    Case Study
    Intermediate

    While having a chat with Naresh Jain, he suggested me to go through the Ted Talk – “Gaming can make a better world” by Jane McGonigal. I found the title very weird and was wondering how is that possible? After going through the talk though, I was amazed. I started wondering if I can use the gamification technique in Agile Adoption, in our Products, in Performance Management Systems, in Employee Engagement Programs?

    Dhaval Dalal introduced me to Prof. Kevin Werbach’s definition of Gamification – “The use of game elements and game design techniques in non-game contexts.

    For our 4th ShipIt Day, organized on 25th/26th Sept 2014 at IDeaS, I decided to explore the idea of using game elements and game design techniques in the context of Agile Adoption. The idea was to create a gaming system which will automatically collect data, i.e. without explicit user intervention,  from multiple sources like Jenkins, Rally and manually from individuals and offer Star’s for positive behavior and deduct Star’s otherwise.

    The aim was to help the team get continuous visual feedback on how they are doing, adopt agile practices, visualize sense of accountability, visualize sense of achievement, drive positive behavior, create healthy competition, create a culture of appreciation, help performance tracking and create transparency.

     

    Landing Page

    User Profile

     

     

     Update - 

    1. Deducting points seems to be bothering the individuals. Now we are experimenting with getting rid of negative points and introducing short lived badeges instead e.g. "Build Breaker". 
    2. We have now added more badges to recognize individual efforts in various categories.
    3. Working on open sourcing the core app at https://github.com/IDeaSCo/rockstar