Some great questions for our Speaker Panel.
Click on the names below to see their Agile Summit talks!
See the questions below!
Question: How do you make sure that Agile isn’t used as a fire extinguishing tool?
- Answer by Pam Johnson: Understand the priorities first, go from there and don’t fight fires.
- Answer by Susan Block: Understand whether it is a business or IT fire first. Root-cause analysis may need to be looked into first.
Question: Where do you start estimating? How do you kick off the process?
- Answer by Manoj Vadakkan: Estimation should continue as is if it’s working. Try small projects and iterate on them.
- Answer by Dave Grabel: Focus on a small problem and celebrate the small wins. Try starting with a User Story workshop and invite all the Product Owners.
- Answer by Jane Shellum: Estimate in a sandbox if possible. Use demos to try out estimation.
Question: Can a project be too Agile? Moving ahead without enough requirements definition?
- Answer by Susan Block: So long as the work is understood, go ahead with the work. As long as there is just enough information to begin, start, and then engage the needed resources as you go along. If there are a couple stories that are prioritized and ready to go, start!
- Answer by Dave Grabel: Have a starting point. Build a product backlog. Agile is the willingness to proceed without knowing everything. Have the team have a good enough understanding of what the key features the business wants.
- Answer by Janet Bartz: You won’t ever really have all the stories at the start. But having some prioritized stories is enough of a starting point to begin. You won’t ever have all of the stories at the beginning. You just won’t.
- Answer by Manoj Vadakkan: It’s like an iceberg. You start at the top (prioritized), and as you get deeper it can get bigger. That’s fine.
Question: How can Agile techniques for integration and package delivery?
- Answer by Susan Block: We have to understand how integration as a product is brought into development. Analysis exercise to elicit the stories to deploy the configuration or integration. Need to have stories to cover that work.
- Answer by Janet Bartz: Keep the requirements at a high level for integration. Don’t deep dive in initially. Work towards just enough information.
- Answer by Jane Shellum: Deep dive details are not necessary in the beginning. Start at a high level and build out over time.
- Answer by Dave Grabel: We have a CRM (Customer relationship management tool) that we’re integrating. Most of the backlog items are rolled out in an Agile-like fashion.
Question: Multiple customers and conflicting priorities? Does Agile work?
- Answer by Pam Johnson: Bring all product owners in and have a prioritization session. If that doesn’t work, escalate it up towards higher level.
- Answer by Dave Grabel: Have an executive steering committee that can review the conflicting priorities. They can balance the client relationship management.
- Answer by Jane Shellum: We have a steering committee that priorities and we lock our iterations so things can’t get changed mid-stream.
- Answer by Susan Block: Governance. Usually becomes and escalation issue. If you can prove business value by some measurement thats great, but if you can provide some intermediary value point, that may help with prioritizing.
Question: Is it possible to perform Agile business analyst tasks even when project is still formally waterfall?
- Answer by Susan Block: I recommend that you look at your big requirements phase and break it down into prioritized functionality. What will add the most value? Maybe you can make the case to provide just enough requirements instead of “all.”
- Answer by Manoj Vadakkan: The question I would ask is “Why would I want to do Agile requirements in waterfall? Where is the value?”
- Answer by Dave Grabel: Use Agile if it solves a problem. What is the motivation? If it’s the latest buzz word and thats why you want to do it, then don’t do it.
Question: Does Agile make sense for projects without a major customer facing component?
- Answer by Pam Johnson: Yes. Customers are whomever you’re doing the work for. Can be internal.
Question: How do you get team members to work outside their primary skillset to enable swarming?
- Answer by Susan Block: Very hard to do, but try leveraging a bonus criteria for team members who are stepping outside their role. Give a carrot of promotion or rewards as a motivator. But also, have a Product Owner not move a card until other people pick up the work. (Interesting example)
- Answer by Pam Johnson: Challenge your team to go beyond. Pick up the hard projects and blow away peoples expectations.
- Answer by Jane Shellum: Build in an expectation that team members should have blurred roles. It’s everybody’s problem, everybody’s challenge, hire people that work that way.
- Answer by Manoj Vadakkan: Define the the projects goals and have people work towards those goals. People will have to pick up extra roles to get it done. Put project radiators on the wall and ask for help. Tell people they need to help to get it done to make the iteration.
Question: Does the business have to colocate with the development team?
- Answer by Susan Block: If not full time colocation, there has to be a full commitment by the business to be there consistently. If you can’t, try moving yourself to the business. You don’t realize how important the relationship building is until you’re all together.
- Answer by Janet Bartz: Shadow the business people. My personal view is you have to have the business people with IT. It’s so much more powerful. You can feel that somethings different where we are. It’s tangible. Forget the throw-it-over-the-fence mentality.
- Answer by Dave Grabel: Our lead developer met with the business and wore a path between his desk and the business. It worked.
Question: Executive support and Agile. What actions would you recommend for teams who want to move to Agile but don’t have the support of upper management?
- Answer by Manoj Vadakkan: Ask the business the question of why they want to go Agile and what are the reasons?
- Answer by Dave Grabel: Start small, create predictability, success breeds success. Give visibility up the chain that Agile works.
Question: What kinds of IT software initiatives are not Agile-appropriate?
- Answer by Susan Block: Support issues and infrastructure projects that are cut and dry.
- Answer by Janet Bartz: Try using Agile on something. If something makes sense, then try it out. Don’t follow the methodology religiously, some techniques make a lot of sense some don’t work. We don’t try to be Agile. We try to deliver value. Many of those were Agile.
- Answer by Dave Grabel: Embedded systems often were thought of as anti-Agile. If you can be successful in embedded systems using Agile, then you can use Agile for anything. It’s not the project, but the organizational culture. If your culture doesn’t support collaboration and Agile practices then you have to focus on that first.
Question: How do you get the business to let go of big business requirements documents?
- Answer by Jane Shellum: Nobody likes fat requirements documents. They come out of fear of not having all your bases covered. Easy to let go once you understand how Agile works. No such thing as scope creep. Scope change. Then prioritize the total list.
- Answer by Manoj Vadakkan: The key is the trust. Build the trust and then you can lose the heavy requirements documents.
- Answer by Susan Block: Make sure that you demonstrate the business context and understanding and you won’t need the business document.