Agile Baltimore on March 2, 2018

Agile Baltimore

We fought the wintery and windy bomb cyclone to meet for coffee and conversation.  Traffic sucked. There were trees down. Thankfully, there was power, heat, and coffee!

What we discussed

  1. *** Product First or Process First. How do you solve a problem?
  2. **** Requirements - From business translating to tech. 
  3. **** Why do organizations fail to address cultural issues before implementing Agile?
  4. Hands-on experience dealing with EPMO/Compliance and Agile
  5. What management practices impede Agile? How to address?
  6. *** Agile in FDA compliance environment
  7. * Bugs on Scrum Team
  8. Managers. How do you deal with them?

* Topics with the most stars were discussed first.

What are your thoughts on the topics? Conversation and respective dialog welcome.

8 Domains Executives should Plan and Coordinate

Planning and Coordinating use Agile PPM tools

Executives are responsible for maintaining the structure of the organization and supporting the mechanisms that enable the flow of value across many teams. To that, executives should plan and coordinate across major organizational domains. Though I believe there are eight domains which executives should be planning and coordinating in, I'm not prepared to say Sales & CRM or Marketing Management should be included in an Agile PPM tool (at this time). Beyond that, a single PPM tool should cover the remaining six domains.

Often, the first tools purchased are to help the delivery teams manage their daily work. As the organization evolves or grows, more tools are purchased to cover the gaps left by the team-level tools. The tools then become entrenched. At some point, organizations have a collection of tools they are trying to maintain and they lose sight of the original reasons for purchasing and implementing them.

Organizations then turn to PPM tools. There is a wide variety of motivations for using agile project portfolio management (PPM) tools. One key reason can simply be the desire for their teams to collaboratively plan. Other key reasons include the desire to prioritize and track work on a synchronized cadence, while providing visibility of the portfolio to the executive stakeholders. To meet organizational needs, the number of tools being used to satisfy these desires expand over time.

Before you choose an Agile PPM tool, remember that your company operations should influence how that tool is implemented across your organization, not the other way around.

What types of problems are Agile PPM tools good at solving?

Six Organizational Domains of Planning and Coordinating

Portfolio Management

The art and science of making decisions about investment mix and policy, matching investments to objectives and key results (OKRs), asset allocation for individuals and institutions, and balancing risk against performance. Your Agile PPM tool needs to provide a sufficient level of visibility of the roadmap and investment themes, through the lens of a portfolio team.

Program Management

The process of managing several related projects or products that are part of an investment portfolio. Your Agile PPM tool must provide a sufficient level of visibility of the release backlog and to allow for necessary elaboration for release targeting, all through the lens of a program or capability team.

Capacity Management

Deals with the organizations ability to create or develop new product. Capacity constraints in any process or resource can be a major bottleneck for a company. Your Agile PPM tool should make it easy to know what the organization and teams have historically delivered, in order to understand where the bottlenecks exist, and what to commit to in the future.

Human Capital Management

Related to people resource management. In order to deliver product predictably, it is necessary to have stable teams, providing specific competencies. Your organization needs the right people in place to deliver on commitments in the portfolio. Do you need to hire or replace people? Your Agile PPM tool should help facilitate a conversation around who are the right people, what teams they should be on, and when we need them on a team.

Dependency Management

The ability to either encapsulate or orchestrate around “dependent” organizational, structural, or technical activities. Dependencies tend to be a major productivity killer for organizations. They slow and sometimes stop the ability to deliver value. It is critical that your Agile PPM tool provides indications of dependencies across the organization. Having the first indication of a dependency discovered after a delivery team has already made a commitment against its impacted deliverable is too late.

Budget Management

Refers to a financial plan for a defined period of time. It may also include planned revenues, resource quantities, costs and expenses, assets, liabilities and cash flows. Your Agile PPM tool must provide the necessary information to shift conversations from just scope and schedule to budget.


Use the above list as a guide to catalog tools your organization is using (or considering) for planning and coordinating. Are there gaps or are there overlaps and duplications? If you have overlaps and duplications, there is an opportunity for you to consolidate some of those tools. Begin consolidating tools, and you may reclaim some budget next year you didn't think you had.

Want to know how you are covering the six or eight domains? Schedule an assessment with me.

Agile Baltimore Meetup | April 14th, 2017

Another great meetup! This month, topics we discussed:

  • Half-breed implementations where no business was included.
  • Heuristics for determining a good user story
  • Incorporating project managers in Scrum'ish Agile
  • Program vs Project Scrum implementation
  • LeSS vs SAFe

Link to Agile Baltimore Facebook Page Link to Meetup Group Page

Check out the image gallery!

[srizonfbalbum id=2]

Agile Baltimore Meetup | March 3rd, 2017

After hosting Lean Coffee's every month for the last three years, I figured I would share some photos and stories. Though I have a Facebook Page and Meetup Page, my blog gets the most traffic. So, I'll try to post about the event here going forward and then link to the other sites. On March 3rd, we had our monthly meetup at Mad City Coffee.  Check out the image gallery![srizonfbalbum id=1]

Failure Pattern in Scrum

I recently spoke at a corporate community of practice event.  My session presented a useful model to identify indicators within a system to predict its failure. First, we started by applying the model to everyday systems everyone could relate to.  Next, I asked the attendees to map a system of their own. As I walked them through my model step by step, I used Scrum as my example system. Upon completion of the worksheet (see my completed sheet below), attendees were able to see if there were any “gaps” in their systems. The gaps provided an indication that a respective system was at risk of failure. To clarify, on a delivery team level, I see the Scrum Framework as a solid method for managing product development. But what about Scrum in the context of the entire delivery organization?  Using both The Three Things You Need To Know To Transform Any Sized Organization and my model, I look at Scrum in a broader context. I can see a potential failure pattern.

Scrum failure pattern


What is the failure pattern I see in Scrum?

My model will segment any system into 5 areas: Clarity, Commitment, Ritual, Progress, and Habit. The gaps that I will note below are those things not mentioned in the Scrum Guide.

Gap 1: Clarity

What does the structure of the organization look like (Portfolio, Program, Product) above the Scrum Team? We need a shared understanding.  What does the governance of the organization look like (Budget, Dependencies, Risks, Quality,…) above the Scrum Team? What are necessary metrics and tools of the organization above the Scrum Team?  Some organizations are very large and heavily distributed.  How will you measure the health of the entire delivery system?

Gap 2: Commitment

In Mike's 3-things talk, he calls this accountability. Given the broad applicability of my model, I prefer to call it commitment.  Commitment can be any resource. So, what money and time may be required for Scrum training of all leadership and Scrum teams within an enterprise?  What money and time may be required for procurement, installation, and training of tooling used to manage and report on the health of the delivery system? Lastly, we need agreement from the Leadership team to follow the Scrum Framework (or more particularly respect that the Scrum team is following it).

Gap 3: Progress

As I noted in my post on Productivity Patterns, if you lack progress, you lose momentum. If you lose momentum (or should I be so bold to say velocity or throughput), you will lose commitment to the system. Those who are funding the efforts (those outside the Scrum team) need to know progress is being made in a way that is important to them.  What is the Time to Value?  Is the Scrum team predictable on a release level (Release Burndown/Burnup chart)?  Are we even building the right things? (Product Fit) Are we building things right? (Quality)

Gap 4: Rituals

Rituals can be event or meetings, as part of your system of delivery. First, let's start with product vision.  Scrum teams have a horizon of a few weeks (the sprint).  Vision is viewed or realized in months, quarters, or years. Read the Scrum Guide and you won't see Vision mentioned once.  Also absent from the the Scrum Guide is the notion of portfolio or release planning.  Unless you have a delivery capability that allows you to release at the end of every sprint, I can't champion release planning enough.  In addition to that, good portfolio planning ensures we have a balanced system of delivery and ensures we have capacity to make commitments against a roadmap.

Gap 5: Habit

Given the rituals I outlined above, you should make it a habit to have periodic Vision Reviews, regularly scheduled Portfolio Planning/Reviews, and ensure you're consistently doing your Release Planning.


I'm not suggesting you abandon Scrum. But after you look at the highlighted gaps I listed above, in a system of delivery larger than a single Scrum team, you should consider more than what is in the Scrum Guide.