|
Do you point the stories(terminology used in agile)? Had a scrum master who was completely hung up on Fibonacci point values. Mercifully he changed jobs within the company. A day is approximately 2 points now.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
Yes, we score stories with points that are Fibonacci point values.
Also points are not about how long it will take to complete but complexity.
I could drone on endlessly about that last subject of complexity/time but suffice it to say that I am now so indoctrinated that I accept that points are not about time 
Defects however are not scored with points but with t-shirt sizes S/M/L which is a time score - please big hole in the ground come and swallow me up...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Be thankful that your experience with a highly touted process has been so innocuous.
|
|
|
|
|
As you're no doubt aware, Agile is a manifesto. It's not a methodology, it's just the following principles.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan That's it - it's pretty simple. The whole idea revolves around the idea that you are meant to be delivering software that people can use so you shouldn't be forced to jump through documentation hoops to get there. At it's heart, Agile can be condensed into the idea that you deliver early and you deliver often. In other words, develop your applications in such away that you're at most 6 weeks or so away from a deployable, tested version. Don't worry about polishing the application at first; get the basics and the areas that will give you the most benefit in place first, and add more and more to it as you go on. Interestingly enough, when we hear about teams focusing on stand ups then this is a situation where the very first principle is being violated. (Oh, and despite what people think, agile development does not mean there should be no documentation - there's always going to be a place for it).
|
|
|
|
|
Pete O'Hanlon wrote: Working software over comprehensive documentation
That must be why our source code has NO meaningful comments. 
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Very well put, POH!
/ravi
|
|
|
|
|
Oh, well, that's just Scrum. Agile is a broader topic.
My team has always been agile. When management came around telling everyone to use Scrum, I said "that's gonna slow us down".
P.S. You don't "do" Agile; you "be" Agile. "Doing" Scrum is just one way to "be" Agile, and not the best.
modified 17-Sep-21 15:40pm.
|
|
|
|
|
I work in an agile environment and that's how we work - morning meetings and two week sprints.
Anything committed at the end of the sprint goes into the release candidate which is tested for two weeks.
It just seems to be a way of organising work so that we can release something every four weeks.
Previously we have also had a more complex approach to agile with all the "ceremonies" but the morning "standup" and two week sprint seems enough to me.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
When you lack management skills and try to micro manage project you give it a name; Agile.
What happened to the days when a manager actually got out of their big boy chair and got in the trenches to help solve problems.
Give someone a goal and a time and let them go. If you're not sure of their skills, help them, guide them and teach them.
You can't put every programmer in the same category, we all have strengths and weaknesses.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
Managers don't seem to exists nowadays - typically agile teams have a scrum master, a team lead and a product owner.
I remember when I first joined and asked about managers and was almost hissed at for asking the question.
The concept of manager seems to be a bit alien to modern software methods - it's something I miss.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Fortunately I'm managed by a team lead who really knows his stuff. He has been able to answer all of my questions about how the software works.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Your team isn't doing agile! Also, "agile" isn't something you "magically apply" to a development team and expect it to work. Your entire product development organization needs to be agile for it to work for the dev team.
Put simply, an agile (software development) process allows stakeholders to request the implementation of small pieces of functionality. The implementations can then be reviewed by the stakeholders, and the requirements could potentially be refined or revised. This is immensely valuable, because it's very difficult to get software requirements right the first time. Don't misinterpret this for a "free for all" when it comes to defining requirements. The agile process simply makes it easier to deliver a continuous and progressive path towards the final product, because customers usually don't know what they want until they've seen what they didn't want.
I highly recommend watching this video (in fact all videos on Clean Code by Uncle Bob). At my organization, the set of Uncle Bob videos is mandatory instruction for all devs and dev managers. A few of the early videos are required to be watched (and understood) by the entire product team. I understand we're probably in the minority.
What is Agile?[^]
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: the set of Uncle Bob videos is mandatory
right
|
|
|
|
|
Agile is just developer socialism. Whenever it has been tried people who survive it never want anything more to do with it and people who have never tried it think that “this time will be different!”
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
What, no three to four 1+-hour meetings a week!?
There's the backlog refinements, sprint planning, review, retrospective...
I've literally spent hours refining, prioritizing and planning a sprint, only for some manager to come in three days into the sprint and change everything because priorities had changed 
That company was the biggest money wasting pile of incompetence I've ever seen though, so maybe not completely representative.
|
|
|
|
|
That's a good story, thanks!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Or you're just a tiny cog in a huge machine. Requirements in, module out.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
To repurpose an old aphorism, Agile is like teenage sex:
- Everyone claims to be doing it
- Very few are actually doing it
- The few that are doing it are usually doing it wrong.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Richard Andrew x64 wrote: But I've been in the position for a year now, and the only difference from my previous jobs to this one is that now we have morning meetings and we delineate our work into two week intervals. That's it. Is this the highly touted Agile method?
I've worked projects in traditional "up front design"/waterfall and agile management. The right choice depends on the project and the players.
I've found that the following are relevant:
- UFD requires that the entire project is designed and planned before the software development starts. This can help with budgeting and well defined tasks. The project is finished when the development and testing is done. This works best with a relatively short time span (several months).
- A UFD design document is "the design" and needs to be completely thought out.
- A UFD project generally describes one version of the product.
- An Agile design document is needed, and needs to define high level features but should not describe granular details.
- UFD invites project management dysfunction such as feature creep, "this isn't what we want" and is very difficult to change one or two steps in "the plan".
- Agile accommodates feature creep and invites stakeholder and end user participation if they see that they can change a bad choice into something they want.
- Agile projects can comfortably go on for years and span multiple versions of a product.
- Agile allows software development at an earlier stage in the project design. You also get a better ad hoc idea of how much effort is required to complete the task.
- Agile is harder to budget and justify to upstream managers and bean counters.
- UFD generally provides better adherence to features and (sometimes) reliability.
- Agile generally provides better UI and general User Experience.
- Agile will give you a product that you can start using much sooner, as feature 'x' and 'y' are implemented.
- Agile will let you prioritize implementation details, do UI changes or partial redesign or add new features as needed.
- As long as you have incoming funding, Agile will give you a better product that more people will like.
For a better outcome:
- Use UFD to design a rocket lander or navigation computer or hospital ventilator.
- Use Agile if you have indecisive users or sales/managers that promise new features that were not planned for.
P.S. if your scrum meetings are hours in length, you are doing scrum wrong. This daily meeting should take place every day with every person in the meeting saying something for 30-60 seconds max. The whole scrum meeting should be over within 15-20 minutes. If a major issue comes up, it should trigger another non-scrum meeting with only the appropriate people attending.
If pigs could fly, just imagine how good their wings would taste!
- Harvey
|
|
|
|
|
|
|
That was already posted in Insider News.
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: That was already posted in Insider News.
or was it? maybe there is a tear in the space time continuum, causing you to think this, but in reality it never really happened.
maybe it happened, but because the internet really doesn't exist, it didn't actually happen after-all.
all of this is very interesting and mysterious indeed. 
|
|
|
|
|
This is your last chance. After this there is no turning back.
You take the blue pill, the story ends; you wake up in your bed and believe whatever you want to believe.
You take the red pill, you stay in Wonderland and I show you how deep the rabbit hole goes.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
No, Twatter and Farcebox would require advanced Artificial Stupidity, and that's much harder to create. 
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
