This past Tuesday, I had an opportunity to speak to a combined audience from Central Florida IIBA and Agile Orlando. It was a great session and I hope everyone had as much fun as I did! Thank you for the opportunity. If anyone took photos, please let me know so we can get them posted on AgileOrlando.com
There were a few questions we didn’t get to in our question backlog kanban. So I’ll answer them here:
- Role: Co-Founder – Question: What are some good strategies to utilize agile for a startup tech company.
Answer: You really should attend our March 11th meetup where a founder of multiple startups will talk about how his team used lean startup and agile principles to launch Talent4Startups.org (RSVP free at http://meetu.ps/2GDWfN)
- Role: IT Director BA & QA – Question: In agile projects, what is the best practice for who owns the scope change communication process?
Answer: The role of Product Owner in Scrum is specifically designed to manage communications and prioritize scope through the product backlog. This is a living artifact that is constantly updated as the Product Owner gathers requirements from different stakeholders and gains understanding on technical feasibility and cost (effort/sizing) from the delivery teams. FYI, agile delivery teams include developers, BAs, QA, UX and any other skill sets to go from concept to cash in delivering increments of the product. One of the best references on the Product Owner role is Roman Pichler’s book on Agile Product Management http://amzn.to/1z226gM You can get a 35-45% discount if you click on the InformIT sponsor logo on AgileOrlando.com (sponsors listed on the left navigation bar)
- Role: Product Owner – Question: How to handle emerging production issues without disturbing the sprint.
Answer: My guess is that you are expecting some production issues. That spawns a few answers. First, every agile team should plan some slack in what they commit to for a sprint. For example, if you have 200 person-hours of time, I often recommend a team commit to 80-90% capacity (~160-180 hours of work in this example). That will allow the team to deal with any unanticipated production issues or even problems with development infrastructure, staff out sick (if cold/flu season) etc.
Second, always plan beyond the sprint. If the team feels they can pull in 3 feature segment (a.k.a. user story) from the backlog, be sure to have them estimate and discuss four or five. Then, if they plan with slack and they don’t use the slack, the team can pull in that fourth feature/story if the other three are close to completion and there is still ample time in the sprint. Keep in mind this is NOT a commitment to complete the fourth item you pull in mid-sprint. It’s a stretch goal.
Third, in the team retrospectives at the end of every iteration, it might be worth discussing the Definition of Done (DoD). In Scrum, this is an agreement between the team and product owner on what the team needs to do to maintain quality (design coding standards and other best practices, testing practices and any kind of review and automation practices). If you are experiencing frequent production issues, it might be worth providing information on the Definition of Done ( https://www.scrum.org/resources/scrum-glossary/definition-of-doneor https://www.scrumalliance.org/community/articles/2008/september/what-is-definition-of-done-(dod) ) and then asking what we might need to change to reduce or eliminate the production issues. What is an experiment we can try based on these ideas? Run that experiment for 1-2 sprints. Gather data and follow up in another retrospective to see if changes need to be made to the Definition of Done.