Category: Project Management

Agile Delivery Lead

Amy1 Comment

Last November a change was made to the composition of our development teams.  I had been working as a team lead since the previous March and things were going really well.  But a gap in the department was identified and I was asked to change roles to fill it.   My new title became “Software Engineer – Agile Delivery Lead”, yes it is a mouthful but it encompasses what I do.   Almost 6 months later I have settled into my new role and we have been slowly defining what that means for our teams, department, org, and myself.   I’m still working on what my duties entail.   For right now I have identified a list of responsibilities that are on my plate and we prioritized them based on how much I can help by performing each role.  As with anything, it changes constantly.

#1 Team Support:  Keeping the teams moving and the work steadily flowing onto our production systems is the first priority that I have on my plate.  I currently work directly with 2 development teams and keep my ears open for what 3 others are working on.  This includes activities such as Daily Standups, Weekly retrospectives, quarterly retrospectives, team velocity reporting, and managing the “Coming Soon” part of the team backlogs.

#2 Product Manager Support:  Working with the product managers to help to research potential improvements to the systems and start scoping out the work.   Research, reporting, epic/ticket creation, determining order of the work to get done, backup for the team when the PMs are out, and reviewing the work completed.

#3 Senior Software Engineer: Utiliziing my skills as a Sr. SE in the department to help move the platform forward.   Estimating, documentation, cross-training, code reviews, backup for Engineering Leads, architecture, and special projects.

#4 Department support:  Helping upper management with keeping a pulse on the various teams and making sure things are flowing smoothly.  Team velocity reporting, department velocity reporting, process research & implementation, and help to manage engineering needs backlogs.

#5 Personal Projects:  Continue to grow my own skills and knowledge by doing projects that will help the team, department, and company work more smoothly.

Dev Team Lead Resources

AmyLeave a comment

Articles

Books

Quote: Team Goals

AmyLeave a comment

My mission is to create teams that change the world.

I began this mission as a software developer. I saw in myself and other teams a passion for creating products that people would use and love. I saw that same passion dashed over and over again when the products fell flat. I knew there was more out there.

I have sought for years to find ways of enabling teams and organizations to have a different story. One where the hard work pays off. One where people take pride in a job well done and a product that people love.

I’m a long way off still from saying my mission is accomplished, but I’m here to share what I’ve learned and to help people find that new story.

~ Ryan Latta, LeanAgileUS 2019 bio https://twitter.com/recursivefaults

The Programmers Oath by Uncle Bob

AmyLeave a comment

The Programmers Oath by Uncle Bob

In order to defend and preserve the honor of the profession of computer programmers,

I Promise that, to the best of my ability and judgement:

  1. I will not produce harmful code.
  2. The code that I produce will always be my best work. I will not knowingly allow code that is defective either in behavior or structure to accumulate.
  3. I will produce, with each release, a quick, sure, and repeatable proof that every element of the code works as it should.
  4. I will make frequent, small, releases so that I do not impede the progress of others.
  5. I will fearlessly and relentlessly improve my creations at every opportunity. I will never degrade them.
  6. I will do all that I can to keep the productivity of myself, and others, as high as possible. I will do nothing that decreases that productivity.
  7. I will continuously ensure that others can cover for me, and that I can cover for them.
  8. I will produce estimates that are honest both in magnitude and precision. I will not make promises without certainty.
  9. I will never stop learning and improving my craft.

Requirements: The Expert (Video)

AmyLeave a comment

This video has been floating around for a while now. I found it hilarious. But in reality the more I think about it and the message in it the more true it seems to be. I wish it wasn’t true but it is. Pulling requirements out of users who aren’t sure what they want can be difficult, if impossible at times. It takes a skilled person to be able to design software for users like these.

Managing a large project backlog

AmyLeave a comment

Question on Programmers.StackExchange.com:

Do you have any particular style of organizing projects? LINK

Edited copy of my answer:

First have each developer look at each of the items and review/test each item to see if it is still an issue (it may work best to split these up amongst people). Then close any that are no longer an issue or have already been taken care of with other development efforts.

Now make sure that each are marked as either a large, medium, or small development effort. This is a very rough estimate just used to more easily categorize the projects and to help to pull things together. If everything is already estimated then it will help but don’t get hung up on the hours. Just go with a quick gut check. It often works to get the develpers in a room and just go through each item and use the effort that the majority of the people feel is appropriate.

Review each of the three effort groups and mark each item in the group with a priority of Critical, High business value, High Technical value, Medium value, Low value, and Never going to fix.

By this point you really know the list inside out and really understand the work that is involved in your backlog and you can start to really make a decision on what to do with the items. Take all the items that are marked as never going to fix and archive them out of your backlog.

Now when you schedule the items to go into your next release you can use the critical and high importance items as the core of your release. Review the list of medium and low priority items and add in any that can be worked on at the same time as the other items in your list because the developers will already be working in that part of the system.

The list of items marked with medium or low prioity can be used as a list of things for people to work on when they have a bit of spare time or as training for new employees. I always find that it is nice to have one person on the team during every itteration working on these items and helping the rest of the team where necessary. This way you are still completing work on the current itterateion but have someone that is flexible and can help put out fires when needed but is handling the issues that wouldn’t normally get attention.

One thing that we found was nice was that between each itteration we had a short 2 week period where the entire team would only work on items that were marked with a small development effort. We would focus closing a large number of tickets in a short time.