Split user stories ruthlessly and get value earlier
mikeborozdin.com
mikeborozdin.com
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 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.
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.
Ironically, you could argue this is agile with one day sprints - I wouldn't disagree much.
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.
IME tech debt gets worse under "scrum done right" and velocity is a bullshit measure. Those two things alone are enough to reject it.
It's a shame because scrum gets, like, 70% right.
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).
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 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.
Companies like this exist.
This is what agile was a reaction to.
You know, I am sure many of those Agile consultants that big companies hire don't even know what the Agile Manifesto is.
Agile is not agile.
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 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.
[0] https://en.wikipedia.org/wiki/Dave_Thomas_(programmer)
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?
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.
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.
"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.
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.
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.
True agile works fine but it seems most agile frameworks lead to non agile work.
"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.
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.
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.
But it matched the spec, exactly.
- 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.
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.
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.
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.
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 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?
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.
"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.
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.
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.
I have been slowly suggesting we get rid of pointing all together, but I don't think that will be easily won :p
Specs should and will change.
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.
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 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.
It was literally created to try to fit agile methods into company that still thinks in waterfall.
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.
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.
See my another post for a real discussion of an issue is see with OP's post: https://news.ycombinator.com/item?id=15004260
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.
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.
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
This way we don't end up building stuff because someone random thought they wanted it.
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.
- https://paulhammant.com/2012/04/24/call-to-arms-average-stor...
Background: each story has deliverable value to the stakeholder/
Ask: Download file from vendor, process file with error and success counts, save results in X datastore, email report with stats to specified DL...