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

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

 

 
12 favorite thumb_down thumb_up 7 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  1. Overview of agile metrix used: demonstration of the metric
  2. Demonstration of the metrix applied with some real data to the audience
  3. Break into smaller groups and workshop some additional metrix that people have used successfully within teams
  4. This will be shared back from the groups with the wider audience
  5. Integrating this back to the initial demonstration

A trial run will be done at a local SA conference by the end of this year. Slides and video will be shared then.

Learning Outcome

Taking the techniques, examples and tools demonstrated and learned during this session to start measuring the success of your organisation in adopting agile.

To make sure that you keep yourself honest in continuously improving, moving forward and maturing in your agile adoption.

Making progress in your organisation transparent and visible against a set of defined measurements.

Moving your organisation to the next level of excellence using the feedback from these metrix to continuously improve.

Target Audience

Managers, agile coaches, CIO, CEO, Product Owners, Scrum Masters

schedule Submitted 4 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • AgileSattva Consulting LLP
    By AgileSattva Consulting LLP  ~  1 year ago
    reply Reply

    Need of the day for agile teams is "metrics".. would like to know if you would cover on how to capture the above mentioned few metrics? Is it through questionaire that you like to capture? Could you please share details on the metrics and their ways of capturing it?

    Would also like to know if the metrics you are mentioning is "framework agnositc" for agile teams? (not dependent on whether its scrum/kanban/etc)

  • Joel Tosi
    By Joel Tosi  ~  4 years ago
    reply Reply

    Hi Tania,

       Congrats on having your submission accepted.  How can I best serve you and your session?  Would you like me to review any material with you, do a practice session, anything like that?  I am more than happy to assist.

     

    Best,

    Joel

  • Naresh Jain
    By Naresh Jain  ~  4 years ago
    reply Reply

    Hi Tania, this is an important proposal. However at this stage we won't be able to accept a 90 mins proposal. Would you consider doing this as a 45 mins case-study, where you share your real experience from one or more projects?

    Also we don't see any slides or videos, this is very important for us to evaluate the quality of your presentation style. Would request you to update the proposal to add slides and/or video. You can add slides or videos from any other talk.

    Thanks. 

    • Arijit Sarbagna
      By Arijit Sarbagna  ~  4 years ago
      reply Reply

      Hi Tania,

      If we are talking about Metrices - whereas traditionally Agile has been relying mostly on Burndown (& some Burnups), how do you wish to keep the audience engaged for 90 minutes? Doesn't this appear bit stretched to cover reports/staistics? Looking forward to your thoughts on this.

      • Tania van Wyk de Vries
        By Tania van Wyk de Vries  ~  4 years ago
        reply Reply

        Hi Arijit,

        If you look at the reply I made to Pradeep, there is quite a number of metrics I was hoping to cover. So it is not only burndown, burnup related. It is actually measuring the Agile enterprise adoption, so it goes beyond just focusing on the simple 'in-sprint' measurements.

        The format of the session was explained in my proposal.

        So 30-40 mins will be going through some metrics and examples.

        20-30 mins of the audience breaking up into groups to discuss further measurements 

        and then 30 mins of each group giving their feedback to the rest of the session.

        In my experience with these type of sessions, this can be a tight timeline rather than not knowing what to do with the time.

        Hope that clarifies this a bit more.

    • pradeep panda
      By pradeep panda  ~  4 years ago
      reply Reply

      Hi Tania,

                  As this topic is in "beyond agile" track, you are obviously not talking about story points and velocity concept.  Is not it, correct me if I am wrong. And is this metrix only for the team for their improvement or through these metrixes does the management of the organization get a picture of the overall execution status? Can you provide a small paragraph on the metrixes you have mentioned? 

      regards

      Pradeep

      • Tania van Wyk de Vries
        By Tania van Wyk de Vries  ~  4 years ago
        reply Reply

        Hi Pradeep,

         

        It is not only focusing on story points and velocity. It is covering the following measurements

        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

        I am happy to 'classify' this as another type of track. This is where your guidenance will be appreciated.


    • Liked Bernd Schiffer
      keyboard_arrow_down

      Bernd Schiffer - Net Promoter System for Agile Companies

      45 mins
      Talk
      Intermediate

      Customer collaboration is essential to every Agile business. To create and collaborate to keep a customer is the purpose of an organisation. But still lots of companies try to make bad profits, i.e. profits earned at the expense of customer relationships. The Net Promoter System (NPS) is a renowned open-source system which addresses and measures customer collaboration. And did you know that you not only can use it to get feedback on your products and services, but also on your employees and your personal performance?

      NPS is a perfect fit for Agile companies - and those who want to be. Most of the companies I worked with (Agile coaching, training, consulting) had not heard about it, and far less were actually using it. This really surprises me, since NPS integrates like a charm with Agile, e.g. within product development via Scrum.

      In this session I'll explain the basics of NPS, i.e. promoters and detractors, satisfied and delighted customers, bad profits (how to deal with bad feedback?) and good profits, and why and how to measure these. Several stories from companies like Apple Retail, Zappos, Southwest Airlines, and others will help to make my point. I’ll further show why NPS is a very good fit with Agile regarding products, employees, and personal performance. Dos and Don’ts regarding NPS (also from personal experience) will close this session. Related to the Don'ts, I also cover some of the negative critiques out there.

    • Liked Victoria Schiffer
      keyboard_arrow_down

      Victoria Schiffer - Agile Coaching? Sure thing! What about Life Coaching in Agile Thinking?

      Victoria Schiffer
      Victoria Schiffer
      Agile Coach
      SEEK
      schedule 4 years ago
      Sold Out!
      45 mins
      Talk
      Beginner

      I love being around awesome people, who build great products customers desire. 
      I love learning from and together with these amazing minds. 
      I love creating the right environment for teams to flourish. 
      I love change, and learning from new experiences. 
      I love working in Agile environments.

      How about you? 
      I bet there are some elements of this list why you're in Agile, too. And you can probably add even more elements to it.

      The Agile Manifesto states amongst others individuals and interactions, customer collaboration and responding to change.

      In our everyday life doing Agile we already respect these aspects in many ways. 
      But do we practice what we preach as best we can?

      I'd like to challenge your current way of thinking about people and processes. 
      I'd like to challenge you to focus on you, before you focus on others. 
      I'd like to challenge your current way of reflecting. 
      I'd like to inspire you to go different ways. 
      I'd like to inspire you to inspire others.

      In Agile we're already good in improving our processes and creating well performing teams and hence building the right things in the right way. And in the Agile Manifesto's communication and collaboration piece we can even get better.
      "You have not yet reached the limit of what you're capable of!" means we can always further improve. And we do follow this idea in our Agile processes, too, through continuous feedback (Retrospectives) and improvement.

      And why not take it even further? Why not go "Beyond Agile"?!

      Here's where aspects of Life Coaching come in handy: through also understanding and improving ourselves (how do we interact with people due to how we perceive our environment) we will even further improve communication and collaboration.

      Life Coaches believe our clients know the answer. And even if Agile Coaching is slightly different than Life Coaching, I see it as very relevant in Agile Coaching, too. If we apply this in Agile, instead of giving our clients (team, colleagues) the answers, asking them powerful questions to help them be more aware of what's happening at the moment, they will find their answer for it and will have a much better commitment to making the change for themselves, their teams and the company. It's not for us to TELL them what to do, but to ASK them what's going on for themselves. Here's where I see a huge chance for improvement.

      In my session I give lots of examples on how to link Life Coaching ideas to our Agile work environments. I've given the session at LAST Conference Melbourne and at the Agile Coaching Circles Meetup Melbourne. The audience was engaged and the attendees were very happy about having some new ideas on how to improve their daily work life.

      Come along to be inspired by Life Coaching and thus to benefit our Agile Thinking!

    • Liked Giovanni Asproni
      keyboard_arrow_down

      Giovanni Asproni - Methodology Patterns: a Different Approach to Create a Methodology for Your Project

      Giovanni Asproni
      Giovanni Asproni
      Consultant
      Asprotunity Limited
      schedule 4 years ago
      Sold Out!
      90 mins
      Tutorial
      Advanced

      In the software world we have been looking for “The Methodology” to solve our software development sorrows for quite a while. We started with Waterfall, then Spiral, Evo, RUP and, more recently with XP, Scrum, Kanban, DAD, SAFe (there are many others, but, their impact, so far, has been limited).

      In this tutorial, I'll show why this search for the holy grail is bound to fail--each methodology has strenghts and weaknesses that make it suitable only in some contexts--and I'll describe a different approach based on patterns and pattern languages, that teams can use to create their own methodologies to suit their specific needs, which, in my experience, has a higher chance of success. 

      The approach is based on the observation that all the practices used in all modern methodologies--e.g., user stories, use cases, team self organization, TDD, unit testing, acceptance testing, continuous integration, iterative and incremental development, etc.--come from the same set. Different methodologies just mix and match them differently. All those practices can (and many have already been) described as patterns whose relationships with each other form a set of pattern languages.

    • Naresh Jain
      Naresh Jain
      Founder
      ConfEngine.com
      schedule 4 years ago
      Sold Out!
      45 mins
      Demonstration
      Intermediate

      "Release Early, Release Often" is a proven mantra and many companies have taken this one step further by releasing products to real users with every commit a.k.a Continuous Deployment (CD).

      Over the years, I've built many web/infrastructure products, where we've effectively practiced CD. However at Edventure Labs, when we started building iPad games, we realized there was no easy was to practice CD, esp. given the fact that Apple review takes a few days.

      Our main question was: As mobile app developers, how should we architect/design our apps for CD?

      We were a young startup, learning new behavior about our users (kids aged 5-8) everyday. We could not afford any delay in releasing latest, greatest features to our users. To solve this problem, I believe we've built an innovative solution to enable any mobile app developer to achieve CD.

      If you are building real products, which have platform/3rd-party dependencies and you want to practice CD, this session is for you.

    • Liked Venkatraman L
      keyboard_arrow_down

      Venkatraman L - Scaling from Project > Program > Portfolio - The Agile Transformation and Journey

      45 mins
      Case Study
      Intermediate

      The case in point is a journey of Agile transformation when the organization was looking to manage releases through shorter iteration cycles. As the journey began, the organization had to leapfrog into 3x growth in terms of both people and business needs due to a round of substantial investor funding.

      The agile transformation started with just 6 teams in the organization and due to the nature of the team structure, the 3-member PMO team did not have the luxury for pilot projects and had to simultaniously roll out at one go across the 6+ component teams.

      In a span of 6 months, the number of teams grew to 12+ and the number of releases more than doubled. Also, 80% of the releases cut across more than 3 teams and the challenge was to keep the process pretty lean. PMO team worked closely with key stakeholders from Product, Engineering, Architecture and Operations to forumate and roll-out a simple 3 step process that aided the teams to deliver releases better than before. Here is when the organization leaped from project to portfolio of releases cutting across 10+ themes.

      Similar to what is quoted in the "Scaled Agile Framework" which the PMO tripped on much later in the process, there were organization wide prioritization done based on the product strategy, infrastructure and technology needs which eventually got translated into multiple programs within the organization, cutting across various teams. A concept of 3-in-a-box (PM, Architect and Engineering Owner) was formulated to bring in the required vigor in to the planning and execution process.The 3 in the box was further extended to Dev +QA + Ops who worked as a team to deliver the various stories across the contributing stacks.

      The challenges across value-driven prioritization from 100+ releases across the portfolio, release planning with engineering and product, the execution framework and scalability in engineering infrastructure commensurate with the agile processes, working with operations teams and all the way till adoption was seamlessly scaled using the initial framework that was set for just 15 releases.

      The presentation details how agile helped and is helping the product and technology teams in delivering better results than before. This would also detail the necessary Agile and operational metrics across the project teams, the program and the portfolio levels that aid the mid and senior management to take informed decisions. As always, this would not cover the IP and actual data of the organization but provide a clear framework to substantiate the process.

    • Liked Johannes Brodwall
      keyboard_arrow_down

      Johannes Brodwall / Niruka Ruhunage - Remote Pair Programming

      45 mins
      Demonstration
      Beginner

      Can you maintain agile engineering practices with a distributed team?

      Johannes is the Oslo based Chief Scientist for the Sri Lanka based company Exilesoft. In order to promote agile engineering practices, he uses remote pair programming to connect with teams halfway across the world.

      In this talk, we will go through a practical approach for remote pair programming adopted for high-latency situations. We will demonstrate remote pair programming with a live example and we will discuss the advantages and usages of the approach. We will also cover the practical parts of remote pair programming, such as tools and setup.

      After seeing this talk, the audience should be able to remotely pair with members of their distributed team. They will also get a lot of tips on how to use pair programming effectively in both local and remote settings.

    • Liked Michael Heydt
      keyboard_arrow_down

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

      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 Mikael Gislen
      keyboard_arrow_down

      Mikael Gislen - Mitigating clashing paradigms between Agile Development and ISO 9000

      45 mins
      Talk
      Advanced

      There are, on a philosophical level, significant clashes between the agile paradigm and Quality Systems such as ISO 9000 or CMM/CMMi, this is already presented in the Agile Manifesto. Agile Development is based on what I would call post-modern paradigms when compared to the plan-driven and early iterative development methodologies which are based on a positivist paradigm.

      The underlying philosophical challenges cannot be easily mitigated. But a purist agile paradigm may tend to stress a positivist paradigm as well and this can be dangerous since then agile would not be agile any longer.

      While it may not be possible to completely remove the challenges between agile and quality systems, it is possible to learn to live with some tension between different paradigms. 

      There are some obvious areas of conflict, for examplethe Agile methodologies strongly discourages unnecessary documentation, and questions that it is possible to provide all requirements up-front. ISO 9000 on the other hand demands requirements up-front and documented evidence of almost anything, but such practical aspects can actually be mitigated with relative ease. Other aspects may demand much more effort. In particular the internal auditing process is problematic and other means of ensuring compliance may have to be considered.

      We have in my company systematically piloted a number of organisational changes in order to better support agile development. We have done this within the overall framework of our ISO 9000 system which is used a structure anda a gatekeeper. To do this we have used Action Research, which in it self is a kind of agile methodology, although of much older date than agile development.

      I will in my talk focus on the practical experiences we have had of building an organisational framework for agile development and while doing that suggesting a few means to mitigate the challenges mentioned initialy.

    • Liked Evan Leybourn
      keyboard_arrow_down

      Evan Leybourn - From Lean Startup to Agile Enterprise (beyond IT)

      45 mins
      Talk
      Beginner

      Traditional models of management and corporate governance are failing to keep up with the needs of the modern economy. Change, both technological and cultural, is occurring at faster rates than ever before. In this climate, modern enterprises will live or die on their ability to adapt. This is where Agile, and Agile Business Management, come in. Agile is change; changing how you think, changing how you work and changing the way you interact. This is important whether you are a software developer or a CEO.

      In this presentation, Evan will provide engaging and enlightening case studies of Agile beyond IT; from lean startups to large enterprises. These will be reinforced with practical approaches for the leadership of teams, divisions and businesses. 

      Taking the successful concepts and methods from the Agile movement and Evan's new book, Agile Business Management is a framework for the day-to-day management of organisations regardless of industry, size or location. We will discuss processes, techniques, and case studies for the 4 key domains from Agile Business Management;

      1. You, the Agile Manager - What makes a good manager and how do their responsibilities change?
      2. Integrated Customer Engagement - Collaboration and communication techniques to build trust and deliver Customer needs efficiently, with minimal waste, and to everyone's satisfaction.
      3. The Structure of an Agile Organisation - Efficient, transparent and collaborative techniques to manage empowered staff.
      4. Work, the Agile Way - Managing all types of business functions, from software, HR, finance to legal, by using Just-In-Time planning and Incremental or Continuous Delivery processes.

      Ultimately, the goal of this presentation is to make you think about your role as a leader. 

    • Aman King
      Aman King
      Agile Technologist
      ThoughtWorks
      schedule 4 years ago
      Sold Out!
      20 mins
      Experience Report
      Beginner

      Are you an Agile Practitioner? Or are you responsible for Agile transformation?

      Organizations that have begun their Agile journey welcome the guidance of an experienced Agile Coach. But external guidance cannot continue indefinitely as the only way to scale Agile.

      If you are in an Agile team, are you prepared to take on the coaching role for other teams once your Agile Coach moves on?

      If you are a manager, are you looking at grooming in-house coaches to scale and self-sustain transformation?

      The transitioning of practitioners into coaches can be key to your Agile journey. Individuals get to build on their potential, while the organization becomes more self-reliant.

      This session explores my personal journey from practitioner to coach. It should help you too in taking that first jump into the role of a coach. I will share real-world examples of dealing with on-the-fly situations, and of preparing upfront where possible. I will recommend resources, and mention handy techniques that should be in a coach's toolkit. The session essentially provides a kick-start for first-time coaches.

    • Liked Nikhil Joshi
      keyboard_arrow_down

      Nikhil Joshi - Build - Measure - Learn : Without spending a fortune

      20 mins
      Experience Report
      Beginner

      At times we have great product ideas but the biggest barrier to entry lies in answering few questions such as:

      - How do I define and validate Problem hypothesis, Solution hypothesis and Underlying assumptions?

      - How do I quickly setup a platform for people to register their interest?

      - What will keep the potential customers engaged, excited until the first release (or beta) is out?

      - How do I get feedback from the early adopters?

      - And eventually when I have answers to some of these questions, how do I make a decision to persevere or pivot?

      If you've faced a challenge while answering any of these questions while building/validating your product idea, this session is for you. We'll look at tools and techniques to validate the product hypothesis early-on without spending months or fortunes. We'll also look at a case study to highlight how some of these tools, techniques helped us validate our product idea.

    • Liked Andrea Heck
      keyboard_arrow_down

      Andrea Heck - Distributed Product Owner Team for an Agile Medical Development

      Andrea Heck
      Andrea Heck
      Agile Coach
      Siemens AG Healthcare
      schedule 4 years ago
      Sold Out!
      45 mins
      Case Study
      Advanced

      We are developing medical imaging and workflow software in an agile way with development teams distributed to several countries. One of the major challenges is how to set up and communicate within the Product Owner team. There we have to deal with the distribution, e.g., have the Product Owner either onsite with her peers or with her Scrum team, travelling, or with proxy. We need people who are good in two different fields of knowledge: medical and software development. As a third issues, the environment of the customers may be different in different countries.

      We have ramped up local Product Owners in different countries, have found local collaboration customers, and have developed a set of communication channels and workshops how to synchronize Product Owners in the team, share a common vision and backlog with their Scrum teams, and collaborate with customers locally and globally.

    • Liked Prasanna Vaste
      keyboard_arrow_down

      Prasanna Vaste - Should we stop using Story Points and Velocity?

      Prasanna Vaste
      Prasanna Vaste
      Business Analyst
      Thoughtworks
      schedule 4 years ago
      Sold Out!
      20 mins
      Experience Report
      Beginner

      On Agile projects we estimate user stories in order to allow team to

      1. 1. Track velocity
      2. 2. Decide scope for the Iteration
      3. 3. Help Prioritize stories
      4. 4. Help Release planning

      But most of the time we faced issues with estimation. It takes lot of time in estimating user stories, managers tend to relate estimate to number of days it will take to complete the story, in some teams estimate is equal to deadline. Most of the teams which use story points to estimate the work face these issues. This results in lack of confidence on development team when stories are taking more time to complete.

      Here I am going to talk about better alternative for both the suppliers of software products (financially and ethically) and their customers (internal and external). This alternative is being used in real companies delivering to real customers with great effect where team uses count of stories completed in an Iteration as measure of progress. Will talk about how this alternative can be used to track velocity, prioritize stories, planning Iteration and for release planning.

      I will share some exmples from my past projects where team did not use story points/velocty but used count of stories completed in Iteration to measure progress and also as best indicator of future performance.

    • Liked Karthik Sirasanagandla
      keyboard_arrow_down

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

      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
       
    • Liked Yashasree Barve
      keyboard_arrow_down

      Yashasree Barve - Why can’t Enterprise have all the Fun? –Tales from Enterprisy DevOps Land

      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 Pradeepa Narayanaswamy
      keyboard_arrow_down

      Pradeepa Narayanaswamy - WORKSHOP- Defining Behaviors as a team

      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 Savita Pahuja
      keyboard_arrow_down

      Savita Pahuja - Battlefield Agility

      Savita Pahuja
      Savita Pahuja
      Agile Consultant
      Palo-IT
      schedule 4 years ago
      Sold Out!
      45 mins
      Workshop
      Intermediate

      Battlefield Agility® is a quest to make our deliveries better, more collaborative, faster and effective. It relies on age old principle from the Army to provide a holistic view of the problem landscape which a project team needs to solve and be able to succeed in this, through small collaborative groups working in coordination to achieve the bigger goals.

      Battlefield Agility® derives from the Agile manifesto and principles and adds to it the key ingredient of individual wisdom to create a plan for a team which will help it succeed in successful deliveries . This is a goal based approach to increase MVP and ROI.

      The purpose of this method is to make team members more focused about their work, equal distribution of work in the team and increase productivity.

      Battlefield Agility enumerates the mechanisms of planning, better field view to all team members, ease of multitasking, reduce task switching.

      Key benefits of Battlefield Agility® 

      • A focused approach to software development as development proceeds through small battles to be won
      • Reduced multitasking and better efficiency of team members
      • Faster deliveries as the work is divided to right sized battles to be won
      • Parallel efforts by team members ensure the time to market is significantly lesser
      • Less process overhead as the collaboration is real time and more time is spent on the ground than on meetings
      • Small teams ensure close camaraderie and collaboration among team member
      • The team can even work on disparate work areas ( if required) in order to make best us of their expertise

       

    • Liked Vibhu Srinivasan
      keyboard_arrow_down

      Vibhu Srinivasan - Coding with Geeks- De Code the secrets behind TDD, BDD and ATDD

      90 mins
      Tutorial
      Intermediate

      This session is a coding sessiont that takes a problem and shows clearly what is the difference between TDD, ATDD and BDD. Ths session uses code for the server layer as well as UI layer.

      This session is not for you if you do not code. If you do code, please bring your laptop as we delve into the details of all these styles of programming techniques.

      We will rotate between ATTD, TDD and BDD periodically and show it at use in different layers. This session will be using Java , Rails, Scala and C# together so that you can see how you can benefit do these techniques even when coding in different languages.

      We look at common pitfalls and wrong beliefs that programmers have when it comes to these concepts

      This session is purely keyboard and you will have to bring a laptop.

    • Liked Yashasree Barve
      keyboard_arrow_down

      Yashasree Barve - What Works and What Not! A Portfolio Lead Retrospects

      20 mins
      Case Study
      Beginner

      Enterprises are complex, and so are the development groups within those. Being agile definitely enables the software development groups to deliver high value and high quality software with speed for even within an Enterprise.

      However legacy applications along with the overall Enterprise landscape pose its own challenges that are outside of the scrum framework to solve. Multiple Small scrum teams though working on separate applications need to be cohesive with a big picture. As a portfolio lead, who owns multiple applications and teams related to a portfolio within an Enterprise is a Chicken in scrum terminology. The expectation from the role is that of leader, scrum master as well as an Architect providing technical and functional oversight to the teams within the portfolio. The idea is to be a leader and not a manager in the true spirit of scrum.

      This session is about a retrospective of my work life as a Portfolio Lead who takes care of multiple scrum teams, and applications. I would like to speak about the top 3 challenges faced such as Scaling Production Support / Knowledge Retention for applications delivered through Scrum, Impact of Organizational Transformation initiatives on the scrum teams, and Multiple Stakeholder Expectations / Conflict Management through real life examples of my work. I would retrospect what I did, and discuss and debate what worked well, and what did not during this journey of mine.

    • Liked Yashasree Barve
      keyboard_arrow_down

      Yashasree Barve - Seven tales from an Ever-invigorating Agile Development Group

      45 mins
      Case Study
      Intermediate

      The constant quest in one’s mind to find Nirvana, of excelling the way we work, is never ending. Starting to do scrum is only the beginning of 'Being agile'. 'Being agile' attributes to constantly re-inventing and improving the way we develop software.

      We would like to present a case study of a development group that has adopted agile, and not shied away from trying newer things to keep scrum adoption true to the spirit of agile. We would discuss seven most powerful initiatives we practised over last 6 years to keep our developers and business excited about being agile and maximizing business value delivered. These initiatives defined the way we constantly evolved, got the new joinees of this group into the culture of agility and ensured that we are relevant to the need of hour.

      This talk would comprise of motives behind thinking about these initiatives, vision, road map as well as the way we executed them by engaging our whole development group. We would also like to highlight challenges we faced, and the benefits we derived out of these initiatives.