‘We run several projects. Some are development projects and
the other are maintenance or testing projects.
We follow different flavors of agile methods depending on the needs of
each project. How can we standardize the way we execute these projects?’ That is the point of discussion in this post.
When someone asks me a question like this, I try to chunk it
into small questions. That approach helps us better understand the problem
statement. Here are those small
questions. What do we mean by
standardization? Standard tools or a
common set of tools? Standard
techniques? Standard team structures,
roles and skills? Standard milestones or
release timelines? Standard processes for project initiation, planning,
governance, monitoring? Standard
guidelines and checklists? Or
everything?
Obviously we want to standardize as many of these as we can.
Some of you may say ‘Everything. Why not?’ Fair enough. Let us explore.
The purpose of standardization to stop reinventing the wheel
and optimize the way we do projects. That
is a great opportunity to eliminate waste.
There is more to the purpose. For example, one may have things to add
here such as creating benchmarks, baselines, etc. Let us set these add-ons aside for now.
Let us take it step by step. Can we say ‘this is the way we
plan to do things in each and every project?’ No. We cannot standardize the way every project
team works. If someone says ‘Why not?
We can. We can make everything standardized across projects’, beware! That is a management myth. Read more about this in Johanna Rothman’s
article ‘Management Myth 28: I Can Standardize How Other People Work’.
Let me know if you disagree. If you disagree, let me know why you disagree and
share your experience.
I am sure you read Johanna’s article. Does it convey that
there is no room for standardization?
No. Certainly not. We need to identify things that can be
standardized to benefit us. Again, this
list (of what can be standardized) cannot be the same for all organizations. To know a list of some familiar things read
‘5 Effective Ways to Improve Project Performance through Standardized Processes.’ After reading this article,
one may debate and say ‘Many of these are not applicable to agile
projects.’ I won’t argue against that! Of course, that is a generic project
management article. In included that article in this post to trigger your
thoughts.
Also, read this PDF paper ‘Standardized Project ManagementMay Increase Development Project Success.’
This paper is pretty much academic and research oriented but it is worth
a read.
When we talk about ‘standardization’, PMO comes to our mind. Isn’t it?
About a decade ago organizations started setting up PMOs to improve
project success. The objective was to
standardize the way we do things. Meanwhile
ISO, CMM etc. became popular in several countries.
However, the question ‘How can we standardize the way we
executed these different flavors (of agile project?’ comes to us from time to
time. Because, none of these mechanisms address this question.
A classic answer is ‘What do you mean? Standardization in
agile projects? If we standardize, we are not agile! Every project is unique
and hence the need of every project ecosystem is unique.’
I won’t give you that answer. That answer would shut the
door and the question in front of us is an important question facing large
organizations. So, what is the answer?
Here, it is. This is
what I believe. I have seen this working. And you can consider as many of the
following in your projects.
1)
Infrastructure:
Workplace settings as well as infrastructure for communication and
coordination
2)
Basic team norms: You have to standardize this
anyway so that the norms of one team does not surprise the norms of the other.
An example is team availability at work and norms on allowances, compensatory
offs etc.
3)
Tools:
You can standardize the tools used for both iteration management and
engineering activities such as unit testing, static analysis and so on.
4)
Governance: You can standardize the governance
mechanism across project in a program or portfolio or business unit.
5)
Quality: You can standardize the way you measure
quality across a common set of projects. For example, measuring code quality
across all sustenance projects can be done the same way to bring in consistency. That will be beneficial.
6)
Checklists and guidelines: Not all but some common checklists such as
release checklist, build checklist, branching/merging guidelines.
You can standardize these at program or portfolio
level. You can standardize these at a
business unit level too. But you cannot
standardize these as well as everything else across all projects. That is the
point. Let me share two examples.
Can we standardize templates? Try!
For example, attempt to define a template to capture user stories. Have
you ever seen a user story template working across projects? I have not. Every project will end up taking the standard
template and tweak it. Tweaking may help as long as team members know what to
add, what to retain and what to remove.
For example, if they forget to remove the unwanted, they will have a
heavy template that does not serve the purpose.
Can we standardize metrics and publish a list of common
metrics for projects of the same nature?
It depends. If it is doable, and
if it serves project goals, do that. Make sure that it does not blindfold teams
and stop them from thinking and questioning.
When team members stop thinking and questioning, they confine their
efforts to task execution in a predetermined way. They don’t innovate. Obviously, we don’t want that to happen. We want quantitative management to enable transparency and trust - for this, metrics have to be context-specific, multi-dimensional and seasonal.
Have you standardized anything else in agile projects? Or
have you found anything tough to standardize?
1 comment:
Standardisation is the root of un creativity. It stares you in the face when the client is up with a challange and all you have to say is its a standardised process. Notice when you loose your cellohone or credit card and the customer servixe executie asks you hell lot of questions before registering your loss and blocking. Thats standardisation hurting when it is a bad time. Similalry a project by irself is a unique endeavour with a unique result, standardising will be an oxymoron statement. What i oike about the bolog is that metrics have to be context specific, thats a gem of a statement. We capture somany metrics that do not add value to customers but we charge it to them, matrics captured doesnt help in next assignment as its different.
Post a Comment