How to (Agile) manage a fairly complex IT PoC?

Question

I'm a technical lead employed by in an agile IT organization where most teams observe Scrum.

I'm 2 weeks into a task of building a proof-of-concept of a service that is fairly sizable and complex (multiple man-months) and I am the only FTE resource dedicated to the project. While we are waiting for the vendor to provide us particulars - I've begun to do some technical due diligence activity and map requirements to our capabilities, map our use-cases to features, etc, etc and out of this process I've managed to generate a list of dependencies that need resolving (some prerequisites, some deferrable) amongst other artefacts. My work isn't too structured yet.

My manager (VP and stand-in PO) seems to have some issues with this.

• He doubts if my reasoning is valid with most of the dependencies and wants second and third opinions - he wants me to be the one to seek out the further opinions.
• He suggests it's me that work with (potential) stakeholders on requirements, work with the vendor on open topics, etc, etc.
• He thinks my critical approach may be a sign of pessimism but I feel I'm merely trying to quantify and then convert the unknowns to knowns - and clear some ground before work begins.
• We seem to have extended discussions (over slack) about each and it mostly descends into a talk-past-each-other ball-of-mud with no resolution. Drip feeding him information isn't working (or perhaps he's not receptive to unwelcome news).

Things aren't great and are strained in the project. I need to come up with a way to control things that will address the abovementioned "problems" in this early stage but more importantly a process to use as the project ramps up in the build & evaluation stages where things will be busy and there will be no time for process engineering.

If it was a small, trivial task - I'd probably just do it but this is a fairly complex project with many unknowns. What (Agile) methodologies should I follow? Some notes.

• This is a PoC - it may not work (Think 3 month spike?). If it works, it will likely take on a formal scrum team.
• We're strapped for (mainly FTE) resource.
• There's no product owner but my manager assumes the role. The responsibilities so far seem to be "sponsorship" and high-level decision making.
• We've no artefacts from scrum (or design thinking, etc) process - product vision/one pagers, user stories. There were some discussions with the vendor very early on (but I wasn't present for these) - I don't have very much substance to work with except a task to deliver a PoC and some vendor documentation.
• There is a team of 1 - me, the FTE engineer who's also wearing solution design/tech. lead/product owner hats - as well as that of a Scrum Master when things pick up. (I sense a few conflicts of interest to resolve here).
• Being something I am familiar with, I'm inclined to using some light-weight form of scrum for the usual benefits but perhaps without some of the "overheads" of ceremonies.

Answer 1

As I mentioned in the comment above, you and your manager/stand-in PO need to agree on the outcomes for this PoC. You need to define the goals of the implementation or you might risk working towards different targets. Also discuss what everyone's role will be in this. From the question it seems you want him to be a PO, while he wants you to be more involved with stakeholders.

With that being said, I would personally not go with Scrum for managing the built of a PoC. This is everyone's knee-jerk reaction when choosing an Agile approach for building software, but I don't think it's neccessarily the best choice here for a few reasons.

Scrum lays out some things and rules to get right from the beginning, thus creating a good structure within which teams can then build their own working process. But this structure can create an overhead when you have a small team or you're the only full- time employee working on the project.

Scrum is flexible enough for most work but it also has a rigid part: the sprint. This sets the cadence for a lot of activities. Many stakeholders engage with a Scrum team during the Review Meeting, i.e. once per sprint. You are building a PoC, a feasibility experiment, to validate something. Is collecting feedback once per sprint enough, or do you need feedback sooner?

You also have a Retrospective Meeting. You use this to improve how you work. Is this important when you build the PoC? Or is just the PoC you are interested in? I'm not necessarily saying that you should go all cowboy style and shoot from the hip, but do you really want to invest a lot in the process? Will this PoC be a throw-away once you validate/invalidate the idea, or will you build the real app on top of it? For example, do you need a Definition of Done? Do you want this PoC to be considered a success only if every line of code was code reviewed, or if you have a good coverage of unit tests? Yes? No? If the PoC will be a success and you get to implement the real application later on, then you can focus on your process. With a PoC that's of the type "get the thing out the door as fast as possible" you probably won't invest much in being disciplined in how you build it.

Scrum also has a Sprint Planning meeting. You estimate what work you can fit in the next Sprint. You set a sprint goal. You create a releasable increment each sprint. You try to keep scope unchanged during the sprint. Does this make sense for the work you are doing? A PoC is a minimum viable solution. Any less and it won't help you validate/invalidate your assumptions. Any more and it's no longer just a PoC. Will the increments be in a releasable condition? If you discover something that completelly changes your scope of work for the sprint what will you do with the sprint? Cancel it? Stick to the Sprint goal? If you plan your sprint and realize the next day that you need to do something different, you just wasted time doing planning ehn you could have worked on the PoC implementation.

Do you need to do backlog refinement? Is your PoC taking shape as you build it, or did you already draw out the minimum items that need to be part of the PoC? Some new things will show up, some will change, some will no longer be needed, but will that happen because of what you discover during the implementation, or will it be because you have a "business reason" to add, change, or remove items from the backlog?

I could think of other reasons, but this is getting long already. So, what about an alternative to Scrum?

I would personally manage this using Kanban.

Put everything on a board to have visibility into what you are doing. Doing Kanban will keep everyone more engaged. Interaction happens more often, not on a Sprint cadence.

Put WIP limits on things so you don't work on too many things at once. WIP limits will also highlight blockers and bottlenecks and allow a faster response time to clear them and keep the flow of work moving.

Instead of estimating every task, just focus on what's important, where you are, what you are doing, where you need to be next. Many of the things on your board will be mandatory to be done otherwise the PoC won't serve its purpose. No point in estimating those, it's a waste. Estimate when you need too (like deciding between two options and going for the one that's faster, so you estimate the effort to know what to chose).

Stand in front of the Kanban board and plan your work every day, not once a sprint. Adjust course as needed.

Being something I am familiar with, I'm inclined to using some light-weight form of scrum for the usual benefits but perhaps without some of the "overheads" of ceremonies.

Start with Kanban and add on top of it whatever practices from Scrum you find useful, which I think would work better than Starting with Scrum and chopping things of from it.

Answer 2

I don't understand why you started to think of Scrum here. Or any other team process. You don't need coordination or meetings or anything. Spend these 3 months doing what matters. A typical scientist/engineer would first spend time trying to understand the problem, then would plan how to tackle it and then would roll up the sleeves, so:

1. Research the domain. Get acquainted with the terminology to be able to communicate with the stakeholders.
2. Find the riskiest parts of the requirements and draw mockups/diagrams.
3. Then determine which of the mockups/diagrams you can implement and what are the dependencies between them.
4. Then just do it!

Only when you start building a team you'll have to think of how coordinate and communicate the work.