In case you missed them, here's a curated collection of the best and most informative posts from this week's edition of The Agile Zone. As chosen by yours truly. This week: I'm a software developer -- not a lawyer, managers are not homogenous, prioritizing projects with minimum loss of money, how to fail by not knowing what the goal is, and who the heck is "The Business?"
Since the product persons were “business people” and not “software developers” they did not fully understand the logical way in which developers understood the requirements, and vice versa. Like a lot of development plans, this one had its share of troubles -- but this is what I learned from it.
The problem with “manager objects” is that they are usually a vaguely connected set of functionality which either deserves a better name. And sometimes, some of those functions would be better off as a stand alone function not bundled into a class because it happens to share part of a name.
Most managers will tend to prioritize their projects based on non-quantifiable attributes such as the strategic importance of a project or the risk of loosing a contract. But if you have a multitude of those projects, all equally important, how do you make a decision on what project should be done first?
If you don’t know what the goal line is for a specific release or sprint, you have no means to understand how you are traveling and whether you are on the right track. I have seen many teams post great velocities in their first couple of sprints, but when it comes to the actual release goal, it gets a little more difficult.
As a VP of Technology your day is going along fine and then boom… priorities shift from product and marketing moves the date up. The teams below you are stuck at the perceived whim of a madman. Who is the madman they perceive? He is actually a variety of demands from all departments -- here's how to deal.