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.
  • I'm a little bit confused. You mention building a PoC. A PoC is an experiment, but you seem to want to treat it as a full blown project with upfront planning. Your PO seems to want you to just build something ASAP. I think here is the disconnect: maybe you both haven't agreed on what the outcome of this PoC should be and to what level of quality to be built. As for using Scrum, if you are a one man team with maybe another person wearing many hats, Scrum will not work all that well, especially with building an actual experiment, if that's what the PoC is.
    – Bogdan
    Oct 29, 2020 at 20:58
  • @Bogdan - right, it's a feasibility study type PoC but it's an enterprise application that is sufficiently complex (ballpark ~60-90 man days) to deploy and evaluate that the entire exercise needs to be broken down into small chunks of work, sized, prioritized, measured, etc - that something like Scrum will be needed. You're right on the outcomes or exit-criteria not being defined - it's something we have to work on setting.
    – shalomb
    Oct 29, 2020 at 22:12
  • @shalomb, for each activity you introduce - you need to have a clear understanding of why you need it. Most of the time people simply follow the crowd - doing whatever everyone else is doing, and that's very ineffective. If you start thinking critically (why exactly do I need to estimate? why exactly do I need to measure?) you may find that many of these activities are not needed for your situation. Oct 30, 2020 at 20:14

2 Answers 2


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.

  • 2
    Quite possibly one of the most useful answers I've read on this site!
    – MCW
    Oct 30, 2020 at 14:22
  • "Put everything on a board" - what would be the columns on the board? It's only TODO and DONE - which basically is just a checklist. "Put WIP limits on things so you don't work on too many things at once" - why would he work on more than 1 thing at a time? 2+ concurrent tasks show up when you collaborate with someone. Neither Scrum nor Kanban are needed for a 1-person job. Oct 30, 2020 at 20:22
  • @Stanislav Bashkyrtsev: The OP will create whatever columns he finds necessary to manage his work. The question mentions waiting on vendors, stakeholder engagement, evaluation stages, managing dependencies, and that the PoC isn't a small, trivial task. You can't handle all of that interaction with TODO and DONE. No one works in a vacuum by himself. Additionally, a board is an information radiator for the OP's manager to see, who otherwise might be tempted to constantly interrupt and ask "what are you doing now?" and "are we there yet?"
    – Bogdan
    Oct 31, 2020 at 9:17
  • @Stanislav Bashkyrtsev: humans have a WIP limit of 1, because we can't multi-task. But we can multi-switch. While the OP is working on something, he might wait for input from a stakeholder, or a dependency to be fixed by the vendor. When those things become available, he might switch to incorporate the input, or test the dependency. All of a sudden you find yourself with a bunch of things in progress, but none finished. A proper board with WIP limits (1 or other) is there "in your face" and reminds you that maybe you should finish some stuff before starting to work on something else.
    – Bogdan
    Oct 31, 2020 at 9:17
  • @Bogdan, most of what you said can be accomplished with a pen & paper and 2 lists: overall plan and short-term plan (today/tomorrow activities which include "waiting for response from X and Y"). And as for the visibility - 5 min status meeting every day or two will be sufficient (you need that anyway to get input/feedback from others). Introducing dev processes here is like hunting a fly with a bazooka. This whole question is not about project management - it's about self-discipline, time-management, software architecture, engineering, etc. Oct 31, 2020 at 11:34

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.

  • Scrum is default because the organization uses it widely and would the vehicle of delivery past PoC - bringing team members on later if needed (quite likely) is easier. It's considered now because we need to have the ability to scope and estimate the work just-in-time, prioritize and to demonstrate progress and course corret with go/no-go at regular check-points. There are some good tips here but I don't agree on the "mini-waterfall approach" because the "just do it" without continuous measurement is what will inevitably lead to death marches closer to crunch time - I'm keen to avoid that
    – shalomb
    Nov 1, 2020 at 21:58
  • @shalomb (1) I don't know if this changes anything in this discussion, but Scrum is kinda outdated. Modern methods are: Theory of Constraints, Just-in-time (aka Kanban), Continuous Delivery and their mix. (2) Even if you decide to introduce Scrum when you start building a team - it's not going to be any more complicated later. (3) I didn't mention waterfall in my answer ("mini" or not). Any good engineering/scientific process is a cycle which consists of plan->do->draw conclusions->repeat. (4) Scrum doesn't have any "continuous measurement" built it. It doesn't even have metrics to measure. Nov 1, 2020 at 22:51
  • @shalomb I'd also try to at least consider an idea that your manager is right about your current approach. It seems like he wants you to be a grown-up developer and lead the project. To do that you do need to understand the domain and talk to the stakeholders. And from what (and how) you write it does seem like he's onto something about "my critical approach may be a sign of pessimism". You seem to over-think & over-complicate things. Nov 1, 2020 at 23:00
  • @Stansilav - I'm after a responsible approach to ensure the PoC stands and fall for the right reasons (i.e. not fail because of inadequate structure and support). If this were a PoC for a silly socks web app, I'd be inclined to the just do it approach. Capturing the domain's complexity and reasoning on the ground while being pragmatic is the point of my question - keeping on top of all of this requires a huge mental working-set that needs to be outside my head and accessible to the stakeholder (and more importantly myself, because I don't remember details from as far back as last week).
    – shalomb
    Nov 2, 2020 at 10:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.