Group items tagged

an additional day or so of training for specialized roles of Product Owner, Project/Release Manager, and Agile/Scrum Master

All other executives and managers are invited to attend an overview course on scaling software agility

Agile for Teams –Essential, team-based training in a two day workshop

philosophy, principles, and benefits of agility, agile methods, iterative and release framework, roles, agile technical practices, and agile management practices (Scrum)

Agile Release and Project Management at Enterprise Scale – For Project Managers, Release Managers, Program and Portfolio Managers who have responsibility for helping deliver the product(s) to the marketplace. Topics include differences between traditional and agile product management, iteration framework, multi-level release planning and tracking, the agile release train, planning and executing the release planning event, and measuring enterprise progress.

Agile Product Owner in the Enterprise – For team-based product owners/candidates who will become responsible for backlog management, story writing, and iteration and release planning, and who will also be involved in the planning and coordination of larger scale software systems of systems built by teams of teams.

The Agile Master In The Enterprise – For potential agile team leads/future Scrum Masters who will be coaching agile teams and who will interact with other teams as well. Topics include: process facilitation, enterprise agility, mastering the iteration, team roles, release planning and tracking, agile leadership, empowerment and conflict management, and integration Scrums.

Agile Product Manager in the Enterprise – For enterprise product managers with product, product line, portfolio and business unit responsibilities. Topics include: what’s so different about agile, backlog and prioritization, relationship to product owners, PM’s role in release planning and management, visioning and the product roadmap.

Scaling Software Agility – Best Practices for Large Enterprises – For executives and key stakeholders in support, distribution, quality, internal IT, HR and all others whose roles will be impacted by the substantive changes that enterprise agile engenders. Part I – overview of agility highlighting lessons learned from the most common and effective agile methods Part II – seven team best practices of agility that natively scale to the enterprise level Part III – seven organizational capabilities that companies can master to achieve the full benefits of enterprise scale agility

The team member doesn’t need a CSM course, but he does need to know how to work in an agile environment.

what are the engineering practices need to support agile development? I’ve found that if developers only have their existing tools and practices, then they will continue to specify and develop waterfall-style within the sprints.

Independent Software Vendors (ISV) -teams of teams who develop software for sale, including products like network management, supply chain management, mobile applications, etc. This segment now also includes the rapidly emerging Software as a Service (SaaS) vendors. Customers are external to the enterprise.

So far, former developers/tech leads with business sense and good project management skills seem to be the best fit.

ultimate user (mobile device user) is fairly far removed from the major technologies

Ryan went on to note that the title of "Program Manager" also performed a similar role in some larger scale contexts:

Embedded Systems Example - Symbian Software Limited

Clearly, the development of a mobile phone operating system is a highly technical endeavor

mention this because I suspect that the Technical Marketing Specialist role, where it exists in the ISV today, could make a good role model for the Agile Product Owner in today's larger ISV

the development process does not lend itself quite so easily to the traditional, customer/user facing, agile Product Manager/Product Owner roles. However, the Product Owner role must still be successfully addressed in this highly technical context.

All our POs come from engineering teams and are senior engineers with product or customer experience.

one PO to two team mapping typically, rarely 3 teams, sometimes 1

IS/IT Examples

role/title of the Business Systems Analyst

is often a reasonably good fit for the Product Owner role.

In the larger IT shop, I have also seen the role filled by Project Managers

In many cases, the self-managing and team-based planning lightens the workload for the project manager in the agile enterprise, and they often have the domain knowledge, inclination and insights necessary to fulfill the Product Owner role. Therefore, many have the time, skills and inclination to fill this role.

In our case, our product owners are in IT. They are the liaison to the business and in many cases speak for the business

Our Business Systems Analysts in IT are filling the role of Product Owner. Their previous responsibility of documenting detailed business requirements and rules now falls to the entire team in the form of user stories and acceptance tests

The dates and themes for the next release are fixed. The features are prioritized and variable.

The teams can commit only to the features in the next upcoming release. Releases beyond the next, represent only a best estimate.

The Roadmap, then, is a “plan of intent” and is subject to change as development facts, business context and customer needs change. With respect to the upcoming release, perhaps the most important guidance is this:

Even though the team has committed to the objectives and we have agreed that the feature set cannot be guaranteed, it is a reasonable expectation that the agile teams will: 1) meet the date 2) accomplish the theme 3) deliver most of the features, and certainly the highest priority ones, with the requisite quality.

Anything less would be unprofessional and belie the power, discipline and accountability of our agile enterprise model. Moreover, it will eventually threaten our own empowerment, as failure to deliver will inevitably cause the implementation of various controls to “help us”!

I told them I just saved them $12,535! They looked around to figure out how. The reason I was there was simple. Earlier that year, those same IT managers had performed a series of calculations to estimate how much it cost the department each time a bug made its way out of development, into SIT, into User Acceptance Testing, or all the way into production. For this IT shop, one bug into SIT cost them $12,605 (and you can imagine how much a bug into production would cost.)