141–150 of 174 posts
Problem I found with this journey is that Scrum concepts pollute Kanban and beyond. We now just do what works, as little process as works for us - and we implicitly review the process with each commit.
There is a whole industry of selling "Agile" to corporations that is peddling this shit. If you are implementing a set process from a book you are by very definition anti-agile. When I implement agile at companies I don't even call it agile. And the only initial practices are: * transparency -- you can't fix what you can't see * improvement loop -- you need to learn from your mistakes and feed the results into next c…
What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a da…
Rather than focusing on the team, its own alchemy, its work and the very specific nature of the work.
The process should adapt to the people and the work at hand. Not the other way around. That's the very ethos of the Agile Manifesto. Scrum is used in corporate environments as the exact opposite.
There is a whole industry of selling "Agile" to corporations that is peddling this shit. If you are implementing a set process from a book you are by very definition anti-agile. When I implement agile at companies I don't even call it agile. And the only initial practices are: * transparency -- you can't fix what you can't see * improvement loop -- you need to learn from your mistakes and feed the results into next c…
What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a da…
Daily Scrum, Sprint Review, Sprint Goal, even the role of Scrum Master - depending on the team, some or all of these things can be removed to the benefit of the team, but Scrum itself doesn't allow it. It's either all or nothing, which is why I believe Scrum itself is anti-Agile.
Earlier quoted context omitted.
What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a da…
The problem is not that Scrum doesn't have these things. The problem is that Scrum is a heavy and rigid set of processes that, besides a few useful things, adds a lot of unnecessary overhead. Daily Scrum, Sprint Review, Sprint Goal, even the role of Scrum Master - depending on the team, some or all of these things can be removed to the benefit of the team, but Scrum itself doesn't allow it. It's either all or nothing…
Of course it doesn't. It wouldn't be scrum if these were removed; it would be something else. Which is fine; but if you prefer to organize your work in a way that isn't scrum, then why would you call it scrum?
> It's either all or nothing
Isn't it the same with everything else? An agile manifesto, but with only one value rather than four? TDD but with tests written after the code, and without refactoring? And so on?
Earlier quoted context omitted.
What you described here is perfectly consistent with scrum, which Holub and Farley ridicule. > feed the results into next cycle Right, so you have a concept of cycles; in scrum these would be thought of as sprints (larger cycles) or single days of work (smaller cycles) > transparency -- you can't fix what you can't see Yep. In scrum, this would would be addressed by daily scrums (transparency and coordination on a da…
The problem with Scrum is people talking about how this should be more Scrum, or how this is not really how Scrum is/defines things/should happen. Rather than focusing on the team, its own alchemy, its work and the very specific nature of the work. The process should adapt to the people and the work at hand. Not the other way around. That's the very ethos of the Agile Manifesto. Scrum is used in corporate environment…
Scrum, as defined in the Scrum Guide, is perfectly consistent with the Agile Manifesto. It is one of the ways of putting the manifesto into practice. Scrum's framework clearly promotes interactions between individuals, customer collaboration, working software, and response to change. If individuals, who, according to the manifesto, are more valuable than the processes, decide that the processes defined in scrum aren't working for them, they are always free to reject scrum and work out another set of processes. But if a team doesn't yet know what processes would work for it, scrum is as good a place to start as any, to actually feel what enacting the manifesto actually involves.
Earlier quoted context omitted.
Just do away with sprint commitments. Pull a new story off the backlog each time someone needs a task, and count how much you accomplished at the end of the sprint instead of guessing at the beginning.
That sounds sensible to me! Thanks. Nice to get these perspectives as I have never heard a colleague say that before. I guess you can then get rid of the 2 weeks? Because you can measure velocity as a continuous rolling average. Retros could be continuous too and standups already are. Grooming is easy to make continuous too.
A lot of this really resonates with me as a manager of dev teams, but once again the very unhelpful advice for "how do you figure out when you'll be done?" is "refuse to do it". If an executive is asking me when we will deliver something this is a completely valid question. It's how everyone outside software development lives. If lean aglie can't give me a way to shape expectation of what we're building AND answer th…
Everything in my experience aligns with what this post states. The best teams had processes that they developed themselves, organically. However, there is a very real, pressing need from middle management to answer “what’s going on with X” when upper management asks. “I don’t know” is not an answer and neither is “we don’t know when it will be done.” These conversations ultimately control the flow of funding. So we m…
This. The people paying for a project want to know how long it will take, how much it will cost, and what the feature set is going to be. This is of course not reliably possible, so we end up with an elaborate back and forth that tries to re-impose waterfall whatever the label on the process is. Similarly, "Individuals and Interactions over Processes and Tools" is really difficult for an organisation to cope with. Ev…
> the people paying for a project want to know how long it will take, how much it will cost, and what the feature set is going to be.
Certainly … if they’re “doing it wrong”. :-)
Do VC know any of these things? The agile approach, YC, and the SAFE are predicated on these being unspecifiable to any signficant accuracy.
So a better approach may be to:
1. Change the money process from budgeting to investment.
2. Fund capable teams of dedicated fixed capacity, and you can nail budget to the penny.
3. Then, fund by mix of ROX/ROE/ROI* on prioritization of the backlog, and you’ll get out of the team what you chose to fund as the team capacity.
Done.
* Return on Experience (NPS etc.), Return on Equity, Return on Investment. And consider sharing something like “Implementing Beyond Budgeting” with the money people:
https://smile.amazon.com/Implementing-Beyond-Budgeting-Unloc...
** To maintain trust with the money people, engineering cannot employ unproductive teams. It may be the tradeoff for engineers from a terrible budget driven process is better job security, since their individual performance or abilities to output great features matters less to the corporation than the estimation/budgeting/CYA processes do. In the budgeting world, senior executives get rotated out faster than IT teams.
It’s not hard. Maintain a priority list. Always work on what is #1 priority. If #1 priority is blocked then work on #2 priority. Use the priority list to negotiate with your stake holders. That’s it. I have had a lot of success using this simple formula in my 30+ years career. Both as an individual developer and when managing small to large software teams. It’s simple. It works.
Agreed. It’s not hard. Maintain a priority list. Always work on what is #1 priority. If #1 priority is blocked then work on #2 priority. I've described this same approach as "risk driven development." Identify the highest risk to an effort's success, address it, then the next highest, etc. If, during this process, a newly discovered risk is identified as being more than what is currently being worked, put the new ris…
Earlier quoted context omitted.
Contractor is the wrong metaphor. They're building a house based on a plan already designed by an architect. Software isn't the making of a thing, it's the designing of a thing. Ask an architect how long it will take for them to design your dream home.
Architect designing home is the wrong metaphor. Buildings do not have moving parts. Their core structures are almost all fundamentally the same. There are problems to solve, but again, not dynamic systems, and always variations on very well known themes. Programming is usually like building a new type of interdimensional alien spacecraft engine that interfaces with some other alien artifacts. There are usually a lot…
If programming indeed was "usually" like that, then there shouldn't be much software getting produced at all. Since building "a new type of interdimensional alien spacecraft engine" is something that's very very unusual, to say the least. :)