CT2 Team Processes and Resource Allocation Update for Oct Nov 2010

From UG

Jump to: navigation, search


Contents

[edit] Author of this article

Alex (IT/Software Dev Manager, Lead Architect)

[edit] Introduction

Most recently IT/Software Dept experienced the following:

  • one more BA has been added
  • number of projects grew significantly
  • number of unexpected releases doubled and pressure mounted
  • quality dropped

To address the above I had to re-design some of our workflows and create new roles. This should streamline our operation, reduce stress and bring quality back to normal.

Please read carefully. Let me know if you have questions.

[edit] Allocation per Module

Everyone will have their own set of modules to own and work on. This will add focus, reduce communication overhead and stress.

This is already how we operate in 60% of cases. I decided that there is a value in making this a norm.

  • I reserve a right to assign a task to you from another module in the future if I see that load is unequal. But do not allow this for anyone else and let me know when this happens.
  • New modules and projects will be assigned as they come in
  • I might re-assign modules if I see that current structure does not work. I will not do it too often. Let's review this in 1 month.

[edit] Allocation Per Module Nov Dec 2010

(Module / BA / SA(QA)):





Current list of modules as displayed on a wiki homepage:

[+] Acc
[+] Client
[+] ClientEtc  (Shipper, Agent, etc)
[+] Misc       - not a CT2 module; tasks related to Architecture, Speed, Internals, IT, DB, PM, LA, etc
[+] OpsAdmin
[+] OpsCore
[+] OpsMisc
[+] OpsPdfs
[+] OpsReps
[+] OpsTruck  (NATP, TMS, etc)

[edit] New Roles

[edit] BAs doing more SA like work and SAs doing QA for some projects

It is agreed that BAs will:

  • provide more detailed requirements more often
  • provide suggested design more often
  • will become more technical

Based on the above SAs will in many cases just have to review spec from BAs and discuss (before it is assigned to developer into Dev Est). And will not have to add too much to a spec. Of course in some cases they will have to.

In many cases SA role and QA role is done by the same person - see #Allocation Per Module Nov Dec 2010.

[edit] Sprint and Release Manager role

Tira will play this role. Responsibilities:

  • based on priorities negotiate and compile tasks for each Sprint/Release
  • monitor Sprint progression, resolve problems
  • tag released mantis tasks with release number
  • distribute release notes

[edit] Release schedule

Tira, please create release schedule (together with Kostya) for the next 6 months. Allocate 1 release per month. Post into our shedule.

[edit] Emergency releases

Emergency release can be scheduled only if very serious bug was discovered after regular release. It can not be used as a way to add new features in advance of regular release.

[edit] BAs in a role of Project Managers

BAs will have to play a role of project managers for their components and projects assigned.

It implies managing MOs expectations in terms of when features will be released. It could be hard. Please ALWAYS follow procedure:

  • finalize detailed requirements
  • set priority
  • wait to set any expectations until tasks are estimated by developers
  • after estimation was completed negotiate with Release Manager in what Sprint/Release these features could be included
  • notify MO about the release date

Remember that trying to skip steps in the above sequence may lead to a lot of problems. Escalate to upper IT management if there is a conflict.

On another hand BAs will have to interface with and manage implementation team:

  • Make sure that they are on time,
  • manage communication
  • collaborate on a best design
  • Escalate to Lead Dev Manager in case of issues
  • every morning use 3 hours overlap with Remote Team to review what was completed and discuss new work
  • for urgent tasks / tight schedules:
    • ask QA to report on what was completed
    • do UAT right away to confirm his result

[edit] Remote SAs and QAs in a role of Coordinators

In case of large changes or projects SA must:

  • play a role of coordinators that coordinate work of remote developer and QA
  • they are communication medium between BA on one hand and QA/Developer on another

If remote SA is not a part of the project then remote QA must play his role

[edit] Lead Architect role

I will play this role. The goal is to have one senior engineer overview entire project, review work of BAs and SAs, help, advise, spot problems.

Responsibilities:

  • review tasks in Backlog and move tasks to LA approved
    • LA approved is a folder from which BAs can take tasks and move them forward
  • review tasks in LA review folder
  • start new projects
  • develop and maintain proper software development processes
  • etc

[edit] Lead Development Manager

Lead Development Manager is responsible for overall coordination of remote Implementation Team. Everyone on that team reports to him. This role is played by Kostya. If you have any serious issues (quality, time, etc) you can escalate to him.

[edit] Support Coordinator role

Now that we have 1 more BA and breakdown into ownership of components we can utilize support coordination.

See more in #Workflow for Support

[edit] Release and IT Admin

Just to remind you. Releases on a technical side are managed by Paul. Any server / network assistance as well.

[edit] Updated workflows

[edit] Workflow for Bugs

No changes - assign(completed) bug report directly to developer into Dev folder

[edit] Workflow for Support

I will be a Support Coordinator for incoming support requests (later Tracy will play this role).

All, please forward all incoming requests for support to Support coordinator if they come directly to you.

Workflow:

  • support tasks will be assigned to BAs (modules they own only)
  • every BA must check Support folder once a day to see if there any tasks assigned
  • BAs, allocate 1 hours a day for Support tasks
  • BAs, you can assign non urgent support tasks to remote SA or QA who are assigned to your module
    • This make scene if you are busy or it is the end of the day and remote SA/QA can potentially resolve it before start of the business day tomorrow
  • Note that this process is optimized to minimize interruptions so do not interrupt yourself by checking Support folder too often
  • It is agreed that support must be done through e-mail only, do not take phone calls

[edit] Workflow for tweaks

Requirements for Tweaks/minor changes BA can assign directly to Developers in Dev Est folder

[edit] Workflow for major changes

  • Requirements for large changes and new projects must be assigned to SA first.
  • After that SA should post their spec into LA Review folder

[edit] Workflow for new projects

  • LA will also often start new large / challenging project, develop approach, create work breakdown structure (WBS) before handing it down to BAs/SAs.
  • After that workflow is the same as for major changes

[edit] Workflow for UAT

For minor tweaks UAT is to be done by BA.

For major changes and new projects SA should be involved in QA or/and UAT. SA must transfer knowledge of a solution created by him and and implemented by developer to BA (transition to Support).

[edit] Workflow for Wiki update

For minor tweaks Wiki update is to be done by BA.

For major changes and new projects SA should together with BA transition to "project wikis/mantises" into "standard wiki/mantises" after projects are completed / released.

[edit] LA approved folder

Most of tasks will not be assigned to BAs. Instead they should pull tasks by themselves from "LA approved" folder.

[edit] Misc To do

Everyone, please:

  • review wiki and mantis parents for components and projects you own. A lot of them are missing or misplaced. Please update them to reflect current state of the system
  • schedule one on one time with me to go over introduced changes and over all your components, subcomponents, projects, tasks to clarify your front of work going forward
Personal tools