Effective Solutions Through Partnership

Category Archives: Agile

KAIP Academy Certified ScrumMaster® Training Recap

Agile, Certified ScrumMaster (CSM), KAIP Academy, Learning, Sacramento, Scrum, Training

Photo Credit: Ryan Hatcher

By Ryan Hatcher

The KAIP Academy held its first training sessions last week, delivering two successful Certified ScrumMaster® (CSM) trainings.

The truly innovative aspect of this training, led by veteran Certified Scrum Trainer Bernie Maloney of Radtac, was the overarching idea that the class members and the trainer are all active participants in a two day “sprint.” It turns out that Scrum and the Agile framework, in addition to being effective for project delivery, are also an excellent way to teach Scrum and the Agile framework.

The collaboration and teamwork inherent in the Scrum process was especially visible seeing groups of strangers quickly becoming cohesive teams capable of solving problems ranging from tossing ping pong balls through a course to building a city made of LEGOs.

At the beginning of the course, Bernie promised that we would get to know our classmates, learn, and have fun. Like an experienced Scrum team, he delivered high value on all three.

The KAIP Academy is excited to offer more training courses beginning in 2018. To stay up-to-date on future KAIP Academy course offerings, please email academy@kaipartners.com or visit the KAIP Academy course page. We look forward to passing more learning opportunities onto you soon!

About the Author: Ryan Hatcher is a skilled communications and management consultant with over a decade of experience campaigning for government, public affairs, and political clients. A recent addition to KAI Partners, Ryan serves as an executive consultant providing communications support to one of California’s heath care agencies. He resides in Sacramento with his wife, Nikki, and their two dogs.

Is the Certified ScrumMaster® (CSM) training right for me?

Agile, Certified ScrumMaster (CSM), Human Resources, KAIP Academy, Learning, Project Management, Scrum, Training

With the KAIP Academy’s Certified ScrumMaster® (CSM) training sessions taking place soon, we wanted to address some questions we’ve received about whether a CSM designation is worth it. One of our partners, Michael Bosch (Certified Scrum Professional from Brightline Solutions, Inc., a locally-based firm offering Agile Delivery and Change Management Services) answers some questions we’ve received. Hopefully these will help you if you are on the fence about getting your CSM certification! If there are any questions we haven’t addressed, please ask them in the comments—or email academy@kaipartners.com—and we will tackle them in a future blog post!

Question: I have relatively limited experience using Agile processes and I am not an “IT” person. I do business process analysis and participate in Change Management on an Agile project.) Would training to be a Certified ScrumMaster® be appropriate for me?

Answer: Absolutely. Scrum, at its heart, is what’s known as an empirical process control framework. This means it helps us figure out what needs to be done when it hasn’t been done before. Organizational change management frequently involves solving the unsolved, building incrementally and adaptively, and creating and maintaining early and constant communication with the project community. All these are honed in the acquisition of a CSM.

Question: I would likely be described as an “end user” of systems rather than a person who develops systems. Would it be useful for me to be a Certified ScrumMaster® if I’m not developing new systems?

Answer: Yes, if you find yourself leading or being part of teams that are called upon to perform what is referred to as “knowledge work, i.e., effort that requires creative, adaptive, incremental development of something that has a lot of unknowns to it. If this describes your team’s work, then having the knowledge of a CSM will help you be more predictably successful.

Question: I have learned the basics of Agile and use it on the projects I work on—how would getting a CSM help me at all?

Answer: Learning Agile in a way that it can be used to get reliable, adaptive products in the hands of clients when they need them in a way that provides real business value is constant and rewarding journey. Pursuing a CSM adds to the value of that journey; moreover, it provides a benchmark with which we can rely on a set of established, common knowledge about Scrum as a community of Agilists.

Question: I readily see the value in getting my CSM designation in my role, but I literally can’t afford to take time off from work and pay for the training costs: How can I get my employer to endorse or sponsor my training?

Answer: When I got my CSM, I ran into similar issues. One idea is to work out a bargain with your employer: you’ll take the time off as vacation if they pay the course. Another selling point to give your boss: You can provide the team/organization with a presentation of what you learned. Or, you could do some research and gather data and information (the KAIP Academy website and KAI Partners Blog are a great place to start) on the real business value, profitability, and potential for innovation represented by employees gaining their CSM.

Question: I work in administrative services but work with Project Managers and Certified Scrum Masters daily, how would being certified as a CSM myself help me?

Answer: The CSM certification provides a balanced, effective introduction to Agile and Scrum. The value this provides is exposure to the concepts, vocabulary, and mindset of an Agile framework. It would help you in understanding the difference between the approach your PMs follow as opposed to your CSMs – giving you a firm perspective on the entirety of work being performed and delivered.

Question: As a human resources professional (in a leadership role), other than understanding the language, process, and methodology, is there a benefit to me or my organization for me to be a Certified ScrumMaster®?

Answer: Agile and Scrum are human-centric and collaboration and communication dominant. In these and other ways, Agile comports with the mindsets of human and talent resource management. HR is a process-centric discipline, too—much of what is performed follows prescribed workflows. New initiatives, unusual circumstances, and expansion of business services often result in a need for an HR team to have a framework to plan, execute, and deliver on these needs that is adaptive and lightweight. Scrum to the rescue!

Question: Would having this certification make a difference in the way I perform my job functions or interact with my staff (of whom I have PMs and Agile/Scrum personnel)? From a human capital perspective, what would be the benefit (or the disadvantage, if any) of achieving this certification as a human resources professional in a leadership role?

Answer: Dedicated, committed acquisition of a CSM will result in positive changes in one’s leadership styles and capabilities. It provides an alternative to Theory X management styles, giving the HR professional a fresh look at how to govern the creation and sponsorship of self-governing, self-managing teams. Without the knowledge and practices provided by a CSM certification process, an HR professional would be unprepared to support this ever-more common organizational structure.

From HR to PM and everything in between, we hope this article helped you get the answers you need to know whether the Certified ScrumMaster® training is right for you!

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 offers Certified ScrumMaster® (CSM) training courses! 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.

Remember, KAIP Academy offers Certified ScrumMaster® (CSM) training courses! 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.

Leveraging Lean Startup and Design Thinking Startup Sac Event Recap

Agile, Conferences, Event Recap, Government, Leveraging Lean Startup and Design Thinking event, Project Management, Sacramento, Small Business, Startup Company, Technology, Waterfall


Picture Credit: Startup Sac

By Terry Daffin

The Death of the Traditional Product Development Lifecycle

When we think of innovation, we typically think of product innovation. The tangible things we use on a daily basis go through massive change in one’s lifetime.

For example, the smartphone: Does anyone remember using a rotary phone that had to stay plugged into the wall? What about music? Does anyone still buy or play LPs? Maybe the historians, a few collectors, and the staunch laggards of society still have these items around, but they have almost totally been forgotten.

Process and methodology also experiences periods of innovation. The assembly line revolutionized the manufacturing industry over 100 years ago. Kaizen was introduced in the 1980s as an innovative improvement for manufacturing and beyond. The tech industry has certainly seen its fair share of technology products.

The process for developing those products is also changing. The traditional methods for product development is far too laborious to keep up with demand and often does not meet the needs of users once the product is complete. Private industries and even some public sector departments have move to more innovative processes and methodologies to meet the demand.

I recently attended an event sponsored by Startup Sac. The event, Leveraging Lean Startup and Design Thinking, featured presenter Jake Elia, Bamboo Creative’s Head of Products and Technology.

Jake delivered an impressive presentation and provided many examples of his own startup experiences, as well as example of other startups to accentuate points along the way. I was intrigued by his description of his own life path as a “lean startup” and pivoting when needing to do so.

I started to think my own career path and compared it to the product lifecycles I’ve used over my 30-year career in the industry. Has my life/career mirrored a traditional waterfall development lifecycle? Maybe to a certain degree, but here is what I’ve come to know about life: It doesn’t follow any set process or plan. You have to be ready to make a change when the plan falls apart.

Don’t get me wrong, I’m not saying all plans fall apart, but even a minor deviation in the plan creates some sort of change that may alter the direction of the original plan. That is also the case with product development. The big difference between the traditional development lifecycles and today’s more agile or lean lifecycles is the speed in which product builds, feedback, and changes in direction occur. The increase in “speed” can be attributed to several changes/innovations in the traditional development lifecycle process itself:

  1. Clarity of the problem being solved
  2. Frequent customer involvement and feedback
  3. Simplify the minimum viable product (MVP)

In their own way, Lean Startup and Design Thinking both take into account these three factors. So, how can you use them in your next product development project? Here are my takeaways of the presentation:

Lean Startup

The Lean Startup is a methodology and book written by Eric Reis about his experiences with startup companies. Through his experiences, he saw the need to develop and document a methodology to share with others. I recommend The Lean Startup be on the reading list of anyone who has vision with a solution to a problem and a notion to engage in a startup.

According to Reis, the lean startup “provides a scientific approach to creating and managing startups and get a desired product to customers’ hands faster. The Lean Startup method teaches you how to drive a startup … and grow a business with maximum acceleration.”

The model is simple: Build, Measure, and Learn. Here’s how it works:

  • Starting with a vision or an idea for how to resolve a problem, you create a hypothesis on how the solution might resolve a problem. This step is the clarification of the problem to be solved.
  • Then you build a minimum viable product (MVP). Your MVP should focus on the main or most important problem to be solved. Know that there may be many problems to solve which means many build iterations. Resist the urge to solve all problems with your MVP.
  • Next, you must develop measurable metrics,present to customers who have this problem, record customer feedback, and use the data to learn something about your solution.

The key is using the data to make sound decisions about the path forward. Be brutally honest with yourself and the problem you are trying to solve. The data should provide you with the information to either continue down the path you are on or pivot with a different idea. You don’t want to waste time building something no one needs or wants.

The model looks like this:

Picture credit

Think of your solution to a problem as an experiment. Experiments are valuable not only to prove your hypothesis was correct, but to prove your hypotheses was incorrect as well.

Design Thinking

According to Stanford Graduate School of Business, Design Thinking is a “user-centered way to conceive and create a successful product.”

The Design Thinking model is similar to Lean Startup, however the customer interaction is at the beginning and may be a more beneficial method to use when your customer has known problem.

The model is simple and is meant to be more expedient than a traditional model because it is also iterative.

The phases of Design Thinking include Empathize, Define, Ideate, Prototype, and Test. The model looks like this:

Picture credit

  • The Empathize and Define steps are critical to making crystal clear the problem to be solved. The interviewer should probe the customer for pain points. These steps are to get to the root cause of the problem.
  • The Ideate and Prototype steps are to come up with solutions and to build an MVP. Problems are prioritized and prototypes are simplified focusing on the most important problems to resolve first.
  • Finally, Test your solution by presenting to customers and collecting feedback to be used in making the next decision on what to move forward with. Rinse and repeat!

Unlike traditional develop lifecycles, the Lean Startup and Design Thinking methodologies are highly iterative to simplify build cycles and involve frequent customer interaction and feedback to provide data for plan adjustments.

These and other innovative process improvements are becoming more and more the norm. Even the Federal government has recognized this is true in order to meet the demands of the general public. Case in point, the Federal General Services Administration created an office known as 18F to deliver “digital services” in response to the failure of the website that was developed for the Affordable Care Act.

California is also beginning to ramp up its own digital service methodologies as evidenced by the recent contract award by the California Child Welfare Digital Services project to CivicActions for development of the Department’s new system.

The traditional development lifecycle is not dead yet, but it may be on its last leg. How are you pivoting to these innovations and changes in development?

About the Author: Terry Daffin is an Executive Consultant within KAI Partners. He has worked in the IT industry for more than 30 years and has over 25 years of project management experience. As a public sector consultant in the health care industry, Mr. Daffin has assisted in the development and implementation of Project Management Offices that include project management, service management, lean agile and traditional product development lifecycles, and governance processes. He has been an innovation advocate and evangelist for 15 years and has implemented innovative processes for projects that he has been engaged on since 2001. He has worked with the California Medi-Cal Management and Information System (CA-MMIS) division of the Department of Health Care Services, California Franchise Tax Board, Commission on Teacher Credentialing, California Department of Consumer Affairs, California Board of Equalization, and California Department of Water Resources. Mr. Daffin is currently working on a project for KAI Partners to expand an existing co-working organization into an innovation incubator/accelerator focused on connecting innovative start-ups and the public sector.

next page »