Pages

jeudi 28 avril 2011

My method : a Task driven and scored method


Pragmatic Task-driven & scored method

Historic

For years, I have used a pragmatic method for producing software in small companies with small teams.

In this context, I always wore many hats: product manager, project manager, R&D manager and lead senior programmer. In this post, I resume these roles as a "manager", a multi-hats manager, capable of multitasking...

Without a lightweight and self-propelled system, it would have been very difficult to do my job.

More than an "innovative and revolutionary" method, it's rather a blend of good practice and pragmatism. It is mainly based on the classic "Agile Methodology", but adapted to very versatile "mini-teams".

With a lot of different roles tp juggle, I had to make choices and fix priorities.
It is not the quantity of work that determines the success of a project: it’s the quality of the work, the organization, the commitment of its team and passions for the product.

In various management roles, I overlooked features kept only the essentials:
·         Product manager: inspired by Agile Method, no big and formal requirement, just short and explicit specifications, the famous "user stories"
·         Product manager: no planning, just cutouts of "user stories» in tasks, and priority estimations. These tasks allow a self-management by the team, headed by the tasks and priorities, but without imposed order.

Task-driven & Task-centric

The Tasks

My method is based on tasks and autonomy of the team and its members.

The key is the possibility or rather, the duty of developers to choose the tasks they want to realize, according to their inspirations, their skills, their moods or their ambitions.

Having a choice in the selection of tasks gives great autonomy to team members and allows them to adjust their efforts and aspirations in order to achieve greater productivity.

When developer choses his own job, he does it according to some criteria:
·         Its relevance to the topic of the task:
"Look, this task looks interesting; it's really in my skills"
Example +: good expertise on the topic => good productivity and satisfaction
Example -: challenge may fail=> poor productivity and loss of confidence

·         The state of fatigue and motivation:
« I am very tired this week, I'll do all spelling corrections and forms alignment »
Example +: choice of short and fast tasks => remaining productivity
Example -: confinement in a long task without the requisite skills => decreased productivity

In order for a developement team to achieve the goal of delivering high quality software within the given delay. The ability of team member to express their free will within the organization can help preserve high productivity and positive motivation, despite long work hours or other organizational issues.

In this context, the manager can (I would even say should) assign himself tasks, and assign the score to the team, thus the manager plays a support role to his team.

Scheduling

It does not exist as such. Only a few milestones are fixed.
As I use Agile principles, my milestones are end sprint and end of the release dates.

I don't know whahat project respects its deadline just because it was scheduled, but rather because the project team was mobilized on a clear and shared goal: the deadline.
The detailed planning of all tasks is often a way for all stakeholders in the project to reassure themselves.
To borrow a citation from Reworks: « Planning is guessing ».

The manager's role is to lead and motivate the team to keep those deadlines.
But above all, its role is to properly quantify the number of tasks and difficulties in order to "fit" in the sprint or release.
The realism in the estimation of labor to provide is a key point of the job of manager of development team.

«I think I know what I'll do this week, but what imponderables will fall on me and change my beautiful schedule? »

Let's move on, since I'd much rather talk about targets, and goal dates.

The Goal: Little Reminders

The goal of every development team is:

To deliver high quality software within a set period of time

Only reach the goal, reach objective, and for that alone the motivation, mobilization around the goal are the keys.

Even though autonomy via choice and the exercising of free will are the basis of this method, the manager must be able to assign and impose choices and decisions to team members to benefit the project, and especially with the objective of achieving the goal.

How do you reach the goal? Finishing and testing all tasks. Everything evolves around the tasks.

So despite a form of self-management for developers, the manager is still the manager.

New feature: the Score

Why a Score?

My idea is that the motivation of team members can be animated and boosted by providing them with a score per a given period (week, month, release, sprint, etc... according with the organization).

"My method" has its limitations, particularly due to the lack of measures of performance and evaluation of team members. And without indicators, there are no axes for improvement, thus no proactive detection of malfunctions.

The idea of scoring induces a small degree of competitivity that can stimulate a team, help it to advance.

Score using

By team

A minimum average score (MAS) per team member is given. A minimum score to be achieved should also be set to encourage teamwork.

The ideal is to set a reward for each MAS reached, individual and collective, thus rewarding individual effort and collective efforts. This difference between "individual" and "collective" is important; a member who provides great efforts and obtains a good score shouldn't to be penalized by the poor performance of the team.

On the other hand, if the overall, team productivity was good, everyone should be rewarded so that nobody feels excluded, even if an individuals on the team wasn't as involved as other in the effort achieved.

At the end of each period, an analysis of the worst score should be made ​​in a positive spirit.
It is necessary to rule out "bad scores”, low scores obtained because of personal or external factors (eg sick = bad score)
.

By the manager

It helps to estimate tasks.
The score is very similar to the velocity (based on points of Agile user-stories), and therefore allows its use for planning sprints and releases.

Score Definition

The score of a task is the result of a calculation based on criteria. It is used to tell developers how many points they will win in performing those tasks.
There are three criteria with three values ​​that determine the score of the task.


Expert level:

Easy= 1, Normal=3, Hard=5

Task duration:

Short=1, Normal=3, Long=5

Task priority:

Low=1, Normal=3, High=5

Subjectivity in the evaluation.

Though it exists it is limited due to the low number of choices and task choice's transparency. In case of disagreement, the choices should be debatable by all team members and at any time of the process, even when it is completed. Most important thing is that this disagreement is motivated.
Exceptionally, like the "planning poker", the "scoring" can be collective, by imitating the same method as the "planning poker".

What’s next

Some tools

I haven't found a tool for management based on the scores. For the task-driven management, a number of tools are avalaible and I've only used or evaluated:
TFS, Mantis, Jira and the very promising Asana

My Choice  : TFS

I find that the integration of TFS and Visual Studio on the wholes makes a formidable platform for productivity and efficiency.
What I also like in the TFS is the idea of being able to relate the code "WorkItems" including archiving (check-out), which is an aspect I beleive is lacking in Mantis.

TFS is a very good source controller but the management of "WorkItems"is not adapted to managing with task-driven method and it does not handle scoring, so I'm working on a web interface and a "process template" which will correlate well with my method of work.

That’s what the project ScrumPilot is about

ScrumPilot

ScrumPilot's initial idea was to create a simple, more user-friendly dashboard than those that exist.
Stitches in time, I have added read-only "workitems, projects and users" features.
At this point, with my best understanding of the TFS API facetious and with a little elbow grease, I should be able to make a mix between Mantis and Asana, TFS, my method and my scoring to give a "small agile teams focused on tasks" varnish to the TFS



There will be another more detailed article when I will make progress on it.

Aucun commentaire:

Enregistrer un commentaire