Mind shift for End-user documentation in Agile Methodology

After a successful release, the product manager feels extremely happy that the team met the commitments and delivered the software on time. However, when he probes the actual users for the feedback, the first reaction is “documentation sucks”. Why does this happen? Most of the developers and testers still follow the traditional approach of involving documentation folks towards the end of the release! This is paradoxical because when you have development and testing happening in agile approach how can you have documentation in traditional approach?

This session deals with the mindshift change that the entire value chain needs to make end-user documentation a critical part of the scrum team deliverables and bring it on equal pedestal as any other deliverable.

It emphasizes that technical writers should not feel marginalized with the fast paced development, testing, and delivery cycles. Instead, they must work very closely with the developers and testers because they no longer require to sit outside the room and walk in only after the bell rings! And the developers, testers, product owners should not consider documentation folks as the last leg of the product delivery cycle. They must all work as an integrated team, start-to-finish.

 
5 favorite thumb_down thumb_up 5 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

  • Current approach towards end-user documentation
  • Flaws and drawbacks in this approach
  • Change in approach, make doc members part of scrum teams
  • Make doc deliverables as part of sprints
  • Make one integrated team
  • How the quality of all the release deliverables (including docs) enhances

Learning Outcome

Technical writers should not feel marginalized with the fast paced development, testing, and delivery cycles. Instead, they must work very closely with the developers and testers because they no longer require to sit outside the room and walk in only after the bell rings! And the developers, testers, product owners should not consider documentation folks as the last leg of the product delivery cycle. They must all work as an integrated team, start-to-finish.

Thus, there is a need for a mind shift. We must build teams that have team spirit in real sense where there is better collaboration, close working relationship, and a tightly integrated team is required to deliver the complete software package…

Target Audience

Agile team members, product owners, scrum masters

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Anish Cheriyan
    By Anish Cheriyan  ~  1 year ago
    reply Reply

    Hi Vijay,

    Thanks for the topic submission

    As requested by Srinath, please request to add related slides.

     

    Regards

    Anish

  • Srinath Chandrasekharan
    By Srinath Chandrasekharan  ~  1 year ago
    reply Reply

    Vijay,

    The Topic is interesting and appropriate. Can I also request you to add content slides around this topic and a video of any session you have done earlier. As the theme is Agile-in-trenches, the thought in this theme is more about "How it was done for a project or projects (s)" and sharing the experience around the same.

    At this point , your content looks more of theory and more like "How it should be done".

    Please add appropriate content to help us evaluate your proposal.

     

    Regards,

    Srinath

  • Ganesh
    By Ganesh  ~  1 year ago
    reply Reply

    Important topic needed for today, as the agile adoption for product development is increasing significantly.

  • Savitha G
    By Savitha G  ~  1 year ago
    reply Reply

    Good topic!! All the best !

  • Anjum
    By Anjum  ~  1 year ago
    reply Reply

    Interesting topic!


  • Naresh Jain
    Naresh Jain
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Intermediate

    What started off as a trial-and-error approach to improve the state of software development by a bunch of tinkerers, is today dominated by management consultants, "Thou-Shall" codified frameworks and rigid, expensive tools. Over the last 20 years, we've gone from, "I'm not sure, let's try this in a small-safe environment" to "you/your-team sucks; you guys have a very poor agile maturity because you are not doing _x_y_z_ (not conforming to the standards)." Along the way, we've lost the purpose of being agile .i.e. to embrace uncertainty and simplicity. Instead we've been forced to believe that consistency via top-down standardisation and predictability by increasing the rigour on process is our eternal quest. Anything that sounds simple and works 80% of the cases is discarded as being naive. What once drove thought-leader into agile, is now driving them insane. This is the unfortunate fate of Agile.

    Luckily there has been some fresh perspectives from Nassim Taleb, author of Antifragile. His work explains how some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. More importantly why antifragility is beyond resilience or robustness.

    In this talk, I'll use some of Nassim's thoughts (and some of my own) to explain what is wrong with our current approach to Agile and how we can bring life back into Agile. Particularly how we can leverage Volatility, Uncertainty, Complexity, and Ambiguity to make product development more antifragile.

  • Liked Evan Leybourn
    keyboard_arrow_down

    If you need to start a project, you’ve already failed #noprojects

    Evan Leybourn
    Evan Leybourn
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Beginner

    I want to be controversial for a moment and propose an end to IT projects, project management & project managers. I propose that the entire project process is flawed from the start for one simple reason. If you need to run a project, you've already failed.

    By definition, an IT project is a temporary structure to govern and deliver a complex change (such as a new product or platform) into an organisation. However, to be truly competitive, an organisation needs to be able to deliver a continuous stream of change. Managed properly, this negates the need for a project and the associated cost overheads.

    This is fundamentally what #noprojects is. The approach, structure, tactics and techniques available to successfully deliver continuous change. At its core, #noprojects is predicated on the alignment of activities to outcomes, measured by value, constrained by guiding principles and supported by continuous delivery technologies.

    This presentation will introduce you to #noprojects. You will learn how to define an outcome and create an Outcome Profile. You will also learn how to manage change within the context of an outcome through the Activity Canvas.

  • Naresh Jain
    Naresh Jain
    schedule 1 year ago
    Sold Out!
    45 mins
    Keynote
    Advanced

    On Agile teams, collaboration is the way of life. Our leaders want their team members to work closely with each other, have shared goals and even think as one entity. Why? Because we believe that collaboration leads to happier, more productive teams that can build innovative products/services.

    It's strange that companies use the word collaboration very tightly with innovation. Collaboration is based on consensus building, which rarely leads to visionary or revolutionary products/services. Innovative/disruptive concepts require people to independently test out divergent ideas without getting caught up in collaborative boardroom meetings.

    In this presentation, Naresh Jain explores the scary, unspoken side of collaboration and explains in what context, collaboration can be extremely important; and when it can get in the way or be a total waste of time.

  • Liked Niranjan N V
    keyboard_arrow_down

    “If You Can’t Change, Who Can ? “ - Lean Agile Leadership for Enterprise Agility

    Niranjan N V
    Niranjan N V
    schedule 1 year ago
    Sold Out!
    45 mins
    Experience Report
    Advanced

    My talk is about how the leadership can play their role when we talk about the Software Enterprise Agility. As per Peter Drucker a well known management guru, “Workers themselves are best placed to make decisions about how to perform their work”. To effectively lead, the workers must be heard and respected. They have to have autonomy. Continuing innovation has to be part of their work, the task, and the responsibility of knowledge workers. When we talk about Scaling Leadership style for enterprise agility, The leadership should be ,

    • Taking responsibility for Lean-Agile success,
    • Teaching Lean-Agile behaviors to other employees, direct and indirect reports , teams, departments etc,
    • Trained in practices and tools of continuous improvement
    • Teaching problem solving skills and corrective action
    • “Develop people” —People will develop solution, management need not worry too much on focusing developing solutions.
    1. Brief description of the talk

     

    My talk will initially consist of current challenges in the Leadership based on my experience in coaching, consulting and training

    When we talk about the scaling leadership for Enterprise Agility, the most desired style is “Leaders should be developer of people”. Lean-Agile Leaders are lifelong learners and should help teams build better software systems through understanding and exhibiting the values, principles and practices of Lean, Systems Thinking, and Agile development

    The main part of the talk is based on my experience of coaching, training and consulting. The Lean Agile Leaders for Enterprise Agility should

    1. Have a Systems View:

    That means today’s Lean-Agile Leaders should understand the economics, the full value chain, and the Cost of Delay, Optimize the whole, not the parts, the organization & software system. They should focus more on implementing Lean Budgeting rather than traditional project based budgeting.

    1. Implement the Product Development Flow:

    Lean agile leaders should know how to visualize work; expose bottlenecks, Reduce queues and backlogs. In Enterprise Agility , bigger the size of people, it will lead to more coordination issues, complexity increases, alignment to the business units . Implementing organization strategic goals becomes difficult and pose multiple challenges. Therefore we need to think of Reduce batch size, accelerate feedback, exploit variability using cadence and synchronization so that every team demonstrates value to the customers

    1. Embrace the Agile values and principles:

    In an Enterprise Agility, Lean Agile leaders should fully understand agile values and principles; such as focusing more on deliver more frequently and know how to implement XP, Scrum, Kanban more importantly Scaled Agile Methods such as SAFe, LeSS etc. Exhibit Kaizen mind and empower high-performing, cross-functional teams.

    1. Strengthen the hidden potential and intrinsic motivation of knowledge workers

    The lean agile leaders should focus more building a learning organization and emphasize lifelong learning. They should provide safe environment of mutual influence the teams and who ever work under them. They should foster decentralized decision-making with minimum specific work requirements. One of the ways of unlocking the hidden potential and motivation of the workers is ensuring the direct reports and team members have

    • Autonomy
    • Mastery and
    • Purpose
  • Jayaprakash Puttaswamy
    Jayaprakash Puttaswamy
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Advanced

    This talk is an experience sharing session about what it takes to realize business benefits in a large-scale (beyond 100 people) agile transformation. Having driven more than 4 large-scale transformation initiatives (of scales 160 to 700 people) over last 5 years, I would be sharing a couple of case-studies where I worked recently and I would discuss various challenges of implementing large-scale transformation and possible approaches to handle them. Participants would be engaged through interactive discussions on mutual experience sharing with a focus on key dimensions of agile execution.

    As the title reveals, the talk would focus more on execution challenges and approaches to handle them at all levels of stakeholders involved in a transformation. Levels include developers, architects, managers (project/engineering), senior management (delivery/program management, directors) and CXO's. More details in Outline section. 

    The key dimensions to be covered include

    1. Building and sustaining learning culture (approaches include Community of Practice, Guilds and Joint Workshops)
    2. Causing the mindset shift in engineers (different approaches for developers, architects and engineering managers)
    3. Enabling managers to create and nurture agile engineering culture (approaches include effective metrics about quality of code, tests, application and build)
    4. Inverting the Test Pyramid (approaches include test automation strategies, BDD, dealing with Legacy using Strangler pattern, Component Guardian pattern)
    5. Leadership Agility (approaches include catalyst style of leadership, risk driven decision making, leading the change)

     

  • Liked Neil Killick
    keyboard_arrow_down

    The Slicing Heuristic - A #NoEstimates Method for Defining, Splitting, Measuring and Predicting Work

    Neil Killick
    Neil Killick
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Advanced

    This is a concept I devised a couple of years ago, and it seems there is a new #NoEstimates audience that would like to know more about it.

    A Slicing Heuristic is essentially:

    An explicit policy that describes how to "slice" work Just-In-Time to help us create consistency, a shared language for work and better predictability.

    The Slicing Heuristic seeks to replace deterministic estimation rituals by incorporating empirical measurement of actual cycle times for the various types of work in your software delivery lifecycle.

    It is based on the hypothesis that empiricism leads to smaller cycle time duration and variation (which in business value terms means quicker time to market and better predictability) because it requires work to be sliced into clear, simple, unambiguous goals. Crucially, the heuristic also describes success criteria to ensure it is achieving the level of predictability we require.

    Its application is most effective when used for all levels of work, but can certainly be used for individual work types. For example, a User Story heuristic can be an extremely effective way of creating smaller, simpler work increments, allowing teams to provide empirical forecasts without the need for estimating how long individual stories will take. However, if you are able to incorporate this concept from the portfolio level down, the idea is that you define each work type (e.g. Program, Project, Feature, User Story, etc.) along with a Slicing Heuristic, which forms part of that work type’s Definition of Ready.

    This talk will equip teams and organisations who are established on their Agile journey with a robust, clear and repeatable method for improving the quality and time-to-market of their software development efforts.

  • Liked Ashay Saxena
    keyboard_arrow_down

    Researching Agile - Issues, Challenges & Solutions!

    Ashay Saxena
    Ashay Saxena
    schedule 1 year ago
    Sold Out!
    20 mins
    Pecha Kucha
    Intermediate

    Over the last decade, organisations have embraced agile approaches in a bid to uncover "better ways of developing software". Agile has fast-become the norm for software development owing to its credibility to be able to deliver continuous business value to the customer. Despite the promise, there are several grey areas expressed with the specific approaches (be it Scrum, XP et al) as well as ways in which teams practice them at a project level. Subsequently, several concerns have been raised by the practitioners. Consultants, Coaches and Researchers constantly dwell on these aspects and make an attempt to provide solutions to these existing challenges.

    A succinct account of the status-quo is that practice has led research in the domain. However, there has been recent surge of Agile research playing catch-up with the various facets of Agile practice. This session shall dwell on the present state of Agile research. The issues and challenges concerning Agile research shall be presented. A brief discussion, in the form of "chit-chat", shall ensue to possibly lay out a bright future for Agile research. 

  • Liked Karthikeyan Chellappa
    keyboard_arrow_down

    The Balancing Act of Distributed Agile

    Karthikeyan Chellappa
    Karthikeyan Chellappa
    Ashay Saxena
    Ashay Saxena
    schedule 1 year ago
    Sold Out!
    45 mins
    Case Study
    Beginner

    The need of the hour for almost any software organization today is being or doing Agile. It helps organizations deliver continuous business value to the customer. At the same time, some organizations may need to embrace distributed teams, working from multiple sites on a project, to capture global talent and leverage expertise at different locations.

    In present times, software organizations are making a sincere attempt to successfully deliver projects following the distributed-agile approach. However, ‘Agile' and ‘ Distributed' seems to be at two opposite ends of a continuum, in terms of demands for flexibility and control to the approach of software development. In such a scenario, how does one manage to work with this approach in harmony?

    We made an attempt to understand the drivers that leads to effective balance between the tenets of distributedness and agility in a software development team. Our research lead us to one of the leading agile practitioners viz. ThoughtWorks in a bid to uncover the mechanisms followed in their distributed agile projects. We interviewed several people in their organization including Developers, QA, Business Analysts, Project Leads and Managers working on a project to figure out just what makes distributed agile project(s) tick.

    Our findings have led us to believe that the creation of a unique 'project context' is essential to effectively balance the conflicting requirements of distributed and agile development. Our objective is to share these findings with the agile community. We hope that our insights will help other agile practitioners working with distributed teams to execute their work more efficiently and effectively. 

    Moreover, we would also dwell on the case study research approach to help agile researchers carry them out in a convincing manner. In particular, we shall focus on the process of site selection, data collection and analysis which could lead to good insights from the “field" on the researchers’ topic.

  • Liked Pavan Soni
    keyboard_arrow_down

    Does Agile Approach kill Creativity in Organizations?

    Pavan Soni
    Pavan Soni
    schedule 1 year ago
    Sold Out!
    45 mins
    Keynote
    Advanced
    The key tenets of Agile Software Development, or Agile Development, are shorter timescales, close-teamwork, continuous improvement, continuous customer involvement, and quick response to change, amongst others. Whereas the key tenets of creative thinking are deferring judgement, divergent thinking, individual time-out, overriding customers' demands, deliberately introducing errors and serendipity, and valuing improvisation over improvement, including others psychological practices. It is seldom realized that some of the principles of Agility might be at the very cost of Creativity. Are they opposites or complementary? 
    I propose a temporal and spatial complementarity model of Creativity and Agility along with innovation process, from idea generation all the way to execution. Doing so, I caution the adrant adopters of Agility on the risk of not fully utilizing the creative faculty of humans, and propose ways in which agility and creativity can co-exist. 
    Based upon understanding the developments in the field of creativity and innovation, and contrasting the same with the Agile tenants, I propose a few areas where the two converge, and where they diverge.
    The insights are mostly drawn from viewing firms in action, and from cases studies of building a culture of innovation in the organizations. 
  • Liked Sindhu Srinivasa
    keyboard_arrow_down

    Role-Playing – Seeing is believing

    Sindhu Srinivasa
    Sindhu Srinivasa
    Musarrath Jabeen
    Musarrath Jabeen
    schedule 1 year ago
    Sold Out!
    20 mins
    Experience Report
    Beginner

    When teams are On-boarded on Agile Projects , members are trained on the Scrum framework  including Agile Manifesto, Principles, Ceremonies, Scrum Values, Roles and Responsibilities.

    In addition to the Scrum framework , Mindsets and behaviors also play major role in the success of scrum teams and programs.

    While awareness is created on Scrum Values and Growth mindsets, each individual has a unique way of interpreting a scenario and responding to the situation. In several situations members in the Scrum Teams/Product Owners/Scrum Masters/Other Stakeholders expect a near perfect( Text book) behavior from the other, while there could be several challenges for each individual especially in the different phases of transformation.

     “I hear and I forget. I see and I remember. I do and I understand”  is a famous saying by Confucius.

     “A role-playing game is a game in which the participants assume the roles of characters and collaboratively create stories. Participants determine the actions of their characters based on their characterisation, and the actions succeed or fail according to a formal system of rules and guidelines. Within the rules, they may improvise freely; their choices shape the direction and outcome of the games.”

    Reference: https://en.wikipedia.org/wiki/Role-playing

    Role-playing is a powerful tool that we have been able to successfully use as a self-introspection coaching tool in our Agile Transformations to bring out the behaviors in different scenarios, and let the participants experience the challenges.

    In this experience report, we will discuss on the scenario’s noticed on the ground from the Scrum teams for the Role Plays and how the team members and various stake-holders have benefited from the same.

    A few of these scenarios are as mentioned below :

    • PO’s influencing the estimation of teams due to their past experience with the product.
    • Scrum Masters continuing to command and control the team.
    • External stakeholders expecting Scrum Masters to be a Project Manager.
    • Individual glory over one team approach.
    • Senior members/Architects unwilling to collaborate in the team due to their past way of working.
    • Collaborative Inter-team dependency resolution.
    • Challenges of distributed teams not being considered.

     The benefits that role play provided us :

    • Acts as a introspection tool for the teams/individuals part of the Role Play and also for observers.
    • Builds confidence for individuals to take up the roles.
    • Creates an environment for problem solving.
    • Empathy towards individuals.

     

    During the presentation session, a short Role Play is planned.

    Let us play the game – bring out the actor in us, have fun and share !!