The Two-week COBOL Sprint: How to Build a Scrum Team
Throughout this blog series, I’ve written about why mainframe shops need Agile processes like the two-week COBOL sprint to more quickly develop and deliver software for customers in the digital economy. In this post I’ll talk about how to build a scrum team to do that.
Choosing Scrum Team Leadership Roles
Communication and collaboration are vital components of Agile processes like the two-week COBOL sprint. The Agile product manager and the product owner are key roles on a scrum team, and should be two excellent communicators who work well together to drive the scrum team. Don’t appoint one person to handle the work of both roles or they will become a bottleneck, decreasing production and customer satisfaction.
Agile Product Manager
Choose an ambitious product manager to become your Agile product manager. Although this person isn’t technically on the scrum team, they provide invaluable information to the product owner and scrum team members.
The focus of the Agile product manager is toward the customer. To understand customer needs, they travel to meet with customers in their natural habitats and analyze the market and competitors. From this process they create epics that guide the product owner in the creation of user stories.
The Agile product manager works with sales and marketing to communicate product value and relays this information to the team to confirm or redirect product development efforts. As the leading expert, the Agile product manager should be able to convey product value to anyone.
Choose a product manager, business analyst or product planner to become your product owner. The product owner creates user stories and works with the Agile product manager to assign user story priorities. They ensure the scrum team understands story details and implements stories in ways that excite customers, which is why the product owner should be co-located with their scrum team to be available for answering questions about story details.
The product owner must make sound decisions to bypass technical roadblocks. For instance, as the guardian of the backlog, the product owner keeps it organized and prioritized, preventing it from ballooning into a mess of incomplete stories, duplicates and tasks with erroneous statuses.
Choosing Scrum Team Roles
The scrum team should be comprised of people across functional areas committed to daily interaction. Certain roles in your organization will cross over as specific scrum team roles, while other roles in your organization will benefit the scrum team in their normal capacity as needed. Team roles include:
- Evolves from Team Lead/Development Lead/Development Manager
- Works with product owner and stakeholders
- Ensures agreed upon items built in agreed upon order
- Becomes scrum team members
- Builds software according to stories about user needs
Quality Assurance Team
- Becomes scrum team members
- Confirms sprint deliverables meet requirements
- Ensures software works and errors aren’t reintroduced
- Does testing during every sprint
- Builds and improves automated testing
- Gathers and maintains data for testing
- Stakeholders at sprint reviews
- Ensures data privacy and prevents abuse of personal data (fines for privacy violations are increasing, so make sure these people show up!)
- Part of scrum team or stakeholders at sprint reviews
- Ensures software designs and changes pass audit criteria without delay so software can be immediately deployed when completed
- Guides software updates so software performs well in system environment and requires minimal care while operating
- Helps define operating environment
- Member of scrum team or stakeholder at sprint reviews (depending on amount of database management system work in software)
- Analyzes query performance and database commands
- Changes DBMS configuration to optimize performance
- Helps ensure consistency of data across systems
- May be part of the operations organization
- Identifies where software components will run
- Helps with ongoing automated software builds
Scrum team members should work through an entire product delivery before declaring victory, but should expect to encounter unfamiliar tasks along the way. To assist the journey and eliminate surprises, I recommend capturing delivery tasks—detailed descriptions of the processes for packaging, deployment and initial use—as user stories.
After reaching success, the scrum team’s use of the two-week COBOL sprint will become a standardized model for others to follow, helping your company develop and release software solutions faster than before.
Two-week COBOL Sprint Next Steps
Are things fitting together as you read through “The Two-week COBOL Sprint” blog series? To recap on important steps leading up to the building of your scrum team, read my previous posts below:
- “The Two-week COBOL Sprint: Why Mainframe Shops Need It“
- “The Two-week COBOL Sprint: How Agile Mends Broken Trust“
- “The Two-week COBOL Sprint: Having a Critical Conversation About Agile“
- “The Two-week COBOL Sprint: Developing a Process of Continuous Builds“
- “The Two-week COBOL Sprint: Agile Feedback Loops“
- “The Two-week COBOL Sprint: Deployment Automation“
- “The Two-week COBOL Sprint: Software Development Bottlenecks“
Moving forward, I’ll explain how to install the various parts of the two-week COBOL sprint that make it an Agile process, beginning with my next post about developing a process of continuous builds.
Latest posts by Glenn Everitt (see all)
- Reducing the Danger of Shadow IT with DevOps - May 15, 2018
- Living in a ‘More Data, More Problems’ World with Unit Tests - September 6, 2017
- No Mock Objects for Your Mainframe? Create COBOL Program Stubs - March 23, 2017