Skip to content
GitLab Next
Closed
Created by Katherine Okpara@katokpara🤓Contributor

Development Team Lead Persona

The Development Team Lead persona resulted from interviews with industry professionals who manage teams, estimate capacity, assign development work, and monitor the development of software applications. Interviewees were asked questions about their daily duties, goals and motivations, challenges they face in their roles, and the tools they use throughout the software development lifecycle.

Persona

Interview Notes

Top Challenges


  • Delivering on-time
    • "...the balance between having good peer code reviews being done in a reasonable time frame while still making daily progress on their own tasks. Someone might see a code review request but feel conflicted since they only have two days left to finish their own tasks. So sometimes testers and customers are waiting on these code reviews to move forward. Balancing priorities and capacity. Reprioritizing and setting different expectations after that point. The biggest thing would be having all those tickets, all of those changes, closely correlated with the actual changes in Git. 'For this particular feature, here are all the changes in Git.' You don’t have to read the codebase or fire up the whole application. You have the information all-in-one place and don’t need to hunt down information."
  • Receiving clear requirements and improving communication
    • "Sometimes the back and forth can be annoying. When the requirements aren’t clear and I have to go back a step to understand what is going on or a component is not what I wanted. In a previous company, the back-and-forth was especially drawn out since the team did not work closely together. At this company, this problem isn’t as severe since I work closely with the team and can quickly ask for clarification if I need to. Working more efficiently saves a lot of time."
  • Changing mindsets in organizations to adopt faster, iterative approaches
    • "Most blockers that arise are put in their own way. I would prefer to iterate while they rather plan everything out for long periods of time. Their own processes get in their own ways because they don’t think they can move faster. Many of their processes are filled with errors and take days or weeks. They’ve always done things a certain way and are not really willing to make a change."
  • Making accurate estimations of timeline and capacity
    • “Having a predictable development cycle has been difficult since the beginning of time. Handling estimations for developers and being able to give partners a reasonable estimate that is not off-base. This goes back to the burndown chart - if it is being used correctly, it can help you see where you’ll end up. In order for that to happen, you need your estimations to be accurate. And in order for that to happen you need to figure out the accuracy of the baseline and experience of the developer. For example, someone who is more junior has less of a reference point. I have to assign extra points to stories, if there are unknown variables.”


Potential Next Steps

  • DevOps WorkFlow Issue Boards
  • Automatically update issues when an MR is deployed https://gitlab.com/gitlab-org/gitlab-ce/issues/28692
    • Configurable notifications? (e.g. I’d like everyone to be notified when X stage in the cycle happens)
    • "Automate the flow of product-critical information (e.g. artifacts such as Features, Epics, Stories, Defects) and other associated data (comments, attachments etc.) across the value stream." (reference: https://www.tasktop.com/blog/value-stream-management-in-software-delivery/)
  • Workload Estimations - trends over time (graph of point estimations vs actual time taken to complete cycle).
    • Add this information to a central location (for example, when a PM wants to assign a certain developer to an issue, where can they go to find the developer's "success" rate?)
    • “Looking at the developer’s estimations over time. Say they estimated the story to be 1 point. And over time you have 20-30 1-point stories from them. You could estimate the average 1-point story being roughly 2 days...So you now have a trend over time. And you can start getting an idea of the fact that when a developer says “1-point,” this is roughly the timeline associated with that. You can see how much time they actually take vs. what they say it will take. Here’s their rough accuracy of estimating and here’s the rough timeframe they associate with points (for ex: over time, 3-point stories mean 5 days). And integrate that into the burndown chart and then you can see roughly where they’ll land.”

Who I Spoke With (video recordings)

All Tools Mentioned by Interviewees

  • JIRA, GitHub, Microsoft Team Server, Aha!, CollabNet TeamForge, Google Analytics, Crashlytics

Keywords

Organization, communication, traceability, flow time, comprehensive, tangible, integration patterns, trends over time, agile estimation, story points, Fibonacci scale, velocity, stories

Limitations

Experienced some difficulty recruiting participants who had enough familiarity with/job duties related to value stream management.

Other Links

Edited by Katherine Okpara