7 ms·

I appreciate how clearly it is written down. It is how I would like to work and have tried at numerous jobs. I do find that reality is hard, though. There's al

• thombat 6y ago
  Our company became determined to control such panic-driven prioritisation, and had four simple levels of importance, P4 up to P1, a predictable conveyor belt delivering work. Equally predictable was the later addition of P0. Followed inevitably by P-1. Sadly the company was bought out before we learnt whether the underlying datatype was a signed short or a long...
  • ehnto 6y ago
    I've seen good success with having an entirely different pipeline for rushed/rapid/panic tickets. The rapid pipeline reduces some of the ticket and procedural bureaucracy of the normal pipeline, and only lasts a sprint. That obviously comes with risk, so putting something in the rapid pipeline needs to be weighed properly. The somewhat untold benefit of this system, is it makes the product manager or client decide between "I want to control this ticket" and "This needs to be done as fast as possible". That seems to naturally filter out tickets that are only superfluously high priority.
    • dataduck 6y ago
      This seems interesting but I'm having trouble visualising it. Would you care to elaborate?
      • ehnto 6y ago
        Sure! A standard ticket pipeline might look like this: Backlog > Review/Estimate > In Progress > Internal Review > Testing > Client Review > Feedback > Testing > Release But the rapid pipeline will be more like: Create Ticket > In Progress > Testing > Release This leaves the ball almost entirely in the developers court, and removes any step that requires waiting for feedback from the client or even the Project Manager. So you can see the risk factors pretty quickly, with no review steps what if the developer gets it wrong? So that leaves the Project Manager some important questions: Is this ticket concise enough to be rapid? No room for back and forth discussions or muddy details. Is this ticket small enough to be rapid? Can't be a big new feature that's just being framed as urgent but could realistically wait. Can I trust the developer to get this right with no review? If you can't, then it's probably best it goes through the standard pipeline with the review steps anyway. In big enough teams it can help manage workload, you can leave a specific developer intentionally under-utilized so that they have space for rapid tickets. During their under-utilized time they can be open for mentorship/learning/pair-programming until a rapid ticket pops up.
        • sethammons 6y ago
          That is how all our tickets work. We have a lot of autonomy in that regard, put the product owner still sets the priorities
  • VBprogrammer 6y ago
    That is so familiar that I seriously wondered if we had crossed paths at a previous job. The only difference being our priority was the other way around P4 being the highest. Basically all tickets would naturally migrate to P4. Eventually when someone started working on 'the wrong thing' another level was added. In my current job we use Jira and the backlog has things at the bottom which have been just added, things at the top which we thought were priorities at some point and a whole bunch of crap in the middle which is unordered. I keep thinking about some kind of system where people would rate the priority of one ticket against each other rather than against an arbitrary scale.
    • jschwartzi 6y ago
      That’s the whole point of that backlog. The order should reflect the priority of everything relative to everything else. You drag stuff up above other stuff that is lower priority and part of everyone’s job is to groom that list so it reflects reality.
      • VBprogrammer 6y ago
        While that may be true in theory in practice it is difficult. A big improvement would be if new things needed to be inserted into the backlog at an appropriate place but I don't know if it's possible to do that in Jira.
        • mumblemumble 6y ago
          This, I think, is exactly why everyone I know who is happy with their backlog management does it in an Excel spreadsheet or Google Sheets. I'm fine with ticketing systems for handling immediate work in progress. Which, incidentally, is what they're meant to be used for. Every time I've ever seen people try to juggle business priorities and long-term goals in a ticketing system, though, the end result has always struck me as being something of a failed experiment to develop a product that works well as both an ice cream topping and an engine lubricant.
    • travisjungroth 6y ago
  • mytailorisrich 6y ago
    This does not mean that having priority is not useful, this just means that they did it badly. Everything is prioritisation. I'd say that prioritisation is one for the key skill of people leading organisations. People who can't do it will fail whatever tools they use.
  • vincentmarle 6y ago
    This works well in theory, until managers urge you to treat every task as "P-0" and you suddenly need to prioritize within the P-0's (we would jokingly use negative numbers instead).
• Almad 6y ago
  In my experience, the relative queue _is_ helping with that since you can be explicit. If SEMIEB is really more important than SIEB, it's fair to switch—but it should be done as a relative comparison / override. I mostly saw people pushing SEMIEB without being aware what they are pushing down. Although I would agree that if you have to reshift on hourly basis, this sounds more like oncall than normal dev work :) Agreed on "on the top" not always being viable / feeling like it, but it helps when you go top-to-bottom consciously as opposed to randomly.
• deleted 6y ago
  [deleted]
• ehnto 6y ago
  Priorities changing is one of the more frustrating parts of doing client work. Business priorities can change for so many different reasons, and you just have to learn to let go. I've seen entire product lines disappear the week a singular person leaves the company. Product in boxes, ready to ship, no longer needed. If you are in an environment like this though, try to do very atomic commits as you go. Often you can salvage some work for the betterment of the platform even if the whole feature is not needed. Maybe you did some refactoring, if that's in a neatly organised commit you can just cherry pick it right out of there.
• Etheryte 6y ago
  I think an important consideration is important for whom. If the only reason something is important is because of an arbitrary management deadline, the right response is to stand your ground and calmly finish working on what you already picked up. While I understand it's easier said than done, if you don't stand your ground, it won't get better. The polar opposite of this is when I personally broke something and it's stopping others from doing their work. In that case, the right response is to drop what I was or wanted to be working on and fix the issue. An extra case of all of the above is planning work around big releases and the like. Regardless of how solid your CI pipeline is, if there's a bigger change set released, it's good to have someone who's designated on call. They're free to work on their stuff if they please, but their main priority for that whole day is the delivery. If anything is fishy, they're the guy who picks it up first. None of the above happens without good communication. To get to good procedures you need to take the time, discuss with your team, and agree on what your plan of operation is. Make sure it's clearly communicated both inwards and outwards. If anyone internal or external comes to you with a fire, you can point them to your plan. It may be urgent to them, but that doesn't mean it overrides your team's agreements. With all of the above in place, the scenario you described changes considerably: instead of asking whether you can finish your task, you will instead inform the other side that you're going to finish your task, and if it fits your plan, then deal with their problem. At the end of the day, it's a matter of mutual respect — it doesn't matter what the org hierarchy is, they're asking you for help, they can't demand it.
  • TheRealPomax 6y ago
    As an employee of the person telling you to drop your current work and go work on something else, it literally doesn't matter "for whom", you do it because you want to stay employed rather than doing "what's right" and getting fired over it. Standing your ground if you don't have solid seniority first is about as ridiculous advice as a parent telling their 7yo to "just tell them to stop" when they're getting bullied. You don't have ground to stand on, and even if your input is right, and well reasoned, it can't come _from you_ because your voice has no weight. By all means, try to change the system, but telling others they should too is advice from an extremely privileged position.
• crdrost 6y ago
  There's a great manufacturing-management book that regrettably speaks to a manufacturing context and not a project context and therefore applying it literally to our software projects would be a fallacy, called “The Goal”—and then the rederivation of the same principles for project management is in a follow-up book called “Critical Chain.” They are both weird in that they are textbooks written as novels and therefore you do have to roll your eyes a little bit, of course when the beleaguered manager follows the smart scientist’s advice his company succeeds and his marriage gets better, sigh. And why is it a he, both times? But if you pay the cost of these eye rolls you get some joyous moments. For instance, your “panic mode” is discussed in The Goal (as “factories that seem to have three priority levels: Hot, Red Hot, and Do It NOW!!!”) and the emergence of those panic modes is actually diagnosed as a failure of those first principles. If you had managed differently, you would have been aware of your spare capacity, and this panic mode instead becomes a business problem of some sort—either you are not getting enough biz value out of your “SuperImportantEmergencyBugfix” project to justify continued investment of developer time or you are not getting enough biz value out of the EvenMoreImportant project or else you are getting enough business value out of both that it is time to expand your dev team so that your bottom line can get better sooner. But rather the panic is usually because the two projects are not profitable either way, and the company was willing to take a loss to build them up to profitability, but now revenues have gotten unexpectedly tighter and people are trying to fallaciously optimize on cost rather than marginal profit.
  • twic 6y ago
    The Phoenix Project is a software instance of one of these textbooks-as-novels: https://itrevolution.com/book/the-phoenix-project/ https://itrevolution.com/book/the-phoenix-project/ https://itrevolution.com/wp-content/uploads/files/PhoenixProjectExcerpt.pdf https://itrevolution.com/wp-content/uploads/files/PhoenixPro... And Commitment is about software projects, and is a graphic novel (with a female protagonist!): https://hennyportman.wordpress.com/2016/05/29/review-commitment-novel-about-managing-project-risk/ https://hennyportman.wordpress.com/2016/05/29/review-commitm... I'm also reminded a bit of Simon Wardley's dialogues with X; these are just a roundabout way of him expressing his thoughts, but because they're structured as a debate, i think he gives himself a bit of unearned authority when he runs rings around his imaginary opponent: https://twitter.com/swardley/status/1082647878349324288 https://twitter.com/swardley/status/1082647878349324288
• nicbou 6y ago
  In my experience, it worked better with Kanban. The "top ticket first" approach forced us to improve knowledge sharing in the team. In practice, you can pick the second topmost ticket if it doesn't affect the schedule. You're a grown up. The tickets you work on should not be based on your feelings, but on actual priority. In practice, if you feel like it won't affect the schedule, go for it. You're a grown up. In my experience, panic shifting is more manageable with Kanban. Tickets aren't given arbitrary deadlines, so shifting them around doesn't change the order of work, but not the intensity of work. Bringing one ticket up pushes every other ticket down. Nothing gets squeezed into the sprint. As for interruptions, it's a matter of urgency. Usually, Kanban dictates what you do next, not right now. There's also a limit on how many tickets you can have in progress. In practice, it's up to you to decide if a task is urgent enough to interrupt your work. You're a grown up.
  • opportune 6y ago
    For well-defined tasks, I love Kanban. Many people don't. But I think there is a lot of value in having a limited number of tickets "checked out" and having a quick, regular discussion on how the current state should be updated. It is also, in my opinion, the simplest way to "be agile". It's also not compatible with complicated work. If you're still in the discovery phase, sometimes it takes a significant amount of work to get to a point where you really feel confident on what the end goal looks like, and how to estimate how you'll get there. In that case the work is shifting under you too much for Kanban to be of much help.
• zelphirkalt 6y ago
  Time for a quicky is always good to have. When I don't however, I usually take that "annoying" task and see, whether I can divide into sub tasks. Divide and conquer often helps. If that does not work, I make a list of steps, which I need to take to accomplish whatever the task is about.
• wpietri 6y ago
  The panic shifting thing is real, and for me way too many companies operate in permanent panic. I'm fine with responding to actual crises. But so much "urgent" work is really just managerial failure. Fake deadlines used to "motivate" people. Broken processes that people work around. Executives urgently need to look like they're doing something. Easily solvable problems festering until they become crises. Managers rushing to score points, or to cover up for earlier neglect. If everything is urgent, nothing is urgent. Even in an early-state startup, where urgency abounds, it's possible to work with a measured pace and clear focus. I've done it! https://williampietri.com/writing/2015/the-big-board/ https://williampietri.com/writing/2015/the-big-board/ The fact that larger, more stable companies fail to create order is not because it's impossible. It's because the people with power either don't care or have interests that actually work against getting things done quickly and reliably.
  • mumblemumble 6y ago
    > people with power either don't care or have interests that actually work against getting things done quickly and reliably. This is what I have seen, time and time again. Decision makers don't work for their employer, they work for their compensation package. It's amazing what one can rationalize when one thinks it might positively impact some number that's mechanically tied to one's bonus. I've also seen it arise as a simple "too many cooks in the kitchen" situation. Ironically, the one thing from Scrum that I like without reservation is also the first one to get thrown out the window: the idea that exactly one person gets to decide the development team's priorities. Because if you allow n people to collaboratively allocate a scarce resource, they will allocate it to n * 100%, every single time.
    • wpietri 6y ago
      Agreed. Although it's possible to get people to collaboratively agree on priorities. I've had a lot of success with putting stakeholders together at at table, making them write down what they want on cards, and then saying, "Ok, put them in strict linear order of delivery." It helps to give them a bunch of cards with "RELEASE" written boldly on them. I once did this with 25 people representing a dozen different nonprofits, and I've done it many times at both startups and large companies, so I know it can work. Every time, people try to put things side by side. But if I gently say, "strict linear order" enough times, everybody gets it. And then they start discussing, negotiating, planning. Another approach, one that works if your teams are established enough that you can give good engineering estimates, was what Rob Fan at Sharethrough used for quarterly planning: https://www.slideshare.net/rfan622/launch-scale-presentation https://www.slideshare.net/rfan622/launch-scale-presentation Basically, they gave out poker chips that represented the available engineering capacity for the quarter. And then had everybody discuss and persuade until they arrived at a quarterly plan. As you say, the trick is to have some way to make sure people don't overallocate, which they dearly love to do. With that in place, stakeholders stop fighting with engineering and instead wrestle with one another, letting engineers quietly get on with popping things off the backlog and shipping them.
• wpietri 6y ago
  > There's always that moment when you don't feel like picking "the one at the top". A few solutions for this that have worked for me: * Small units of work * Having a tech-debt backlog broken into short lumps of cleanup, so you can "take a break" with something different * Pair programming with frequent pair rotation. The next ticket is always taken by the next open pair, but you can work one something different every few hours if you need. * trade tasks with a colleague * sighing, saying, "well, this is my job," and picking the top thing anyhow
• medius 6y ago
  To tackle this, I highly recommend the percentile technique from MIT paper, "A Structured Approach to Strategic Decisions". [1] If you are judging any dimension, say priority, then assigning percentile rating to a task (i.e where does this given task stand relative to all the others) can be quite helpful to overcome the "SuperEvenMoreImportantEmergencyBugfix" cases. This is what the article is also suggesting. And if you end up assigning 90% percentile to more than 50% of the tasks, you know your judgement is wrong, and it can be corrected accordingly. And it can also be standardized much better across the organization. Everyone can now judge their own judgements. Rating on multiple dimensions with low correlations important for your company, say signup rate, retention, security, etc. and adding them up is a good way to not miss something important. It's not important to assign weights. Equal weights is fine [2] I'm finding this technique quite useful in deciding what to work on next with fewer doubts about their priority. I failed to make Trello work for this and use a spreadsheet. [1] A Structured Approach to Strategic Decisions - https://omegaleadership.com/media/Structured_Approach_to_Strategic_Decisions.pdf https://omegaleadership.com/media/Structured_Approach_to_Str... [2] The robust beauty of improper linear models in decision making. - https://pdfs.semanticscholar.org/8793/408a67fd4c32bd7b5483d36eb2e409ca1220.pdf https://pdfs.semanticscholar.org/8793/408a67fd4c32bd7b5483d3...
• mikekchar 6y ago
  I had to read up on the "means of production" because I had no idea previously that it often refers to the capital (both social and financial) used to produce goods. It's interesting to me that Engels says (in essence) that a worker lacks the means of production and is therefore forced to sell their labour. But, it occurs to me that this has always been a seller's market. I have, in my naive youth, thought, "What are they going to do, fire me?" Because they might, but it's not like I couldn't another job -- probably even higher paying! What exactly is the "means of production"? Is it really the capital that pays the salary of the programmer, or... is it the will of the programmer to actually write the code? By and large, the programmer is very difficult to replace. If you take note of the incredible number of programmers that are an absolute PITA (I mean, I'm sorry but we are and ornery bunch!), how on earth do they get jobs if the capitalists are not completely desperate. In fact, the big companies even lobby the government to allow them to ship programmers in in large quantities! So can you not finish and deploy it? I wonder... What could possibly happen? Small print: Not responsible for loss of livelihood, and social shame that results thereby.