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.

Summary

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.

Getting Clarity

I believe the number one reason for failure or waste is a lack of clarity or understanding. If you getting clarity on something, it gives you the freedom to decide if you want to do it or not.  If something is ambiguous, you may agree in principle but you don't know what you're really getting yourself into.

OKRs

Firstly, what are your Objectives and Key Results (OKR)? How do you set and communicate goals and results in your organization? Because you want people to move together in the right direction, you need to get clarity.

KPIs

What are your Key Performance Indicators (KPI)? How do you want to measure value that demonstrates how effectively your company is achieving key business objectives?  Because you want your organization to evaluate its success at reaching targets, you need to get clarity.

Structure

What does the team design or structure of the organization look like on portfolio, program, product, and service layers? We need a shared understanding of which individuals or teams are responsible for what.

Governance

What does the governance of the organization look like? How do we manage our budget, dependencies, risks, or quality? What are the inputs, outputs, and artifacts?

Metrics and Tools

Because we want to manage our system of delivery, what are necessary metrics and tools of the organization?

Getting Clarity

Remember, if you expect others to commit to something, regardless if it's a process or a deliverable, we need a shared understanding.

Review of the book Angel by Jason Calacanis

I just finished reading and listening to Angel: How to Invest in Technology Startups, a book by Jason Calacanis.  I first mentioned Jason on this blog back in 2009, when I wrote "starting is easy; finishing is hard." Fast forward 8 years.

First Thoughts

First, let me say, this is a great book. I'm now going back, highlighting sections, and ready to put what I have read to work. I also recommend downloading the Audible version. It's read by Jason and has some extras at the end (not in the physical book).

So many other books are all hype, promising everyone that they can do anything. They promise you fame and fortune, resulting in readers changing their profiles to read "Hustler, Grinder, and Lifestyle Coach". I love that Jason didn't say everyone can be an angel investor.

Actually, he did but there were some clear caveats. If you want to be an effective angel investor, you'll need a combination of things and Jason details what they are (see chapter 4).

Though you might not meet all of Jason's criteria to be an effective angel investor, I still think you should read (and listen to) this book if you're a founder or thinking of getting into angel investing.

CONS:

1. Jason was specific about what you need to do, to be an effective angel investor.  Right away, you'll realize if you can or can not do this.  Sorry to all of those precious snowflakes out there who think they can do anything.  If you don't have the money or stomach for high risk, you can't do this.
2. At $1000-$2500 for each of your first 10 investments, if you don't have the money, you can't afford to be an angel investor.
3. If you can't deploy even greater amounts of money, in the event one of your startups gets a Series A from a known venture capital firm, you'll get diluted. (do a search on Pro Rata)
4. If you're unwilling to move to Silicon Valley, your deal flow may be limited. (I like my home in Maryland)
5. You have less than a 1% chance of being successful. (The truth hurts)

I just exchanged Twitter DM's with Jason.  He wanted to note that he did talk about being an angel with no money (advisor shares!).  I want to make sure I properly represent the book so I'm adding this blog post edit.  Also, I plan to write other blog posts about the book.

PROS:

1. Jason was specific about what you need to do, to be an effective angel investor.  Right away, you'll realize if you can or can not do this.  Note I'm listing this as both a Pro and a Con.
2. He describes probably the safest path you can take if you're going to get into angel investing.  Granted, you still have less than a 1% chance of being successful.
3. Jason speaks and writes from the heart. He sounds like a kid from Brooklyn.  He actually reads the Audible version of his book.  I've been listening to him since the beginning of his This Week in Startups (TWIST) podcast. It was good to hear his voice and not some voice actor.
4. He has an impressive track record in angel investing so he's not like these knuckleheads you see out there trying to be "lifestyle advisors".
5. "You only have to be right once" ~Mark Cuban

Now, it's time to put in the work.

Disclaimer: I was in no way compensated for the writing of this review.

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.

Conclusion

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.

10 ScrumMaster Qualities

A ScrumMaster is one of the three key roles of the Scrum Framework. Ken Schwaber and Jeff Sutherland conceived the Scrum process in the early 90’s. With so many years having passed, you'd think organizations would better understand good ScrumMaster qualities. More noteworthy, they should know qualities of a bad ScrumMaster. Because of this, I created a simple infographic to focus on both good and bad qualities of ScrumMasters.  I've noticed, as organizations begin to scale, roles and responsibilities begin to blur. People may be asked to take on ScrumMaster responsibilities.  Do you have the right qualities?

View and download the free infographic:  10 ScrumMaster Qualities 

5 Qualities of a Good ScrumMaster

First, a Servant Leader is an empathetic listener and healer. This self-aware steward is committed to the growth of people. Second, a Coach can coach the other team members on how to use Scrum in the most effective manner.  Third, the Framework Champion is an expert on how Scrum works and how to apply it. Next, the Problem Solver protects the team from organizational disruptions or internal distractions or helps remove them.  Last, the Facilitator is a neutral participant who helps a group of people understand their common objectives and assists them to achieve these objectives.

5 Qualities of a Bad ScrumMaster

First, the Boss has the ability to hire and fire others.  Second, the Taskmaster myopically focuses on assigning and tracking progress against tasks. Third, a Product Manager is responsible for managing schedule, budget, and scope of the product. Next, if you are Apathetic you lack interest in or concern about emotional, social, or spiritual well being of others.  Last, the Performance Reviewer is responsible for documenting and evaluating job performance.

Summary

While you may call yourself a ScrumMaster, understand that people who understand Scrum are going to have expectations.  If you have any of the bad qualities that I listed above and in the infographic, maybe you should find someone else to do the job.

---

This was originally published on LeadingAgile Field Notes with permission of Derek Huether. See the original article here.

---