Agile Baltimore on March 2, 2018

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.

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.

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.

---

I Discovered a Productivity Pattern

My Past Experience

The Internet is littered with a million improvement patterns. In my many years of attempting to improve productivity for my clients and myself, I’ve tried just about everything. Regardless if the post, podcast, or book is promising to do twice the work in half the time or that you can cram an entire work week into 4 hours, there is something out there for everyone. My first venture into this productivity-focused world was way back in the early 90s, when I watched this horrible movie titled Taking Care of Business, starring Jim Belushi and Charles Grodin. In the movie, an uptight advertising exec has his entire life in a filofax organizer which mistakenly ends up in the hands of a friendly convict who poses as him. The movie is still horrible but the organizer idea seemed to work for me.

Franklin Covey Planner

From this movie, I discovered the Franklin Covey Planner. Yep, my world was filled with A1, B1, C1’s. Alas, I couldn’t make it work. Much like the guy in the movie, everything was in a little leather book with special pages (that were not cheap). Unfortunately, if I didn’t have the book in my field of view to constantly remind myself, things didn’t get done. I think I lasted a year, until I discovered the cost of refilling the book with new pages.

GTD

I then discovered GTD (Getting Things Done) by David Allen. This was 15–20 years ago. Again, it worked for a little while but I then found myself doing too much organizing and too little doing. Things were going away from paper filing and everything in that system was all about paper filing. Maybe I was doing it wrong. It just wasn’t clear to me. I didn’t see any real progress or productivity improvement so I just stopped doing it.

Personal Kanban + Pomodoro Technique

In mid 2009, in a moment of Internet serendipity, I ventured into the world of Personal Kanban. I think I searched “Zen” and up popped a website for a Kanban tool. I started using it and loved it. Alas, that company got purchased by Rally and they are no longer taking registrations. But, this has become the first system I have been able to stick with. Just to try other tools, I soon switched over to LeanKit Kanban. I’ve been using it ever since. I like that it doesn’t make any promises it can’t keep. “Visualize your work, optimize your process and deliver faster”. Around the same time in 2009, I also began using the Pomodoro Technique to optimize my productivity.

LeadingAgile Transformation Framework

In 2012, I joined LeadingAgile. Though we didn’t have a defined system at the time, a Transformation Framework emerged.  Since that time, when the system is followed, it works really well.  When things don’t work so well, the same failure patterns are present.

Productivity Rosetta Stone

So, why do some methods work and some do not? Why did I abandon the Planner and GTD systems so long ago but still use Personal Kanban and the Pomodoro Technique? Well, I started by listing common traits on a whiteboard and saw relationships and discovered some patterns. Not only are there three things I believe every productivity system needs to work, I also see three things that are necessary to prevent you from abandoning that system.

I describe it as a Productivity Rosetta Stone. For those unfamiliar, the Rosetta Stone is a rock slab, found in 1799. It was inscribed with a decree that appears in three scripts: Ancient Egyptian hieroglyphs, Demotic script, and Ancient Greek. The stone presents essentially the same text in all three scripts and provided the key to the modern understanding of Egyptian hieroglyphs. I’ve applied my productivity Rosetta Stone to Scrum, Kanban, Pomodoro Technique, Lean Startup, and even organizational transformation frameworks. All of them check out and it provided me with a key to better understand productivity patterns.

3 Things to Increase Productivity

1. A system is a set of principles or procedures to get something done or accomplished; Anyone can follow a system.

2. A ritual is a series of actions or type of behavior regularly and invariably followed by someone. It’s different from a system. A system might only be followed once, but by many people. A ritual is something someone or some group does again and again, in the hope of arriving at the same or improved outcome.

3. A habit is a regular tendency or practice, especially one that is hard to give up. If you want to be productive, you have to be habitual with your rituals, as part of your system.

How does it all fit together? Name a system. Next, list your process steps, sequence, and any rules around them. Last, do the steps again and again until it becomes a habit.

Lack of These Kills Productivity

Clarity, Progress, or Commitment

1. Clarity is the quality of being certain or definite. You need clarity in order to know what you need to do. Lack of clarity creates confusion and waste. Each step of a system should be actionable and repeatable. In order to ensure certainty around your steps, write them down; maybe draw a picture or diagram. If your outcomes are not repeatable, you have an experiment but not a system.

2. Progress is forward or onward movement toward a destination or goal. Your goal is productivity. 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.

3. Lack of commitment to the system results in you no longer using the system. You move on to something new to get the productivity results you seek.

In the event your system lacks clarity, progress, or commitment, performance will go down or you’ll stop using it all together.

Scrum

Enough with the  nebulous ideas. Let's apply the patterns against the Scrum Framework.

Jeff Sutherland and Ken Schwaber did a pretty darned good job providing clarity around the system in The Scrum Guide.  Being the Guide is only 16 pages long, there it's a whole lot to it. It includes a definition of Scrum, the theory behind it, and then provides details behind teams, events, and artifacts.  That's it!  Rituals (events) include sprint planning, a daily (15-minute) Scrum, a sprint review, and a retrospective.  Each of these rituals helps provide both feedback and progress within the sprint.  To ensure we see the progress, we timebox sprints, commit to deliver product increments regularly, and use information radiators like burndown charts to visualize the completion of work.  Like any system, if you are not habitual about each of the items within the Scrum Guide, Scrum falls apart.  That means commit to the system and be consistent, sprint after sprint.

Summary

Though I have only provided a conceptual model, try applying it to your personal system. Like in any productivity strategy, once your defined system becomes habitual, you can start to focus on improvements. Maybe you want to do more in less time. Maybe you want to do the same with higher quality. You be the judge. It’s your system. Remember, you’ll still need clarity, progress, and commitment or your productivity will be short lived.

Listen to Dave Prior and me in an episode of LeadingAgile Sound Notes, as we talk about the Productivity Triangle.

If you want an editable copy of the triangle, download it here: productivity triangle template

One final note. It would mean a lot to me if you could leave a comment and tell me which design you like more. Do you like the colorful Venn diagram look or the black and white triangle?  Please tell me in the comments.  Thanks!   ~Derek

Karaoke Agile

Have you ever gone out with your friends to a karaoke bar and watched someone, who did not speak English, sing the best Bon Jovi Livin on a Prayer you have ever heard, just short of seeing Bon Jovi live back in 1987?  I've seen both.  Have you ever worked with or for someone who follows a process or framework to the letter but does not have the first clue why they are doing what they are doing?  Again, I've seen it. The major difference is one is singing a song for personal entertainment and the other is potentially wasting time, money, and putting projects or product delivery at risk.

Cargo Cult

The name is derived from the belief among Melanesians in the late 19th and early 20th century that various ritualistic acts such as the building of an airplane runway will manifest in the appearance of material wealth, particularly cargo, via Western airplanes, though the meaning of the behavior is more complex than a simple misunderstanding. That mouthful is brought to you from Wikipedia.

I hear cargo cult referenced a lot in the Agile community.  I've been to half a dozen Project Management conferences and never heard the term once. I've been to an equal number of Agile conferences and heard it used every time.  We reference it all of the time, referring to the rituals of Scrum, SAFe, and other frameworks.  People memorize the frameworks but don't know why they are doing the rituals. They have little hope of improving upon a framework, if they follow rituals blindly.

Agile Translation

I recently wrote that the Agile community should consider using terms anyone understands.  If I said cargo cult, I would have to spend the next few minutes quoting what I wrote above, to explain it to a customer.  It could make you feel smart, needing to educate someone on a new term.  But, why not use a new term like karaoke agile?  First, I know the Agile community LOVES to use Japanese words.  With a Japanese word origin, from kara empty + ōke, short for ōkesutora orchestra, practitioners should be all over this!  For better or worse, I don't know anyone who doesn't know what karaoke is.  This includes anyone outside the Agile community.

Karaoke Agile

Combine words of Japanese origin and the word Agile.  Stop using the term cargo cult when describing people or organizations that follow processes or frameworks without understanding why they do it.  Win-Win.