The OveractDev Team Structure

OveractDev Teams consists of cells of approx 4 engineers and one QA Lead.  Some number of cells are deployed to fulfill a Project under direction of the Fulfillment Lead

OveractDev Team Structure

OveractDev teams are deployed to complete Projects.  Each Team works under the direction of a Fulfillment Lead (aka Project Manager).  Teams are composed of Cells consisting of 4-5 engineers and one QA Lead.

Posted in Uncategorized | Leave a comment

OveractDev White Box Engagements

  1. OveractDev White Box engagements are all and always Team engagements
    1. Team Members are never isolated, neither Heroes nor Villians, in front of our Client.  We succeed and fail as a Team.
    2. Team members with daily collaboration must elevate issues to the Fulfillment Leader as needed.
    3. Tasks are implicitly assigned to the OveractDev team, not just to one individual.
      1. each team member relies on the rest of the team to complete the assigned tasks.
      2. the Team accepts responsibility for the completion of all tasks assigned to each member of the team
        1. Some Clients and some task management systems require us to assign a task to an individual.  Our Clients are informed that, even though the task is assigned to a single team member, the responsibility for completion of that task (and all tasks) belongs to the entire team.
      3. Ultimately, the responsibility belongs to OveractDev.  It is part of our brand, our reputation and our commitment that our work will be completed on time, it will work as specified, and it will have a minimum number of bugs.
    4. Team members assist each other with task completion for the following reasons:
      1. to cover for a team member that will be absent or is overloaded in some way.
      2. a complex aspect of the task goes to another team member’s expertise.
      3. a simple aspect can be completed by another team member, working under direction.
      4. to cross-train team members for team agility, transitions, increased bandwidth, etc.
    5. We consider the question of how we complete assigned tasks and, specifically, how we deploy our team resources to complete these assigned tasks to be an internal matter.
      1. This policy is NOT related to our transparency.  The point of this policy is to make clear that we need to make these decisions on our own.  That said, we are more than willing to discuss these decisions as they are made, or even as they are anticipated.  Also, during the SCRUM it will be clear who is doing what.
        1. Note: SCRUM reports are made by the Team member to whom a task is ASSIGNED.  If the Team member was assisted in some way (on a complex of simple aspect of the task), the member who assisted with the task usually does NOT need to report to the SCRUM.
    6. We support the process of having our clients interview Engineering/Technology Leads to determine our competency with certain technologies and/or tasks.  For example, if we will be asked to develop an application using Flash, we will identify the team member who has this expertise and will be accountable for the completion of the Flash work.  However, the Client understands that the Lead who is interviewed is the point of contact and the responsible person.  This interview does not alter any policy outlined above.
Posted in Discipline | Leave a comment

The Project (aka Initiative, Engagement)

A Project is a undertaking initiated by an OveractDev Client for a specific purpose – with a start date, end date, and budget; as defined in the Project’s Business Model.

Fulfillment, Fulfillment Cycle

At OveractDev, we use the terms “fulfillment” and “fulfillment cycle”.  These terms refer to the procedures we use to complete a project for a client on time and which meets the expectations of the stakeholder. We define our success as having completed a project which fulfills our client’s expectation for timeliness, robustness and quality.

The Project fulfillment cycle includes iterations of:

  1. Phase Planning
  2. Requirement Change
  3. Sprint
    1. Sprint Planning
      1. Retrospection
      2. Product to Sprint Backlog transition
        1. Dev estimate
      3. SOW submission
    2. Sprint Execution
      1. Implementation
      2. Daily SCRUMs
      3. Deployment
      4. Invoice submission

Phases and Sprints

All Projects are broken down into Phases, each one having a defined strategic objective.  Phases have a duration of 3 months to one year or more, depending on the project.  Each Phase is completed in a series of Sprints.  Sprints have a duration of one week up to 5 weeks or more.

Phase Backlog (aka Agile::Product Backlog)

  1. A Phase Backlog is maintained for each Phase.  The Phase Backlog is a collection of requirements (features) that must be completed for a Phase to be successful.
  • the list is prioritized indicating the most urgent, most important, optional requirements, etc.
  • Each requirement needs to be precisely specified so that it is “testable”
    • A “testable requirement” is a description of a feature that
      • considers all Actors, Triggers, and Preconditions
      • considers all Stakeholders affected by the feature
      • considers all alternate Scenarios including:
        • error conditions & failure modes
        • conditional steps
        • optional extra steps and optional omittable steps
      • is described precisely and robustly enough for QA to clearly distinguish a satisfactory or unsatisfactory implementation of the requirement, once Dev has implemented the feature.

Sprint Backlog

At the beginning of each Sprint one or more items in the Phase Backlog are transferred to the Spring Backlog, indicating the intention for that item to be developed during the Sprint to which it is assigned.

For each item accepted into the Sprint Backlog, the developers provide an hour estimate for its implementation.  A running total of these hour estimates is maintained during Sprint Planning.  When this total hour-estimate equals the burn rate of the available dev resources, the Sprint Backlog is considered “full” and no more items can be accepted without risking a failure to complete all items assigned to a Sprint.

Posted in Discipline | Leave a comment

Incentivized Qualities and Metrics for Measuring

As we discussed, here are the qualities we want to promote through our incentive programs:


 

  1. leadership – To what extent do you:
    1. help your team mates grow and complete their work?  
    2. show willingness to be the Driver on various projects and initiatives?
    3. set an example in all aspects of your work and demeanor?
    4. teach and train others?
    5. maintain and project order and a positive, creative frame of mind?
  2. ownership – To what extent do you:
    1. develop an understanding of the Business Model? …what the stakeholders want and why…
    2. develop an understanding of the overall architectural plan for the project, as well as the milestones, etc.
    3. work as if:
      1. the client is your client?
      2. the project is your project?
      3. the OveractDev team is your team?
      4. OveractDev is your company?
    4. work as if you can make a difference?
  3. mastery of discipline & technology – to what extent do you
    1. show personal pride and dedication to your chosen profession?
    2. if you are a software engineer:
      1. mastery of paradigms: object-oriented, component-oriented, function programming, declarative programming, etc.?
      2. mastery of design patterns, database normalization, modeling (UML, state, database), etc.?
      3. mastery of key platforms, development stacks, etc.?
      4. mastery of CM and SCM?
      5. mastery of principles like Agile, waterfall, product-life-cycle (PLC), etc.?
      6. mastery of key technologies and emerging technologies?
    3. understanding and apply knowledge of how your mind works in various modes: analytical, creative, inductive, deductive, idealistic, realistic, pragmatic, etc.?
  4. teamwork – to what extent do you:
    1. insure you have the support of the teams in which you work?
    2. support the other members of your team?
    3. take care to not isolate a fellow team member – IOW, to insure we win and lose as a team.
    4. take care not to isolate yourself by bragging, soapboxing or otherwise, working outside your support team (project managers, etc.)?
    5. edify your teammates to our clients?
  5. rapport building – to what extend do you:
    1. learn new communication skills – better ways to listen, ask questions, dovetail understandings, and assert for your or our point of view?
    2. show your team mates and our customers that you care about them and their needs and concerns?
    3. project competence in your and our ability to do excellent work and amaze our clients?
    4. resolve conflicts when they arise?

 


And, here are the metrics for recognizing progress in those qualities:


 

  1. growth – 
    1. what are measurable improvements you have made since the last review?
    2. what definite steps (books read, courses attended, etc.) have you taken to grow since the last review?
  2. service above baseline – 
    1. how has the quality of your performance EXCEED baseline expectations for your title/position/salary level?
    2. what have you done to maintain your excellence?
    3.  what did you do that was amazing?
  3. stars
    1. because of the quality of your performance, what specific outcomes were achieved by our clients or their stakeholders, by your team members, or by OveractDev?
Posted in Uncategorized | Leave a comment

The Role of QA

QA is involved with a number of areas in the fulfillment cycle:

  1. Product Backlog Planning – The intended result of Product Backlog Planning is to maintain a Phase Backlog of prioritized testable requirements sufficient to fill one or more upcoming Sprints.
    1. Note: These requirements transfer from the Product Backlog to the Sprint Backlog during the Sprint Planning Meeting.
    2. For a requirement to be a candidate for transfer to a Sprint, QA must certify that it is “testable”.  See Phase Backlog in The Project topic for the definition of testable.
  2. Development – QA has a role in development:
    1. Insure developers understand the requirements
    2. Insure developers are using good quality practices:
      1. adequate testing before code is moved from the developer’s local machine
      2. peer-code reviews are being done
      3. unit testing is being created and/or updated
    3. Validate developer’s unit tests and in-code assumption assertions.
    4. Help developer maintain automated test and build scripts.
  3. Bug Backlog – QA participates in
    1. collection of new bugs
    2. insuring bugs submitted by non-QA people are well-described
    3. participating in bug review committees in rating the bugs for importance and urgency.
    4. follow-up on bug status & resolution.
  4. Testing
    1. Test Planning
      1. defining test plans for full Regression, Sanity, Integration/Functional
      2. defining candidates for Automated test
    2. Writing Automated Tests
    3. Manual Testing
    4. Creating build environments that automate test execution.

Notes:

  1. The first three QA roles (Product Backlog, Dev, Bug Backlog) described above are intrinsic to OveractDev’s fulfillment cycle.  Therefore, they are never quoted separately nor can they be left unfulfilled.  Note:  various clients may do a greater or lesser job of completing the above work through their own QA department.  In this case, the amount of work our QA does to insure that the work is completed will vary widely.
  2. QA::Product Backlog and QA::Bug Backlog work is included in the Project Management estimate and billing.
  3. QA::Dev and is included in the Dev Estimate, and they are not broken out separately in the Dev estimate and billing.
    1. Full Deliverable – When effort hours are calculated for a task or feature on the Dev estimate, we say that the estimate shall be for a “Full Deliverable”.  A full deliverable includes:
      1. implementation of a feature that works as specified with a minimum number of bugs
      2. coding, implementation and deployment that conforms to our quality standards and practices.
      3. unit testing, as needed
      4. QA fulfillment of the Dev and Backlog roles, as needed
      5. therefore, if, for example, if we estimate building a DB table of 3 columns as 4 Function Points * 2 hrs per FP = 8 hours, this estimate of 8 hours is for a “full deliverable”, as described above.
  4. QA::Testing is the only role a Client may purchase from OveractDev, and it is quoted separately on the SOW.


Posted in Roles | Leave a comment

Policy: Contributors

OveractDev does not rent people to our clients. Clients engage OveractDev as a company to fulfill whatever requirements they have for us. We reserve the right at all times, to engage whichever internal resources we feel will best complete the requirements. Internally, we work as a team.

I tell clients that they are free to assign tasks/bugs/tickets, etc., to whichever OTP team member they like. But, that does NOT necessarily mean that the named person will complete the task, or that they will complete every part of it by themselves.

One of our client-facing roles is the Engineering Lead. This is the person the client should look at to determine if we have the necessary skill set to fulfill the requested work. If the client is satisfied that the Engineering Lead has the appropriate skill set, it is then up to the Lead to determine how much work his team can commit to.

Also, we do not want our clients interviewing each member of the team. This sends the wrong message. It is up to the Lead to select members for the team and to determine how much work his team can commit to.

This is our policy. We will generally refuse an assignment for a client that is not willing to work with us in this way. Any exceptions should be approved by the President before we agree to a client request for an exception.

Hiring:

In line with this policy, the following hiring policy is also in effect: we hire Contributors BEFORE allowing the client to interview them or even review their resume. It is up to us to hire people that are first, right for OveractDev and, second, right for the client. Also, we generally do not hire Contributors for a single project. In other words, we need to be able to justify a hiring decision based on our long term need for that Contributor.

Posted in Uncategorized | Tagged | Leave a comment

Truth in Advance

“Never delegate responsibility but allow people to TAKE it.” ~unknown
“You are not paid for how hard you work or how many hours you work.  You are paid for the quality of your thoughts.”  ~Jerry

Clients will often ask us whether we can do something, whether we have experience with a certain technology, or some similar question.  This post discusses how we handle a question like that at OveractDev.

Clients who ask this type of question are often trying to determine whether they can TRUST us to complete a task for us BASED on our past experience.  Engineers will often handle this question literally and “realistically”.  So, they will truthfully reply: “No, I have not worked with that particular technology (e.g. iPhone app, VMWare, Selenium, etc.). “

However, if this IS a technology we want to master, if this IS a task we want to do for this client.  there is a better way to handle the question.  It is called, “changing the base”.  Changing the base refers to altering the way the client makes their decision, FROM: do they trust us based on our past experience? TO: trusting us because we are willing to take ownership of completing the task successfully and on time.

So, if asked, for example,”Do you have experience writing iPhone apps?”, assuming iPhone apps is an area we wish to master and we would like to do it now, for this client, on this task; the reply that TAKES ownership is: “Not as much as I would like but, I promise, if you assign me the task, I WILL complete the task on time.” The first part of the answer can vary a bit but the punch is in the second part – take ownership. Allow them to delegate responsibility to you.

The fact is, new technologies arise all the time.  And, we have mastered many of them.   We will continuously be mastering new technologies as long as we work in software.   Truth in Advance is when we KNOW that we can accomplish something that we have not yet mastered or sometimes, have not yet figured out HOW we might accomplish it.  It is based on knowing that we will work hard, that we will do what ever it takes – and, most important, we have to trust our proven ability to think quality thoughts.  We trust ourselves to be successful and on time.

When a client senses this from us, they have NO problem saying: “Right on.  Make it happen.”  And, you now have the job.

Posted in Uncategorized | Leave a comment