Critera for selecting Project Management Tool

Choosing a tool to be used for project management is very critical as this has impact on smooth project execution and productivity.  If careful analysis is not done while choosing a tool, a project team may suffer with following problems :

• Loss in productivity due to ambiguity or lack of instructions
• Problems in communication between various groups/stakeholders
• Problem in publishing targets/goals

At a high level choosing a tool is a three step process:

1. Identify problem you want to solve with the tool
2. Evaluate potential Tools available
3. Identify Best Fit 

Step 1 Identify Problem you want to solve with the tool

Following could be the reasons you are looking for a project management tool : 

• Product Road map management :  This requires:
• Keeping a list of features/ enhancements
• Ability to document requirement for each feature
• Ability to prioritize requirements and put them in development buckets
• Log defects and prioritize them

• Tasks for getting it done : This could involve

• Managing list of proof of concepts / research required to be done
• Doing competitor analysis
• Plans for items like
• Product release
• Testing
• Code Review
• User Acceptance testing
• Re factoring / Architectural improvements

• Integration with other tools
• Integration with source code management system
• Integration with build release process
• Integration with automated build and acceptance testing
• Integration with defect tracking system
• Integration with public interface for publishing product updates to end users

• Other Documentation :
• Decisions taken
• Design Guidelines 
• Code Guidelines
• Technical documents
• Business documents

Following could be the key questions:

• Search : How easy and fast is to search for required information?
• Customization:
• Do I get the flexibility to categorize and view items based on my preferences?
• Can a add new fields /item types ?
• Prioritization :What is the ease of moving items up and down?
• Flexibility:
• How easily can I add an enhancement request and schedule it for development?
• Can i maintain a hierarchy /inter dependency between items?
• Usability:
• Do I have the visibility about the stage  of development a particular feature is currently in?
• Can I have a report on open defects in my product ?
• Am I able to communicate requirement to development team efficiently?
• Is their a facility to document the comments/ discussions or queries about a feature requirement?
• Can different stakeholders customize the view to see information relevant to them?
• Are their email notification facility? Can a user update an item by sending email?
• Does it provide interface for bulk operations?
• Does it support import /export from outside source?
• How easy it is perform tasks like:
• update status
• re assign
• add comment
• change priority
• Availability : It the tool available as web interface?
• Performance : How fast can I search, add , edit?

Step 2 Evaluate potential Tools available

Once step one is done , you are clear about your objectives. You can create a comparative analysis of tools available with your specific objectives

	Tool 1	Tool 2	Tool 3
Objective 1	5	6	8
Objective 2	8	3	10
Objective 3	9	7	5
Total

Step 3 Identify Best Fit 

You can attach ratings to different objective and based on total rating decide a tool perfect for you.

Dilemma in Organizing Development team

There can be various ways of organizing a software development team

1. Vertical Organization : This approach is concept of total separation between the front end, middle tier and database layer of software development and have specialist dealing with different tiers with no overlap.
2. Horizontal Organization  : In this approach , there is no separation. Any team member can work across different layers of software. We call this generalist approach.
3. Hybrid organization : This is a mixture of 1 & 2 above, where we can have generalist to deal with simple problems and specialists to take care of complex scenarios.

There are pros and cons for each approach and what organization is chosen depends on various factors like:

• Team Size.
• How mature is architecture and coding standards.
• How smooth is communication between various team members
• How well documented your software process are
• What type of output is required
• What is the response time required
• Is the team doing software maintenance or new development
• How complex the project is

Vertical team organization

A vertical team is composed of generalists. Use cases are assigned to individuals or small groups, who then proceed to implement the use case end to end.

How this works

• There is an integrated development team responsible for all layers of architecture.
• Single development team can be divided into smaller sub teams and assigned individual targets. They take up tasks at each layer.
• There is a project lead and several module leans for leading sub teams.

Advantages

• You have smooth end-to-end development on an individual use case basis.
• Developers gain a wider range of skills.
• Ownership of modules and focus on delivery.
• Flexibility to use team members in any area as per requirement.
• Faster response time during bug fixing and while implementing simple enhancements

Disadvantages

• Generalists typically do not have the specific technical expertise required to quickly solve detailed problems.
• Subject matter experts may have to work with several groups of developers, increasing their burden.
• A focused approach at each layer is compromised if architectural standards are not well defined.
• May result in redundant code if communication is not centralized among developers.

Success factors

• Everyone is working to a common set of standards and guidelines.
• Good communication between developers is required to avoid common functionality being implemented by various teams.
• Common, and agreed to, architecture needs to be developed early in the project.

Horizontal team organization

A horizontal team is composed of specialists. This team works on several use cases simultaneously, each member working on their own aspects of the use case.

How this works

• Development team is divided in 3 sub teams namely:
• UI /Front End Team
• Middle /Business Layer Team
• Database /Back end team
• Each requirement is broken down into these three components and respective teams are responsible for their part.
• There is lead for each layer

Advantages

• A focused approach at each layer.
• Easier to maintain code quality and  discipline responsibility at each layer.

Disadvantages

• Specialists often do not appreciate the importance of other specialties, resulting in disconnects between various aspects of the project.
• Information required by "back-end" people may not be gathered by the "front-end" people.
• Project management is more difficult because of competing priorities, visions, and needs of specialists.
• More coordination required between different team layers.
• More Dependencies resulting in greater time to develop
• Lack of ownership and responsibility of a complete module.
• May result in dissatisfaction in developers as they are restricted to one area of product.

Success factors

• Good communication is required between team members so that they understand where each person is coming from.
• Defined processes and quality gates that specialists must follow to promote effective hand-off to other specialists are required.
• Very well defined requirements so that iterations between teams of various layers are minimized.

Hybrid team organization

A hybrid team is made up of both generalists and specialists. The generalists stay with a use case throughout its development, supporting and working with specialists who work on portions of several use cases.

How this works

• There is an integrated team with some team members assigned as owners for each of 3 layers.
• All the assignments are taken by a team as single module but an owner for each layer is consulted and involved in design of any new solution.
• There is a single lead and module leads for sub teams. There are leaders/owners assigned for each layer

Advantages

• You get the best of both worlds.
• External groups interact with a small group of experts.
• Specialists focus on what they are good at.
• Individual use cases are implemented consistently.
• Flexibility to choose a generalist for a simple task and associate a specialist for a complex requirement.
• Ownership of modules as well as each layer of application.
• Greater control over code quality

Disadvantages

• Specialists still may not appreciate and work well with other specialists, although this should be tempered by the generalists.

Success factors

• Good team communication is required.
• Common architecture needs to be developed.
• Common processes, standards, and guidelines must be well defined.

Comparison

Factor	Vertical	Horizontal	Hybrid
Chances to Deliver  fast	High	Low	Medium
Chance to Development fast ( New Development)	High	High	High
Chance to develop fast ( Bug fixing and enhancements)	High	Low	Medium
Chances to have high Code Quality	Medium	High	Medium
Chance of Code Reusability	Medium	High	Medium
Focus on delivery	High	Low	High
Ownership	High	Low	Medium
Ability to work independently	High	Low	Medium
Ease of operation in agile requirements	High	Low	High
Flexibility to use resource	High	Low	Medium
Ability to solve complex problems	Low	High	High

Scrum VS Kanban

Once a project team has decided that they want to execute project on Agile principles, next big question is which methodology to follow.

Ideally a project team should pick up one base methodology and customize or fine tune the processes to the project requirements.

Two very popular flavors of Agile are SCRUM and KANBAN.

What is SCRUM

SCRUM is basically a way of organizing projects using two important principles:

• Product backlog: This is a list of all the work (Enhancements, New Development, and Bugs) which is required to be done for a product.
•  Time Boxing: Product is delivered in iterations and duration for iterations is always fixed. It could be any duration generally from 1 -4 week(s). But once this is decided, it should not be changed.

How Scrum Works:

• Sprint: At the beginning of Project a fixed duration for deliverable is decided. This is called a SPRINT
• Product backlog items are prioritized and placed in a sprint. This gives product development road map
• During each Sprint, backlog items are reviewed and re prioritization is done. This is done on regular interval to make sure that all the changes and new requirements which have come up since last Sprint are placed in product development plan.

Practical Problems with SCRUM

Scrum focuses on time boxing of development cycle. This could be a challenge for maintenance teams where fast turnaround time is required.  They may want to have releases based on priorities instead of waiting for a fixed time period.

For example in first iteration there might be 3 important issues which are required to be released and which will take 2 weeks to deliver. In next iteration this could be 1 week or 3 weeks. So holding on to the release to fulfill fixed duration requirement of SCRUM becomes challenging in environment where there is high pressure from clients for fast turnaround time.

·        

     Sometimes it’s difficult to freeze the priorities even for a small sprint. What if an urgent issue comes up? Should the team keep on waiting for the current SPRINT to be completed to pick up the urgent issue, or should this be picked up immediately?

KANBAN

Kanban eliminates the need for time boxing while maintaining most of the other principles of AGILE intact.

Kanban focuses on continues delivery approach by focusing on limited items at a time

How Kanban works:

Step 1: Define stages of development: 

Each work item, needs to go through different phases from initialization till completion. These are called stages of development. For example the stages could be

• Requirement gathering
• Design
• Develop
• Test
• Release

This is the sequence which is required to be followed for completion of an work item. This sequence could be different for each team and needs to be defined based on project requirement.

When one work item goes through all the stages of development that is called a completion of one Cycle

Step 2: Fix Work in Progress (WIP) for each stage:

After the stages of development are defined next step is to fix the max work in progress items for each stage

For example if it is decided that requirement gathering team can pick only 3 items at a time to define requirements. Unless any of these current item is completed, any new item is not picked up and is kept in a queue. Till the time team is working on current item in hand, priority of queue can be changed any time. Only when one of the items is completed next item from the queue is picked up.

Step 3: Manage Work Queue for Each Stage:

Work Queue for each stage is managed to ensure WIP limit in maintained for each cycle. One work item passes through work queue for each stage in life cycle. It is completed when it passes the last stage of the life cycle.  

This gives flexibility to re prioritize at any stage of life cycle.     

Scrum Vs Kanban Diffrences

Scrum	Kanban
Time boxed delivery	Continuous Delivery
Predefined roles for team , scrum master and product owner	No Prescribed Roles
Work is managed in sprint backlog and cannot be reprioritized once sprint started	Work is managed in Queues for each stage and can be reprioritized as long as it’s still in the queue
Batch work is picked up to create product backlog	One item is picked up at a time
Team productivity is assessed using team Velocity which is the average number of story points completed in each cycle	Team productivity is assessed using Item Cycle Time. This is the average time required by an item to complete one full cycle from first stage till the last stage

Scrum Vs Kanban Similarities

• Both are lean and Agile

• Both focus on cross functional teams

• Both are focused on end delivery 

• Both promote small incremental releases

• Both promote transparency in the team and flat team structure

Which one is Better SCRUM or KANBAN

Both SCRUM and KANBAN are designed to deal with specific problems.  While SCRUM should be a good practice for a product development, KANBAN can be adopted by Product maintenance teams where turnaround time is of extreme importance. 

Scrum Simplified

SCRUM is an agile methodolgy for software projects.

There are 2 ideas which form the core of SCRUM : :

• Maintain Product Feature List  ( called Product Backlog )
•  Time Boxed Development (called Sprint)

Product Feature List/ Product Backlog

The Product Backlog is the master list of all functionality desired in the product.
It is not necessary to start a project with a lengthy, upfront effort to document all requirements.

Typically, it starts with a small list and it grows and changes as product evolves.

It helps in following ways:

• It helps maintain one single list for all product Requirements.
• Tracking: A status is maintained for all backlog items which give visibility of what is complete, what is current work in progress and what the future plans are.
• Prioritization: List of features can be prioritized based on business scenario to align development with the business need.
• Estimation: Each Backlog Item has a rough size and complexity estimate. This helps in
• Planning the work for future iterations/Sprints.
• Understanding team productivity based on work completed in previous iterations/Sprints

Time Boxed Development/ Sprint

Development is divided in small iterations called SPRINT:

• A Sprint has a fixed period (generally 1 – 4 weeks).
• Once decided Sprint period is not changed. This helps in setting a rhythm in the team.
• Every Sprint has a defined Start and End Date.
• A Sub set of backlog Items from Product Backlog are taken and assigned to the Sprint. This is called Sprint Backlog.  This defines the target or the output for the sprint.
• End Date for sprint is fixed; if all the items from sprint backlog could not be completed they are moved on to future sprints.
• The Sprint Backlog Items are prioritized as
•    Must Have
•    Good to have
•   Nice to have
• All the “Must have” items should be completed by the end of sprint. “Good to Have” and “Nice to have “could be picked based on time available.

Some Rules

• All work should be present in Product backlog and there is no requirement outside it.
• The End date of Sprint is fixed.
• Once a sprint has started, Sprint backlog items in that Sprint should not be changed. If there are changes coming up in the work under progress, they should be captured separately and assigned for future sprints.

Standard Practices

• Daily Standup Scrum Meeting by Development team ( less than 15 minutes each day ) where each team member  tells about :
•  What was done yesterday
•  What is planned for today
•  Any Blocker in doing the work
•  Lessons Learnt or retrospective Meeting at the end of each sprint to evaluate what worked and what not and find out ways of improvement.
• Sprint Pre Planning Meeting: here the work for the sprint is planned before start of the sprint.
• Sprint Demo Meeting: This usually is used to give a demo to stakeholders from dev team as to what work was completed in the sprint.

Important Reports/ Figures

• Sprint Burn down Chart: The estimated work remaining in the sprint is calculated daily and graphed, resulting in a Sprint Burn down Chart. The vertical axis displays the hours of effort remaining for the Sprint.  The horizontal axis displays the days of the Sprint.  The burn down is supposed to be shown by the line of descent from the start of the Sprint with the starting hours, down to the end of the Sprint with no hours remaining. 
• Product Burn Down Chart: No of features completed in each sprint.
• Sprint Velocity: No of Backlog Items completed by team in a sprint. This helps in planning work for future sprints.

How to Implement

Following lists are required to be maintained:

      1.  Sprint List: List of planned sprints.

      Required Fields:

• Sprint Name
• Start Date
• End Date
• Description

      2.  Product backlog List: List of all the product features

       Required Fields:

• Backlog Id : an auto generated field
• Dependency : multi select list where backlog ids of other features can be filled
• Sprint: Combo Field coming from Sprint list. This helps in defining sprint backlog
• Release ( e.g. 1.0 , 1.5 etc ) : release in which this feature is planned
• Week (  within sprint  which week this feature will be developed )
• Module: a logical division of features ( e.g. User, Account etc)
• Sub Module : a logical sub division of features
• Category ( e.g. :New Screen, Workflow, enhancement,Bug  etc)
• Backlog Item Title
• Backlog Item Description
• Complexity ( Complex, Medium, Simple)
•  Priority ( must have, good to have , nice to have)
• Status ( not Started, In Progress, Completed, On hold, Released)
• Assigned to
• Time Estimated
•  Time Spent
• Time Remaining
• Remarks
• Source :  This item was requested by whome or was promised to whome ?
• URL of  document location ( These are detailed requirement document or link to a wiki page for this backlog item)

      3. Task List: list of all the task required to be done for development of a feature. Should be a child of a feature/ Backlog item

      Required Fields

• Task Title
• Sprint
• Backlog Id
• Task Description
• Time Spent
• Start Date
• End Date
• Assigned To

     4.  Optional - Release Plan : expected release plan for the product : required only if multiple sprints are to be clubbed for a release

      Required Fields

• Release : ( e.g. 1.0, 1.1. 2.0)
• Dev Complete Date
• QA Complete Date
• Move to staging Date
• User Acceptance testing  date
• Release Date

Agile Development

What is Agile Development

 Agile  Development is based on following core values:

• Develop software in small increments
• Involvement of stakeholders in Development
• Ownership of Development team in development and mechanism to ensure independence

Why Develop Agile ?

Requirements Keeps  Changing :

Product Development involves developing ideas into working software.

Even though product team spends lots of time brainstorming about requirements ,it is difficult to capture all the thoughts and ideas in one go. Ideas keep on evolving over period of time. One idea leads to other ideas. Often when one part of working software is exposed it leads to other ideas. During the course of development you may find  better ways to perform a function which is already developed.

Business Priority Keeps Changing

As the time goes by priority of product feature keeps changing.  For Example a feature which was very critical few months back may take back seat because a new feature is introduced.

Gap between Requirement Analysis Vs Development

Often there is a gap between product requirement and implementation. This can be reduced easily if implemented software is getting reviewed by business stakeholders frequently and regularly.

How Agile Development solves the Problem ?

Problem 1 : Need check & balance approach to ensure minimal gap between expectation and outcome

Solution : A development approach which produces working software in small iterations. This ensures business stakeholders are able to review the working software on periodic intervals.

Problem 2 : Need flexibility to change requirements and prioritize development as per changing business scenario.

Solution :  Divide work in small chunks and ability to re priorities based on business.

Problem 3 : Ability to have a clear product development Road map

Solution : Capture all requirements/changes as Product Backlog.  Schedules Development time frame for each item give clear indication  about Development road map.

Agile Methodologies

Various Agile methodologies are available to implement guiding principles of Agile Manifesto.

There is no best methodology and project teams adopt methodologies suitable to their project. Most of the times these methodologies are further tailored to suit individual project needs.

Agile methodologies can be organised into two categories

Methodologies on engineering practices :

These basically act as guiding principle on how development should be done. These are generally good practices for development and many of them could be adopted in a single project.For example

• "Test Driven Development " : This is based on principle  that all forms of development should be proceeded by test case.

• "Pair Programming" : this emphasis on two developers working together to write one piece of code.

Methodologies on Organizing work and management:

These define the way work is organised , how the progress is tracked and processes followed. Only one of them can be adopted at a time but good practices from other methodologies can be adopted. For example

• "SCRUM" : This is a development approach where work is divided into small time boxed chunks called "SPRINT" . Every sprint results in a product version which is demo able and deploy able.

• "Kanban" : This is similar to SCRUM except time boxing is not there.