Yesterday, John Scumniotales, Paul Dupuy and I participated in a Webcast for The Agile Journal. We could not answer all the various questions on line. I thought it might be interesting to see some of them and our answers.
You can see the Webcast yourself by visiting: http://w.on24.com/r.htm?e=155782&s=1&k=A98F0FB3D0AD7D354E60F0C65DB31BB7
Here are the questions and answers:
Question: What if the business process isn't defined how does Agile handle business reengineering?
Answer: When the business process is not defined, an agile approach provides an incremental model to explore and define it! Using Scrum for instance, you would work with your Product Owner (customer) to elaborate user stories that define some aspect of the business process. Don't boil the ocean. Pick a small "chunk" that can be easily described and understood. If the end goal is to have a system that is implemented using software, then you should strive to implement this process as well. To the extent possible, this should be accomplished in the same sprint. Avoid using the sprints to only document the process. Your goal should be to produce working software as early as often as possible.
Q: Thanks for this presentation. One issue we struggle with is using scrum teams that do all of the things you are describing but we have trouble bidding competitively on small professional services projects. There is some overhead with scrum when applied to smallish projects (lasting 2 - 6 weeks) that we struggle with. If you have any suggestions or examples for how to insulate the customer from our internal costs of using scrum on small projects I would love to hear it. We've been using scrum for about 4 years and it works great for our product team. Any thoughts you have would be appreciated.
A: When using Scrum on professional services engagements, we highly recommend giving your customers visibility (and getting their buy in!) to the process you use to deliver the requested features. If they've agreed to the approach, then this should minimize the impedance mismatch and associated overhead costs for spinning up the project. Also, try and keep your teams together. Remember, with Scrum, we focus on building and optimizing teams. If your building up and tearing down teams for each project, this will certainly introduce overhead and also decrease the predictability of teams velocity as it can take up to three sprints for a team's velocity to normalize.
Q: Which is more important between Individuals/Interaction and Processes/Tools? What I should do if my team members do not have cross-functional skills?
A: In agile we always favor direct communication. Whenever and where ever possible get people in a room together hashing through the problems and issues. The reality of "agile in the enterprise" is that teams are distributed by time and distance. This is where tools are essential in enabling team collaboration. When teams are first formed, its common that there is some specialization of skills. This moderates over time. Pairing, an extreme programming best practice, is an excellent tool to use to help cross train team members.
Q: How can you help a large, compliance-oriented, traditional development organization move to a more agile approach without jumping all the way into Scrum?
A: If you don't have expert help on staff, we recommend getting help with the organizational change management issues that you will deal with in adopting agile. That is why Serena partnered with Valtech, a leading provider of Agile transformational services, with our Serena On Demand product.
Also set it up for early success. Identify a few of your best teams that are starting up new projects. Plant an experienced agile coach on the team, get them norming and storming. You'll be able to use the experience from this team to seed (and motivate) others.
A tool like Serena Agile On Demand helps as well. It provides a prescriptive Scrum framework for the teams to follow.
Q: What tools to you offer to facilitate yearly budgeting and goal setting in a way that could feed into incremental deliveries while supporting financial accountability within key cost centers?
A: The "team" is the key unit for agile projects. We want to fund teams and keep them stable for as long as possible. This allows us to optimize predictability. So you want to fund as many teams as possible, keep them together for as long as possible, and bring the work (projects) to them. At the portfolio level, its also helpful to consider relative investment levels for key initiative requested from the business units. This will dictate the mix of projects that you direct to the teams.
Q: Can we implement these tools based on traditional methods and then seamlessly transition to agile?
A: No. Adopting agile has significant impacts on the people and processes within an organization.
Q: How does this approach handle complex systems integrations with third parties and systems involving end-to-end financial settlement processes such as GL posting.
A: This is hard regardless of whether your following a traditional or agile approach! When we scale agile, we typically have many teams collaborating on a single appliation/product/service. The integration of the work developed by these teams of course needs to be closely managed. From a program management perspective, we can use the "Scrum of Scrums" to manage the inter-dependencies between teams and other cross team issues. We can also use the "Super Scrum" as longer range product planning tool to make sure that work is appropriately sequenced so that cross team dependencies will be satisfied.
Q: What if the business perception is that small, incremental releases do not generate adequate business value to warrant business change, training, and communication required? Can this process handle small internal increments that culminate into large releases?
A: Absolutely. Agile (and Scrum) are based on incremental approaches that produce potentially shippable code. Whether or not the increment is shipped is a business decision based on product, market, and customer readiness.
Q: (Loaded question) What if the user stories to be delivered in a sprint get delayed, and the spring demo cannot be completed on time?
A: We love loaded questions! The duration of a sprint never changes. If a story is not completed, its not accepted and not delivered as part of the sprint. The story will either be returned to the product backlog or moved into the next sprint.
Q: How is Serena differentiated from competition (such as Rally)?
A: Serena Agile On Demand was built from the ground up to deal with agile at the enterprise scale. Multiple teams, multiple releases, multiple products. We offer unique capabilities in our ability to deal with enterprise complexity. Serena Agile On Demand comes fully loaded for prescriptive Scrum development. While complete in its ability to deal with Scrum, its hyper-configurable to meet your specific needs as well. Serena Agile On Demand not only delivers the product features as a service, but it also delivers on demand agile coaching through Coach Live in cooperation with Valtech.
Q: How can the tool support allocating planned resource capacity to specific initiatives while allowing freedom from scrum masters to manage specific task assignments for team members. Need to measure that actual utilization is not exceeding targeted resource allocations.
A: A major difference with agile approaches from traditional approaches with respect to resource management is that the team is the unit of planning, not an individual resource. We try and put cross functional teams together and keep them together. The team then establishes a velocity - basically the amount of work they can complete in a sprint. Once the teams velocity is established, the team commits to deliver the amount of work that matches their velocity. Agile teams are always looking for ways to optimize their throughput (increase their velocity). This is contrasted with traditional approaches where management attempts to maximize utlization.
Q: Can the Agile On Demand task board be customized to reflect custom statuses ("swim lanes")?"
A: Yes. The swim lanes in the Card Wall are completely configurable.
Q: Who selects scrum team
A: When making a transition from traditional methodologies to SCRUM we think it is a best practice to "invite" members of the team to join the SCRUM. It's important in the early stages to get enthusiastic members on the team who will actively engage and support adoption. Hard to get people like that if they are 'forced' to be on the team.
Q: Since agile / scrum utilizes an Empirical model for managing costs, How can management make an assessment of the total cost of the program in order to fund development.
A: Plan the work as far as the release horizon using coarse grain items. Have the team size the items using rough estimates. Use historical information from the team's activity or make an educated guess about how much work the team can do in a sprint. Determine the cost of a team for a sprint. Calculate how many sprints you need to finish the work in the release. This gives you the estimated cost to complete the work. You'll need to use scope negotiation skills to prevent "scope creep" and decrease the priority of low priority items. You'll also need to recognize that as the software is developed, changes will occur (which is a good thing -- you'll find that what you wanted at the beginning isn't what you need) and trade-offs will have to be made.
Q: I manage a small unit responsible for several projects. Some were started over a year ago and were designed to follow waterfall. Subsequent projects are now developed via Scrum Agile method. With at least a year left on the waterfal project, how or should we switch mid-stream to agile?
A: It is fairly simple to switch to Scrum to manage your work. If your waterfall planning resulted in a pretty gantt chart with tasks, you can use them as the work items in your product backlog. Read up on Scrum and get a certified scrum master if you can.
Q: Have you ever heard of ACTUAL customers (in addition to product owners and PMs) participating in a sprint review? Any ideas how this could be implemented? Thanks!
A: Absolutely. This is done quite frequently in fact. If possible invite the customer to attend in person. Otherwise their are many virtualized meeting tools that can be used quite effectively.
Q: Could you expand some on non-product stories, how they get prioritized since the product owner may not care, how you track those vs. product user stories in metrics, etc?"
A: Pay me now or pay me later. Sometimes the team has to go slow for a few sprints to go faster in future sprints. There are many examples of non-product stories where technical debt is addressed that may not result in direct value to the customer. This is where the team and the Scrum Master must lobby and compel the product owner to include these stories into a sprint. Without this balance, an insurmountable amount of technical debt will build up.
Q: Is Serena overkill for a team just looking for a requirements/project management?
A: No, not at all. Serena's Agile On Demand has the ability to manage many types of backlogs and is ideal for requirements/project management. Internally here, the Marketing department has several teams actively sprinting and using Agile On Demand to manage projects and requirements. Multiple product backlogs, about nine is our case, contain stories for different projects the team is working on, each managed by a separate 'product owner' (usually a Product Marketing Manager). Then there are separate TEAM backlogs that contain the sprints and cross functional teams of marketing types who all contribute to the completion of stories with the project backlogs. The benefits of have a team manage requirements this way include time management, capacity planning for the sprint and minimizing the randomizing effects of fire drills.
Q: How did you convince your managment to use XP?
A: XP is a collection of best practices that increase the likelihood a team will deliver running tested features that meet customer needs in a predictable and repeatable way. Surely management can see the value in that result? ;-) The book "Extreme Programming Applied" has a good discussion of this. Also see the discussion on the c2 wiki: http://c2.com/cgi/wiki?WhyItIsSoHardToSellExtremeProgramming
Q: So, Product Managers can equate to Business Analyst in a traditional organization and Scrum Master is played by Project Managers?
A: The Product Manager's roles and responsibilities align quite well with the Product Owner's. BUT, the approach they take to elaborating requirements and engaging with team varies significantly. A Project Manager can be a Scrum Master, but be cautious. Project Managers are typically in a top-down command and control roll where they plan and dictate to the team how to complete work. A Scrum Master is a passive leader that facilitates the team. The Scrum Master coordinates meetings, interfaces with external teams, and manages the impediments that the team can't resolve themselves.
Q: How do we handle Standup meetings for geographically distributed teams?"
A: Tools are essential. Use planning and collaborations tools like Serena Agile On Demand and Virtual Meeting tools.
Q: What estimation method do you use from sprint planning?
A: We use story points with "unit-less" value. Our teams use planning poker to estimate sizes. There is an interesting video of it's creator talking about it here: http://www.youtube.com/watch?v=1oIaz7aZsno&feature=channel_page and more info on this site: http://www.planningpoker.com/
Q: Would you recommend adding to the backlog a "regression testing" item?"
A: Using stories to manage work that is difficult to complete or track can work well. If the team is having trouble doing regression testing in a predictable way during the course of a sprint, using a story is recommended. If the team does a consistent amount of regression testing every sprint, you could instead consider it "overhead" and choose not to track it.
Q: is serena agile license per user based?
A: Yes. $35 per user per month.
Q: Where would a Business/System Analyst fit into the Scrum team/role
A: Often times we see Business/System Analysts as part of the Scrum team in primarily a Product Owner role.
Q: IS a user story different than a story board. Or is the story board where you post all the user stories for selection?
A: The card wall (story board) is a technique for showing stories and their current state in a single view. It is typically used to manage the state for stories in a sprint.
Q: Where is the current "high-bar" for portfolio management across an enterprise for full Scrum methodology used on across large teams of developers? Team size of 500 + developers? 800+ developers?
A: 1000s of resources.
