Please login or join to subscribe to this thread
Few typical questions & answers I came across -
1. How well agile methods can be integrated?
2. Not all (stakeholder) familiar with this buzz word.
3. Traditional waterfall method is still widely accepted.
4. Resistance in accepting & learning agile methodologies.
5. What wonders it can do? Projects existed, and were successful much before agile?
I know it is a myth that Agile means no documentation and status reporting, but I want to dig in to that more - specifically around project performance monitoring. How can you ensure that stakeholders are informed during product development projects when the product is being developed using Agile methodologies? We know we will keep getting the standard questions from leaders ("Is the product going to launch on time?!"), so how do we make sure we can answer them? How might Agile methodology impact and influence a standard project performance dashboard?
1) How well you can implement agile methods is directly related to organizational change management. I strongly recommend looking into organizational change management techniques (e.g. ADKAR model). IMHO, this is a fundamental job skill for any PMO practitioner or "agile coach"
2) No, stakeholders will NOT know what agile is. It's OUR job as project leaders to have brief talking points at the ready, "Certainly Mr. Vice President I can tell you what agile is. It's a movement that is focused on (1) delivering business value earlier and more often, but doing that is hard so we (2) empower self-organizing teams to leverage our talent, but they're usually not ready so (3) start with what we have and use continuous improvement"
3) It's okay that waterfall is still accepted. There's a time-and-place for plan-driven projects. The point is to advocate for an empirical approach (iterative/incremental) to higher risk projects.
4) Resistance to change is a fundamental human behavior. See answer above to #1
5) Agile is not the goal; it is a means to an end. The key question for agile is WHY? If projects were completed to full satisfaction of stakeholders and employees all these years, then there is no need to change. The annual "state of agile" survey (google it) tells of key business benefits of going agile.
FIRST, regarding documents, the agilemanifesto.org says at the bottom "while there is value in the items on
the right (i.e. documentation), we value the items on the left more ("working product"). So the original statement of agile methods admits there IS value in documentation. The point is to shift SOME of the energy we pour into documents into actually building product. Any agile guys who says "we don't do documents anymore" did not read the document properly.
SECOND, regarding agile methods, the point is to accelerate and amplify business results, NOT to be compliant with a manifesto or methodology. So, it does matter when your business needs a performance dashboard to make strategic decisions ("this project has only 35% stakeholder satisfaction after 5 incremental deliveries!?!? Then we should kill this investment").
Here are some tips:
* Start first with the questions your leadership is asking (e.g. "when will projects be done?"..."what MVP will we have by this fixed date?")
* Then, see what data you already have available to help address those questions. Don't reinvent the wheel if you don't have to.
* Finally, if there are gaps between leaderships questions and our ability to answer then, try as much as possible to minimize the impact to delivery teams. One CIO wanted every employee to record their activities in a new timesheet system, so that he could find inefficiencies. When you did the math, he had a 100 person organization and a portfolio of authorized projects totaling 400 man years. The real problem was NOT efficiency reporting; the real problem was that his organization was over-committed by 4x
So...generate as many documents as necessary to empower leadership, but do so without impacting the empowerment or effectiveness of delivery teams as much as possible. That sweet spot is different for every organization.
Please login or join to reply