Friday, April 11, 2014

Agile Projects: How Can We Standardize?

‘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:

Lost In Venus said...

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.