"Yes, I said the same yesterday, it's a big job, but it's going fine."
and, this is even more defensive, you feel people will not believe you so you invite them to see some proof:
"Anyone can come over and ask me about analytics if they like!"
Maybe the biggest problem is this though:
"Yesterday, analytics. Today, analytics"
This task needs to be broken up into manageable pieces badly.
This seems to be a sentiment I see a lot, but I don't think it applies equally to all people.
Maybe it depends whether the person doing the task is a mature worker (in the sense of doing independent work).
When you break things down, you make it easier for less experienced workers to complete work. It helps the managers with tracking progress.
However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly.
Moreover, dividing work that way is harder and less efficient for more experienced workers. They often dislike being micromanaged and probed multiple times a week (or day) about their progress. Give them space and they excel, but ask them to explain what they do, what's next, how much time is left, etc. and they get annoyed.
Mature workers generally know who needs to be informed of issues, recognize them early on, and proactively resolve those. "Process" is what you typically need when you don't have many mature workers. It's fine, but perhaps it's best to be careful who we apply it to.
Actually you make it easier for everyone. The point of breaking down a task is to start removing assumptions, and make it so others can also lend a hand.
> However, increased breakdown is very costly on many levels. You need extra time to break things down (senior dev), extra effort to track it in project management tools, extra time to deal with it all every day. It's costly.
Time and again I have heard this reasoning, but in my experience the real costs comes when not breaking down tasks. There is an unknown unknown problem with large tasks, that is often solved by breaking them down with the stake holder instead of finding the issues during acceptance.
I do agree though that the right level to break down tasks is an art that ends up being team specific.
Personally, I find the "tasks must be tiny teeny as you can not manage task larger then few hours autonomly" management insulting - it feels like babysitting. Ok if one was irresponsible in the past or is too junior to work normally, but not ok if I was working alright.
I am not ok with being micromanaged on hourly basis. I am not ok when I loose all autonomy and have no responsibility. The whole 10 minutes of talk you put in is nonsense - you won't be able to split large tasks into microtasks in those 10 minuteš a day.
Last point - waterfall vs agile is false dichotomy. So is the strawman of evil badgering management who stands against pack of developers who have all awesome social skills and are natural born benevolent leaders.
The problem is that the Agile industry caters to the fast world of write-only web site and app producers where the most complex thing is usually the decision whether a IAP purchase should be 0.49 USD or 0.99 USD.
The fact that there might exist some actual real-world problems that map to features that take weeks to month to implement and are not trivially decomposable is completely foreign to them.
Having said that the team should be the ones driving this sort of thing - we switched between scrum and kanban several times depend on the nature of the work, and we kept looking at what we were doing to see if it was helping us, and when it wasn't we stopped doing it or changed it.
Any specifics? I would have imagined this to be a case with very strict up front requirements with a relatively heavy toll on changing the design during the project.
This would also be my immediate thought as well. "Yesterday I setup integration with the analytics service. Today, I'm going to audit the places where we currently send analytics and see if it would be possible to centralise it – I'll share the results later".
It's hard to track progress and estimate if your tickets are huge multi-week affairs.
Just responding to this one, I would say that it really depends. If your task is implementing analytics and no one else on the team has anything much to do with it, then maybe it's best not to trouble them with the specifics. Your summary is much better, and only a few extra words, but if no one really cares about the analytics except to know that it's cheerfully in progress, maybe it's not all that necessary to go into more detail. This is definitely something you need to be wary of in a multi-disciplinary team.
Also, I didn't mean "Anyone can come over and ask me about analytics if they like!" to sound defensive - it was actually more tongue-in-cheek! Here's another attempt: "I can't imagine why you would want to bore yourself with my analytics implementation, but please come over and ask me about it if you're having trouble sleeping at night." (I will freely admit that I am a confident person and would have no trouble saying something like that in front of a dozen people.)
IMO, only for a small minority of tasks.
The vast majority of projects I've seen and worked on are measured in dev years of effort.
My current project is well over a thousand dev years.
In comparison a few days is meaningless.
Most often it's a trust issue.
It depends on the team.
We find it useful specifically because we want to make sure we are estimating relatively accurately. Since we work in essentially 10-working-day periods, it's great to know when a piece of work we thought we could easily achieve is actually a blocker, or much more complex than we thought.
Just for contrast: I've been working for a medium size software house for the past 4 years. Typical project size is somewhere around 500 to 1000 man days. On that scale, individual days matter.
Still, I also have the impression that they matter because Clients demand certainty and precision in reporting rather than focusing on actual value delivered, but the management doesn't always see it that way.
Kind of. It's upper-medium.
It's nothing compared to Microsoft Office, a web browser, etc.
Microsoft for example has maybe 50k developers and so creates 50,000 man years of work every single year.
> Typical project size is somewhere around 500 to 1000 man days.
That's roughly 2 devs for a year. That's hardly even a prototype where I work.
It is fascinating to see the difference in scale in our industry.
Tracking progress goes on a Kanban board (or digital equivalent).
www.scrumguides.org/scrum-guide.html#events-daily
So what you are saying is that the standup really _is_ for project tracking. I don't disagree. In my experience that has been the main point to the meeting, but it's not really how it's supposed to be done according to agile doctrine.
The point of the meeting is often (A) let management/outsiders assess progress across devs with minimal time investment on the manager's part, and (B) put subtle pressure on the devs via the daily confession.
Only in the sense that the team needs to know itself how work is progressing, in order to understand what they can realistically achieve, or to estimate more accurately, or to identify pain points that need to be resolved. Not tracking in the 'report to an external agency how much is being done every day', which I agree is awful.
The point of the meeting is often…
I maintain that is this happens, you are in a bad environment.
That's what retrospectives, demos, and stories are for.
If there is concern about individual performance, managers could create dashboard of their teams' git commits, allowing them to jump around and see peoples' work passively without disrupting the entire team.
The team knowing about whole thing won't make your job for you. It will just make them lash at each other unpredictably.
Project tracking should be in a Kanban board (or digital equivalent, such as Jira or TFS). This should be used by the dev's so that they know what work is queued up, what work is in process and who's working on it, and what is completed, so that they can do their jobs. In an agile team most of the management is externalized onto a Kanban board - the team manages itself most of the time, using the Kanban board to have a shared understanding of what's going on. A secondary benefit is that outsiders can look at the Kanban board to assess progress, without consuming any dev time.
The "subtle pressure" on the dev to deliver is a great point. In fact, when status is completely transparent, developers put a great deal of pressure on themselves to deliver, because they want to honor their commitments, and there's a social pressure not to be "that guy" that blows the sprint.
As for second paragraph, I prefer management style that accepts that things sometimes take longer then estimated. I don't want to stay longer because made up deadline.
Here’s one example:
* Moving functionality from a legacy^2 to legacy (mainframe to client-server)
* Target system groaning under 15 years of neglect, developer outsourcing, technical debt and band-aids. Source system simply untouched for nearly 20 years.
* Source and target systems inherently un- unit testable
* Mediocre developers with no intrinsic sense of craftsmanship nor any desire to acquire some
* Developers with no experience of legacy codebase so completely unqualified to estimate cost of stories
* Culture of fear reinforced by performance reviews, stack ranking and PIPs
* Locked down QA systems and silo’d resources
Any one of these would be a project killer but my last employer suffered from all of them in the same project and showed no inclination to address any of them because they were deemed to be out of scope. But it was totally fine to tie up 10 people for 15 minutes every day to enable the PM to derive a magical velocity curve to feed back to the stakeholders so that the company could demonstrate how effective this SCRUM process was going to be.