In an Agile environment, how should a developer update team members and managers when there's no "visible" progress?

Question

A developer is working on a research project that involves working with new technologies. The concepts are also new to the developer, and the developer is working on building a product on top of the new API's.

As a result of the technology being new and undocumented, the developer spends a lot of time tearing apart demos and analyzing data in order to understand the technology.

Since many agile methodologies involve daily or frequent team updates, such as Scrum and the daily stand up, how should developers give updates to both technical and non-technical stakeholders without it sounding like he or she accomplished nothing? Note that the meeting we have currently doesn't have a name.

When the work involves a fair degree of learning or acquisition of knowledge, as a PM, how can I advise these developers give their updates without making them feel as if they aren't making any progress, since there may not be anything to show for days/weeks?

Should the frequency of status meetings be reduced, or should the frequency remain the same with a different approach?

Answer 1

In order to have a valuable research one usually needs to define it's purpose and goal. So, in other words, developer knows what he wants to do, what is his progress and what are the problems he is facing currently. The question is, how to share such knowledge in a meaningful way.

If the meeting involves only a status report then there is only a concern about describing it in a compact, yet valuable manner.

E.g. I've already checked five out of twelve API's known compatibility criteria. As for now there is no evidence of possible incompatibility, but yesterday I was become aware of two new criteria.

If the meeting is also about teamwork and revealing risk and overall impact of one's work, then a lot of new subjects arise. Does one have blockers? Does one need help? Should she inform someone about important discoveries?

One of the main reasons we do research is to reduce uncertainty. While we reduce it, we often need to change the direction we are going. So, every time your research achieves a progress there is a rising probability that someone else status needs to be influenced as well. To anticipate it and give an update is probably one of the reasons such meeting exist.

Answer 2

TL;DR

• Splitting status meetings with stakeholders from status meetings with developers may help.
• Meeting intervals should match the batch size of your work items.
• Methodology and expectations need to be explicitly communicated throughout the organization.

Potential Chicken-and-Pig Issues with Your Current Methodology

Since many agile methodologies involve daily or frequent team updates...how should developers give updates to both technical and non-technical stakeholders without it sounding like he or she accomplished nothing?

If you were following Scrum, I would point out that the daily stand-ups are for the Team and not for the stakeholders. Iteration results are generally provided to the stakeholders during the Sprint Review at the end of each time-boxed iteration.

Even if you're not following Scrum, I submit that asking developers to provide stakeholder-centric updates too frequently smells a lot like "hold developers accountable" and will lead to C.Y.A. reporting by the developers, and eventually reduce transparency within the project.

Potential Solutions

Consider The Chicken and Pig fable. The linked site says:

On Agile projects the term Pig has come to describe all the developers, designers and testers who commit to the actual work. The term Chicken is applied to everyone else who make intellectual contributions but do not commit to any work.

You may want to consider a few options here, depending on your corporate culture and environment.

1. Consider limiting frequent meetings to pigs (e.g. the development team) rather than including stakeholders in meetings that are procedural.

2. Provide visibility to stakeholders through a dashboard or some other key performance metric that doesn't involve "personal accountability" by the individual developers.

3. Make the project manager responsible for routine status updates to the stakeholders, rather than the team members. This allows the PM to educate the stakeholders on what is (or is not) reasonable progress, and may prevent C.Y.A. reporting by the developers.

4. Create a separate meeting at defined intervals for Q&A between the stakeholders and the team. In Scrum, this would be a Sprint Review, but the main point is to give your stakeholders direct access to the project without hijacking the team's internal process.

5. Meet at intervals appropriate to your batch size. Either decompose work into day-or-less chunks, or increase the interval between meetings. The idea here is to move reporting away from "I'm 29.36% done with foo" to a done/not-done status update. This is more developer-friendly, and easier to track from a PM perspective, too.

Setting Expectations

When the work involves a fair degree of learning or acquisition of knowledge, as a PM, how can I advise these developers give their updates without making them feel as if they aren't making any progress, since there may not be anything to show for days/weeks?

Project management often involves setting expectations, and communicating them clearly within the project team and to various stakeholders. Regardless of your methodology or your reporting intervals, you need to educate your organization on the process and set their expectations appropriately.

1. Set stakeholder expectations.

   If your process involves bursty deliverables, make sure your stakeholders expect appropriate reporting. This may be regular reporting that includes a variable level of deliverables completed during a time-box, or irregular reporting when something is completed and worth bringing to their attention.

2. Set developer expectations.

   Make sure the developers know how they will be measured within your methodology. You get what you measure, and people optimize for metrics that impact them directly. If you decide to keep the daily reporting, make it very clear what information you expect to track, how that information will be used, and how that information will impact both the project and each individual developer.

3. Make expectations explicit.

   [T]here may not be anything to show for days/weeks[.]

   Make sure that this expectation is explicit, and that you continually re-educate and reassure everyone on this point. Asking developers for daily status updates when the expected answer is "I'm not done yet" makes this very challenging, partly for psychological reasons and partly because how you're measuring (daily updates) is intrinsically at odds with your project's expectation of bursty results. You can offset that dissonance to some extent by keeping the real expectations front-and-center.

Answer 3

One of the good things of a daily reporting is that you have to break down the task on pieces, each one in a day. I mean you have to know what are you working on today. Sure, you have to research the API, but are you researching the whole API at the same time, and write code after you've learned every method? Or are you starting small and add new functions, and of course refactor a lot while learning the API, so you know each day lot exactly you are working on? If you are reporting 2 weeks "I'm still researching" you are not telling anything to the team and it's better if you do not participate in the meeting at all; however if you are telling right now I'm working with this [part of the API], or yesterday I had to rewrote the whole [part of the API], you have a status update. And if 3 days in a row you are saying "I work on this [part of the API]", it's obvious you've stuck with it and someone can jump and help you get out of there.

Answer 4

A late answer that might only be relevant if you split projects into User Stories or equivalent.

the developer is working on building a product on top of the new API's.

First let me summarize my understanding of the situation. There is a project. I mean there is an actual software that needs to be developed, the developer must implement a list of features into the software, the features might already have been split into stories, etc. The problem is that implementing these features requires the developer to learn a new technology. As a consequence it is quite impossible to schedule work or estimate the completion time of the project. More, there is no visibility for the stakeholders on the current research part.

In this situation I would recommend using spikes. Spikes are a particular kind of story introduced in XP. They are meant to reduce risk and uncertainty in a part of the project while being themselves estimable and schedulable. They must be time-boxed. In short, there are generally two kind spikes : functional spikes and technical spikes.

Functional spikes are designed to solve functional problems. For example we don't know what the best user interaction is for a story, we create a spike to prototype several possibilities before implementing the actual story.

Technical spikes are the kind of spike you might need. Use them when you need more technical input before implementing a story, a feature or a project. This input might be learning a new technology, choosing between several implementations, choosing between building a solution or buying it, etc.

When a product needs to be built on a new technology that we don't know about at all, I would recommend using three levels of stories:

1. A research-inception spike (maybe a real name exists). We don't even know how to learn. We don't know if there is any documentation, etc...but we know how long it will take to learn about how to learn. The goal of this spike is to gather enough information to build the second type of story.
2. Technical spikes. Now that we know how to learn, we know what precise facets we need to learn to implement the needed features. Create a spike for each one of them. You can estimate the difficulty/time of learning each of these facets based on the information gathered from the research-inception spike.
3. User Stories. Classical user stories can now be estimated.