Group items tagged

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”!

Lesson 3:  Actual progress is infinitely more important than planned progress.

Lesson 4:  Calculate your velocity and use that to plan for the future.

Berteig Consulting can update the Certified ScrumMaster course content so that all CSM course participants receive the best value in the market.” As soon as I made the direction clear, the team self-organized and generated tasks required to achieve each goal.

As the Process Facilitator goes about helping the team overcome obstacles, it can become clear that the team needs to address a systemic challenge during one of the upcoming Cycles. The Growth Facilitator then states the need as a Cycle goal in a S.M.A.R.T. format, allows the team time to give feedback, and prioritizes the goal in the New Work list. When the goal is brought to a future Cycle Commitment Meeting, the team breaks the goal into tasks and solves the systemic obstacle that the Process Facilitator identified.

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.

The reason there's been so much turnover of CIOs in the last ten years is because the end users – the CEOs, the CFOs and the division heads – are unhappy with the results. When IT professionals realize this, and realize that something like Agile gives them the opportunity to create better value for their businesses, then they're going to be a lot more willing to adopt it. I hope that development organizations are starting to see around that corner.

We WANT to go Agile. How do we overcome the skepticism at the CXO level?"

My recommendation would be "try it." Agile doesn't equal risk, but changing development methods does equal some risk

t can be a big deal to say: "I'm going to change our development methodology." It makes people sit up and want to dive into deep detail before getting on board. The question comes in the form of the old development methodology: "Let me see the high level plan and what the change will be in the deliverables and methodology over the next two years." This is exactly what you're trying to avoid by going to an Agile method.

try Agile on a few small projects, measure the results, talk to users about their satisfaction, and then readdress

nitiate the shift in the most change-prone areas first, and then work it backwards through the rest of the organization

It doesn't happen everywhere at all times, and it doesn't work in all areas. It's good to recognize that up front – that software development projects adapt to this easily, but an infrastructure project would have challenges with this approach. So, select a few areas that would naturally lend themselves to Agile, such as application development, gradually introduce it to these areas that need it most, and then measure results.

Again I'd say: "Try it." Agile transition is absolutely about organizational change. To win executive support we need to speak in terms of risk management, measurement and the bottom line.

We do a very good job - in general - teaching the skills. That is, teaching the team to run an iteration with a kickoff, demo and retrospective. Teaching test driven development. Some of us even do a very good job teaching the team to be pseudo-self-organizing by taking a socratic approach to coaching and standing back and letting the teams make their own mistakes and learn from them.

We even do a good job - in many ways - teaching the team the values of Agile development. If we are there long enough, the values come from diligent and disciplined application of the practices.

- (1) Provides organizational vision- (2) Removes impediments- (3) Assists with individual development- (4) Challenges team beyond mediocrity while respecting team boundaries- Helps individuals without sucking the responsibility out of the team- Balances observer and contributor roles- Gives individuals tools to be a great team member- Coaches teams through conflict resolution- Advocates for continuous improvement for teams and the organization at large- Buys things for the team (manages budget)- Provides the right environment- Manages portfolio of projects

1. Providing organizational vision: Often teams flail because there is no vision 'from on high'. Having this vision is important for team members to be able to relate their daily actions.

manager's role in this process to remove escalated impediments from the team(s).

provide strategic vision, business strategy, and resources

3. Assists with individual development: We all have managers who mentor us in professional and sometimes personal growth. We felt that this is an important role for the manager to continue to play. Not all scrummasters have the authority or expertise to help in this regard.

a manager role would be like a 'ScrumMaster on steriods'- a person whose job it is to remove all escalated impediments for the team, take care of external stuff to the team, lead the team by challenging it, and assists direct reports with individual development and other HR-related challenges.

CMMI Level 5 Requirement 2.4.10 Review the activities, status, and results of the Agile Methods with higher level management and resolve issues (GP2.10)

ensure that higher level management has appropriate visibility into the project activities.

The principle of self-managed teams would say "let them be; let them find their own way." A principle of leadership, however, is to challenge teams. We discussed the fine line between challenging teams and taking away their ability to self-manage.

Jens Ostergaard