The Agile Technical Writer

  • 313 views
Published

This lecture was given by me in MegaComm, the annual event of the Technical and marketing writer in Israel and elaborates the changes, the challenges, and the advantages of being a technical writer in …

This lecture was given by me in MegaComm, the annual event of the Technical and marketing writer in Israel and elaborates the changes, the challenges, and the advantages of being a technical writer in an Agile R&D process

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
313
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
4
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. The Agile Technical Writer Aviram Eisenberg, CEO, Ignite
  • 2. Real Life Agility 1 X years ago I was in a honeymoon in Thailand… h il d Like many business men before me I decided to buy Armani-like tailor-made suit We f W found a worthy provider d th id Negotiated price and scope g p p And then the vendor asked me to come on a daily basis to measure the suit
  • 3. Real Life Agility 2 My wife, however, preferred to tickle tigers in Kanchanabury
  • 4. Real Life Agility 3 We prefer to do all measuring on the first day d d and come on the l day to pick up the h last d i k h suit, I told the vendor No, no, no, said the vendor. I need to measure you on a daily basis because first of all this is a manual work, hence we may h d h d have man-made errors that we need to identify and correct
  • 5. Real Life Agility 4 And secondly you may eat too well and change your waste line during this week!
  • 6. Final Results Through an iterative process of daily deliveries, feedback and corrections – mission accomplished!
  • 7. Ignite - Who We Are A Software Development Management company Expertise in Project Management Expertise in SW Development methodologies & tools Agile/Scrum/XP/Kanban Lean Software Development TOC Customized flavor E ti i Gl b l D li d l Expertise in Global Delivery models Distributed development Offshore development (Eastern Europe) Expertise in Project Delivery Turn-key, dedicated teams, ODC, BOT
  • 8. The Agile Umbrella TDD Agile Modeling g XP Scrum Lean L AUP DSDM FDD Crystal
  • 9. Agile Highlights Claims that SW development is a spiral process hence waterfall model is usually not effective Develop in short iterations (sprints) that each contain the detailed spec analysis, estimations, design, develop and testing Working (testable or shippable) software Wo g (testab e o s ppab e) so twa e should be delivered at each iteration (increment) Due dates are fixed, scope can be changed Self S lf contained teams t i dt
  • 10. Agile Highlights Self organized teams Emphasis on process simplicity h i i li i Emphasis on working software rather than p g documentation Emphasis on quality and test automation
  • 11. Waterfall Req Analysis Architecture A hit t Design Task 1 Task 2 Design Testing Task 3 Task 4 Management Integration Testing Documentation
  • 12. Agile Planning I0 Task 1 Task 2 Release Planning Testing Integration Documentation Planning I0 Task 4 Task 3 Testing Documentation D t ti Product Owner I1: Integration Planning Testing Documentation
  • 13. Scrum in a Nutshell
  • 14. Agile Benefits Increase Quality Perform testing in short iterations as part of the development cycle Each iteration must pass acceptance criteria (DoD) Utilize continuous integration platform – each developer is notified when the code breaks ( (compilation or test failure) as soon as he commits it to p ) repository Quick Response to change/market Product manager works closely with the R&D team to define requirements and priorities for each iteration The team is able to change plans at the beginning of each iteration as software is always stable As a result management may quickly shift R&D to new f t features/project within the iteration time window / j t ithi th it ti ti i d (two weeks usually)
  • 15. Agile Benefits Waste Reduction Perform ad-hoc design instead of long preliminary ad hoc design as requirements may change until implementation Develop D l exactly what’s needed according to priorities tl h t’ d d di t i iti – at any given time the team is working on the most valuable features Lean processes and interfaces between stakeholders – overhead reduction Increase Progress visibility At any given time management knows the progress, quality, progress quality main obstacles and concrete due dates
  • 16. Agile Benefits Waste Reduction Perform ad-hoc design instead of long preliminary ad hoc design as requirements may change until implementation Develop D l exactly what’s needed according to priorities tl h t’ d d di t i iti – at any given time the team is working on the most valuable features Lean processes and interfaces between stakeholders – overhead reduction Increase Progress visibility At any given time management knows the progress, quality, progress quality main obstacles and concrete due dates
  • 17. The Technical Writer Challenge From the Agile Manifesto: We Value … Working f W ki software over comprehensive documentation
  • 18. The Technical Writer Challenge Incremental Development = Incremental Documentation: big paradigm change Incremental development vs. the need to see the “big picture” big picture Some tasks can only be done after development ends Frequent releases = Tech writer overload? E b i Change = Rewriting R ii Embracing Ch documentation?
  • 19. Devalued Documentation Devalued documentation? Refers mostly to official development documents Writing all documents at the beginning encourage waste A good document is a live document g Agile encourages less formal documentation – mostly Wiki y Become the wiki expert/manager Set your guidelines and templates y g p Encourage team members to use it Use RSS feeds
  • 20. Incremental Documentation Good documentation, like good software, is not written once and then left to decay Writing the perfect document is an iterative process: Write the page, get it reviewed, and publish it as quickly as possible. There are people out there who need it now! If you find a programming quirk while documenting the software, let the developer know Respond to comments from customers, developers, support staff and anyone else. Update the document immediately Monitor changes made by other people
  • 21. Change Your Habits Participate in Release and sprint planning Use daily standup to raise obstacles Review the Product Backlog and Sprint Backlog B kl Take advantage of your free access to product owner – ask for customer feedback Take advantage of your free access to the development team Insist on good quality user stories Insist on clear definition of done Play with working software after every drop Register to wiki
  • 22. The Big Picture Not everything is incremental Engineering best practices did not fade with Agile Release planning R l l i High level requirements analysis High-level d i Hi h l l design High-level estimation A d hi h l l documentation guidelines t ti id li And…high-level d
  • 23. End of Development Tasks Some tasks can only start when development ends Well, now development ends every two weeks… weeks Tech writer can work in a phased mode I0 Dev I1 Dev I2 Dev I0 Tech Writing I1 Tech Writing I3 Dev I2 Tech Writing I4 Dev I3 Tech Writing I5 Dev I4 Tech Writing I6 Dev I5 Tech Writing Final Release Complete System –Wide Documentation D t ti
  • 24. Tech Writer Overload Frequent releases tend to create overload Distinguish internal and external releases Internal releases – less official documentation External releases – ask f customer feedback E t l l k for t f db k and correct as you go Long effort of reasonable pace work instead of concentrated bursts of work
  • 25. Changes and Document Rewrites Agile embraces change Change implies documentation rewrite Well, yes, if you wrote it all at once… Document only what was already developed Document what was confirmed as done Document only what you see working y y g Did me mention that a live document is better than decaying document??? y g
  • 26. Not Everything is Bad.. The Tech Writer is part of the Agile Team User stories are much more descriptive then feature requirements We t t W get to see working software sooner ki ft The customer is heavily involved in the process – clearer functional and business l f ti l d b i requirements A li document is better than a decaying i b h d i live d document
  • 27. Q&A Aviram Eisenberg Ignite I it www.igniteso.com g aviram@IgniteSO.com