MikePadgett.com

Agile processes

— Seems like everywhere lately, I’ve been seeing a lot about Agile processes. Definition: http://en.wikipedia.org/wiki/Agile_software_development Principles: http://www.agilemanifesto.org/principles.html I was very interested in Agile as a framework for project management when I…”

Seems like everywhere lately, I’ve been seeing a lot about Agile processes.

Definition: http://en.wikipedia.org/wiki/Agile_software_development

Principles: http://www.agilemanifesto.org/principles.html

I was very interested in Agile as a framework for project management when I heard about it.

For web developers, the key points of interest include:

1. Client involvement – it usually happens in the web business that a client approves designs and you barely see them until it’s time for them to QA. The bigger your projects, though, the less you can afford to have this happen. I’ve worked quite a lot with marcomms agencies and you find sometimes that the Account Manager has spec’d one thing and the client wants another. Or else it can happen in-house. Agile says that we should invest clients closely into the development process, which in turn I think gives the client a sense of responsibility.

2. Fixed cost, flexible deadlines – closely allied to the above, though less palatable from a business point of view. Nevertheless, the web industry needs to grow up and dictate standards – let clients and stakeholders know how things are done. With that sense of responsibility described above, the client (or its elected agency) can understand that it has to keep up with asset delivery and provide responses promptly.

Recently I outlined a proposal to firm up the project flow at the company for which I currently work.

It went like this:

SETUP

All new work should come in from clients to you

You decide to delegate smaller matters to me (typically those involving only a single person’s efforts).Larger ones will stay with you, or a future project manager

SIZING AND SPECIFICATION

The job is spec’d out.This would obviously be either you (or a PM) or I doing this process depending upon the size of the project.At this point we would tentatively assign people to the work based on an assessment at availiability, which later goes to the grey book*.It is vital this gets done correctly.We must not allow lazy clients to say “it should do this and that” and then walk off leaving us to figure out the small print, so to speak.

The spec returns to you for costing

You add the cost to the spec and remit it to the client.The spec includes:

Timeline – including PM, Planning and QA.Use the red book* to ensure you have all tasks accounted for.An entry is then made into the grey project book

Client requirements – this is the bit in Agile where we involve the client or the agency. Client’s involvement in the project process: PO remittance, payment, QA, design approval (e.g. we must move release dates to AFTER the client’s QA rather than what is now frequently before) – in most projects this should include progress meetings here; client gives regular feedback, we pick up on missing bits. Similar occasions with the client onsite were most productive and should be used again for other stuff.

A clear and unambiguous statement that the stakeholder’s satisfaction of these requirements will enable project completion as per the content of para. a above.The client is a very big part of the process of getting the work done and the spec assumes that the client acts at all times with due efficiency and accuracy.Act or omission otherwise may lead to delay and additional costs, to be submitted as an Addendum with a separate PO required.This statement, whatever form it takes, must be quite firm and very well drafted.

Once the client signals approval, we should only have to assess whether our people requirements are accurate.An entry is made into the black project book*.

A PO needs to be received

WORK PROCESS

Work begins. Where the work is delegated to me, it should be a small enough matter for me to have minimal supervision over the person.This supervision will loosely involve:

Point of contact for developer and for client where allowed for in the spec

QA

There should be no need to exhort people for completion and stand over them etc, as the specification process is failing if this becomes necessary.It should be seen that lateness is rarely the fault of, and never frequently an issue faced by the developer.Equally the developer MUST behave responsibly when addressing whether he / she can deliver the spec in the time, to the standard and using the technologies, discussed.

Where the work is not delegated, then you or the PM would manage the process, and also take on the additional matters such as progress meetings etc.However, you may choose to appoint certain tasks where there is a practical value – such as chasing assets and QA.Where you do delegate tasks, those tasks should be supported by concise documentation – at least allowing you to monitor the stuff not directly in your attention.Note that the delegation of some large scale project tasks should be motivated by a practical value rather than an absolute necessity and all such delegation should be pre-planned and accounted for in the spec.Use of the red book will be essential here!

CLIENT QA

Given that internal QA is part of the work process rather than an additional stage, the client needs then to QA using whatever method they usually employ.This is not part of the work process, so release dates are affected but not costs (Agile).If you want to deliver on a fixed release date, then the client MUST be part of the project by committing a fixed amount of time for QA to be added on to the work process.

Bugfixes – now this is quite an open part of the process, and in our history, it seems to be endless.Note this: the better our QA, the lesser the bugfixes.NOTHING that is not on the spec should be part of this item.If functionality didn’t get seen by the client in the spec, tough.We as professionals spec’d what was discussed.If we didn’t then we are idiots.

Client QA now is ONLY to check the bugfixes were done OK.NO new ones should be accepted.

RELEASE

A full release (with notes if handed over) should be accompanied by a short meeting to evaluate the successes and failure of the project process if the project was not delegated as a smaller matter during Sizing and Specification.This should also be accounted for in the spec so that it is still a profitable incentive to have this meeting.It should involve all who worked on the project.If there any specific notes of interest, they should be recorded in a memorandum and sent to you.That way, we can cement our good practice and address things that don’t work

Summary:

*red book – this is a list of all of the processes a project can go through. As components in an overall project engine, the processes can be allotted typical timeframes and help us to see projects as being made up of experiential objects. We use these components to plan a project properly so that we don’t miss bits in the overall time the project will take.

*grey book – this is a calendar of projected time use. It shows all projects currently underway and any future ones due to arrive. It gives an overview of the business and assists with future planning

*black book – this is the project plan once approved. It may be occasionally adjusted, but it is basically the timeline of the spec. It must be stuck to and relied upon, by both management and developers.