[Select Repost] 7 Agile Practices You Can Apply In A Controlled Environment

So your teams want to do Agile, perhaps have even started doing so. Now your project managers run around wondering what story points are and why any number of people seem to be attributing hours to their project code. So the question is: what can you adopt easily without turning the Governance of your organisation upside down?

Is this an ideal Agile way of working? No it's not, but it's a good first step that you can take without frustrating the environment too much. That will make additional steps easier.

 

If your are the audio/visual type, you may want to check out the video scribe I made of this topic.

You can also check out the Dutch version HERE

Without further ado, here are the 7 Agile practices that you can and should adopt in a process oriented (e.g. Prince2) environment.

1.) Get the right people on the bus

The role of the Product Owner is of paramount importance in Scrum. The centralisation of business demands and constant interaction between those who can create and those who know what problem to solve is pivotal to success. Yet, in many organisations this difficult to achieve.

The senior user, as the problem owner is referred in Prince2 is typically out of sight, somewhere in a steering committee and is being represented by the Project Manager. But this is not mandatory. Rather than having a Senior User, or Business Project Manager: talk about a Business Product Owner.

Talking about Products rather than Projects makes it easier to think about long term implications, rather than develop and handover. The additive "Business" places additional emphasis that a Product Owner should really "own" the business.

2.) Get a proper guide

Getting things build in an organisation is not easy. I've introduced the role of the Customer Journey Expert to avoid diluting the notion on who owns the product. The Customer Journey Expert makes sure the Business Product Owner adheres to the process and agile rules to make sure they don't fall back to the IT Project Manager to convey their message.

These people are also well versed in creating User Stories so they typically help creating them and manage tools like Jira etc to make sure everything is one place.

3.) Project Initiation Documents must have a Story Map

Project Initiation Documents manage everything except the scope, and in Agile context, scope is probably the first thing that goes out of the window. So why not start by explaining what part of the scope is more important than others.

This has deep implications. For example the very definition of a product changes! In Prince2 all artefacts that a Project produces are called products, but the Story Map forces us to think about end-user value. So we make a distinction between process documents (designs, reporting, calculation etc.) that we need to create end-user value and the actual product that solves the problem of the end-user.

The process documentation can be referred to as whatever standard you are using. There is no need to repeat it, unless you are deviating from the standard. It's a project plan, not a reference document. But the end-user value ends up in the "shippable increments".

…the most reliable form of self-marketing is to have a long history of stunningly great work, shipped.
- Seth Godin

Project Milestones have now become "Shippable" increments! No longer we have the discussion at the end of the budget: "when will everything be ready" but it will become: "was the last increment good enough".

4.) Use Relative sizing

Size projects relatively to each other. Both on impact to user as in complexity to build. You can do this by comparing new projects to projects you have done in the past. Creating business cases can be complex task and all the variables introduce more uncertainty when making multi-month or even multi-year projections. In practice: to remove risk and uncertainty from an absolute planning to become more accurate than relative estimates outweighs the cost.

So if users twice as enthusiastic about feature A than feature B you have a great estimate of the value that these features bring. If you do a similar exercise about the complexity you have a perfectly good starting point for prioritising your projects.

5.) Revise Priority Periodically

So we have set the initial priority, respected the Project Delivery Board, but also know that everything is always in flux. Therefor the Business Product Owners meet regularly to re-evaluate priority based on the actual increment the teams are working on.

So you are now comparing the priority of increment 4 of project A and increment 8 of project B. Since product development adheres to the law of diminishing returns, we will at some point add less and less value to the end user per unit of effort. Analog to Judo: if the game is almost over and you are entangled, it will take much more effort to make an impact than in the beginning of the game. So avoid that (and in Judo don't be on the receiving end.)

We have this alignement meeting weekly. This is where we discuss the allocation as setup by the Project Delivery Board and Project Management Office (Resourcing). In the meeting we listen to the problems the other projects are trying to solve and what impact their next release will make. This guides us in setting the priorities for the mid-term and adjust. (Communication and empathy for each others project is a nice bonus!)

Need help to setup the project alignment meeting in an Agile way? Go check out the book on a detailed description on how you can create an agile way to align multiple teams working on multiple products.

6.) Get Early Feedback

The secret to Agile is early user feedback. So it's the Business Product Owner's responsibility privilege to gather the users he represents and make sure they are informed of every thing the team delivers. Good Agile teams will deliver something valuable and "potentially shippable". The Customer Journey Expert can help to make the delivered functionality in such a way that it is fit-for-feedback.

E.g. I once worked with a team that delivered a highly sophisticated search engine. Rather than working only on complex algorithms, the team created a simple and ugly (otherwise Marketing would put in production) user interface that allowed us to demo to users how search would work. Every single demo we gave, we learned something new about how the product would be used by real people and users gained sympathy for the mystical work we were doing that was taking forever (in their eyes.)

Feedback with users is a two-way street: it builds trust in both ways.

7.) Don't forget the Environment

The Samurai were trained to be aware of their surroundings at all time. When you are in battle with an opponent his friend can come up to you from behind. Now I don't believe the intentions of your fellow colleagues are on war level (at least I hope so), but failing to manage the environment as they expect will have lethal consequences to your project.

This means: be smart about your reporting. The steering board is still expecting the regular reports, but you can play with the content, include burndown graphs, photos of demo's, whiteboard sessions etc. The purpose of the reports is get a feel if the project is on track to deliver value. Agile projects can show this much earlier, the only risk is that the steering board realises that your project has reached its optimal value before the end of the plan and will stop it. But really, that would mean they have adopted the Agile mindset and you are on track for a complete Agile transformation.

Financial reporting is important, since it regulates cashflow. If you overspend, other projects may have difficulties getting funded. Now we run into a snag: if your organisation has an over emphasis on control, you may have lots of small projects, which will result in multiple projects per team. The financial reporting mechanism looks at hours, not at value. This means it becomes important to know how much money is spent by whom on what. This will lead to many surprises since the predictability on team member is probably decreased in favour of increasing the predicability of the team.

Symptoms are large variations on hours spent per week/month/sprint. Which will lead to confusion and project risk due to uneasy controllers. The solution is to group projects to a sensible size, now the increased predictability of the Agile proces will work to your advantage! Additionally, teams will focus their efforts on a single large project rather than half a dozen small ones. If you cannot merge projects due to internal rules: introduce the concept of a program.

Back to my opening picture: Agile won't work if you are entangled in a grappling hold, so create some room and smile!

 

 

---

This blog is part of the Product Samurai series. Sign up here to stay informed of the upcoming book: The Product Manager's Guide to Continuous Innovation.