Spectrum2018 agile roadtrip_med
•Download as PPTX, PDF•
0 likes•46 views
The document summarizes the author's experience transitioning from a traditional waterfall development process to working on an agile software engineering team. Some key points: - She has worked as a technical writer for 25 years and facilitated her team's switch to agile 10 years ago. - Agile utilizes short 2-4 week cycles called sprints, daily standups, and demos instead of long documentation deliverables. - On the agile team, she takes on various roles like Scrum Master and helps with testing and code changes in addition to documentation. - The author believes agile has increased her job satisfaction, career success through promotions, and involvement in decision making. However, it can be developer-centric
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Spectrum2018 agile roadtrip_med
Similar to Spectrum2018 agile roadtrip_med (20)
Recently uploaded
Recently uploaded (20)
Spectrum2018 agile roadtrip_med
- 1. THE AGILE WRITER ROAD TRIP HOW I CRUISED TOAGREAT CAREER Mary Elise (“Mel”) Dedicke 2018
- 2. My background • M.S. in Tech Comm from RPI • STC member since 1994 • Technical writer in the Capital District for 25 years in manufacturing, financial services, and technology companies
- 3. Start your engines! For the last 12 years I’ve worked as a tech writer on various software engineering teams at Pitney Bowes (formerly MapInfo). • First 2 years were Waterfall • Then 10 years ago, we made the big cultural and organizational switch to Agile • Agile is fast and furious, twisty and turning, so BUCKLE UP!
- 4. Lots of new terms
- 6. Waterfall features • Established project plans • Weekly status meetings • Long dev cycles – 1 or more years • Always delays, because it has to be SOLID, close to perfect… • …and that generates fear & CYA behavior • Lots of paperwork
- 7. Agile features • Short cycles called sprints – 1, 2, or 4 weeks, embrace change on the fly, the roadmap is not linear! • Daily scrums/standups • Failing fast & early is perfectly acceptable… • …and that generates trust & collaborative behavior • Demos instead of paperwork
- 8. Wearing many hats In addition to writing docs: • I test and write bugs like a QA engineer • I take turns as ScrumMaster (“project manager”) • I check in files like a developer when I edit UI string files, error messages, config files, etc.
- 9. And I even break builds! (aka “Earning the Fish”)
- 13. How we work • During sprint planning, we normally choose to work in 2-week cycles, expand to 4 if vacations or other events will interfere. • Every day we have our scrum (“standup”) meeting where every team member gives a brief status: what did you do yesterday, what will you do today, what are any impediments you have. • Impediments and issues get covered in the parking lot after the standup. • Mid-sprint we have a backlog grooming meeting with both teams for the product (ours and India’s) to evaluate and size the work on the backlog. • When the 2-week sprint is over, we demo only completed work (features and critical bug fixes) • After the demo we do a retro (short for retrospective) where we discuss what went well, what didn’t, and what we should change going forward. Continuous improvement is always a priority.
- 14. My team at PB – the Scrum Room
- 15. March 27, 2018 Sprint 13Demo TROY BIG DATA TEAM DEMO
- 17. 1. Demo stories that are complete. 2. Explain stories that are not. 3. Gain acceptance from Product Owners. 4. Feedback Sprint Demo Purpose
- 18. Key Summary Points HAD-3063 Performance of UDFs That Return a Geometry Are Slow 8 HAD-2972 Automated tests for alternate Hive execution engines 5 HAD-2955 Add Gef/Pip functional tests for Spark 5 HAD-2892 Productize UDFs for Nearest/PiP using local data 13 HAD-2671 Geocoding UG: Make it better 8 HAD-2415 Upgrade to latest GGS 1.6.7.x 8 HAD-2409 Automate testing of Forward geocoding UDF on HIVE 8 HAD-2218 Documentation of Geocoding jobs with "Download Manager" 5 HAD-2108 Spark Geocoding API - simple augmentation 8 HAD-1004 Automate testing of spatial UDF - Measurement Functions 3 The work we Committed to (66 pts) = Incomplete Stories
- 19. Key Summary Points HAD-3118 Rename Point hive UDF to ST_Point 3 HAD-3023 Update Automation to use m5 instances 3 HAD-3105 Exception during hive geocode output processing causes query to fail 3 HAD-2821 GEF PIP and Address Hardening on HWX, EMR, and Cloudera 3 Things we brought in (12)
- 20. Sprint duration: 9 days (Mar 7 – Mar 19) Sprint Statistics During Sprint Points Committed To: 66 Additional: +12 Not Completed: - 26 Total: 52 Sprintduration:9days(Feb 6 –Feb 20) 20 Sprint Statistics During Sprint Points Committed To: 65 Additional: + 0 Not Completed: - 46 Total: 19
- 21. Story and Critical Bug Demos… Key Summary Demo HAD-2108 Spark Geocoding API - simple augmentation Chris
- 22. My detour into ScrumMastering • Every Agile team has a ScrumMaster to facilitate daily standups, planning, retros, and other meetings. Often this is a team member who has another primary role on the team. • The SM monitors the impediments brought up by the team to get resolution on them. • Our SM went on a year-long maternity leave, so I took over. It gave me invaluable insight into all facets of the project and a liaison with upper management, who we had to report out to every month. • A year later I took a course, passed the test, and became a Certified Scrum Master (CSM). It’s a great credential to have in today’s workplace. https://scrumalliance.org/get-certified/practitioners/csm-certification
- 23. What I like about working on an Agile team • Writers have more input and insight because they’re involved on a daily basis, in planning, sizing, retros • The opportunity to work in different roles • All work is visible and everyone is accountable • Developers and QA help me and I help them in turn, lots of collaboration, we all have the same goal after all
- 24. What I dislike about working on an Agile team • Writers still get crunched at the end of the release. Meanwhile the developers will have moved on to the backlog for the next release. By the time I finish publishing and localizing the current release, I’m already behind for the next. (Technical Debt) • It can still be very Dev-centric. I lose hours listening to discussion about automating tests and fixing build infrastructure. Usually only 1 writer per product supporting multiple dev teams, so we’re in the minority. • It’s easy to get in a rut with the planning, demo, retro cycle (lather, rinse, repeat)
- 25. Turbocharging my career • I’ve gotten experience in all roles of a software engineering team • Employers are looking for Agile, Scrum, the CSM credential & experience • I am part of a team with equal say, very fulfilling, team members and other engineering counterparts approach me for input and assistance • I’ve been promoted twice since we switched to Agile
- 26. Turbocharging our profession • Docs are considered equally important as code and test and must be completed as part of a feature’s development for that feature to be considered DONE (Definition of DONE!) • Working on an Agile team involves writers in the day-to-day decisions, highlights our value to an organization
- 27. YMMV Your mileage may vary of course, but in my experience Agile has increased my job satisfaction and contributed to my career success.
- 28. Any Questions?
- 29. Thank You
- 30. Have a great trip…. Slides are available on SCHED and SlideShare.net #stc_spectrum & #techcomm @MEDedicke maryelise.dedicke@pb.com
Editor's Notes
- Hi everyone! Welcome to The Agile Writer Road Trip – How I Cruised to a Great Career My name is Mary Elise Dedicke, but a lot of people just call me Mel
- A little about me…
- Ok, time to start your engines! This is a crash course on working as a tech writer on an Agile team, where everyone’s contribution is considered equal and team members can take on any role. 12 years ago I joined MapInfo, a mapping software company in Troy, NY. MapInfo was acquired by PB in 2007. In 2008, PB embraced (well, dictated) a switch from the Waterfall Method of software development to an Agile/Scrum approach. It was a corporate-wide, organizational and cultural change. Originally we had separate groups with their respective managers: Docs, QA, Dev, Project Mgmt. Now we had development teams for each product with a mix of roles all reporting to the same manager. One writer per team reporting to a dev manager. The company hired Pollyanna Pixton a consultant from Accelinova to hold Agile bootcamps.
- As we learned in our bootcamps, Agile came with a whole new vocabulary as you can see in this word cloud. Our self-organizing teams would hold daily standup meetings aka Scrums At the end of every iteration or sprint we would demo our work, hold a retrospective, and plan for the next sprint Work is listed in a backlog, each item is a user story that represents some customer value. User stories are created by the product owner and prioritized in the backlog. We use an Atlassian system called JIRA to create and manage our backlogs and sprints. What’s the difference between a pig and chicken? Ham vs eggs https://www.appster.com.au/blog/more-on-agile-development-what-you-need-to-know/
- So here is a graphical depiction of waterfall versus Agile. Waterfall project management, the traditional approach, involves an in-depth upfront planning process and follows a linear, pre-determined project schedule over a period of time. Waterfall projects are typically predictable, have a definitive start and end date, and have an explicit process for execution with phases that usually finish before the next one starts. Agile project management is an iterative approach that aims to deliver the highest value work possible within a limited amount of time. Those iterations or sprints are the loops you see here. Agile development often occurs when technology is changing, teams are changing, or the goal of the project is changing. The essential goal of Agile is to stay nimble and be able to adapt to changes rather than being forced to execute against a plan which may be obsolete. Image: http://blog.planview.com/waterfall-or-agile/
- Waterfalls can still be fun and beautiful, like this one in Hawaii where my kids swam last summer. Waterfall can work in a predicable, stable environment.
- In Agile, I not only write docs, I get to wear many hats. I test features like a QA engineer, and write up bugs that I find. I play ScrumMaster when needed. I act like a developer when I edit string files to ensure UI text and error messages are clear and “error free,” and embed context-sensitive help directly in the software.
- Yes, the writer checks in code and breaks builds, join the club! Big Mouth Billy Bass is the 2nd generation of fish we pass around to whoever breaks the build. It’s a badge of honor. Sort of.
- Here you can see our continuous build system, TeamCity. Every code check in gets compiled and tested here so we always have the latest working code available for everyone to use. But you can see where, I, Mary Elise Dedicke, have broken the build and turned it red. uhoh
- If you break the build, own it! as long as you take accountability for fixing it or least investigating it, it’s all good.
- And…here you can see because I’m a good, accountable team member I have assigned myself to investigate the build failure that may have been the result of my checkin. So I don’t impede the team in India when they come in the next morning.
- We work in 2-week cycles where all code, testing, and docs must be DONE (i.e., shippable)
- This is my team in our dedicated scrum room. We meet here daily for standups, weekly for backlog sizing, biweekly for demos/retros and planning. We have the monitor for showing JIRA and conferencing in chickens or remote workers. The poster on the wall is an information radiator provided by our UX rep that lists the characteristics and needs of our potential users and customers as a constant reminder of who we’re doing this work for.
- This is a sample of the demo slide deck our team recently did during the Olympics. We like robots. They bobsled, they speed skate.
- We remind our audience who is on the team. A set of quirky human beings.
- We revisit the purpose of the demo so no one gets off track about pet peeves and wants.
- We show a JIRA report of what we committed to in planning for the sprint, and show what got done, and what we didn’t with some explanation of why but not a big long rationalization.
- And we also show what was brought in during the sprint after planning, since we’re Agile sometimes critical bug fixes or features need to be added mid-sprint.
- Our production is measured as velocity, how much work we got done in a given sprint. Managers care a lot about velocity so we can have an ever-improving sense of the average amount we can get done in a release, it helps them with release planning.
- BUT the gist of the demo is the Demo. Not a lot of talk and slides. Time to show it off and get feedback.
- Took a 2-day course offered at work Took test online, you must correctly answer 24 of the 35 questions, multiple choice. It’s a great credential and your boss will love to have something to brag about.
- Ask audience if they work in Agile, any thoughts to share?
- Agile experience has made me more marketable and increased my job satisfaction.
- Hit the gas!