One of the more difficult things to understand for companies who are converting from non-agile methods to agile is figuring out how to convert their requirements and support pipelines into something that works for agile teams. If you're familiar with Mike Cohn's book "User Stories Applied" then some of this terminology will be familiar to you. If you're familiar with Scrum and user stories then hopefully this will communicate a more clear 'example' or 'starting point' for you to begin scaling agile practices across larger sets of development teams.

    The classic breakdown of work in a normal organization begins at the strategic office or PMO. They will often begin strategic planning very far in advance of the development teams creating a portfolio of programs that will turn into projects of specific tactical purpose.

    There are generally two camps from here out… those who would say that the PMO and program management acts the same as it did before and Scrum and/or Agile methods fit below that somewhere. The other camp, however, is where I sit. This is the camp that says "There are no secret backlogs, there are no dual backlogs, there is only 1 single enterprise backlog that everyone works from."

    The reason I am in this came is because an organization that focuses on it's highest priority goals succeeds rapidly in the marketplace by delivering it's highest value items first and rapidly responding to the feedback that they provide.

That's my elevator speech for it anyhow.

So what does that look like in practice?

    Well, at the top of this food chain you have products and themes. I generally just call this layer "Themes" but please keep in mind that Themes can span multiple products and a product can span multiple themes. That is to say if Microsoft office was a product and each "word, outlook, excel, and access" are themes and at the same time truetype fonts could be a theme across office, windows 7, and ms project. This complex relationship is important to keep open and flexible because it may require coordinating multiple products to deliver a particular theme (of functionality) and it may be required to coordinate multiple themes to create a single product.

    Under themes you have Epics. Epics are the classic "Minimum Valuable Feature" that a business or stakeholder can recognize. You'll usually recognize an epic when developers say "We can't deliver all of that in one sprint, it's too big, and the business person says "well it's just not deliverable unless I get all of it". A good example of an epic would probably be an initial set of Charting in Excel. You couldn't ship charting with just 1 type of bar chart for example. Careful here because epics can undeniably turn into themes very quickly if not constrained to a certain subset of minimal functionality to be releasable. As an example, if you just said "Charting" then that would be a theme. (In my opinion… but you be the judget because it's all about your context)

    Under Epics we have user stories. These are 'features' that are recognizable to some sort of actor in the system. (Or user if you prefer). I like to say actor because maybe you're building a web service to be consumed by mashups across the globe and your company will never be developing the client application that any end users will utilize. A user story is generally a finite piece of functionality that can be indepdent of other stories, negotiable in content (finite in scope), valuable, estimable, small (enough to fit many of them in an iteration if possible), and testable (or verifiable by the customer so that they know what they got). (INVEST is a simple way to remember this)

    Once you're at the team level you break this down to tasks (mostly technical tasks). Tasks are pretty straightforward… "make getter stored proc", "Make setter stored proc", "create DDL Script", "install sql server", "configure windows server and IIS7", "create build script", "Write end user documentation on widget x"

 

So the tricky part here is… how do customers and stakeholders interface with the team to make sure they get what they want?

 

Short answer… you need to decide that.

    Long answer. Identify your product owner(s): Maybe you have a particularly great customer who is willing to provide you a product owner to work directly with the team and create these artifacts. Perhaps you have that but they are unwilling to create user storiesl…. Those are just too indepth for them to worry about. So you might get a business analyst/user proxy who can create the user story level breakdown. That isn’t much different than writing requirements in many ways (just more real time with development). Perhaps your customers are internal to you and there are many of them. Find someone they trust who can represent them and have them act as your product owner. Perhaps there is a ‘director of product management’ who can be your top “Theme level” product owner. Then product managers would write epics and Business analysts would write user stories.

    The tricky part here to get right is support. How do you handle listening to support and involving their feedback. My recommendation is to make that the area product owner’s primary job. Afterall, keeping your current customers happy is the most important part of a good software practice. They generate revenue, they keep buying new upgrades, they promote your software to other users, they help other users support the product, and they create new ideas and innovation for you.

    This gives them direct contact with the person closest to the team so that if a high priority customer issue comes up you can properly abort the sprint and re-prioritize if needed. I've heard of some organizations just saving 1 team member's capacity solely for support issues every sprint rotate who that is. They can be support-bitch (or support-monkey to be more PC) and rotate it around each iteration. Maybe have a stuffed dog or monkey that signifies who is on support and put it on their desk when it's their turn. That person would work with the APO and Support to create a user story around the issue, create acceptance criteria, get sizing from the team once a solution is ready, then get it into a sprint as a user story once that prep work has been completed.

 

    Support bitch would probably not have time to also develop, test, and push out a hotfix though (but maybe if they're a rockstar, right?)

 

    If you have other ideas of how to scale agile out and up including examples from your organization please drop me a line or comment here. I appreciate your time and feedback.