April 24, 2012
Posted by on
We are living in an age of social media. One where opinions are best expressed in 140 characters or less, hashtags galore and needs need to be met instantly. There is a level of agility required to work well in this environment. If an organization rigidly sticks to how business used to be done, more than likely they will be left behind by others that are willing to alter course. However, can one get into the habit of altering so much that they go around in circles? There are many misconceptions about Agile. Let us explore some of those.
|Aglie is NOT
||Agile is a set of principles.
- Individuals and interactions over process and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
People have created methodologies around these principles – namely Scrum, Kanban, Extreme Programming (XP) etc.
|License to dive straight into code
||All Agile methodologies have a significant emphasis on continually solidifying user stories. A successful delivery is judged by how closely the delivery met the user stories.
|License to develop without scope
||User stories are the definition of scope. User stories must contain enough information for the developers to quantify a particular story “done”.
|License to change your mind daily
||User stories are worked on continuously. More imminent a story is to be worked on; more time is spent detailing it. Adjustments to requirements are accommodated during sprint planning and treated as any other requirement, which it is being prioritised against.
|License to leave half finished work floating around
||Most agile methodologies will restrict the number of in-flight tasks. If some of the team complete their work before others, it is their role to help others complete tasks at hand.
|License to continually chop and change the team
||Most efficiency is gained when you arrive at a team that gels well. The sum of the capability of the team dictates the velocity at which it can operate at. Constant swapping of resources makes it near impossible to measure progress through burn-rate. One area where you expect change is in the role of the subject matter expert, based on tasks at hand.
|License to pull resources mid assignment
||Once the sprint starts, resources are committed to getting the sprint ‘done’. It is acceptable to commit a resource to part of the sprint or a portion of the resources availability. But once committed, they see it through.
|Something that only works on its own
||Agile is perfectly paced to be used in conjunction with other project management methodologies. For example, one can use PRINCE2 and manage by stages, where the stage boundaries represent iterations in an Agile methodology. Agile requires complete software at the end of iterations. PRINCE2 requires the ability to close a project if the business case can no longer be satisfied. Using the two together allows for tangible benefits to remain with the customer even if a project has to be cancelled.
To avoid chaos, you need a level of planning. When planning is impossible, chaos is the more likely outcome than agility.
December 19, 2011
Posted by on
One of the key challenges faced by a Project Manager is to ensure their project is not beholden to an individual for its success or failure. This is especially the case longer the project is in motion. This challenge is faced by the project teams more often than it is acknowledged.
Consider what happens if one of the key staff want to take a vacation, they fall ill or has a family issue, decide to leave altogether or the Project Manager wants to take some time off?
Project Managers are inherently risk averse. There is a tendency to utilize people they have previously worked with and to try and maximize their productivity. It is also against project management ethos to spend time doing this that does not progress your project forward and lead to ticking off a specified outcome. This caution is well served, until the first sign of resource shuffle.
How does the Project Manager prevent a calamitous turn of events? One of the Agile software development methodologies has a very interesting approach. Extreme Programming (XP) insists two developers work together to deliver tasks assigned to them. XP claims improved quality delivery and resulting lesser cost of lifetime delivery as the reasons for the approach. However, this also immediately lessens the reliance on one particular developer. As well as efficiency gains, the approach immediately provides a level of knowledge sharing.
When assimilating a new member in the project team, one of the key challenges challenges is to get the same productivity from the new member as was the case with someone that had been an integral part of the project. This difficulty is usually in the form of knowledge the previous team member had picked up that is not documented anywhere. Even if the new resource is equally as competent as the one they are replacing, they still may not know the approaches that had already been tried and discarded. The only way to ensure the new resource does not waste time by trying the discarded approaches is to have good documentation of tasks assigned and progress on those.
You reap what you sow. If you plan for and encourage a wider team participation in your project, you will be in less risk of getting stuck when something unforeseen happens with your resources. In many cases, the additional effort required is a difficult argument to make. I find it is easiest to get my message across by quantifying the impact in terms of schedule delay or cost to project.