Group items tagged

Has the team made changes that make a difference to them as a result of the retrospective?

Has the team explored a variety of different topics/areas, or do they stick to pretty much the same agenda around continuous improvement? What is the balance of change/improvement work vs. working on the product?

For example, try looking at technical practices, teamwork, or customer relationships... choose what ever seems most relevant to bound the discussion. That might help the team dig deeper and find issues that have more significance for them (now...I'm sure the other changes were significant at the time).

Connect Agile’s Benefits to your Company’s Priorities

aying that Agile is “better, faster, cheaper” may not be enough to cause a company to be willing to go through the often-painful process of cultural and process change.  You could implement Agile, but you could also try Six Sigma or Lean.  Saying that Agile is a general get-better remedy puts it in line with many other get-better methods.

f they don’t see a meaningful update from us, at least once a quarter, we’re going to get kicked out of the game.  We’ve all acknowledged that as we’ve gotten bigger, our processes have become more cumbersome and now is the time to do something about it.  Agile will give us the ability to regain that rapid pace of delivering innovations to market that we were know for in our early days.”

Yuval Yeret shared his Scrumban - taking Scrum out of its comfort zone slides from the Israeli Scrum User Group event this week. It's great to see this. I think Yuval shows great courage and I hope his audience are open-minded enough to give his thoughts a fair hearing.

The responsibility of the Growth Facilitator is about more than simply prioritizing New Work goals and tasks. I see the role as contributing to the organizational culture, and helping to build the business in a sustainable way.

As Growth Facilitator, I am also responsible for guiding the team toward delivering greater value for our stakeholders. At Berteig Consulting, our stakeholders don’t just include the company’s owners. Our stakeholders include a wide range of groups, including customers, suppliers, employees, and our families, all without whose support nothing we do would be possible. Delivering value to our stakeholders requires that we keep them in mind when we commit to our tasks each week.

When I first started, I made goals that were broad, saying for example “to take care of our clients” or “to work at a sustainable pace.”

It’s a lot easier to estimate a story that’s small — which can lead to more accurate estimates, and better predictability.

It’s easier to plan with smaller stories. With big stories — stories that might take weeks for a developer to implement — it becomes difficult to plan a development time-box — particularly when the iterations are only a couple of weeks. It seems that only a couple stories fit — and there’s often room for half a story — but how do you build half a story? Splitting them into smaller stories makes it easier to plan those time-boxes.

Shrinking stories forces earlier elaboration and decision-making. Where product owners could write their stories fairly generally and consider many of the details later, now breaking them down into smaller stories forces more thinking earlier in a planning lifecycle.

Institute an agile transition team, and have the agile PMO play a significant role on that team. If you are starting on the journey, establishing an agile transition team can be a critical factor in your success. The agile transition team plans and implements the strategy for the organization’s agile transition (using a backlog, iterations, planning meetings, retrospectives and, in general, responding to change) This group monitors and communicates results throughout the organization, and is responsible for removing organizational level impediments. The PMO representative can act as ScrumMaster for the agile transition team. Members should be leaders representing different departments and functions that are impacted by the agile transition. For example, having leaders from development, QA, product development and the PMO is an excellent practice.

Establish a “Meta Scrum” that is tasked with mapping projects and features to corporate strategy. As part of optimizing the whole, it is important for there to be a big picture view across products and features. In general, product managers are tasked with defining, prioritizing and communicating the vision and features for their products. When you have a program that encompasses multiple products with multiple product owners and project teams, keeping everything in line with the corporate vision can sometimes be overlooked.   Unlike the Scrum of Scrums--which is tactical, i.e. focused on execution--the Meta Scrum is focused on the strategic planning and decisions guiding the program or programs as a whole. Establishing a Meta Scrum with the PMO representative acting as ScrumMaster to plan and facilitate meetings (as well as reporting and tracking decisions and action items) can add significant value in having a program able to rapidly respond to change while staying true to the corporate strategy and objectives.

I like using story points to establish the velocity of individual teams. From a program point of view, however, story points are difficult to use across multiple teams. The nut there is that one team’s story point is not equivalent to another team’s story point. To crack that nut, I use agileEVM to “normalize” to standard project management metrics like the Cost Performance Index and the Schedule Performance Index, as well as the Estimate At Complete in integrated dollars. These metrics can be aggregated across teams to establish progress against the plan for the entire program.

How to make a LOT more money using agile

More frequent releases

expectations must be set for releases to be smaller but still have significant marketable value.  It also means managing scope for smaller releases so the value can actually be delivered to meet the expectations.  If we make the assumption these two pre-requisites can be handled, then we can also assume faster releases are possible.  Yes, I know, releasing software is expensive, requires other groups, etc.  For now, let’s assume all of those costs are negligible compared to the potential results and see where we end up.