Unless you happen to be a one man shop or small enough that everybody actually does something on the project/product, you have folks that I’m terming IT here. IT people are the managers for test and development, your manager, and Project Managers or other people who are only involved from a budget or “top level”. Since they are not directly related to the team or product the strategies with them are different. They are no less important, and getting them on board can make your days so much better.
- You are driving the project – The customers, team, and product decisions are driven through you. If you have to ask permission or check-in, you don’t own anything. An opinion from them is fine, a suggestion is allowed, a question is great. An order or threat is not.
- Demos and calls – If your product is being pushed actively you’re doing lots of demos for lots of different folks. Sometimes it’s so they understand what their department is paying for so it can continue, sometimes it’s so they can see progress. I love doing demos of the work that has been done. Doing a quick 10-15 min demo once a week is really cool. If the IT people are willing to attend the regular sprint demos, you’ve really got something useful going.
- Agile Mindset – If your boss or the other people working around you “get it”, life is better. If your boss, or the dev manager want to work a different way then it will be hard if not impossible to be successful. I truly believe that “Culture > Process” and the higher up that goes, the more successful you will be.
- There to help – If the other pieces are easy to work with and act in a supporting fashion then life is easier. Expense reports, time sheets, machine procurement, HR staffing are all pieces that contribute to how quickly and effectively a team can be. The more an organization is built around helping your teams succeed, the more focus is on you and delivery.
- Good communication – The ability of the non-team members to understand and know what’s going on is mostly up to you. The PO has to communicate schedules, roadmaps, issues, and changes to a wider audience so the whole ship can be steered together. If IT folks are asking the same questions or don’t understand something then either you’re not communicating or they aren’t listening.
- Decisions are easy and quick – When the program changes or information is needed, it’s readily available or a short time passes before a decision is made. Open questions that need answers and linger on past the point when you need them is a killer. Good PO’s can help mitigate this by truly understanding the goals and driving factors of the product and making a choice easy for them. I typically will take my best guess at a solution if needed, or have a backup story or idea to implement in case a decision isn’t happening. I’ve not been “totally wrong” before, but I have had to come back and turn slightly once an actual decision is made.
- Leaders – If you are surrounded or involved with actual leaders and not just managers, then fewer issues will be raised. When the entire team and organization are actively following a vision set by a great leader, all activities are lined up and headed in the same directon. The leaders give the people the autonomy and information needed to use their skills to solve that problem. Working for a “why” is important and much better than being directed by somebody higher up.
- Problems – When problems arise or are discovered, everyone should react to solve them or eliminate the need for them. Systemic problems or corporate issues are the only real barriers to the team completing something.
- Micro Manage – When PM’s and other people want to get into the details of how something is being done to make it more “efficient” when they are not producing anything of value, you obviously have issues. Either the trust is not there, they don’t understand how an agile program works, or their default state is to muck around with things. None of this is good and will disrupt the team, the schedule, and cause more time to be spent in meaningless meetings to justify the decisions and actions that were made.
- Fungible assets – When resource managers feel that they can move people between teams on a whim, you will always be forming. Having teams on products grow organically and expand knowledge into new teams with existing members is a good thing and can be timed. If people are removed from your team in the middle of a sprint, because a project is in trouble is BS. It’s happened more than once and I know why it’s done, but I don’t believe that it solves their problem as they believe it will, and damages the team they are removed from.
- Late / Budget / Plan – When people make plans well in advance, without understanding, or involving the people who are doing the work, that plan will fail. It will likely be late, it will likely be over budget, the features will not be there as they thought, and there will be scrambles to understand what will be done to make corrections. Whenever such a fantasy is created at high levels, it should be treated as such. The important thing those things give you is a goal or idea of what needs to be done. It’s worth trying to fit your roadmaps/release plans into that as best you can, but you will never hit it.
- Who needs a team? – If it’s hard to hire the people who you need, or if it takes longer to get them in the door, you can’t compete. If you’re teams boards are not within immediate reach ( i.e. in a separate room they can’t see ) your office functions aren’t helping. If they work in the same office/city and aren’t allowed to sit together, or if you can’t have testers, designers, or other needed people on a team because of reason X, then “Team” is not really something your organization is interested in.
- We bought this, use it – Somebody at some point bought a tool and has mandated that your team use it. Does not matter if it isn’t fit for an agile team/deployment/purpose, you must use it. Free or open source tools that fit better? Can’t use them. Bonus points if IT regularly scans and removed offending programs.
- Divide and Conquer – If the reaction to bad news is to brow beat you or other members of your 1st team until somebody says yes. If the reaction to the changing situation, new discoveries, or data that reverts an earlier theory is to find the needle in the haystack that confirms their bias, then you’re going to be constantly chasing your tail. This also shows up when you tell them “No”, and they go over your head or around you to get the answer they were after. It’s their normal way of working, you are not giving them the answer they want, and you’re not playing ball.
- Who’s running for office? – If office or corporate politics are in play, if one group is being pitted against another group, being sacrificed for a goal, or the hidden goals are running strong you are in trouble. The politics will throw away good products, not promote or select the right people, and hinder the product goal to meet their personal goals. You and the product are simply a resource or means to an end and not something to invest.
In the end, the IT staff can really hinder or dramatically accelerate a PO’s ability to deliver. The teams that are assembled, the organizational constraints, and the noise around the product is their responsibility. If it’s hard to do simple things, or if you are constantly arguing over what’s important you’re going to lose, just a matter of how long it takes. The more agile the organization is, and the more support you get, the better your process and focus will be.