• Permalink

    The use of Kanban to support a well defined Software Development Life Cycle

The use of Kanban to support a well defined Software Development Life Cycle

In our last blog I discussed how the Scrum process supported the Software Development Life Cycle. Partnet uses two different proven Agile development methodologies for development: Scrum and Kanban. A specific method is chosen based on the nature of the work.

Scrum: Used for complex projects where increments of work can be flexibly managed and assigned into sprints. Work assigned within a sprint can be completed without disruption.
Kanban: Used for less-complicated projects (e.g., Problem Reports) where priorities frequently change.

Kanban is a backlog-pull model that emphasizes just-in-time delivery of work and avoids process bottlenecks by limiting in-progress work. Kanban also allows for customer-driven prioritization as tasks are regularly prioritized to match their current needs. This means that if an emerging requirement suddenly takes precedence over existing priorities, the team can flexibly respond without affecting project goals or progress. Kanban uses the same Delivery Team roles and responsibilities employed in Partnet’s Scrum process. Partnet employs Kanban for Problem Report work since this work is often subject to shifting priorities.

Partnet’s Kanban process pulls new requirements from a Customer prioritized backlog. Tasks are created and assigned to release versions based on these priorities. The process defines a series of work queues that simultaneously identify the current status of a given development task, and the assigned resource.

Together, the work queues establish a linear workflow for completion of assigned development tasks, as shown below.

 Work Queues and Linear Workflows

Work Queue
Status

    Assigned Resource

To do
Backlog task; not actively being worked on by any project team member
   Backlog

Needs Requirements
Undergoing requirements analysis to define new functional requirements; assess impact to existing functionality
    Requirements Manager

Ready for Development
Requirements analysis complete or not needed

    Developer

Development in Progress
Development and integration underway; includes unit testing and code reviews
  […]

How Scrum supports the Software Development Life Cycle

Last month I did a blog series on the importance of having a well define Software Development Life Cycle. Today I am going to talk about a methodology which supports the Software Development Life Cycle to keep it on track and humming.

Scrum is an iterative software development framework that employs time boxed “sprints” to deliver software quickly and incrementally. Scrum’s short development cycles offer flexibility to react to change by demonstrating functionality at the end of each iteration, promoting frequent customer interaction, and having the customer as part of the team. Scrum is used for larger efforts where work can be prioritized in batches, with each batch being of a scope and complexity such that it can proceed uninterrupted.

A Scrum team is made up of a number of players with differing roles and responsibilities.

Roles
Responsibility

Scrum Master
Enforces adherence to the Scrum methodology. Responsible for removing impediments for the Delivery Team. Ensures project objectives are met while balancing constraints, budgets, schedules, resources, and risk.

Delivery Team
Responsible for delivering the work. The team is made up of the following roles:

Product Owner: The voice of the customer. Has the responsibility to deliver a successful product in terms of vision and features. The  Project Lead would be the ideal person to fill this role.
Requirements Manager: Elicits, refines, and manages the solution requirements
Architect: Defines the architecture and technologies employed by the software solution
Technical Lead: Oversees software design and development
Developer(s): Codes and integrates the software
Software Test Engineer(s): Validates the software against solution requirements; enforces applicable quality standards and documents identified defects
Configuration Manager: Stages and deploys software changes to Development, Staging, and Production environments
Data Architect: Defines data architecture and allocation of data assets
Database Administrator (DBA): Maintains database; manages data access, import/export processes, and migration […]

Part 4: Tera-Scope Contracts – Value Add or Gordian Knot?

In Parts 1, 2 and 3 of this series we have looked at the trend for Federal Information Technology (IT) procurements to enter into “Tera-Scope” contracts where all possible IT goods and services are brought under one massive Performance Work Statement.  Some Agencies are requesting all-or-none responses which are impossible for any one company to meet alone.  This adds further to the complexity by necessitating Teaming Arrangements that create groups capable of meeting all the task areas, experience requirements and socio-economic requirements of the RFP.  Some Agencies are creating their Tera-Scope RFPs but allowing companies to participate only in those areas representing their core competencies.  This simplifies the proposal writing process for the contractor and the evaluation process for the Government.

Ultimately a set of contracts will result that can be used by the target customer groups within an Agency, or even Government-wide, for ordering.  In Agency specific scenarios, the resulting contracts are promised to be the only vehicles to be used for any Agency requirement.  Project Managers must work with a company or a Team that has one of the contracts under the Tera-Scope.  Work may be competed only among those companies or Teams that have one of the contracts under the Tera-Scope.  Let us hope the Source Selection Team has chosen wisely and avoided protests from the losing companies.

What does the Government believe will happen when it limits its buyers’ access to companies that provide goods and services?

Winning companies should provide better prices just because they know they are more likely to get work now that the competition has been narrowed (aka Strategic Sourcing).
Winning companies should continue to provide better and better prices because they have to compete within this smaller pool to […]

Part 3: Tera-Scope Contracts and Risk

In Parts 1 and 2 of this series we talked about the contractor and Government perspectives of setting up for, releasing and responding to a Tera-Scope contract opportunity.  Now let’s talk about the high risks associated with putting together such a complicated contractual arrangement.

For several decades the Federal Government has employed Long Term Contracts in order to found relationships with a vendor or vendors for a long period of time.  Task orders are issued against the contracts for work as needs arise.  This saves the Government from repeating the full acquisition process over and over.  Sometimes only the founding Agency can order from the contract.  If ordering is open outside the founding Agency it qualifies as a Government-Wide Acquisition contract (GWAC).   I’m calling a Tera-Scope contract a Long Term Contract where the Government combines every conceivable IT service under one umbrella that requires each offeror to respond to all task areas.  This necessitates Teaming in order to present an excellent proposal in every regard.  For Tera-Scope opportunities where you must respond to all task areas a company cannot afford to be “just okay” in any one of them.  The main difference for a Tera-Scope is that the range of tasks included is very broad – even vast.

In responding to a Tera-Scope RFP proposals must detail why a Team is high quality and high value for every aspect of the Tera-Scope.  Once everything is written and submitted it may still be a while before a decision is made by the Government.  A recently publicized Tera-Scope draft RFP comes with a timeline of 12 months for evaluation and selection of teams for award.  Make sure you understand the termination provisions of your Teaming Agreements. You don’t […]

Part 2: Tera-Scope IT Contracts

In Part 1 of this series we talked about the trend towards “Tera-Scope” competitions within the U.S. Government for comprehensive Information Technology (IT) services.  Here in Part 2 we will take a peek under the tent at what the Government is going through.

Many groups that are often perceived as different business areas have collaborated on the PWS for this Tera-Scope contract.  Contributions for task areas have to give enough information about that area to foster understanding of the possibilities without getting too specific about what work will or won’t be ordered, so there can be no perceived promises.  Someone should be reviewing the whole package for consistency, duplication and conflict resolution.  Often this is left to the contracting folks who are not technical experts.  The evaluation criteria must give clear guidance to offerors and evaluators on what the Government needs to know to choose the right Teams.  All of the RFP requirements are pulled into a very large package that undergoes a series of pre-solicitation reviews to make sure the RFP is coherent, compliant and will result in a contract that achieves the Government’s objectives.  It depends on the organization and on the specific individuals involved as to how much conversation takes place between the requiring activities and the contracting activity before the RFP hits the street.  More is better, but more takes longer and these days speedy contract awards are in high demand.  There can be a tendency for a “you take care of your part and I’ll take care of my part” scenario to develop between the requiring activity (the IT Department) and the procurement activity.  There are not too many more frustrating things than re-explaining your requirements to your contracts specialist after […]

Google+