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).
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:
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.
