How are you resolving your agile transformation blockers?

Teams leading agile transformations can encounter multiple challenges along their journey including changing the mindsets of senior and mid-level managers, transitioning from a focus on specialists to developing generalizing specialists, educating and effectively engaging delivery or control partners and reducing the time and effort required to deploy deliverables once they’ve been deemed production ready. Worse yet, it can sometimes feel like a game of Whac-a-Mole – as soon as your team resolves one hurdle then another two surface.

How about being agile with your transformation!

Treat each of these blockers as a work item in a backlog. Collaborate with stakeholders to identify appropriate acceptance criteria to help you know when you’ve successfully resolved the issue. Size the work items with your team. As with all preliminary estimates in agile don’t aim for precision but rather for consistency. T-shirt size them or if you feel creative use an alternative fun sizing taxonomy (Decepticon-sizing?).

Prioritization will be a challenge. Just like managing a backlog of product requirements, it’s rarely as simple as letting business value be the sole determinant of priority. Many of these hurdles will be interdependent. You might also want to incorporate relative uncertainty into the ranking process by tackling higher risk and impact hurdles first.

Once you’ve prioritized these blockers at a high-level your team should decide whether it is worth disaggregating them into smaller hurdles. Techniques such as story mapping could then be utilized to help you create a release plan for resolving the issues.

Now comes the tricky part – socializing the plan with your senior stakeholders. Assuming they accept the list of blockers and their relative priority you will want to share it with delivery teams and control partners across the organization. This will increase their confidence in the transformation as well as helping to manage their expectations regarding the resolution timeframes for specific blockers.

A critical step is to adapt and evolve the plan as your transformation progresses but don’t obsess over creating the ideal plan. As new blockers get identified by delivery teams, size them, prioritize them and add them to the backlog. Use information radiators to share status. For example, you could post a list of which hurdles are being actively worked on, which ones are “on deck”, and a burn-up chart with an up-to-date forecasts of when the backlog will be cleared. Your team should also decide whether a sprint-based or lean lifecycle makes sense given their capacity and maturity.

Resolving a backlog of organization blockers can seem an insurmountable task but take the opportunity to increase buy-in and provide a showcase for the benefits of being agile.

 

 

 

 

Categories: Agile, Facilitating Organization Change | Tags: , | 1 Comment

How should I handle an agile-waterfall hybrid project?

A question which I’m frequently asked by learners attending my agile foundations courses is “I’m quite comfortable with what’s required for a waterfall project and what’s required for an agile project, but how do I plan and manage one where some of the scope is going to be delivered in a waterfall manner and some will be delivered using an agile approach?

I could plead the project management equivalent of the Fifth Amendment by answering “It depends!” which is a perfectly valid response given that the context of such hybrid projects varies widely.

In some projects, there is a very clear delineation between the type of deliverables being produced with each approach and there is limited direct integration between these deliverables. For example, technology deliverables might be completed in an agile manner whereas change management deliverables such as training collateral get produced in a traditional manner. In others, deliverables themselves are produced in a hybrid manner. For example, the web portion of a technology solution might be produced using agile methods, but the back end integration with a legacy system needs to be done in a traditional manner.

Another attribute which influences this is an understanding of who is delivering which work streams. Are they all being produced internally, or is a vendor responsible for either the agile or the traditional deliverables?

We also need to be conscious of the relative effort, complexity or scale of each work stream. A project where 95% of the deliverables are produced in a traditional manner will need to be planned and managed in a different fashion than one where the bulk of the scope will follow an agile delivery approach.

Things to consider when faced with such a hybrid project are:

  1. Orchestrating delivery cadence from each work stream to ensure that consuming work streams are not incurring prolonged delays in receiving components from providing ones. This can be a challenge when an agile work stream has dependencies on a waterfall work stream. On the other hand, if an agile work stream is delivering components to a waterfall one, there is an increased potential of component inventory buildup which is wasteful and could increase the likelihood of rework.
  2. Defining a common set of ground rules is important to avoid creating “us and them” rifts between the work stream teams. For example, if the agile work streams are able to use information radiators or other barely sufficient methods of communicating with stakeholders, figure out how the traditional work stream teams can do the same.
  3. Make the life of your approvers and control partners easier by coming up with a common method of capturing key information which they will need in order to bless your project. Requirements capture can be challenging in a hybrid situation as agile teams might prefer to use collaborative tooling such as Jira whereas traditional teams might want to use a business requirements document. Managing reviews and signoffs will be difficult, especially when the outcomes of each work stream are tightly integrated, if you don’t settle on a common approach.
  4. Finally, agile mindset and behavior need to prevail across the entire team and not just the agile work streams.

Purists will be shuddering while reading this while pragmatic realists are likely nodding their heads in recognition of how often a hybrid scenario occurs, especially in large organizations where the large variety of contexts eliminates our ability to apply a single methodology to all projects. When it comes to managing such projects a key lesson (plagiarizing Malcom X) is not to preach integration while practicing segregation!

 

Categories: Agile, Project Management | Tags: , , | 1 Comment

What does project management mean to YOU?

I’m not asking for your elevator pitch for the discipline, but rather what does it mean to you personally?

Being in the middle of changing roles, the thought process I went through to decide to make a change caused me to revisit a question which I’ve asked myself more than once over the past two decades.

If you see your current work in project management as a stepping stone to a higher role such as a C-level business executive then it might just be a job. While you will develop and use project management competencies to successfully deliver projects, you generally won’t commit much personal time to the profession such as mentoring junior PMs or giving presentations. While you might seek and attain a credential such as the PMP, that is a means to an end, and you are likely to let the credential lapse once you have moved into your next non project management-focused role. There is nothing wrong with considering project management as a means to an end, and becoming a senior leader who has done one or more tours of duty in a PM role is an excellent way of elevating the importance of the discipline.

Perhaps you are playing the long game with the profession. A career in project management might give you the opportunity to take on initiatives of progressively greater complexity and scale or to move from delivering individual projects to managing a portfolio or leading a PMO. Instead of a vertical career path, you might pursue a lateral one by switching industries once you feel you’ve developed sufficient domain expertise in any one. Or you might specialize by focusing on a particular aspect of project management such as recovering troubled projects or by becoming a project risk management specialist. You will most likely attain and maintain one or more credentials and might even contribute to the evolution of the profession if you see it furthering your career.

But the third path and the one which will give you the greatest gratification is if you view project management as a calling. Those who see the profession in this light are easy to identify. They are likely unaware of it, but they smile a lot when they speak about project management. They commit a significant amount of personal time to the profession, not because doing so will help advance their career, but because this re-energizes them and they want others to be as passionate about project management as they are. Being recognized as thought leaders by those they respect is more important to them than a promotion or the latest credential.

So is project management your job, your career or your calling?

There is no escaping reason; no denying purpose. Because as we both know, without purpose, we would not exist.” – Agent Smith

Categories: Project Management | Tags: , | 2 Comments

Blog at WordPress.com.

%d bloggers like this: