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.

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

Outline/structure of the Session

5 mins: Introduction - Practitioner to Coach
5 mins: Coaching activities and techniques
5 mins: Common patterns and gotchas
5 mins: Support structures, resources, and way forward

Learning Outcome

Some of these will be covered in the session, and some in the experience report:

* Roles and responsibilities of an Agile Coach
* Types of coaching engagements
* A peek into a coach's toolkit:
  ** Assessments and progress tracking (interviewing, process mapping, metrics, etc)
  ** Facilitation (handling retros, group discussion, etc, with fist of five, mind-mapping, etc)
  ** Enabling self-discovery and self-learning (5 why's, Socratic method, etc)
  ** and more
* Common patterns and gotchas
* How to apply your practitioner skills for coaching
* How to pick up new skills
* Reading recommendations
* Why practitioner to coach:
  ** Individual perspective
  ** Organization perspective

Target Audience

Team member, Manager, Coach

schedule Submitted 3 years ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Ellen Grove
    By Ellen Grove  ~  3 years ago
    reply Reply

    Hi Aman.  Thanks for posting your slides!

  • Karthik Sirasanagandla
    By Karthik Sirasanagandla  ~  3 years ago
    reply Reply

    Hi Aman, the program comitte has decided that the committe members work with the speakers of Agile India 2014 to get the first draft of experience report and work progressivelly there after. I've volunteered to work with or help you as is required in getting this first draft version out. Please let me know the time and medium (skype, gmail, etc.) that works convenient to you for communication and working together ;)

     

    • Aman King
      By Aman King  ~  3 years ago
      reply Reply

      Hi Karthik, thanks for volunteering to work with me on my experience report. Will get in touch with you. Btw, I enjoyed reading your profile. Looks like we have similar experiences and motivations. :)  I will look forward to our collaboration.

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

    Aman, I like your proposal and I think its a very important topic. However I'm a bit confused. It appears to me that you are using Coaching and Mentoring interchangeably. Am I missig something?

    Based on your experience can you please share when you would use coaching vs. mentoring?

    (My thoughts on this topic: http://blogs.agilefaqs.com/2013/07/21/how-coaching-is-different-from-training-mentoring-counseling-and-consulting/)

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

      IMHO Preparing for the first coaching assignment and Growing in-house coaching expertise are very important topics. However I'm concerned that you won't be able to do justice to these vast topics in 25 mins. Would you be open to doing a zoom-in pivot on just these two topics for 45 mins? If yes, request you to update the proposal accordingly.

      • Aman King
        By Aman King  ~  3 years ago
        reply Reply

        Hi, I have updated multiple parts of the proposal to better address the main topic of preparing for the first coaching assignment. Please let me know if you have further suggestions. Thanks.

      • Aman King
        By Aman King  ~  3 years ago
        reply Reply

        My personal objective is to encourage and enable individuals to identify potential in them for coach roles, and to have organizations support that as a viable option. This was the reason of going breadth-wise and not depth-wise. Your recommendation is also valid, so I've allotted more time to "Preparing for the first coaching assignment"; the topics before that will help lead into the main portions, and I could use the Conclusion to highlight salient ideas from the same as well.

    • Aman King
      By Aman King  ~  3 years ago
      reply Reply

      I read your blog post. I agree with the need to bring clarity around terms like coaching, training, etc, especially in Agile consulting/coaching engagements so that all parties have a common understanding of what is requested and what will be provided. 

      The word "coaching" has always been broad and has variations in application. http://en.wikipedia.org/wiki/Coaching

      My perspective, based on my experiences on the ground, is that a Coach will need to employ different methods at different points of time to help the coachees achieve their desired goals (goal-selection, however, is not to be driven by the Coach). And yes, this will involve the aspects that you've called out under Coaching in your blog post. I'd especially call out "Act as a catalyst for the coachee to gain a deeper understanding of themselves. Via this unlock their inherent potential". But, imho, it will also involve various forms of active mentoring and training methods from time to time. So, while I don't believe "coaching" and "mentoring" are interchangeable, I do believe an Agile Coach is free to use mentoring aspects for coaching.

      In this regard, my view of coaching may seem closer to your description of consulting. However, I still try to keep them separate because, as you've called out, a consultant can actively focus on making context-based recommendations for goal setting and act as an advisor, at a organization/department-level as well as team-level. And once the consultant ensures that everyone has a common understanding/consensus, a Coach role can help the teams achieve those goals. For example, coaches often employ the GROW model, and various steps of it benefit from having an experienced practitioner-turned-coach. http://en.wikipedia.org/wiki/GROW_model

      Coming back to your question, of when to use coaching vs mentoring, I recommend coaching in the initial periods, taking the team to a certain level of maturity with respect to an Agile approach, and then sustenance can rely on mentoring-based support (which could be internal).

  • Vijayanand Nagaraj
    By Vijayanand Nagaraj  ~  3 years ago
    reply Reply

    Hi Aman, this is a very interesting talk. However, I would like to know whether is it important to be an Agile Practitioner first before becoming or scaling to an Agile Coach? What according to you is the role of a Coach and can anybody who doesn't know Agile become a Coach?

    • Aman King
      By Aman King  ~  3 years ago
      reply Reply

      Thanks for your interest, Vijayanand. Your question is interesting and multi-faceted.

      Based on my experiences, I've come to realize that Agile is complex in its simplicity. A seemingly simple tenet of Agile can carry complex context-specific manifestations. Yet most of this complexity can be addressed by focusing back on the intent suggested by Agile.

      Applying that thought to Agile Coaching, I'd say there are multiple facets to coaching. I touch upon this as "Types of coaching roles" under "Identifying coaching potential".

      A non-exhaustive list of what a Coach role could end up addressing:

      * Role-based consultation
         ** Technical practices (TDD, Refactoring, CI, and other engineering practices)
         ** QA practices (functional automation, scenarios writing, environments, etc)
         ** Analysis practices (story writing, story slicing, etc)
      * Process activities consultation (planning, estimation, retrospectives, continuous delivery, etc)
      * Mentoring (industry exposure, focus on learning and improvement, mindset shift, empowering, etc)
      * Filling in leadership gaps (technical, architectural, business perspective, motivational, etc)

      As evident, a subset can be addressed without needing prior Agile experience (eg: Mentoring, Leadership, etc); however, just that subset may not qualify as "Agile" coaching. Using coaching to address that subset is in itself an organizational smell.

      For the more direct contributions (eg: TDD, functional automation, story slicing, etc), my opinion is that an experienced practitioner will yield better results as a coach. An effective coach is one who can share a vision, set a direction, provide guidance, and even get hands dirty when needed. Leading by example is a good way to convince people, get a message across using concrete examples, and help people pick up concepts/techniques. Beyond that, there are certain challenges that are difficult to predict and talk about upfront. Having prior experience helps in dealing with these circumstances as they happen, while enabling teams to learn from the experience themselves.

      That said, for organizations without access to a practitioner-turned-coach, they may kick-start their Agile journey on their own with checkpoints in place. Their use of a coach without Agile practitioner experience should also be scoped clearly, and can be supplemented with skill trainings.

      Hope this helps. Feel free to reply if there are still questions.

  • Archana Joshi
    By Archana Joshi  ~  3 years ago
    reply Reply

     

    Aman, Your proposal seems to be referring to a single team undergoing coaching and then moving on to self sustaining. From scaling agile perspective there will be several teams in the organization. Can you elaborate on how this model with fit in scaling agile to multiple teams.

    • Aman King
      By Aman King  ~  3 years ago
      reply Reply

      Thanks for your comment, Archana. I see where you're coming from. I will reword my proposal to be clearer.

      There are two aspects to the topic: (i) individual, and (ii) organization. 

      At an individual-level, I propose identifying coaching potential and building on it, so that the individual can in turn become a coach on other teams. Self-sustenance is not a primary focus at this level, and is implied.

      At an organization-level, I propose grooming and leveraging individuals who show coaching potential. In the long run, external coaches can hand off to such internal coaches. So, at an organization-level, self-sustenance becomes a goal.

      Applying this approach requires structure and support, both at individual-level and organization-level. I will cover these aspects in the session. It's based on my experiences, and that of colleagues, of transitioning ourselves from practitioner to coach, and of using this model to help organizations self-sustain Agile coaching.

      I've blogged about one part of the topic here: http://www.amanking.com/from-practitioner-to-coach-i/


  • Liked Tarang Baxi
    keyboard_arrow_down

    A Practical Guide to Setting up Distributed Agile Projects

    Tarang Baxi
    Tarang Baxi
    Chirag Doshi
    Chirag Doshi
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Beginner

    A practical guide to setting up a new agile project team. Based on years of agile delivery and coaching experience for projects in a number of distributed and offshore models, for teams sized from 10 to 200 people, and spread across 4 continents, and 8+ locations. Some areas that will be touched on:

    • People - how to organize distributed teams, cultural factors to consider, ways to build trust, and how to avoid timezone burnout.
    • Process - how to communicate effectively, plan collaboratively, setup distributed practices (standups, retros, pairing, etc), effectively divide work on a common codebase, maintain visibility, and track progress.
    • Tools - (tips provided as a handout) which hardware and software tools should you absolutely invest in to help overcome communication,  visibility and collaboration challenges
  • Liked Giovanni Asproni
    keyboard_arrow_down

    Methodology Patterns: a Different Approach to Create a Methodology for Your Project

    Giovanni Asproni
    Giovanni Asproni
    schedule 3 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.

  • Liked Naresh Jain
    keyboard_arrow_down

    Scaling XP Practices inside your organization using Train-the-Trainer Model

    Naresh Jain
    Naresh Jain
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Advanced

    How do you effectively scale skill-based, quality training across your organization?

    Over the years, I've experimented with different ideas/models to scaling skill-based training across an organization. In the last 4 years, I've pretty much settled down on the following model. Its very useful when mentoring teams on skills like Test-Drive-Development (TDD), Behavior-Driven Development (BDD), Product Discovery, Writing User Stories, Evolutionary Design, Design Patterns, Problem Solving, etc. I've successfully implemented this model at some very prominent fortune 500 enterprises.

    The goal of this workshop is to explore what other successful models organized have used to scale skill-based training in their organization.

  • Naresh Jain
    Naresh Jain
    schedule 3 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

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

    Venkatraman L
    Venkatraman L
    schedule 3 years ago
    Sold Out!
    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.

  • Bhavin Kamani
    Bhavin Kamani
    Abinav Munshi
    Abinav Munshi
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    Agile processes are the new order of IT implementations. These talk will elaborate on our experience and learnings during agile process implementation at Walmart. 

    We will touchupon following 3 key areas and our learnings that helped us scale agile in large enterprises.

    • Process Visualization - Our learnings related to visualization of existing processes and practices and how it helped us identify signals from noise

    • Product Backlog Elaboration - In a complex and large programs product backlog management and role of product owner needs to be revisited.

    • Team Working Agreement - This is particulary crucial for scaling agile as dependency management is one of the key aspects of enterpsie agile implementation.

    We will conclude with our key learning of how processes needs to be continuously evolved in large scale implementation.

  • Liked Johannes Brodwall
    keyboard_arrow_down

    Practice agile programming with coding dojo

    Johannes Brodwall
    Johannes Brodwall
    Buddhima w.wickramasinghe.
    Buddhima w.wickramasinghe.
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    A Coding Dojo is a fun and social way to become a better programmer. Johannes is an experienced coding coach who will guide you through a few hours of programming that will transform your understand your craft and yourself as a programmer. In the workshop you get to try out pair programming, test-driven development and continuous refactoring for yourself and you get lots of recommendations on how to improve your coding and testing. You will need to bring your own computer with a development environment of your choice. Recommended for Java, Ruby, JavaScript and C# developers.

    This is what previous participants say about the workshop:

    • What did you learn? New tools, pair programming and fun exercises; Ide tricks, programming language basics, testing tools, using tests as a reasoning tool; you can comfortably pair with strangers.
    • What surprised you? Small steps work better than planning; It's easy to get started when you pair program; Pair programming is nice
    • What do you plan to do next? Using TDD every day; Listen to partner more carefully - he may already have solved the problem.
  • Johannes Brodwall
    Johannes Brodwall
    Niruka Ruhunage
    Niruka Ruhunage
    schedule 3 years ago
    Sold Out!
    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 Jason Yip
    keyboard_arrow_down

    Think Like an Agilist: Deliberate practice for Agile culture

    Jason Yip
    Jason Yip
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Intermediate

    If I say, culture is important to adopting Agile, most people will just agree without even thinking too much about it.  But what is meant by "culture"?  Why is it important?

    Culture is not typical behaviour; it is not what we say we value (but don't actually do).  Culture is our basic assumptions of how things work.  Culture is the logic we use to think through and respond to any particular situation.

    If you imagine a pyramid, Agile practice and any other visible behaviour is on the top, stated or written Agile values and principles are in the middle, fundamental assumptions (aka culture) is at the base.

    My session is intended to expose people to the base of that pyramid.

    If culture is assumptions, then to understand Agile culture, we need to understand the basic assumptions of Agile.  To do this, I have created an approach called "Think Like an Agilist" that both exposes how we think through an "Agile situation" and allows us to deliberately practice "Agile culture".

    The general idea is that I won't just talk about Agile culture and values, what I'll call "culture theatre", but rather expose people, who nominally consider themselves part of the Agile culture, to their underlying thought processes and assumptions, given a relatively difficult scenario.  Those thought processes and assumptions are the essence of culture (reference Edgar H. Schein).  What is interesting is noting when the thought processes and assumptions are different which indicates that there is a different culture at play.  What I've noticed is that this difference is common between novice vs expert Agilists.

    Note that it isn't even about analyzing vs doing it mechanically but more about exposing what assumptions are being used to respond.

    NOTE: I will be updating the attached slides as when I created them, I was framing it more as "doctrine" rather than "culture", defined as fundamental assumptions"

  • Liked Nikhil Joshi
    keyboard_arrow_down

    Build - Measure - Learn : Without spending a fortune

    Nikhil Joshi
    Nikhil Joshi
    schedule 3 years ago
    Sold Out!
    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 Vinodhini
    keyboard_arrow_down

    Robotic Warehouses, Alien Domain, Offshore developers, Visionary customer : Saved by agile

    Vinodhini
    Vinodhini
    Thushara Wijewardena
    Thushara Wijewardena
    schedule 3 years ago
    Sold Out!
    20 mins
    Experience Report
    Intermediate

    Here is a case study of how agile outsourcing can be practically applied even when the business domain is very complex and alien to offshore teams.
    The example is a project in which Exilesoft provided for a leading Norwegian producer of Robotic warehousing solutions. The project involved transforming their legacy application, produced using multiple suppliers and methods, into a newly cast application solution. This project also had its own share of typical challenges.

    • Lacked definitive and reliable documentation,
    • Domain knowledge was limited to a few very busy individuals,
    • Development and redeployment could not interrupt attention to current customers,
    • Complexity was high and design was fragmented, and
    • Focus heavily invested on current product and customer support

    These limitations along with the lack of understanding of agile methods strongly suggested the use of a method adaptive in nature, and not heavily vested in large inflexible legacy elements.
    We commenced the engagement with two pivotal elements; client awareness (agile orientation) and a roadmap of committed involvement. To lay credibility this had to be backed up with proven result delivery in the very early stages. It allowed for flexible adaption, and the creation of an atmosphere that fostered client interest.

    During this session, we will take the audience through a small video clipping of such a warehouse. We will elaborate how the customer and offshore developers worked together using agile in a highly integrated team collaboration model to achieve success within a very short time frame.

    The session will cover the following key areas:

    How such projects can be initiated

    - What type of team model and contract type we used

    - How we did the agile transformation with the customer

    - How the roles were assigned between offshore and onshore team members

    - To improve remote collaboration the tools and techniques we used

    - Techniues learned to get teams up to speed with the new domain

    - As we go along, the process changes we identified and implemented to make things work better.

    - Agile engineering practices and team dynamics that helps in such situations

  • Prasanna Vaste
    Prasanna Vaste
    schedule 3 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 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 Neil Killick
    keyboard_arrow_down

    The Guessing Game - Alternatives to Agile Estimation

    Neil Killick
    Neil Killick
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    Agile promotes empiricism and change, yet many practitioners continue to scope out and estimate delivery times and costs for software products and projects.

    Defenders of the art of estimation claim that we need to estimate software projects in order to answer common business and customer questions such as:

    • Should we go ahead with this project? (go/no-go)
    • How much will it cost? (bottom line)
    • When will it be done? (predictability)
    • Should we do project B instead of A? (prioritisation)

    This session challenges participants to flip these questions on their heads and seek alternatives to estimation rituals. It covers the many risks inherent with an estimation culture and demonstrates real, practical alternatives, both at the portfolio and the sprint level.

  • Aruni Siriwardene
    Aruni Siriwardene
    schedule 3 years ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    A traditional software development project entails specifics around elements in or out of scope, tied up to deliverables, all ensconced within specified estimates and timelines, subjected to legal clauses for everything from acceptance to indemnities. For Agile contracts, the boundaries of legal intervention must stand; merely due to the marriage of parties when a project is executed; the definitions of boundaries must be established be it scope, budget or timeline and all standard deliverables from a traditional project stands; yet, the execution is as diverse as chalk and cheese.

    What are the key criteria to be aware of when we define Agile contracts; as in typical agile projects, should the client be involved in mutually drafting the contract? How much legal intervention can we allow? What happens to deliverables and expenses when delays occur and scope boundaries are reduced? Can blame be apportioned to an extent that each party will have to indemnify themselves?

    An Agile contract needs to reflect the nature of the engagement; no template contract with standard clauses can be coaxed upon a true agile project. In line with the Agile principles and values and targeted to the agile manifesto; Agile contracts should be just that – Agile!

  • Liked Anuradha Gajanayaka
    keyboard_arrow_down

    Convincing Agile Estimation to a non-Agile Project board

    Anuradha Gajanayaka
    Anuradha Gajanayaka
    schedule 3 years ago
    Sold Out!
    20 mins
    Case Study
    Intermediate

    Software development estimates are considered to be evil. If you have attended Agile India 2013 you know what I’m talking about! Both we use user stories and points or Gantt chat and hours, we have never discovered that magical formula for the right estimation.

    But is it something you dare to tell your project board?

    The bad news is that the software industry may not be able to forgone Estimate for a foreseeable future. The good news is that agile estimation techniques provides some kind of balance between need for estimates and inability to predict future.

    Still, our Agile Estimates can be really challenging when the receiving partly has no clue about Agile Software Development, specially the customers, members of project control boards and senior management.

    In this case study, I would like to draw the experience on how we used certain techniques and invented some tools to convince a non-Agile, traditional project board to use Agile Estimates.

  • Liked Sharad Julka
    keyboard_arrow_down

    Performance Appraisal For An Agile Team

    Sharad Julka
    Sharad Julka
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate
    Our affection with Bell Curve has been for long. 
    -It is (one of) the most "natural" scheme(s) of evaluating
    and judging performance of an employee in an enterprise.
    -It provides a fair view of the employee performance level
    of all employees to the management.
    -However, in an Agile world, where everyone in the team is expected
    to exercise equal responsibility and accountability,
    does Bell Curve PMS act as a hindrance?
    -Does it motivate a few and demotivate others?
    -Is it the right tool to use?
    -Is it used in the right manner?
    -Does it affect the performance of a highly productive and efficient team?
    -Do we have a choice?
  • Liked Savita Pahuja
    keyboard_arrow_down

    Battlefield Agility

    Savita Pahuja
    Savita Pahuja
    schedule 3 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 Anuradha Gajanayaka
    keyboard_arrow_down

    Some say they do Scrum to be agile ...

    Anuradha Gajanayaka
    Anuradha Gajanayaka
    schedule 3 years ago
    Sold Out!
    45 mins
    Experience Report
    Intermediate

    In the challenging context of offshore Agile Software Development, not everything in the book would work. In this experience report, I would like to discuss how the teams can tailor the current so called standard Agile methodologies/practices (within the guidelines of the Agile Manifesto), yet become successful in deliveries.

    In the session, I would like to discuss some of the agile practices the audience is using and then discuss the challenges they face when it comes to Agile Offshore Development. Then I would like to draw my experience on offshore software development projects where we successfully used Agile concepts and demonstrate how to customize those standard methodologies/practices within the Agile Manifesto Framework.

  • Liked Tarang Baxi
    keyboard_arrow_down

    1000 Words - Illustrating Project Challenges with Visuals

    Tarang Baxi
    Tarang Baxi
    schedule 3 years ago
    Sold Out!
    90 mins
    Workshop
    Beginner

    A project can face varied challenges through its life, foreseen and otherwise - runaway scope, high defect volumes, depressed velocity, and many more. Addressing many of these first requires recognition of the problem and then action from one or more sets of project stakeholders. Telling the story with simple visuals can be a very powerful way to articulate a challenge (the what), the potential root causes (the why) and the options available to fix it (the now-what). Teams typically already track a lot of data related to throughput, quality, scope and cost. Creative use of this data combined with simple, hand-crafted visuals can be much more effective than hundreds of bullet points. In this hands-on workshop, you get to exercise your visual thinking and visual communication skills. We introduce some simple visual thinking techniques like Look-See-Imagine-Show, and then let you apply them in a project simulation, so that you can practice hand-rolling simple visuals that speak volumes (no fancy tools needed!).