If I create my own company, I will try really hard not to hire people who adopted buzzwords like - scrum/agile/user story/spike/standup/sprint etc.
These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done.
Please, do not point me at agile manifesto.
To me agile looks like totalitarian sect which constantly preaches flexibility and freedom while swiftly punishing anybody who ever dare to deviate from strict daily rituals and mantras.
Dry definitions in agile manifesto means nothing in real life. What's actually important is a context which created by people who adopted it.
Agile/scrum is biggest cargo cult I've ever seen in my life.
I used to think that the words you mention are the problem causing so much bureaucracy. My thinking has changed such that I don't blame the vocabulary, instead I blame the people who abuse it.
There are genuine people who use these buzzwords you mentioned because it makes it easier to discuss concepts/aspects of project management. It's faster to say "user story" than to say "an informal, natural language description of one or more features of a software system" (from Wikipedia), or to describe all the additional context that "user story" evokes in a person.
You're right that concepts can be misused and end up in a totalitarian environment. That's because the people at the top want it that way. In my experience, they don't want to (or can't) dive into the context of all of their teams and prefer to seek a one-size-fits-all approach.
At my last job there was a new CTO hired about a year before I got there and he started a Scrum initiative on the whole organization. They hired a PMO (Project Management Officer) and a slew of Scrum Masters. Half of the Scrum Masters I worked with were genuine people who wanted to help their teams and knew that by-the-book Scrum wasn't going to work. Those Scrum Masters left within a few months because they kept being told to force policies that were doomed. People argued, but the CTO and PMO didn't budge and problems never got addressed.
If you ever create your own company and you want to prevent bureaucracy, I think focusing on vocabulary will not be very effective. Focus more on keeping your ego in check, constantly push flexibility, and test the unusual ideas of your workers. However, if you have run-away success, any of your own attempts to wrangle bureaucracy will be hampered by size. Delegating anti-bureaucracy could be hard (and counter-intuitive).
There's some truth in this, but I don't think "good agile" is totally innocent. In particular, they always seem to be uncompromisingly team-focussed methodologies (a lot of stress on the "...and interactions"), with little scope for individual creativity and problem solving.
Not denying that. But those questions are specifically aimed at preventing people "going dark" even for a couple of days. On projects which require some exploration and creativity, I don't see that as a positive.
This is a perfectly valid perspective to have, and I totally understand the apprehension and aversion to management buzzwords.
If I may share an alternative possibility..
It often comes down more to communication styles and the individuals involved. It's still possible to do exploration and answer the questions about what's done / doing / blocking. You could say "I learned X won't work, now I'm exploring Y, and currently debugging Z". The only time this would be problematic is in scenarios where the leader is not supportive of honest communication about activities, in which case it may worth asking why you're spending your life / time underneath such an individual.
In general I'm a strong advocate of tight feedback loops and frequent communication in a team. There are many benefits, including helping ensure everyone has access to the support they need to be successful. The result of these tight loops sometimes also translates to deciding to set someone loose for a[defined] period of time to focus their energy on researching creative solutions or just jamming on something without distractions.
P.S. - Regarding "going dark": As a manager I can understand why as a general rule of thumb that managers pose issue with this.
The common, crappy scenario goes like this. An individual goes dark, then comes back with nothing of consequence to show for it or any evidence that they tried to do anything. Now valuable time has been squandered, while the rest of the team was hard at work. This leads to an array of harmful effects for all involved (the manager, the team, and individual worker).
Even if you are super responsible, fear and trauma from past offenders could still be a trigger for some managers.
I think Dave Thomas[0] made some great points recently [1] about what Agile (as a noun) has become and I think it addresses some of your complaints. Note this isn't just a repeat of the agile manifesto, it is him discussing why he hates what Agile has come to mean to a lot of people and it sounds like his grump-level closely matches yours.
The jist I get from it is that agile has become an Enantiodromia[2] and has in some ways simply replaced the problems it was there to fix. That doesn't mean it has to be that way, but thats what happens when people take something and create a religion around it.
In my company we call our process "agile", but what that really means to us is to do the minimum amount of analysis we can to develop the features that the customer actually wants, and when they realize what they thought that they wanted was not really what they wanted, we can change it without wasting massive amounts of time. If we find that our process is causing problems for the devs, we tweak it. When we find we're not doing enough analysis in some situations, we try to improve those situations. No buzz words really, just what is best for us and what is best for the customers.
You haven't seen cargo cult until you've worked in an organisation with a pmo, and tranditional project management.
I had to literally write a 5 page business case for relatively small features that takes more than 5 days. You then had to get it approved by the pmo board. These people have no product management skills either.
Once it's a approved I have to write a full plan and schedule.
I've seen 50-page project specs written before the dev team even new there was a new project. But PMO board. Ouch.
At the other extreme, you have your process-adverse adhocracy where your brilliant new lead developer unilaterally decides the first step in fixing the latest issue with your existing CRUD application written in PHP is to write a new Node framework.
Meanwhile, junior developers are getting bombarded directly by anyone in the organization who encounters a problem while using their keyboard.
Companies like this exist. Maybe not quite this extreme. But I've encountered a few variations on this theme and they've given me a deeper appreciation for agile concepts and terminology.
The problem is that the companies that "went agile" just added some cargo cult practices they learned by some Agile consultant /in addition/ to the old practices you describe.
You know, I am sure many of those Agile consultants that big companies hire don't even know what the Agile Manifesto is.
This can actually be very useful as it insulates your dev team from some VP wandering across and demanding a pet feature be implemented. The VP has to negotiate the PMO board first
Anyone who traffics in buzzwords without adding value is the problem. Scrum is fantastic when you understand the why of its process instead of just following the rules. If you schedule scrums and sprint planning, then accept ungroomed stories, change priorities, deliver without testing, then you are doing it wrong. Really disciplined and experienced teams can follow the intent without the process, but more often than not you need rules to keep everyone aligned.
XP was for developers. Scrum expands it to product management and ownership. The biggest benefit to me isn't developer productivity, it's the ease with which we can communicate progress to stakeholders.
Actually, my opinion is that "agile" the way I most often see it is nothing more than a lighter weight variation of what we were already doing with SDLC. Time/cycles are compressed, documentation is not quite as structured, but the basic ideas are similar.
I agree the hype cycle distorts things too much. I think maybe your opinion is a bit too harsh, but - I would think to use whatever technique succeeds for the need and the team, whether more or less formal. So more power to you if the technique you prefer works.
Processes are templates, anyone that treats them as dogma is doing it wrong... a good process simply facilitates effective communication and planning with the lowest possible overhead.
Agile/Scrum/waterfall/etc should be used as inspiration - but the right process is custom built for each situation.
The only thing that really matters is periodically retrospecting and refining - cut the cruft, fix the flaws, and reinforce what's working.
I see you have "user story" in your list of hated buzzwords. If you don't mind my ignoring the rest of your comment, I'd like to focus on that single phrase. I claim it is ok.
What was going through the programmer's mind when he wrote a particular passage of code is a very useful thing to document.
In my user-facing code such documentation tends to look something like "just now as part of an attempt to achieve X, I did Y, expecting to see Z, but I got U instead." Comments like those occur often enough and are valuable enough that it is good for me to have some quick way to refer to the category. Isn't "user story" just as good as any other quick way?
It seems that you don't actually object to the principles behind Agile or the processes themselves - just people who abuse and force agile processes on others without understanding _why_ these processes were introduced in the first place.
I don't think the terms you listed are just buzzwords, and I don't think people who use them are always going to be bad hires. It's just terminology.
Agile development has worked well at a lot of organizations. When you hear someone use these terms, you should probably begin digging deeper into why they think the framework/processes/whatever worked for their previous team.
I've found value in adopting bits and pieces. We have a small team (2 developers, sometimes more) and we're balancing bug fixes/customer needs/putting out fires/new development. Some guidance about where we're going and what we're walking on keeps us from focusing on the wrong things, but at the same time, when there's 2 developers you have to minimize overhead. I use a backlog and "sprints" (just a range of dates really). I assign points to have a bit of a clue (since I have to be able to answer what's on my plate and give some guidance as to when things may be completed). Nothing is sacrosanct: bugs get points the same as new development, since to the business it's all revenue blockers. A sprint is never carved in stone; any thing can be put in at any time, and priorities can be shifted, as they necessarily must. I don't do planning poker, standups, or retros ... daily communication via Slack is sufficient. We have no made up jobs like "scrum master". To me it's just a framework, in the same way that TDD or MVC are. You adopt pieces that help you get shit done, and ignore the pieces that get in the way of getting shit done.
Wanted to add, people felt the same way about SDLC when it first came around - since it preaches such structure and method.
I'd be curious what software engineering process you'd prefer then, for your own company?
Some have said that the failure to make structured methods work in software is what makes it less of a formal engineering discipline, like a trade that can be unionized and guarantee a particular level of quality due to standardization of process and method.
Small batches. What can I do today, that will demonstrably put us in a better position at the start of tomorrow. Ideally should result in deployed code to production, but not always (e.g. research).
Ironically, you could argue this is agile with one day sprints - I wouldn't disagree much.
Would you rather be in a situation that before any real work gets done you have to have a "project charter", 3 months worth of requirement gathering, three months worth of development and user testing and find out at the end that your delivered product is completely unusable by the people you were developing for?
"Buzzwords" create a ubiquitous language (a Domain Driven Design buzzword). I can change companies and if they are using those "buzzwords", I know what they mean.
No, that's jargon. Buzzwords are distinguished from jargon by being language that has become semantically ambiguous (possibly even semantically null) through pervasive inconsistent use, particularly in marketing.
"scrum master" is the one that really grinds my gears. Ive pretty much stopped doing all the jira nonsense and let my productivity speak for itself. I've been left alone about it.
Others here have more thoughtful opinions on the whole thing. I'm just kind of annoyed about it all without the energy to try to formize what's wrong and why. Just let me engineer.
With a lot of agile stuff I feel like you tend to end up with a result like a PT cruiser car. Some years ago I rented one and they had done everything right: Interesting design, cool features on the inside, analog clock on the dashboard and everything else. They had checked off all user stories of the car.
But the end result was a crappy car. A lot of features were implemented in a subpar way. Nothing really fit and the car just didn't "feel" right.
With strict agile structures I feel the same happening. You check off stuff and on the surface you are doing everything right in a methodical way. But there is no mechanism to check if the overall result feels right and has cohesion.
It's akin to technical debt, maybe call it Agile Feature Debt.
You implement a feature, it's done, all obvious bugs are fixed. But now that you have finished it you've gained additional knowledge from actually using it. And you realize the way it was designed or implemented isn't optimal, in fact sometimes you realize the way it works is dead wrong, and makes the product less usable.
Too late. It matches the spec. It's been checked off. Time to move on to the next imperfectly designed feature and ignore what happens when it actually works.
In my case our product was designed with a UI that was overly complex, with far too many taps and views to navigate through to accomplish a specific task. And apparently the implementors were either incompetent or totally under the gun to make tight deadlines. Because it's performance is terrible, making the long trip through all those views slow and twice as onerous.
A significant part of the agile process is that meeting the spec isn't the goal, being accepted by the customer is. Your description sounds like there were no sprint reviews to get customer feedback, or it was ignored. So you're arguing that a significant problem with agile is that if you skip a fundamental piece, it results in bad outcomes?
In our case the "product owner" is marketing. The lower level marketing personnel I have contact with just match the work to the spec, and can't or won't authorize any work that doesn't exactly match spec. Eventually things are bubbled up to their boss, and communicated somehow and they are handed back a list of priorities.
For example, I recently on my own time implemented a caching mechanism for the most often used views in our product, it increased their loading performance and usability by massive amounts. It was very encapsulated and easy to test, I asked to check the change in for our last sprint, and was told no, it's out of scope.
I'm not saying these are examples of problems with Agile. I'm saying these are examples of problems with Agile as it is sometimes implemented.
- the person assigned to you as voice of customer does not use the product
- the person doesn't have time to engage with the dev team
- the person doesn't care
Over the years I have seen exactly one product owner who could give useful feedback. All the others in the end had no idea what they were after.
It worries me that I'll paint myself into a corner with Agile one day. Plus, the design documentation gets pulverized into lots of tiny user stories, so it's hard to get new people on board.
I use a technique where I can visualize user stories as if they were part of a regular functional specification. It involves categorizing user stories into features/functions on paper first, and then entering them into our agile tracking tool, and then keeping the paper up to date when new user stories come up.
I use dot notation for functional specification grouping into features to uniquely identify user stories, which get tagged in the user stories in the tracking tool. Often they look like "Admin.UserManagement.CreateUser" or similar naming. I give meaning to each level of the hierarchy and document each, so they become like natural epic, feature and story levels.
It's extra work, but you basically end up with almost the same thing as if you had written a functional specification with use cases, just lighter weight.
If you have the features to do it in your agile tracking tool, you can use tags or categories and then produce a report of user stories that looks the same.
I remain convinced that agile and waterfall use almost the same basic tools but just in different ways.
I could go on how one can use formal project management Gantt charts to visualize sprints too.
The most important part of agile is the feedback cycle and non rolling release products don't have a very good feedback cycle. it can still help if you figure out pre-release feedback loops but sometimes they are poor representatives of actual results.
Is agile considered a product development framework or just a software development methodology? I think that's quite a difficult question to answer. I'm sure anyone that has worked on product development finds it difficult to figure out how things like research, design and maybe even quality assurance should fit into the agile way of doing things.
Agile is so flexible that it doesn't really answer the question of how some of the non-software dev things fit in, ultimately it comes down to strong leadership, and the honesty to say when something is going wrong. At the very least, agile provides the opportunity to fix bad decisions.
Following your metaphor of the PT Cruiser: it seems like they followed a waterfall process. They came up with a list and then built a car that fulfilled that list without evaluating what they were building st every step along the way. If they'd done it agile-ly, the crappyness may have surfaced much earlier in the development of the car... Maybe early enough to have done something about it. Alas, agile doesn't really work well with design of expensive tangible products like cars.
Agile doesn't work with cars because you can't deliver value incrementally by designing additional features. Producing a brake pad this week doesn't help if the chassis is still unfinished. Similarly having the entire car except the brake pads complete doesn't deliver any value. It's all or nothing.
Not sure I totally agree that it can't be done. I have no idea whether it's at all realistic/sensible/pragmatic to create a car via agile but taking your brake pad example it would seem very alright to have a set of stories such as:
"As a driver, I can stop the car at a reasonable pace" - ok, maybe you get some awful brake pads to begin with (or maybe if you are cheeky you just say...well, air resistance does that!)
"As a driver, when the car is travelling fast, I can stop the car extremely quickly" - ok so now we probably need some reasonable brake pads.
"As a driver, I don't need to replace the stopping mechanism all the time" - ok so maybe now we need to make sure the brake pads fitted are of a certain quality.
I think you can see where this is going. Sure the car probably needs brake pads...but assuming you didn't know much about cars (something agile is suited for), at each stage you could decide you need to do something different for the stopping mechanism. Additionally, many of the qualities of the brake pads demonstrate that things are not "all or nothing" necessarily.
I think I should have used the word "scrum" instead of "agile". Most scrum teams I have seen look like a micro-managed waterfall that are extremely reluctant to change anything because they need story points.
True agile works fine but it seems most agile frameworks lead to non agile work.
I don't think I've ever heard anyone compliment anything about the PT Cruiser before. From what I've read, they did everything wrong (assuming you want a car that drives well and lasts a long time, and doesn't look hideous).
I think the number one item on the checklist was "how can we build a car that /just barely/ crosses the line into 'light truck' category so has much lower fuel mileage targets per CAFE standards". On that point they did very well.
> You read articles that say it should be possible to complete a user story within a single sprint, ideally within a few days. That’s entirely accurate.
I'm surprised by that, as I tend to break down stories even smaller, to the point where they can be completed in a day or two. Anything that takes longer I consider risky and potentially a rogue story that could end up eating a lot of time.
Smaller stories are easier to manage, easier to refactor, it's much easier to review the resulting code and they usually have less complexity. I think it's sometimes easier to clear blockers with smaller stories as well.
Downsides are that it can be harder to get an overall view on the progress being made during a sprint, and sometimes tasks can have more dependencies or it can be harder to work on things in parallel. It also takes more time to prioritise the backlog.
Where I work now they have attached too much overhead per story. Time tracking, statuses in jira, separate confluence page with stringent rules about the content etc. So we now make huge stories in order to actually get to spend some time implementing stuff.
I think this is where most organized agile implements tend to fail. There's a lot of jumping straight to the user stories and sprints and all that, and skipping over some of the more basic agile ideas, first. One of them is that any artifacts that aren't executable code and test cases is likely to be dead weight that is expensive but delivers almost no business value.
A good agile book will (IMO) even go so far as to straight out say that if you're in a situation where you can't avoid having that level of documentation and paperwork, whether it be due to contractual obligations or organizational culture, then most agile methodologies are probably going to intensify your overhead problems rather than reduce them.
I imagine when something about the project changes, it takes a really long time to rewrite all those stories? Or you end up never re-assessing because it takes too long.
We often end up reusing the stories for completely different stuff, as they then have already been approved so we can skip some of the boilerplate, haha.
I agree. Also the way user stories are written just makes me want to throw up. "As a user I want to open the about dialog so I can see the version number." Blarghf.
Why not just "Implement about dialog with version number.".
I'm pretty sure 99% of 'user stories' are just feature lists written in a really really awkward and annoying way.
The point of the "narrative statement" is to show what value implementing a story will bring to help bring a relative priority order to things. Otherwise people keep championing their pet features, without focusing on _what's the point_ of this feature.
"As a user, I want to be able to find the full version number of the product to make it easier to get help when raising support requests".
This is now something we can argue about — is this story bringing more or less value than, e.g. setting reminders or 2FA?
If you write the narrative statements in a banal or glib way, just for the sake of them, then of course there's no point, but that's true of most processes — e.g. JavaDocs are a good idea in principle, but you can make them equally useless: "return Boolean: true or false".
"We want to add the software version number to the dialog. We think they will then cite this when they raise tickets"
?
At least in this form, you can expand on the context and justify it in depth.
Also, user stories often phrase the context as a given when it's really not. In your example, it's an implicit premise that a version number may help. In mine, the writer admits scepticism and therefore invites the programmer to think up some better solution.
* By having a premise, it forces you to question its validity up front (before any development work is done), getting rid of ambiguities early and having a shared understanding between business and technical team members (rather than the developer implementing what they think is a better solution, the product owner being unhappy with the outcome & only finding this out at the end).
* Using the format of "As a <type of user>, I want to <use a feature>, so that I can <achieve some value>" forces you to think about what user (customer/website editor/back office) gets what specific value (faster/cheaper/less error prone) from implementing some feature. By following the same pattern it makes it easier to compare unrelated areas.
I don't think the format is sacrosanct, but it's like any constraint you put on yourself (e.g. coding conventions) — if you find it hard to make a story work in that format, it's an indication that it may not be properly understood it really bringing value.
There is some merit in at least trying to think about your users at every stage of the design. Methodically putting the user in every sentence refocuses your work on what makes the experience better for them. You are right that making it super repetitive makes you filter out the bits about user interaction when you read a long list.
User stories are mostly there to frame progress only in terms of things your project owner cares about. If you talk to non-tech people describing their experience of a product, they don't just reel off a list of nouns at you. They say 'you can click on the little thing and it wiggles'. So this is how you should be reporting to your non-tech boss.
Don't say 'I made /timesheet/:id redirect to /timesheet/:id/slug-of-sheet-name', say 'Users trying to get back to a timesheet can just type some of the name in their browser's URL bar and it will show up'. Definitely don't say the word 'slug'. They will thank you for it.
The requirement you wrote makes it easy to accept it as a complete spec (just implement this!), when it isn't.
The user story you wrote prompts more questions -- what's the dialog look like? Do we display the whole version number? Does the dialog contain anything else? How does the user close the dialog? Where does the user interact to open the dialog?
Number one thing I do-- titles need to be scannable:
Admin :: Roles :: Multiple Roles)
And the "story" part goes in the body:
"As an adminstrator I assign multiple roles to users so they have access to all the parts (and only those parts) of the application they need to do their job."
..with additional context, exceptions, rules, examples, etc, in the body.
Number of developer hours should be nearly nothing. A couple per week.
Done properly, these things should keep you from getting halfway into implementing something, having a question nobody thought of, and getting stuck. Then stashing your work and moving on to something else while the original feature lingers half-done or dies altogether, either way the timeline got blown.
This is only possible (the time savings I mean) if you have a PM or product owner -- making devs do that work is madness.
Yup, recently moved to a smaller team. We have reduced standup to once a week and combined the other ceremonies into a single meeting, although we do give slack status' the other days. Even something this small has been a tremendous boost on my productivity.
I have been slowly suggesting we get rid of pointing all together, but I don't think that will be easily won :p
I am a remote dev out of timezone, and give a yesterday/today standup summary in Hipchat every day. If everyone else did that, we'd all have ~10min more each day for actual work. It's super effective.
This is all correct, and following this advice will improve your project planning. BUT it skirts the problem that Agile makes people think they can plan a project without knowing what's a functional spec, what's an implementation plan, and what of those things is implied by a user's desires. You can't arrive at a really good plan just writing more-concise stories that don't span too many hidden requirements. It helps, but it isn't a substitute for domain knowledge and systems analysis training.
That's the good part about agile. The bad part is that the idea of a "story" goes a bit too far in trying to make specification creation accessible. Decomposing stories into smaller pieces is a solution that's palatable to many because it avoids the hard work: Gaining more domain knowledge, and developing critical thinking.
It's an interview with Jeff Patton, who seems to be a pretty well-known name when it come to user stories and story mapping, and I really enjoyed his take on this matter.
"As a developer, I want to be able to log time spent on projects. So that the company could analyse [sic] time spent on different projects."
This user story is utterly absurd.
In this case, the "user" is actually the company, not the developer. The developer usually wants to provide business value by adding new features, or fixing bugs. And this is a feature, but it's not a feature for the developer. It's a feature for the company.
The fact that it got broken down into manual data entry features like:
"Users (read developers) select a project and enter hours spent for each day"
Makes me question whether the users were involved in making the stories at all.
This article feels like an illustration of what is wrong with Big-A Agile, not an exemplar of how to do it right.
I love the discussion happening here. I am into projects which "follow agile model" more than last 5 years, however every time I bring up such questions to folks who are die hard fan of these buzz words (mostly non-engineers), I am threatened to be sent to days long Agile/SAFe training again and looked down upon blaming I have "Old school waterfall mentality".
I am not saying Agile does not have any value at all. I think it helps middle management (top management only see some high level slides) get some numbers to measure how much work has been done and how much time is remaining to complete the features in the road map (epic progress). On the flip side everyone else forced to make those numbers good (either by working on weekend or taking short-cut with tech debts or in worst case compromise quality). This becomes obvious when managers set rules like - 90% of the stories must be completed at the end of two weeks sprint (if there are less than 10 stories, you have to close all of them). I see all stories coming to code review , merged, deployed , tested & closed on the last day of the sprint. Even if engineers believe do not believe its going too fast (superficial review, lack of manual testing) scrum master end up make it happen as his job is to make sure "sprint commitments" are met.
Now enter the world of SAFe. You plan for 3 to 5 months and can't do anything different in this time period (Where is the agility ?). You can't prioritize tech debts that you carried when you took shortcuts earlier to deliver MVP as "things are going alright". Hence, no iteration , only look ahead deliver more features. Spend a week on just planning and trying to accommodate feature based on "High level estimate" which is usually 50% accurate because you have not broken down to stories yet or has not done any experiments to check if some technology or recipe works or not. In addition to this you have hours of grooming, standups planning, retro , review in each up coming sprint involving the whole team.
I think every time you fit a process which may have worked in auto-mobile industry to software industry trying to "get more value " (lean is a new thing) you cease to be an innovative company.
Your company isn't doing Scrum at all. Your management is only using agile vocabulary and that's where the parallels end. And that's how Scrum gets a bad name.
I think scrum gets a bad name because folks get so caught up in strictly adhering to a concrete implementation of the agile philosophy that they lose track of the philosophy. Folks doing scrum often value scrum processes and tools over the individuals using them. Scrummers stick to their scrum plan rigidly instead of reflecting on and changing their process.
It's fine to say such teams aren't really doing scrum. It's true, right?
I wish that instead of promoting scrum as a one-size-fits-all agile process, scrum was taught as a place to start. That if in a couple months, a team was still doing scrum exactly as taught, they were probably failing to respond to the team needs, and also the business.
Yup, the problem is that many people just implement agile without understand why you're supposed to do the rituals. I'm deeply convinced that most things of scrum really benefit the developers. You have to be aware about this and think about it and not just implement it as it was thought.
To pick an example: the OP described how the managers enforce the completion of a story at the end of a sprint. This obviously doesn't make any sense. The philosophy of scrum is that you as developer have the (1-week long) sprints to iteratively learn how long you need for a story. So after several months the team will finish most stories as planned because they have a better understands of their own speed and more importantly how to judge stories.
The most important thing about software development is to understand the "requirements". Or in plain text: what the fuck shall I do? The customer doesn't know this either but it is your job (and that of the product owner and actual customer) to clarify this on a business level. On the concrete implementation level you have the scrum planning where you talk about a story and you try to understand it. You try to clarify what it means and how to implement it. Assigning story points is not a "work item" itself. Assigning story points is only the result of the process of clarifying what the story means. You can only judge how much time you need to implement the story when you really understand it. After a scrum planning you should exactly know how you should begin the implementation of a story. In a scrum planning session the team basically implements the story in English words.
In the first few sprints nothing will work correctly, your estimates are completely wrong and you are not sure how to handle storys. But this will improve sprint after sprint. Shorter sprints = faster learning. And this learning is the whole point, if your manager decides how long your story is and giving you deadlines you won't learn anything. Instead of learning how to evaluate and interpret a similar story in the feature you have to work on the weekend.
> Even if engineers believe do not believe its going too fast (superficial review, lack of manual testing)
If the engineers are speaking up and are actively ignored, then the business's feedback loop is broken. The things in the agile manifesto need buy in beyond the people writing code.
> scrum master end up make it happen as his job is to make sure "sprint commitments" are met
The whole idea of using the word "agile" is to allow commitments to be re-evaluated. Respond to change, don't rigidly follow a plan.
If someone is mandating a rigidly adhered to practice of scrum, and doesn't allow teams to adapt that process to the individuals and interactions at hand, it's not agile.
I don't think Scrum should be judged on how well it can perform but how well it actually performs. If 9 organizations out of 10 can't succeed in applying it, that's certainly a bad evaluation of Scrum even if technically Scrum was never properly applied in those organizations.
It's easy to spot when agile webdev types don't do this... you end up with a responsive mobile site that is missing half the features that you want.
It's easy for sharpie commandos to sort interactions by priority and build a user story that hits most of the priority interactions. Splitting isn't natural especially when the designers aren't very experienced.
IMO somebody representing the business who isn't a designer needs to be in the approval process to throw back work when all of the necessary interactions aren't captured.
> IMO somebody representing the business who isn't a designer needs to be in the approval process to throw back work when all of the necessary interactions aren't captured.
Critical in my experience. I usually call this the "smart ass SME" (subject matter expert).
Or, "Go out on the floor and find me someone who does the work every day, has been doing so for a decent amount of time, and who still complains when things are broken and has no problem speaking up."
I can tease out issues from a generic complaint. I can't from silence.
The other thing you'll find they're useful for is throwing out ass-backward use cases that seem logical to management (and me) but are stupidly inappropriate for some obvious reason to an actual person doing the workm
For us this is the product owner. They are the ones that do the user studies to backup feature requests with data. It's important to test assumptions about what users want.
This way we don't end up building stuff because someone random thought they wanted it.
I approve of this, but I come at it from an I-just-want-to-be-an-engineer point of view.
When looking for velocity, the first thing to optimise is the feature list. Too often the idea of doing something useful quick and dirty devolves into writing bad code that looks like it covers a feature set until you scratch the surface and find the whole thing is made of bugs.
But if you reduce the feature set (that's the first kind of dirty) then you can build a system that really does what it says on the tin. And the second kind of dirty (code), deosn't matter so much, because in a smaller system the total technical debt is less.
I generally advocate this approach, but there is a limit. Each new story is a context switch for everyone involved. It's easy for a product manager to lose track of the holistic POV if they are tracking too many stories. The dev has to stop and start or worse yet, split very tightly coupled work among more than one dev.
Jira is just a ticketing system with a lot of fancy (and optional) features built on-top of it. Or are you asking specifically about the Jira Agile feature?
These people tend to create bureaucratic nightmare, an environment which demotivate creative people and promote mediocre people, an environment where you get rewarded to look busy instead of actually get things done.
Please, do not point me at agile manifesto.
To me agile looks like totalitarian sect which constantly preaches flexibility and freedom while swiftly punishing anybody who ever dare to deviate from strict daily rituals and mantras.
Dry definitions in agile manifesto means nothing in real life. What's actually important is a context which created by people who adopted it.
Agile/scrum is biggest cargo cult I've ever seen in my life.