4 ms·
I can see the merits, but it also seems a rather joyless environment -- just do what Pivotal tells you. Was there any feeling of autonomy?
by dasmoth 10y ago
I can see the merits, but it also seems a rather joyless environment -- just do what Pivotal tells you. Was there any feeling of autonomy?
- andor 10y ago(I work at Pivotal) Tracker is only a communication medium. In such an environment you don't "do what Pivotal tells you", you do what you decided to do as a team, because as a team you prioritized stories in the backlog. That means, as a team, you have pretty high autonomy. You also have autonomy when working on stories, because they should only tell you what and why to do something, not how. If have to compromise a lot to take team decisions, your team is probably not aligned very much. Do you share the same goals with everybody else? For most people around me, joy comes from being productive, helping your team to make good products at a fast pace, and from interacting with people the whole day.
- TeMPOraL 10y agoSounds like the worry I used to have for a long time about todo lists and calendars in personal life. I eventually realized that those tools are not meant to be your boss - they're only means of storing what you figured out when you had more time to focus on something. You can disobey them at any time, freely, but if you find yourself constantly disagreeing with your own todo list, it suggests you need to work on what you put in there in the first place. They're meant to optimize, not take away your autonomy. (Shared todo lists, as it's what all those project planning / issue tracking tools essentially boil down to, is a little different thing because other people put stuff in it too, but the principle is still the same - it's not there to limit your autonomy, it's there to improve your focus and free up your memory.)
- dasmoth 10y agoThis is a good point. I think, for me, the possibility of a little bit of cherry picking is quite important for keeping it clear that the list isn't boss, and that's what I found so rigid about the original comment.
- wpietri 10y agoThe Lean folks draw a distinction between controlling bureaucracy and supportive bureaucracy. I had never even known the second kind existed, but then I realized that whenever I made a personal to-do list, I was creating supportive bureaucracy. We had the same "pick the next thing" rule: http://williampietri.com/writing/2015/the-big-board/#toc3 http://williampietri.com/writing/2015/the-big-board/#toc3 We still had a sense of control, because the team jointly decided the order of the cards every week. If we thought there was a business or a technical reason why A should come before B, the product manager was great at hearing our notions. We all believed that the ordering was our best guess as to business value order. But what we also got out of the rule was a sense of fairness. If I could go up and skip to the second card because I didn't like the first one, I'd be making a colleague take something I didn't want to do. Always taking the first card meant that unpleasant tasks were randomly distributed. I should add that we were in a pairing environment and would switch pairing partners once or twice a day, so everybody ended up working on a variety of things anyhow. If you really wanted to work on something, you could just say so and get the swap to go in your favor. So basically, we weren't just doing what Pivotal told us. We were doing what we thought was the most important work first, and we were handing it out in a way that was fair to everybody.
- lockedoutwhoops 10y agoInteresting. Who puts the tasks in? How do engineering and product work together to prioritize short term business value vs long term business value?
- wpietri 10y agoI'm sure people do it many ways, but here's my approach: Anybody can put a story in. (A story is some shippable unit of work that creates business value or otherwise improves things for some user.) Once a week, the team (by which I mean a cross-functional group of people committed to delivering value together, in the Balanced Team style [1]) sits down and talks about what should happen next. This happens in the context of some agreed-upon set of long-term goals. In a startup, that's usually clear. In larger companies, a process like OKR [2] is a good way to make sure that a team has a clear purpose that meshes with the rest of the org. The only hard rule is that the product manager has the final say on backlog order. But that's a power that should be rarely used; disagreement is usually a sign that people understand things differently, and that's worth sorting out. Often disagreements are worked out by proposing experiments. Questions of short- and long-term get worked out dynamically; in sane environments people are pretty good at striking that balance. [1] http://www.balancedteam.org/ http://www.balancedteam.org/ [2] e.g.:http://eleganthack.com/radical-focus-is-here/ http://eleganthack.com/radical-focus-is-here/