Effective Solutions Through Partnership

Category Archives: Project Management Professional (PMP)

7 Smart Ways to Make Your Sprint a Success

Agile, Best Practices, Certified ScrumMaster (CSM), Corporate Training, KAIP Academy, Learning, Project Management, Project Management Professional (PMP), Sacramento, Scrum, Training, Waterfall

By Michael Bosch, CSP, PMI-ACP, CSM, CSPO

KAI Partners is excited to share a guest blog post by Michael Bosch, Agile Services Director of Brightline Solutions, Inc., a locally-based firm offering Agile Delivery and Change Management Services to public sector organizations and private sector firms.

Remember, KAIP Academy is offering two Certified ScrumMaster® (CSM) training sessions in December. For more information or to register your team and take them to the next level, click here.

Establishing all the components of an Agile framework (even a lightweight one) can be a daunting task for any organization. If yours is one that has decided to take the transformation plunge, then you’re likely planning (or have already started) your iteration cadence.

Timeboxed development periods, known as iterations or sprints (the latter promoted in the Scrum methodology), are the foundational rhythm to the “groove” of Agile. Supported by other elements such as roadmapping, release planning, demonstrations, and retrospectives, sprints are the dominant architectural feature of the Agile framework. And for good reason:

Sprints are where all the work is performed and where the innovation occurs.

The best sprint lengths are one to three weeks. If multiple Agile teams are working in your organization, the common wisdom is to have them running on a synchronized sprint schedule. The most critical aspect of running an iteration is that the team is formed in such a way that it can perform the work foreseeably asked of it, that the team is empowered and entrusted to a sufficient degree, and that the entire product community (not just the team, but everyone involved in its work) understands the mindsets, roles, and expectations required in Agile.

With that foundation in place, you’re ready to start looking to optimize your team’s sprint so that success becomes predictable. Below are seven things high-performing Agile teams do that you can use to ensure your sprints are optimized for business-driven delivery.

1. Create and Promote a Sprint Theme or Goal: One of my favorite ways to focus a team on the sprint is to ask the members to put together a headline of what is to be produced, accomplished, and attained in the upcoming iteration. I’ll ask, “If this next sprint was a newspaper article, what is its headline?” This technique allows the team to:

  • be concise and pithy,
  • create understanding amongst themselves,
  • share insights; and
  • have fun putting a “brand” on their effort to keep a sharp focus on what’s being delivered and why.

2. Encourage the Product Owner and Sponsors to Address the Team: Another stand-by technique to promote success in a sprint is to allow time for the product owner, sponsor, or both to speak to the team about why the planned work is important. Have them speak about the features that will be created and why these are important to the organization, its customers, and their users. I once had a sponsor talk to a team before a sprint about the importance of the new feature set to the world—you have never seen such commitment as I saw in that team in that timebox. Have your sponsor and product manager make the visit—the time invested can translate to delivered value.

3. Establish and Drive an Effective Product Backlog Grooming Process: Disaggregation (a term Agilists use to describe the defining a set of items that will result in the production of the whole) of the product into logical components, commonly referred to as “epics,” and the subsequent disaggregation of those epics into producible items (or “stories,” in Scrum) is the chief responsibility of the product manager (“product owner” in Scrum). This role works in close coordination with the development team, usually working with the Agile Coach (in Scrum, it may be the ScrumMaster) and/or other team members to prioritize the items listed in the product backlog, or PBL, prior to each sprint as part of its planning process.

There are several techniques that can be employed to support and mentor the work of a product manager (stay tuned for future blog posts on this topic!) and there are multiple resources on the Internet to get a good PBL up and running. The take-home message:

Make sure there is a close, communicative connection between the development team and the product owner throughout product development, and that the PBL is the central point of that connection.

4. Champion and Facilitate both Individual and Communal Commitment: A critical component of the translation of items from the Product Backlog to the Sprint Backlog (SBL) is a clear understanding on the team’s part of what each item is, how it will be produced, the criteria of satisfaction for its acceptance, and how it fits into the larger whole. As discussed above, this is fostered by a sufficiently-groomed PBL; another way to help facilitate this understanding is promoting a team-level mindset.

One of the steps in translation of items from PBL to SBL is the volunteering of team member(s) to perform the work involved in the item. This is the individual commitment necessary to produce the work. Great Agile teams, though, don’t stop there: They also commit communally as a team to all individual commitments.

To promote this, have the person(s) who has taken responsibility to produce the feature or component discuss:

  • how the feature will be produced (remember W. Edwards Deming, the father of modern quality management: if you cannot describe what you’re doing as a process, you don’t know what you’re doing)
  • what impediments may be encountered
  • what information gaps needs to be filled, and any foreseen dependencies, risks, or issues.

Then have the team ask questions, give feedback and suggestions, and (if warranted) recite back the work as described. This will ensure a critical common understanding: Not only do the persons doing the work have a clear plan, but the team also understands—and can help if needed. This adds surety that all the work the team committed to in the sprint gets done, which is one definition of a successful iteration.

5. Coach the Team in the Beginning, Coach the Individual in the Middle: As Lyssa Adkins points out in her book Coaching Agile Teams, interruptions—even in the form of well-intentioned but ill-timed coaching—can seriously impact a team’s flow during a sprint. One way to ensure this doesn’t happen is to prevent ad-hoc “mini-retrospectives,” “team teaching sessions,” and other events from occurring during the iteration. You should save that type of teaching for the planning sessions and lessons learned reviews that bookend it (see #6 for more on this topic!). While the sprint is active, it is best to keep coaching at the individual team member level, and even that should be limited to directly supporting an immediate need in the sprint.

6. Leverage the Opportunities for Retrospective: Keep your retrospectives fresh with some easy modifications: Change up the agenda, location, facilitator role, and other elements to keep your team interested and engaged. Come prepared, but be flexible—I usually come to a retro with an agenda in mind (for example, something observed during the sprint that indicates a need for review of an Agile principle), but I check with the team first to see if there’s something they’d rather review. Check with the team on where in the Sprint cycle they’d like their retrospective. Many teams like to hold it directly after the review, some like to do it just before, still others like to wait until just before the beginning of the next iteration. Find what works for each team, but continually impress the importance of the retrospective. It is more than mere ceremony—it is a vital step to allow your team time and space to reflect on the past iteration in order to improve future ones.

7. Foster Urgency and Fun: One of the most productive aspects of an Agile production environment is the consistent, predictable, confining nature of timeboxed development. It creates a sense of urgency that can almost be sensed, like a feeling in the air. The regular performance of sprints helps with this—it creates the downbeat that helps everyone stay (or get back into) rhythm. It is the chassis on which the other elements of the Agile framework are attached (as they owe their intrinsic value to the sprint itself).

Foster that sense of urgency in your teams, but balance it with the need to maintain a sustainable pace. Moreover, make sure that your team is having fun! Agile is fun—getting things done that provide needed value to our customers quickly is intrinsically rewarding. Let that shine on your team in whichever way you find works—they will reward you with sprints jam-packed with innovative product delivery!

About the Author: Specializing in transformation and disruption services for companies looking to improve, Michael Bosch has been providing high-value delivery services for more than 15 years. An Agilist with more than 10 years’ experience in the incremental development of complex digital solutions, Mr. Bosch has served as a Scrum Master, developer, and Agile coach for multiple sectors and lines of business, is a recognized Agile services technologist, product developer, and staff development expert. He specializes in creating breakthrough, team-empowering, lightweight communication and delivery frameworks for organizations of all sizes. Mr. Bosch is a Certified Scrum Professional (CSP), an Agile Certified Practitioner (PMI-ACP), a Certified Scrum Master (CSM) and Product Owner (CSPO), and an accredited Project Management Professional (PMP). He holds multiple degrees, including a masters in computer information systems. He has served as a professional trainer and speaker for more than a decade and is a published author and regular contributor to multiple information sources.

5 Steps to Building a Successful Agile Development Culture

Agile, Certified ScrumMaster (CSM), Corporate Training, Healthcare, KAIP Academy, Learning, Project Management, Project Management Professional (PMP), Sacramento, Scrum, Training, Waterfall

By David Kendall

Software, and for that matter, product development of any kind, has historically been described as a conflict between three primary constraints: Time, cost, and quality.

The missing component to this description is the labor, i.e. the people involved throughout the product development lifecycle: There is a business need identified by the customer, an analysis is required to be completed by an analyst to convert the business need into a product solution, an engineer needs to convert that conceptual solution into some type of prototype which is then tested by another engineer or analyst, and finally an implementation specialist needs to ensure that risk has been mitigated to an acceptable level to present to the customer. Oh, and let’s not forget the customer needs—to experience business value once that product begins production—especially when evaluating the cycle success criteria.

All steps towards building a successful Agile development culture, including those outlined below, require that people be involved, engaged, transparent in communications, and aligned in their expectations.

The irony is that the conflict between time, cost, and quality cannot be optimized unless the culture that the people involved are working in empowers each of them to do their best work, to be accountable for their actions, and to do it in a timeframe that delivers business value throughout the product development lifecycle.

Rigorous application of the Agile principles and values through culture development is a powerful approach to empowering your workforce to do their absolute best work. Below are some of my tips to building a successful Agile development culture in your organization:

Step 1: Decide why (and when) you need Agile Methodology. The “why” part is straightforward: Agile will help you deliver your organization’s highest priorities faster—and more efficiently—than the conventional waterfall methodology. The overall Agile approach eliminates the need for finishing a project or product completely before moving on to the next iteration or dependent deliverable, allowing you to be more flexible with your input and output processes, and facilitating activities in shorter time frames that are much better suited to anticipating and mitigating changes along the way.

Agile methods work best when you are looking to break development down into small increments to shorten or skip up-front planning and design review processes. These small increments or sprints, as they are known in Agile circles, are typically set in one to four-week periods.

Step 2: Set goals for your organization that are compatible with Agile Methodology. If you don’t need the project or product urgently, then Agile methods should not be necessary. Of course, defining what is urgent isn’t always easy—especially when mission-critical operations or contractual obligations are factored into the schedule. Regardless, goal-setting can only be successful with disciplined and prescriptive analysis in hand. And ranking the highest priorities for your organization requires real-world experience as well as well-trained support staff.

Step 3: Equip and empower your Agile Methodology team. Once you have decided that you are going to use Agile Methodology and set the goals that it will help you achieve, you need to equip and empower your staff with the training and tools necessary for them to be successful. For example, investing in Certified ScrumMaster® (CSM) training for the members of your project management and product development teams ensures a common understanding and the practical application of a rapid-process development cycle, which will pay dividends in the form of production efficiency and time-savings.

KAIP Academy is offering two Certified ScrumMaster® (CSM) training sessions in December. For more information or to register your team and take them to the next level, click here.

Step 4: Establish performance metrics and review your Agile Methodology practice continuously. Agile Methodology is designed to drive processes efficiently. Sprints are designed to help teams work collaboratively. Scrum teams are designed to create learning opportunities for individuals to prepare them to adapt to change—quickly. All outcomes from the Agile activities should be measured to ensure that the organization is optimizing the investment of training and tool sets on a continuous basis.

Step 5: Promote Agile Methodology with your staff, clients, and within your vendor community regularly. With purposeful planning, policies, procedures, and processes, Agile Methodology will become an integral part of your organization. By adding thoughtful and regular communication—promoting and reinforcing of the rapid-process development cycle principles and benefits—to both internal and external stakeholders, Agile Methodology will also become a pillar of your resource planning, new business strategy, and partnership programming. In short, it will become an integral part of your culture.

For more information on putting Agile Methodology to work for you, check out the following links:

Values and the 12 Principles of Agile
Agile Model & Methodology: Guide for Developers and Testers
3 REASONS WHY AGILE WORKS

When not to use Agile

About the Author: David Kendall is the President and Managing Director of KAI Partners, Inc. A Senior Information Systems professional with 30 years of experience leading Information Technology (IT) program and project teams focused on enterprise-wide solutions, Mr. Kendall began his career as a member of the United States Air Force working in Electronic Warfare. With an honorable discharge and a degree from the University of Maryland in Information Systems Management, Mr. Kendall moved into the Health and Human Services sector performing roles with increasing responsibility and complexity within the health care field. Mr. Kendall’s current work includes advising one of California’s health care agencies as a Senior Project Manager and Program Integration Manager.

What the KAI Partners Team is Thankful for in 2017

Communications, Data Management, Employee Engagement, General Life/Work, KAI Partners, Organizational Change Management (OCM), Project Management, Project Management Professional (PMP), Prosci, Sacramento, SAHRA—The Sacramento Area Human Resources Association, SHRM, Small Business, Team Building, Training


From the KAI Partners team to yours, we wish you a happy, healthy, and stress-free Thanksgiving holiday.

Consulting Survival 101: A Project Manager’s Perspective

Best Practices, Managing/Leadership, Project Management, Project Management Professional (PMP)

By Jamie Spagner

Those of us who have worked in the corporate world—or any type of workplace, really—for an extended period of time know that longevity is not a guarantee. Your job within a company may change due to corporate restructuring, personnel/job role updates, or any number of other factors.

A silver lining may be consulting. For many people, consulting is a logical step to extend a successful career. If you have worked in project management positions throughout your career, transitioning to consulting may be able to provide you more freedom and flexibility, as well as the opportunity to offer your expertise to the people and organizations who need it the most.

It’s easy to believe that your decades of experience and the various letters—PMP, CSM, SHRM, etc.—after your name will be all you need to prepare for this exciting new chapter. Of course, it’s not always so simple.

After 15 years in the corporate world—and six of those years consulting—I’ve discovered some lessons that most consultants learn the hard way:

  • Do not take things personally: As human beings, we are emotional. One of the best things I have done to improve overall satisfaction in both my personal and work environments is learning not to be governed by my emotions. As a project management consultant, part of my job is making recommendations; sometimes these recommendations are followed and sometimes they are not. Either way, I try to be more logical and less reactive to the way a situation makes me feel.
  • Humility over hubris: There will be times when you know more than your client, but boasting about this is rarely a good idea. As consultants, we are teachers, not show offs. Timing is everything—use your intelligence to know when to show your intelligence.
  • Practice patience: Organizations move at different speeds and as a consultant, we advise, but rarely get the chance to set the pace. Be patient and stay engaged—this way, you will have more impact ensuring the final decisions your client makes are the ideal.
  • Trade in your ‘Nos’: As a consultant, you should be prepared to offer an alternate solution to your client, rather than immediately telling them ‘no.’
  • Champion your client:Consultants should support and champion our clients’ successes, not take credit for the wins. Remember, when people say a home looks lovely, it’s the homeowner who takes the credit, not the architect.

Practicing these tips may not guarantee your success in the consulting world, but they may help keep your sanity, and, quite possibly, your job. Remember, these are just recommendations, so use them or don’t—I won’t take it personally (she said, taking her own advice).

About the Author: Jamie Spagner is an Executive Consultant for KAI Partners, where she works as a Project Manager for a public sector health care client. She graduated from California State University, Sacramento with the Bachelor’s Degree in Communication Studies/Public Relation. She is a loving mother of a teenage son named Wyatt. In her spare time, she enjoys shopping, spending time with family/close friends, and working out.

How to Use Problem Statements to Solve Project Issues

Best Practices, Issues and Risks, Problem Statements, Project Management, Project Management Professional (PMP)

By Stephen Alfano

Who doesn’t have problems? Now, a real question: Is there a simple, surefire, and quick way to break problems down?

Answer: Problem statements.

A problem statement is basically a short, yet compelling description of an issue, or set of issues, that must be resolved. It’s used by problem-solvers of all stripes—from research scientists to project managers to postgraduate students—to drive an effort from beginning to end to ensure and validate an anticipated outcome (not a problem with a well-written problem statement!).

How do you write a problem statement?

I recommend carefully breaking the problem—and the undesirable world it lives in—into three basic components:

  • Vision – This is the description of the anticipated (desired) outcome. Think of it as a view of the future with the changes that will result from the issue(s) being resolved.
  • Issue(s) – This is the description of the problem using a narrative derived from real-world experience (e.g., use cases or test results). It’s usually only a couple of sentences in length and straightforward and concise in tone and manner.
  • Method – This is the description of how the problem (and issues therein) will be resolved. It’s often prescriptive language—sometimes filled with jargon—that helps the problem-solvers map out their path to success.

Of course, there’s a great deal of background detail and mitigating factors that must be condensed to create those three basic components. (We’re talking about a scaling down a small mountain of data and accompanying data analysis into a couple of paragraphs.)

Truth be told, problem statements can be problematic. The input isn’t always neatly packaged. It often comes from structured and unstructured sources that need to be identified, categorized, prioritized and, in some cases, synthesized to establish the following:

  1. the root cause of the problem
  2. the known consequences of the issues that users (and key stakeholders) both up and downstream face
  3. the ill-effects associated with the known consequences
  4. the myriad assumptions and constraints (the pros and cons) within the method used to resolve the issues

Above all, problem statements require persistence and patience. Distilling and editing the content to be clear and concise takes rigorous work—and lots of practice using a tried and true template.

Below, you’ll find links to some of my favorite problem statement templates and best practices:

How do you think problem statements could help your project mitigate issues and achieve success?

About the Author: Stephen Alfano is an Organizational Change Management Consultant and Communications Expert. He has over 25 years of experience leading and managing internal and external marketing initiatives for both private and public-sector clients. His résumé includes providing both new business and business process improvement services to Apple, American Express, AT&T, California Department of Transportation, Chevron, Entergy, Levi Strauss & Co., Louisiana Office of Tourism, Mattel, Microsoft, Novell, SONY, Sutter Health, and Wells Fargo. Stephen currently works as an Executive Consultant with KAI Partners, Inc., providing change management and communications expertise and support services to California State Departments.

next page »