Developers have lives too!: Being a web developer in an Agile environment.

Are you a web developer that is constantly overloaded with work? Does your project seem like it's pushing you towards the exit door? Is your work life starting to take a toll on your life outside of your job? Then this is the session for you!

Over the years, I've worked at a handful of firms that always claimed to do agile, but literally none of them did. Outside of using Jira, there was nothing agile about them. I was always overworked, overtasked, under managed, and often, overlooked.

I found myself working 15 hour days (or longer) on a regular basis. I never had time for myself because I felt like I had to be in front of my computer working. There was even a time that everyone in my office, except me, went to a happy hour. I couldn't go because the client was waiting on me for something because my deadline got moved up by my own project manager!

I was in a band at the time, and we had to go on a 5 month hiatus. Then my wife and I decided to start a family. How would I ever find the time for kids, music, or any other activities I wanted to do when I felt like I was constantly under water???

Enter my latest project and team: Farmers.gov and MetroStarSystems.

I've been with MetroStar for about a year and half. Compared to past companies I've worked for, Metro Star does a great job listening to their employees and, most importantly, making sure they aren't overloaded. This is where Agile really plays an important role.

Being a web developer in an Agile environment means that you have a voice. Don't be an "oh yeah, I can do that" person and let your project manager or scrum master bog you down. You have a life outside of your work just like they do. Make them understand that, when you give a WIP value to something, it has to be realistic and everyone has to stick to that. Feeding more work into the sprint has consequences for everyone, and most importantly, for you.

I fully expect for this session to turn into an "airing of grievances", but I think everyone in attendance will walk away with some helpful solutions to your overbooked work schedule.

 
1 favorite thumb_down thumb_up 1 comment visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/Structure of the Talk

We'll discuss a few things in this session:

  1. First, I'll go over examples of how my previous jobs said they were doing Agile and explain how they definitely were not.
  2. Next, how to be more accurate with a development task and your WIP limit. If you don't know what those are, we'll discuss them. None of my previous jobs had WIP limits and this is an absolute must for a developer.
  3. We'll discuss writing acceptance criteria with developers FOR scrum masters and project managers
  4. Lastly, we'll discuss moving through a sprint with your tasks and current WIP limit and hit on things like sudden tasks that get dropped on you and how to manage them, or what to do when a resource quits suddenly and leaves you hanging in the middle of an iteration.

Basic Agile Terms for this talk

  • WIP
  • Sprint
  • PI

Examples of poor "agile" methods

Examples of current agile method with my current team and project

How to write acceptance criteria with developers FOR scrum masters and project managers

Developer WIP limits: Being realistic

Scrum Master and Project Managers - Stop bothering developers

Learning Outcome

For developers: how to manage development tasks and how to make reasonable tickets while also not going over your WIP limits (or at least getting close to your limit).

For scrum masters: getting accurate user stories and tasks from your developers.

For project managers: how to manage developers accurately and manage expectations of your clients without killing your devs.

Target Audience

Developers, scrum masters, and project managers

Prerequisites for Attendees

Understand common agile terms like scrum, PI, and WIP.

schedule Submitted 2 months ago

Public Feedback

comment Suggest improvements to the Speaker
  • George Dinwiddie
    By George Dinwiddie  ~  1 month ago
    reply Reply

    I like these aspects of the submission, and they should be retained:

    • The content looks interesting

    I think the submission could be improved by:

    • Moving the numbered list from the abstract to the outline
    • Thinking of whom you would like to attend this session.
      • Who would enjoy it?
      • Who would benefit from it?
    • Rewrite the abstract so that those people recognize themselves and the value they will receive
    • Rewrite the title so that it grabs the attention of those people.

     - George, Program Chair