|
In my experience, the best teams (in terms of work environment and output) are where the team members are given expectations and allowed to work solo. One of the expectations is to communicate ad-hoc with others as necessary, without some project manager trying to manage such discussions or make a team meeting out of every minor question.
|
|
|
|
|
Does structure have to be a boolean?
Unstructured is chaos. Whatever structure "structured" has will be the wrong structure at some point, if the structure is considered paramount then you're willfully creating inefficiency.
|
|
|
|
|
It seems more like a floating point number, companies are saying they're doing a certain degree of it, but they're always off 
It's not like it's chaos, just that the priority of tasks often changes daily, instead of biweekly (or triweekly for some teams).
I guess it's more or less structured rather than structured or not.
|
|
|
|
|
I agree. Agile is the invention of project managers and is designed for their purposes. Dividing development work into Scrum's arbitrary sprint lengths is just silly, and only measures how well you can train developers into fitting their work into the process so that progress reports can show artificial improvements.
However, there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month. I'm a loner programmer myself and I've always planned my projects by tasks. Now that I do work with a team I find the Kanban approach works well without all the red tape of scrum. Maybe you and your friend could try Kanban, or your own version.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
TNCaver wrote: I agree. Agile is the invention of project managers and is designed for their purposes. Dividing development work into Scrum's arbitrary sprint lengths is just silly, and only measures how well you can train developers into fitting their work into the process so that progress reports can show artificial improvements.
Exactly this.
I've even worked in a team where I wasn't allowed to pick up additional work if I finished my work, say, one or two days before the end of the sprint, because "we'll be planning that for the next sprint" 
I'd just sit there and pretend to be working.
Coworkers were just finishing up their work for the sprint so they didn't need my help either.
TNCaver wrote: there is nothing wrong with planning your project, structuring its development into a logical sequence and being able to plan your day/week/month.
Of course there isn't!
However, when a client calls and says "we'd prefer you'd work on tasks A and B rather than what you're doing now" or even "drop everything, we need to do this work ASAP!" there should be room for that.
I prefer knowing what I'll be doing the next month (if only because that means I have any work at all), but priorities can shift by the day.
|
|
|
|
|
And that's always been the case. Priorities change. I don't know what the "official" Kanban approach to that is, but we shift tasks between the "doing" and the "backlog" and the "on hold" statuses quite often because of shifting priorities. It doesn't mean you can't plan your day, it just means that sometimes you change your plans.
If you think 'goto' is evil, try writing an Assembly program without JMP.
|
|
|
|
|
TNCaver wrote: it just means that sometimes you change your plans.
And sometimes multiple times a day 
Maybe this is also because I'm alone working on multiple projects?
I guess when you're in a team people have their own clients and projects and maybe there's a bit more stability.
|
|
|
|
|
How many clients do you have? Because if I drop whatever I am working on because client "A" think it is important... what about clients "B-Z"?
Support cases gets priority (i.e. the product can't do something it should be able to do and it affects their business), but besides that we can't interrupt the team every time a client gets "a good idea".
|
|
|
|
|
A couple, but sometimes it's like that.
Last month, I had months of work ahead of me, but someone quit his job and months of work kind of evaporated and priorities for this customer changed quite a bit.
Yesterday I had a call with the customer and we're now going to pick up a new project while postponing the previous one.
So, I now have weeks of work for this client alone, while yesterday I had none, while last month I had months (talk about churn) 
Of course, that resulted in other customers getting more priority with their changes.
Meanwhile, another customer called this morning, his reporting didn't work, took me half a day to fix.
Of course I'm not doing everything ASAP, but when a client calls it usually has to be scheduled in later this week, or at least somewhere this month.
|
|
|
|
|
Scrum grew out to solve a different problem that the one you have. It was an answer to the world of large teams running waterfall with Gantt-charts and other horrible things.
So I would cross that one our right away in your situation, but I would also recommend you stop with remarks as "I know scrum should be the opposite of rigid, but that's not at all how I've experienced it" as that directly translate to "I tried to use this screwdriver as a hammer, and it sucks so it is a bad tool."
Kanban is a known "lighter" alternative, but it might still be too rigid for you. Look at it and see if there is one or two things you can take our of it - maybe as little as a prioritized list where you show restraint from changing the top item unless really needed is enough. I have seen teams receiving "Why is that feature I asked about just before the last two emails asking for urgent features not finished yet" emails while they are still working on the last email. A list makes something like this apparent - it it might also make it easier both for you and the customer to judge "do I REALLY need to change the priority right now, or will tomorrow do".
|
|
|
|
|
lmoelleb wrote: but I would also recommend you stop with remarks as "I know scrum should be the opposite of rigid, but that's not at all how I've experienced it" as that directly translate to "I tried to use this screwdriver as a hammer, and it sucks so it is a bad tool."
I'm really not the only one saying that and I think many people here would agree with me.
Actually, I believe one of the writers of the original manifesto said something along the lines of that it was meant to grow more agile, but teams are now stuck in their scrum ways and holy two-week cycles.
I think it's so hard to implement correctly because it's based around change and many people don't react to change very well.
I've literally been in the situation where we were two days into a sprint when management came in and said, "things changed, we don't need what you're doing now, we need that other thing."
And the team was like, bad luck, we're finishing this sprint anyway because that's what we committed to, and then start on the work you need.
That's two weeks wasted!
Or how about, this story has a very high priority, but we don't know if the business wants the button red or green, so we'll have to refine it further and it'll have to wait for the next sprint.
That's not adding value, that's just mindlessly clinging to some process to the point where it does more damage than good.
Two distinct teams by the way.
lmoelleb wrote: Kanban is a known "lighter" alternative, but it might still be too rigid for you.
Kanban is actually fine!
Not doing it now since I'm alone most of the time, but a good one for working with that designer.
I'm working on growing the team and I definitely need something like that.
|
|
|
|
|
Of course many will agree Scrum is too rigid. Everyone who needs something less rigid that what Scrum gives them. Rigid or flexible is a relative measure. Stop treating it like absolute and assume something is "too rigid" or "too flexible" for every situation. It is fine you say "Scrum is too rigid for what I need - or "Scrum is more rigid that what I use". That is very likely to be the case.
And if your anecdotes makes you believe "that is how scrum is", then you have no clue what Scrum is. You have seen someone doing something they do not understand and based on this, you now think you understand Scrum is not flexible.
Both your anecdotes are 100% clear violation of the agile manifesto. Scrum and other agile methodologies can't fix incompetence...
It's been a while (years) since I last abandoned everything in a sprint - but I have of course been in situations where it happens - and you just do it. Basically you remove any story that it no longer makes sense to work on no matter where you are in the sprint - and if that is all of them, then you remove all of them. Once you have no stories left, you have two choices: Start a new sprint, or pull in some stories in the current sprint. Do whatever works best for the team in the situation. If it happens now and then, no big deal. If it happens often, it is a sign Scrum is being applied in the wrong environment.
Some more anecdotes to add to yours:
Time since we accepted a story even though it was not ready for grooming: 15 days. It was clearly the priority, so the planning was longer than usual as a lot of things had to be discussed. Time since we have accepted a new story into a running already committed sprint: 3 hours.
|
|
|
|
|
Look, I get what you're saying and we mostly agree with each other.
I know scrum, I know what it's supposed to be, and I know how different teams implement it differently.
All I'm saying is, I generally don't like the implementation, whether that's because people are incompetent or scrum is too rigid/time-wasting for my tastes is not really the issue.
Besides, a big part of scrum is that you involve your clients and that's really the last thing my clients want (and also the last thing I want as my clients know absolutely nothing about software development or even what they want/need).
Doing scrum by myself doesn't really make sense and doing scrum with a designer who just gets a bunch of separate assignments also doesn't really make sense (to me, at least).
I have one larger customer who has their own IT department where we use a kanban-like approach (although not for everything).
So let's agree to agree, or disagree, whatever makes you happy
|
|
|
|
|
I could not agree more. I have a client that doesn't know what he wants until he sees what I have done.
AND, any new need that pops up for his business, I have to drop everything and get that done. 
Very frustrating. I have to keep an Excel spreadsheet to keep up with what is done and what is not!
ed
|
|
|
|
|
Yeah, but don't tell them "no!"
I'm going for customer satisfaction, they want something and I deliver (well, if it's possible with the means at my disposal, I now have a customer who wants front-row seats for back-row money, that ain't happening).
Customers like working with me because I don't have all that red tape, they ask and I deliver.
Sometimes not immediately, but always faster than their larger suppliers.
Slow Eddie wrote: I have to keep an Excel spreadsheet to keep up with what is done and what is not!
I have that too, all teams have that I guess (or a scrum/kanban board).
|
|
|
|
|
Do you know where Agile comes from? Because the statement "Agile is the invention of project managers and is designed for their purposes" to me looks a bit strange when you know the history of agile.
|
|
|
|
|
In most cases, project managers and scrum masters are not software developers.
They too often see software development as a bunch of developers on an assembly line, putting software widgets together. That is because much of what has been applied to the Agile Manifesto comes from the manufacturing and automotive industries. They have a hard time understanding how, in the "widget assembly" paradigm, you can't know the exact amount of time a software project will take, or how there could be unknown impediments that only appear during development, not design and planning.
IMHO, a senior-level software engineer who is good with "people skills" and can lead (not just manage) is who should replace the slots occupied now by project managers, business analysts, and scrum masters. Neither Scrum nor Kanban work well for software development but do work well in manufacturing. The proper role for project managers and business analysts is as assistants to the project lead (who is a software engineer as described in the first sentence of this paragraph).
My preference is to meet once a week to outline progress and setup the work for the week, then let the developers work on their own to accomplish their work. Stop with all the metrics that are better suited for manufacturing, and just measure progress once a week at the weekly meeting by what is actually accomplished.
Results matter much more than process.
|
|
|
|
|
Working solo you can do however you want but once a second person is added there needs to be some sort of structure. Formal process for two people who know each other, probably not. But some form of "Here's what I'm working on. What are you working on? Are we going to step on each other's toes?" conversations need to happen.
I agree with the Kanban suggestion.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
MarkTJohnson wrote: But some form of "Here's what I'm working on. What are you working on? Are we going to step on each other's toes?" conversations need to happen.
Yeah, definitely!
But for me, they can be just that, conversations.
That's exactly how my first employer did it.
You fix that form, you write a new one and I'll work on a third. Are we clear? See you next week (or when someone has questions, or actually keep seeing you as we shared an office)
|
|
|
|
|
Waterfall:
"We can't do that until the next release in around a year"
With Scrum:
"We can't do that until the next sprint in a few weeks"
That is why you will find people saying Scrum gives flexibility. It all depends on where you started from. So yes, people who says "Scrum brings flexibility" are completely right. Just as the people who says "Scrum is making the process too rigid" are completely right.
Understand what the methodologies tries to solve - then understand your own processes (and the problems with it). Then you can choose the right methodology for your team. Only consultants think the same process is the answer to every situation (and strangely, it is always the one where they can offer you "services").
Personally my productivity can be pretty much killed by switching priority daily (or multiple times a day) and I have yet to see a team (let's say 5 people+) that is not more productive if they are allowed to work unobstructed for at least a few days. My personal preference would probably be Kanban - but to be honest our Scrum is already leaning in that direction just because we don't take it too too serious 
|
|
|
|
|
In 40 years of professional software development experience, I have never seen Waterfall (as you describe it) done. There is always versatility in every project I have seen or been a part of in that time.
I think the "waterfall" argument that underlies the current approaches to Agile is a strawman argument. I don't doubt it has or does happen with rarity (I have not worked for IBM, for example), but I have not witnessed it.
|
|
|
|
|
I have 25 years in software development, and I have seen it in two out of three companies I worked in. Well at least it was supposed to be waterfall, but of course it did not work so it was fudged left and right - still, they pretended everything was planned 6-12 month ahead. The first company was a very large ISV, the second a small one, but both of them made products (as opposed to projects) targeting large enterprise customers. A friend worked doing projects for government, and they also had to do waterfall - and for them the trick was of course to quote low, then charge relative high for the changes that would ALWAYS be requested to turn a profit. If they quoted realistically from the start someone else would get the deal - or the project would be cancelled due to too high cost.
|
|
|
|
|
I think your post is talking about two different things.
The first one is process. You don't need guidelines or rules to follow until something bad happens. Then you put something in place to reduce the chances of it happening again, even if working alone.
The second one is stability. I would also get annoyed if priorities were constantly changing. It's also not an effective way to work when you often have to drop one thing for another. Returning to where you left off takes time. And if you never return to it, you wasted time on something that wasn't needed.
The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
|
|
|
|
|
Greg Utas wrote: The less churn, the better. Wanting to know what's coming months in advance may be unrealistic, but knowing what's coming this week isn't. It won't always work out as planned, but it usually should.
True, but our churn is dependent on that of our customers.
If they have churn, we have it too.
The difference is that we're getting paid for it.
Greg Utas wrote: And if you never return to it, you wasted time on something that wasn't needed.
I've been hearing this a lot too.
Frankly, I don't really care.
It's nice when customers use your software, but if they don't, they don't.
As long as they pay for it it's not my time that was wasted, but their money.
|
|
|
|
|
I can see why you wouldn't care if the customer is paying anyway. It's probably a personality thing. Like your colleague, I don't like being yanked around in one direction, then another. I would tell the customer that churn has a cost and suggest that we work together to better determine the requirements in advance. If they didn't want to do that, OK, they're the customer. But not one that I'd gladly take on again.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
