2017 Rise Up Dinner – ROOTS Young Adult Shelter

Plaster Group is honored to have sponsored Seattle’s ROOTS Young Adult Shelter fundraiser Rise Up for the 5th year running, celebrating ROOTS’ anniversary as an 18 year-old organization.

It has been wonderful to watch this event grow from its inauguration.  In the face of rising concerns over Seattle’s homeless crisis, it is incredibly important to support organizations like Roots. Please visit the ROOTS website to find out more about how you can volunteer or contribute in other ways.

 

Check out ROOTS’ Impact

  • It takes $86 in resources to host a guest for a night – but $44 is covered by in-kind donated food and labor
  • 32,400 hours of labor are donated annually for Friday Feast and shelter by ROOTS volunteers
  • ROOTS Supplies 16,000 “bednights” or stays by young people every year
  • 92% of young people without stable housing polled during the 2017 “Count Us In” survey identified employment as their top goal
  • ROOTS washes 2,300 loads of guest laundry and provides 8,600 showers annually

Do you have any Items on ROOTS’ Wishlist?

  • Full-size bath towels
  • Nail clippers
  • Boxer shorts, undershirts, socks (new)

Plaster Group Book Club – Getting Naked, a Business Fable

by Mike Fernandez, Sr. Business Intelligence Consultant

Book Overview

In “Getting Naked”, Patrick Lencioni presents a consulting approach that maximizes value to the client while emphasizing the role of a consultant as a true servant to the client company. He does this by relating a story of how Jack, a senior consultant at Kendrick and Black (K&B), is pushed into a completely different company culture at K&H’s recently acquired company Lighthouse Partners (Lighthouse).  Jack has had a somewhat adversarial relationship with Lighthouse in the past and he is not initially interested in learning about or applying their methods.

During the story, Jack is exposed directly to the way that Lighthouse works and the attitudes that their consultants bring to their clients, an approach developed over time through discussion, observation and application.  Jack’s journey is not an academic one – his insight and growth come from working with Lighthouse consultants at client sites and from personal experience.  At one point, he has several “teachable moments” as he leads a project using the Lighthouse approach.  Jack goes from a biased outsider to a full participant – and as he progresses, he learns to appreciate the results of the different approach. As a result of his new knowledge and viewpoint, Jack creates a model for the methodology and approach.  He then has the opportunity to present this model to colleagues at K&H and gains some converts along the way.

So, what does Jack learn?  The final section is devoted to an overview of the model that’s used by the author’s real-life consulting company, which he calls the Three Fears.   These are available in graphic form at Patrick’s website (linked at the end of the article).  Simply reading the list can provide some info, but the true value comes from reading about Jack’s journey –  which provides the necessary context to truly understand the reasoning and value behind this approach.  That said, here are the primary points of the model…

The Model

The Three Fears and strategies to avoid them:

1) Fear of Losing the Business – the customer needs to know that we’re there to help them; avoid making our primary goal maintaining or increasing our revenue stream

  • Always consult instead of sell
  • Give away the business
  • Tell the kind truth
  • Enter the danger

2) Fear of Being Embarrassed – avoid letting a lack of complete expertise in a client’s business or scenario result in not finding and following important but perhaps not obvious information

  • Ask dumb questions
  • Make dumb suggestions
  • Celebrate your mistakes

3) Fear of Feeling Inferior – don’t allow the need to be an “important consultant”, with certain role and duty expectations, override service to the client and acting in the client’s best interest

  • Take a bullet for the client
  • Make everything about the client
  • Honor the client’s work
  • Do the dirty work

A mindset that will help with all of the above is to always be willing to admit your weaknesses and limitations.

The Reviewer’s Experience

I found the book to have a strong message worth examining by the modern consultant – that as consultants, our purpose and focus should be on the client and what helps them.  Following this approach may take us out of our comfort zones, but a quality and appreciative client can be our best advocate.

For those having difficulty with the idea of not selling their services, the story relates that having happy clients can be the best source of new clients – and that by focusing on consulting directly with the client, rather than spending time on sales, “Those clients in turn became a sales engine for the firm…and it was references from clients that shortened the sales cycle considerably.”  Jack’s chapter titled “The First Fear” explains that “…It’s about building trust.  And in the end, that means the client trusts them and takes care of them.”

I find the second fear to be a challenge – as a consultant, not being the expert in everything.  Although not my first inclination, the times I have stepped back and asked the basic questions about specifics or situations , I was rewarded with a better understanding and with an excellent relationship with my client.  This chapter provided even greater incentive to continue doing this.

The third fear, as the book notes, can be a subtle variation on the second fear, but it is different.  The third fear relates to doing what needs to be done, regardless of what type of task or role it requires.  My experience, like the author’s experience, is that doing some things not normally associated with the role of “Consultant” has been more instrumental in moving projects and deliverables forward than other more “high level” activities – at the right times.

I feel that this book will provide insight to a different approach that can help consultants and non-consultants build better professional relationships.  This book can get you started, but as they point out, “…there is a big difference between understanding something and putting it into practice.”

Interested in learning more? Pat’s website contains information on this book and others.

 

Plaster Group Volunteer Day – Q3 2017

One of the most popular suggestions to improve our workplace environment on last year’s employee satisfaction survey? That Plaster Group should volunteer our time somewhere as a team. So we took our consultants up on their suggestion and did just that.

Did you know 1 in 5 Washingtonians relies on their local food bank? This Saturday, Plaster Group consultants and their families were warmly welcomed by Northwest Harvest, the only nonprofit food bank distributor operating statewide in Washington. With a network of 375 food banks, Northwest Harvest is able to feed a family of three a nutritional meal with only 67 cents due to the work provided by volunteers. We had a great time getting a mountain of beans packaged through coordination and teamwork!

Plaster Group is one of Washington’s Best Places to Work!

Plaster Group has been a finalist on the Puget Sound Business Journal’s WA Best Places to Work three times, and last Thursday we were recognized as the second best medium-sized company to work for in Washington. We are very proud of this distinction as we consistently seek to serve our Consultants, our Clients, and the Community. Read more about why we are one Washington’s Best Places to Work here

Agile Nirvana

by Shama Bole, Sr. Agile Consultant 

Growing up, I remember being told the story of a village boy in India who, at a very tender age, wrote a famous treatise summarising his meaning-of-life philosophy and conclusions, and in the wake of that, sought samadhi (death via unending meditation) in a nearby cave that he requested be sealed thereafter. (He has been revered as a saint since the 13th century.) Apparently, life held no more questions, surprises, puzzles worth the pondering.

Unfortunately, people with a similar degree of certitude about their adoptive philosophy are rarely obliging enough to hibernate in meditative solitude. Instead, they evangelise. Nowhere is this truer than in the Agile landscape. (Well, that’s an exaggeration, given the torridity of political and religious evangelising, but it makes my point.)

I think this rather stream-of-consciousness article/gripe was borne out of some frustration with Agile converts and sometimes uninformed zealotry (which sounds breathtakingly presumptuous, I know). But, hear me out.

Art, Not Science

Agile, like project management, is more an art than science and draws more than its share of argumentative fanatics. (This may explain why physical science practitioners seem saner since they deal with absolutes, though Copernicus, Galileo et al might have deeply ironic posthumous thoughts to share on that). Art seems to have a greater margin for opinions and ambiguity and that may be the source of so much dissent within the ranks of Agilists. Natural science absolutely has its own paradigms but there is a grounding in theory and empirically measurable outcomes that is extremely challenging to achieve outside of the laboratory. Agile is very much about people, and relationships are messy things. There is no science around resolution and no clear path to some universal truth, as may be found in managing budgets or PNL statements. Dialectics is critical to intellectual progress but Agile thinkers often seem blind to all views but their own.

Unchecked Passion

Sounds thrilling, doesn’t it? Not quite. My company is often engaged to effect Agile transformation, and we’re always looking to bring on folks who can accomplish that. When hiring, we look for not just competence and expertise but also a level of polish combined with amicability. Inevitably, “a spoonful of sugar makes the medicine go down”, one of the harsher truths in life being that any kind of change is easier when shoehorned by someone personable. It’s not the strength of one’s convictions that sells but rather the efficacy of one’s approach. I’m sure this is true in matters of the heart as well! Too many Agilists seem to forget/ignore this principle and indulge in passion unchecked by any veneer of professionalism.

Old Wine in New Bottles

A lot of Agile presentations and written material is essentially nothing more profound than old wine in new bottles. I saw this in graduate school, where we students floundered for a dissertation topic on which to make our mark in academia. It wasn’t about original thinking, but rather about leveraging intellectual capital to launch oneself out of obscurity.

To illustrate this: at one of the conferences I attended, an Agilist gave a talk predicated on the notion that there were no values prescribed by Agile. To me, that seemed a case of not seeing the forest for the trees. Agile is a philosophy, a set of values and a suggested way of interacting with the world. It’s a directional compass and a behavioural guide. No values?

More Emotional than Cerebral

To a lot of practitioners, Agile philosophy comes as epiphany, and I don’t use the word lightly. After all, what comes to your mind when you think of epiphany? To me it is the image of Archimedes shrieking “Eureka!” as he ran through the streets of Syracuse, naked from his bath, in a state of mental elevation that obliterated everyday habits of common sense and rational behaviour … a possibly apocryphal tale but who cares? What a great story!  Adopting Agile is beyond just methodology – it is an inner transformation that engages one’s passions and beliefs and value systems. To me, that puts it outside the realm of a purely cerebral exercise in project delivery. Some of the fallout/passion is attributable to that.

Hubris

Other than (excess) passion, Agilists also tend to suffer from an excess of certitude and a tendency to dismiss everyone else’s opinion and store of knowledge. I’ve seen CVs posted where Agilists proclaim themselves “Masters” of Agile. Where does this hubris come from? I listened to a hilarious segment by a stand-up comedian who explains the inexplicable success of political rhetoric/pap with the following theory: people tend to see as truth (only) what they can in fact understand. However, truth can and often does come in complex and no-directions-provided packages as well. Interestingly enough, though, understanding Agile is not hard. Implementing it is tricky. The best (Agile) coaches I know are humble and genuinely put other people and their interests first. They get it.

Low Entry Point

Because Agile reads as easy, one other big casualty has been the entry of unqualified and unsuitable practitioners into the field. Maybe this is akin to why there are so many charlatans in what is called “alternative” medicine such as homeopathy and acupuncture. There are a lot of ways and reasons to explain away why outcomes are not as expected. Of course, it is circular reasoning that if Agile were practiced correctly then outcomes could always be predicted (as desired). This is why it also baffles executives who are interested only in outcomes – totally understandable – and have only a foggy conception of what Agile means. And proceed, therefore, to harry and micromanage it to death.

Team-Building, not Reputation-building

Finally, to me a good Agile coach is like a parent. It’s the daily little disciplines and acts of patience, humility (and dare I say) suffering that brings together a community of people embarked on a convergent goal. It’s not about making your mark via displays of bombastic self-virtuosity.

In conclusion: I picked the term “nirvana” almost unconsciously, but I think one aspect that calls to me is the constant striving. To be better, to keep trying, to never rest on one’s laurels. And liberation from painful habits and practices that keep us chained to mediocrity and hamper self-actualisation. (The term “best practice”, which is bandied about with unctuous glee, also makes me cringe nervously.)

Agile nirvana is a lofty ideal but one where the journey is as rich with rewards as the destination. And, my respects to the (very few) coaches who make trustworthy companions on this sojourn.

Unsure of how to begin  your journey to Agile nirvana? Our experienced Agile Team would be happy to provide you with a guide!

Designing Customer Experience

picture of limo with focus on tire

by Doug Ugarte, Supply Chain Consultant

Designing and managing customer experience is a lot like chauffeuring your customer safely to their destination, when suddenly you have a flat tire… on the highway… at night… and have only a crescent wrench and flashlight to replace it. Did we mention that during this process, your customer should be relaxing in the backseat, blissfully unaware of the mission-critical upgrade you are performing under a constrained schedule? If you’re involved in designing or supporting customer experience, you’ve probably contributed to the Herculean efforts that go into producing delighted customers.

Whether your role sits in Supply Chain, Marketing, or Customer Service centers, a tremendous amount of focus is applied to the design and management of customer experience.  Interestingly, we see each of these teams having varying degrees of ownership of designing customer experience, crafting solutions, implementing services, and managing toward a predictable and reliable result.  How are you approaching the customer experience?  Did you take an iterative approach based on customer feedback and/or competitive benchmarking?  Or did you begin with a vision of the end to end experience and implement a solution to support it?

If you expect your customer to choose you for their next purchase, it is paramount that you deliver on your customer experience promise.  Regardless of your product or industry, customers expect and demand flawless execution.  eCommerce customers expect to know when their product will arrive before they even purchase it.  After purchasing it, they want to know that it shipped on time, who is delivering it, its transit status, and that it arrived…all in real time.  Manufacturing and commercial customers rely on you to deliver on your promises so that they can meet their own customer commitments.  You fail once and you might get a second chance.  You fail twice and you’re done.

Different departments could have ownership over designing customer experience.  It may be Marketing because this could be a branding function at your company.  It could be the Customer Service group because they are closest to managing the reality of customer experience.  Or it may be your Supply Chain organization because most of the building blocks of the solution align to their charter.  Regardless of the owner, a successful customer experience requires these teams to perform in concert to decide what to implement, execute the solution, and drive continuous improvement.

To be successful, you must have these core competencies:

  1. Know what you can promise
  2. Clearly articulate the experience that the Customer can expect
  3. Keep your customer informed of progress of their purchase
  4. Deal with issues as soon as they arise. Reset customer expectations if you are unable to resolve the issue behind the scenes

Looking at the list of core competencies, everything falls into one of two themes – external customer communications or internal operations – that determine what can be promised and the certitude of delivering on that promise.

If you pull back the curtain at leading supply chains, you will find a customer promise that is built on knowing that product is available, how long it will take to ship, and how long it will take to arrive at the customer’s doorstep. The building blocks of these core competencies comprise the following strategies:

Formulate your Customer Promise

  • You can have a customized promise to each customer based on real time supply chain insights. Alternatively, you can provide a static offer to all customers and the offer can be adjusted if there are constraints affecting delivery.
  • Inventory Availability – You have unreserved and unrestricted product to ship.
  • Logistics – Calculate time to delivery. Based on ship from/to addresses, calculate delivery commitment based on customer-determined shipping service level.
  • Fulfillment Center – Visibility to operational performance. If SLAs are not being met, you might need to adjust the customer promise up front rather than apologizing for a missed commitment.

Visibility to Execution

  • Integration across all internal and external partners designed to provide real time visibility.
  • Integration should tell you 1) you have a problem, 2) what problem you have, 3) the scope of the problem, and 4) what time it occurred. Visualization tools help you see the issue and if it is growing.
  • This is where “batch” processing becomes the enemy to customer satisfaction. For every minute you don’t know about a problem that has already started, you diminish your ability to fix it without impacting the customer.

Exceptions Management

  • Identify your most common problems and incorporate automated exception handlers to resolve problems before they impact your customer experience. Examples include: Automatically upgrading your shipping service level from 2-day to Overnight because the fulfillment center is a day late. Or, automatically sending a replacement shipment if the logistics provider system shows the item lost or damaged in transit.
  • If you cannot meet your customer commitment, reset expectations based on real time insights (same logic as formulating the original promise). Automated messaging keeps your customer informed and reduces the strain on customer service resources.

Leverage data insights from your Customer Service organization for feedback on how customers feel about your designed experience and how reliably you are meeting it.  Social media analytics can offer additional visibility to what is being said about your company, your customer policies, customer experiences, and more.  You should also assess your competition to understand what you’re up against.  From competitive analysis, social media analytics, and customer feedback given directly to your company, you can garner a good understanding of purchasing drivers, how customers view you versus your competition, and how customer perception aligns to your designed customer experience.  The more granular view you have into the systems and partners involved in the end to end experience the better you will be able to 1) compare customer perception to reality, and 2) evolve your supply chain to be more closely aligned with the reasons customers buy from you instead of your competitor.

Customer experience requires close collaboration between departments that sometimes measure success quite differently.  It requires a complex technical solution to align directly to the customer experience design.  The weakest link is frequently access to real time data, so systems integration becomes a prerequisite for success.  Lastly, with the solution deployed, leverage every source of customer and market insight to understand if you’ve implemented the right design relative to both customer desires and the competitive landscape.

Lean Business Analysis 

By Heather Smith,  Consultant

As companies try to do more with less, Lean is still growing in popularity. The Japanese manufacturing philosophy from Toyota emphasizes cutting waste and boosting efficiency. Other industries often struggle to adapt Lean to their processes. This is because Lean was developed as a system to eliminate waste in automotive manufacturing in the 1960’s. Today, Lean is evolving into a management approach to improve operational effectiveness (Kovacheva, 2010). However, because Lean methods were developed in the manufacturing industry they often need to be adjusted to fit other processes—like business analysis. Put simply, “Lean business analysis is about doing the right thing at the right time and removing things that don’t add value” (Saboe, 2016).

It makes sense business analysis would use Lean to create efficiency and eliminate waste. The International Institute of Business Analysis (IIBA) – the organization responsible for defining the profession – calls business analysis “the practice of enabling change in an organizational context, by defining needs and recommending solutions that deliver value to stakeholders” (IIBA website). By definition, both Lean and business analysis involve examining and refining business behaviors and processes. In this article, I explore how Lean relates to business analysis in the technology sector.

Lean identifies several types of “muda” or waste (see the table below). The column on the left lists traditional/manufacturing definitions of waste. At a glance, none of these seem applicable to business analysis or software development – the column on the right shows how those wastes are defined in a software development context.

The Seven Wastes of Manufacturing The Seven Wastes of Software Development
Overproduction Partially done work
Inventory Extra features
Extra processing Relearning
Transportation Handovers
Motion Task switching
Waiting Delays
Defects Defects

Source: Poppendieck & Poppendieck, 2007.

Overproduction/Partially Done Work

Overproduction and partially done work are equally wasteful. The simplest example of overproduction in a non-manufacturing environment is “gold-plating.” The Project Management Institute (PMI) is clear in its position that delivering more than what is explicitly defined in the scope statement is not good for any project. Exceeding customer expectations is great—but schedules and budgets are estimated based on planned work. There are ways to go above and beyond without doing extra work. This is where innovation and ingenuity are vital.

Partially done work is another aspect of waste in business analysis. Most often this is because we forge ahead with insufficient information (Gottesdiener, 2009). In software development there is always some degree of uncertainty – Lean business analysis means delivering only what is needed, when it is needed. Some organizations want to have all requirements up front. This is not the best approach. Requirements are specific, standalone statements and should be verified as they are developed (Gottesdiener, 2005). Another common problem occurs when business analysts rely too heavily on templates or tools out of habit or protocol. Work products should be developed on an as-needed basis. A Lean methodology prioritizes only the tasks that add value.

Inventory/Extra Features

Business analysts frequently encounter customers who want requirements documented in case they are needed later (“nice to have”/ “just in case”). Some customers want to document every possible permutation of user stories and requirements – even those they know they will likely never use. This can be difficult. Business analysts find and document the processes that add value. They also identify and eliminate those that don’t. Taking time to record everything leads to unused work and increases document management at both the project and enterprise levels.

One way to circumvent this is to create value stream maps. They provide a clear visualization of what is needed to perform business processes. They also enable the business analyst to demonstrate what requirements and use cases are truly necessary.

Extra Processing/Relearning

In some cases, waste occurs when there are too many people involved in creating or approving a product. Once I worked with a team that had a 29 step process for analyzing and approving minor changes to a software product. This quickly resulted in significant backlog and made tracking work difficult.

Another common problem occurs when requirements and related business analysis tasks are done in bulk. This “relearning” can lead to ongoing reviews of previous work. This happens because it is difficult for people to remember precisely what was agreed on and why. The best way to avoid this type of waste is to develop requirements and business analysis products as close to the deadline/consumption as possible (Gottesdiener, 2009). This type of waste is closely related to Overproduction/Partially Done Work and Inventory/Extra Features.

Transportation/Handovers

Depending on the number of people and teams involved in a technology project, there needs to be a strategy in place to avoid sending the same work products to different audiences for review. While it is certainly helpful to get feedback and to ensure shared understanding of outcomes, it is not beneficial to have multiple rounds of reviews with separate audiences. There are a couple of reasons for this—different groups may have different feedback/requests, the business analyst must then resolve the contradiction—meaning more meetings. This takes more time and increases costs.

Motion/Task Switching

Motion is closely related to transport in its potential to create waste and delay results. Unlike transport, motion is not necessarily physical. Too many review/approval cycles or email chains that involve several people and span several days do not add business value. I have a rule: if the team cannot reach a shared understanding in 3 emails, we need to have a meeting or a phone conversation.

Task switching in business analysis is typically caused by resource shortage. When organizations lack sufficient resources they often assign the same people to multiple projects. This is acceptable so long as there is careful coordination of tasks and deadlines. Task switching requires more attention to detail and work planning to ensure that one person’s workload does not have adverse downstream impacts (Gottesdiener, 2009).

Waiting/Delays

None of us accomplishes anything alone—we depend on others to complete key tasks. Inevitably, those people have competing deadlines and personal lives to contend with. It is impossible to completely eliminate waiting; however, it is absolutely possible to identify known scheduling conflicts and plan activities around them. For example, if you know in advance key teams or resources are unavailable, you can plan to work on other tasks or with other teams. “One, plan your approach for the initiative and two, conduct a retrospective to learn and adapt for future initiatives.  There should be a consistent start and a consistent end.  Everything in between should be flexible” (Kupersmith, 2011). By breaking down tasks, you can deliver more quickly, proactively address resource constraints, and improve processes.

Defects

Of all wastes, defects require the least explanation. No one wants to create a faulty product. The sooner a defect is detected the more easily (and cheaply) it can be fixed. This suggests an approach where inspection prevents defects. Creating smaller user stories and packages of requirements on an as-needed basis and building mockups/draft prototypes makes it easier to avoid defects (Galen, 2013).

Conclusion

Ultimately, Lean business analysis means the ability to quickly and neatly decide which tools to apply, what deliverables matter, and to engage in activities that add value to your client, project, or organization. There is not a clear path – practicing Lean as a business analyst requires years of experience. It requires trial and error. What works well for one team or project, cannot necessarily guarantee later success.

IIBA defines specific business analysis tasks alongside specific techniques used to accomplish each task. While there is value in defining tasks and relating them to appropriate tools, this information should not be taken as prescriptive. Not all tasks add value to all projects. Seasoned business analysts are able to quickly assess the situation, client, or project needs and craft a suitable strategy. Less experienced analysts are more likely to simply accept process and templates without considering whether they add value or provide the most expedient return on investment. Templates and techniques are tools and business analysts who know how and when to apply those tools will create more value by doing only what is needed to get the job done.

There is no single solution.

Works Cited

Galen, R. (2013). 10 Indicators that you don’t understand agile requirements. Retrieved from: https://www.batimes.com/robert-galen/10-indicators-that-you-dont-understand-agile-requirements.html

Gottesdiener, E. (2009). The agile business analyst: Eyes for waste. Retrieved from: http://www.modernanalyst.com/Resources/Articles/tabid/115/ID/811/The-Agile-Business-Analyst-Eyes-for-Waste.aspx

Gottesdiener, E. (2005). The software requirements memory jogger: A pocket guide to help software and business teams develop and manage requirements. Goal/UPC.

Kovacheva, A. (2010). Challenges in Lean implementation: Successful transformation towards Lean enterprise. Retrieved from: http://pure.au.dk/portal-asb-student/files/9093/ak83188…pdf

Kupersmith, K. (2011). Why business analysis processes are a waste of time. https://www.batimes.com/kupe-kupersmith/why-business-analysis-processes-are-a-waste-of-time.html

Poppendieck, M. &Poppendieck, T. (2007). Implementing Lean software development: From concept to cash. Pearson Education, Boston.

Saboe, Dave (2016). MBA074: Lean ausiness analysis. http://masteringbusinessanalysis.com/mba074-lean-business-analysis/

 

February 2017 Beyond Agile

Aki Beyond AGile Feb 2017

Plaster Group was a proud sponsor of yesterday’s BeyondAgile event. This month’s meetup was at Getty Images and was presented by the gregarious Marius Grigoriu, Development Manager at Nordstrom. Grigoriu covered the very timely topic of “the trouble with DevOps and what to do about it.” This talked explored the dynamics of DevOps through several lenses, from strategic and financial, all the way to the engineering experience. The presentation c losed with an exciting demo of a proposed solution in a live, product environment.

Join BeyondAgile on Meetup here to keep current on upcoming events!