Three Reasons Your Agile Practice Isn’t Agile

A strong Agile practice is a three-legged stool comprised of the Product Owner (the What), the Team (the How), and the Scrum Master (the Process). These roles are equal to and independent of one another.

In other words, there is no hierarchy in an Agile team; there are workstreams, and workstream owners. No workstream is above or below more significant or more important than another. Each has its own purpose, its own outputs, and its own responsibilities.

In a high-performing Agile team, there are no bosses – there are only teammates.

If your three-legged Agile stool is wobbling, consider these most common root-causes of poor performing Agile teams:

The Tyrant or Timid Scrum Master

No position is as misunderstood in the Agile practice as the scrum master. I often ask prospective clients why they’re hiring a scrum master (as opposed to a project manager or business analyst), and I’m no longer surprised that most cannot tell me why, or what, exactly, the role is responsible for (except for the events) or what the differences are among the PM, BA, and scrum master roles.

The most common answer is, “A scrum master is a project manager, except for Agile.” Dead wrong.

The scrum master owns the PROCESS. He does not determine what is built (that is the role of the PO), nor how to build it (that is the role of the team). The scrum master ensures a consistent, transparent process (timekeeping, utilization, governance, metrics.) He ensures accountability, keeping people honest (in other words, calling them out on their shit.) He demonstrates leadership through questions, coaching, by defining workstreams, R&Rs, working agreements, DOD, DOR, and using the word, “No.” It’s less about servant and more about leadership.

The scrum master is the “Servant Leader” of the team. Unfortunately, too many people stop at the word “servant,” especially if the scrum master is female or an immigrant.

As a scrum master, it’s not my role to “whip” the team. I’m an advocate and a coach. In some ways, I’m unconcerned about the project’s “success” or “value.” That’s not my lane. I trust that the PO has determined/documented the value of the effort, the success criteria, and KPIs. If that’s not done, I’ll ensure it is done, or I’ll escalate it as a risk. I might think the project is a huge waste of money. That’s not my call as scrum master.

The leadership of the scrum master is easily corrupted if the scrum master has a direct report relationship to any of the other parties in the team. It’s also corrupted if the organization hires a scrum master when it really needs a product owner, an analyst, or an architect — this is all too common with “Purple Squirrel” hiring managers in many tech organizations.

The Faux PO

While letting the team continuously iterate some BPOs “mind dump,” is a common ailment, even more debilitating is the old-school, top-down manager posing as a Faux PO.

The Faux PO is common in the Ghost Ship Agile practice, which means that from a distance the Agile Ship seems like it’s sailing along, but when you look a more closely, you see no one is on board.

The Faux PO tells you that the jury is still out on this Agile fad. He’s not convinced it works because the team is too incompetent to complete anything on time, which is why they need to be managed closely. Meanwhile: No metrics. No Dashboards, No backlog. No working agreements. No Definition of Ready (DOR). No Definition of Done (DOD). No separation of development from analysis. No Requirements. The Faux PO isn’t going to sully himself documenting requirements in JIRA. Plueeze….clerical tasks are for women and subordinates who can take notes while they hold court.

The Faux PO’s unwillingness to actually DO the work of being a bona fide product owner doesn’t mean that work goes away. Instead, like a house without front steps, everyone has to find a way around the Faux POs lack of output. What choice is there? Calling your boss out for being lazy AF isn’t really an option…

The Faux PO excuse is that he is much too important for events and deadlines. Because of this, there’s no cadence to the work. The Scrum Master/ Servant arranges a ton of last-minute, ad hoc brain storming or demo sessions to accommodate the Faux PO and other people with titles and opinions. At these meetings, the Faux PO talks at, past, and through the team, (who sit on mute, and stopped offering opinions long ago). No need for backlog refinement or DOR. The Faux PO tells the team exactly what to do, who to call, what to say. If they have questions, they can email the Faux PO for more detailed direction on how to accomplish their work.

But, I Like Being the Boss!

When I’ve suggested to Faux POs that the direct report relationship they have with the team is corrupting their Agile Practice, the Faux PO is incredulous! Don’t be ridiculous! They are natural leaders and visionaries! Their leadership is what is keeping this boat afloat. The team would be rudderless without them.

If everyone on your Agile team reports to you – you’re not an Agile team!

I’ve asked Faux POs if they would give up their direct reports and move their “vision” to another team as a loose-matrix product owner. They won’t. I’ve also asked if they would hire a bona fide product owner, who doesn’t report to them, and can make decisions independently. They won’t do that either.

So, I think we know what the deal is here – it’s called control – and if managers and executives are dictating the manner and methods by which work is accomplished by the team, then you’re not an Agile Shop – you’re old-school, command-control, boss-helper, my-way-or-the-highway shop, and it’s probably not going to change. Why? Maintaining a status quo (especially when you’re benefiting from it) is easier than change. Being a boss is easier than being a teammate. Hierarchy is easier than egalitarianism.

Bosses like being the boss. It’s awesome having people do what they’re told, when they’re told, without pushback or question. If only their wife and kids were like that…..

The Faux PO is a very common root-cause of Agile failure. In a risk report, it would fall under “executive-level support.” or “Unwillingness to adopt new systems and processes.” If there is an unwillingness to acknowledge these entitled behaviors or modify organizational structures, no Agile transformation can be had.

Architect as King

The Architect as King organization is really the worst of all possible Agile worlds. The team builds whatever it wants – the business can take it or leave it. There are no repercussions for crappy work, technical debt, or missed deadlines. UAT? What’s that? Open a ticket with the service desk….

The entire team, scrum master included, reports to an invincible lead, architect, or engineer, who doesn’t GAF about your process or product or metrics. You don’t like it? Do it yourself! Oh, you can’t? Oh, well. Scrum Master? Product Owner? Plueeze, The team reports to me, and your name is NOT on my performance review. Don’t piss me off, or I’ll quit, and then you’ll really be screwed….

From a product, user, and process perspective, the Architect as King organization is DOA for an Agile practice. Hire a technical writer to document the build. Anything else is a waste of money.

As amazing as this sounds, Architect as King is pretty common – especially in private or mid-cap companies. And, when I encounter a dev lead or principal architect who has been with one of these organizations since Christ was a baby, I know that this will be dev-driven development, an inelegant user experience, a shit-ton of technical debt, and I also know that nothing going to change until the king is deposed and replaced.

Final Thoughts….

It’s called an Agile practice, not an Agile perfect, and just like anything that requires practice, you’re going to suck at it the first 1000x you try to do it. But, you WILL get better. Things are never perfect, there’s always more to do. That’s why we have retros. Over time, you’ll begin to see how and why one team is better than another, why a coach is different from an owner, and how having a player in the wrong position or a hot-shot who hogs the ball can kill the team and ruin the game.

If you’re in software or tech, you’re going to have to learn to play the Agile game. Learn everything you can about it, and keep practicing. Agile is part of good project management, and good project management is Agile!

###

I hope you enjoyed this article, please check out some of my other posts and podcasts on Agile and the contingent job market. Thanks for reading!

###

Copyright 2021 Pierce/Wharton Research, LLC. All rights reserved. No part of this post shall be reproduced without permission.

The Vol-en-Told Analyst: Three Things NOT to Do

So, your <checkwriter> has determined you can’t afford an analyst for your technology project.  Instead, they want you to do it. (You? Have they met you?)  After Googling “business analyst,” and “elicit” you realize you’re even more clueless than you thought.  Worse, your PM and development team just asked you what the team should start working on….

I can’t teach you to be me, but I can tell you a few things I definitely would NOT do…..

Don’t Become Immersed in Current State

Resist the temptation to become (another) subject matter expert (SME). Chances are you’ve got lots of people in the weeds.  Ask them about the swamp; do not get in there with them. You’ll learn along the way…

Too often novice analysts (and insecure project managers) focus on mastering (and tirelessly documenting) the current state – as if having a Visio now makes it okay to finally get rid of it!  Business process owners are also guilty of the “let me show you ….” instead of providing an answer to your question. Steer clear!  If not, you’ll find yourself burning week(s) learning and flowing out someone’s job when all you really needed was agreement on a data set for the cloud architect.

Unless current state flows and docs are a specific deliverable in the project’s SOW, don’t waste time documenting system’s past. Focus your efforts on eliciting the information you need from your SMEs to define, build, and document future workflows, future components, future interfaces, the future.

Don’t Be Afraid to Assign Deliverables

One of core responsibilities of the team’s analyst to provide the infrastructure and artifacts needed by the appdev (and devops) team so they can build (and test) software.  That doesn’t mean that the analyst is the only person who has to write stuff down.

Every team has a different division of labor, and each analyst has a different style and approach.  Style notwithstanding, we can all agree that I cannot do a Vulcan mind-meld with the DB architect.  I need a schema and component diagram (regularly updated) regardless of how busy you are. Similarly, business process owners aren’t exempt from writing stuff down, either.  I need a list of the exact data points everyone wants retained.  Another demo of “how I do it now,” isn’t a deliverable.

The beauty of a Waterfall effort is that there are clearly defined inputs and outputs. The Gantt is not forgiving.  It shows everyone in the room if a gate is open/closed, and who/what is keeping that gate from closing.  The beauty (and curse) of Agile is that it’s much more flexible. Things requiring more discussion, bigger decisions, “grooming and refinement” can easily be re-prioritized in favor of backlog items upon which there is violent agreement.  As an analyst, you offer insight and best practice advice, but at the end of the day, deliverables codify key business decisions. I can’t make those for you.

Don’t Forget Whose Side You’re On

Whose side are you on?  The Development Team. Period. Why? Because that’s the team you’re actually a part of, and they’re the people doing the work (for you.)

If you’re new to being an software analyst, you will quickly see that your seat in the development team is to articulate the client/business vision.  That doesn’t mean you’re the client.  Conversely, when you sit in client meetings, your role is to be a relentless advocate for the development team.  But, that doesn’t mean you can make decisions or agreements on their behalf.  Being the “creamy filling in the Oreo,” can be difficult.  Empathy, and helping others to have more of it, is an essential skill.

The reality is that no matter how smart you are and how much you’ve thought about something, you’re going to make a mistake or mis-assumption.  Analyst’s mistakes are built into the code, seen in public – sometimes in really big meetings.  You can’t let your client blame the “stupid developers,” when you know full well your poorly written acceptance criteria was the cause.  If you throw your team under the bus – even once – you will quickly regret your lack of courage.

Final Thoughts

There’s a certain amount of frustration involved in the analyst psyche. You’re usually on a steep learning curve, and time is not endless.  You have to accept ambiguity (sometimes a lot of it) and push forward despite unknowns. Learn to say, “I haven’t gotten there yet,” “That was my mistake,” and “We can do it, but it will take more time and money,” and you’ll be just fine.

+++++++++++++++++++++++++++++++++

Copyright 2017 Pierce/Wharton Research, LLC.  All rights reserved.  No part of this post shall be reproduced without permission. info@piercewharton.com.

Your Culture is your Brand

I’ve been spending a lot of time thinking about culture, how it eats strategy for breakfast, and how most of us think we can’t do anything to change or affect the culture in which we live and work.  I strongly disagree, and so does Tony Hsieh, CEO of Zappos.com.  The following is an excerpt from Delivering Happiness: A Path to Profits, Passion, and Purpose.

“Building a brand today is very different from building a brand 50 years ago. It used to be that a few people got together in a room, decided what the brand position was going to be, and then spent a lot of money buying advertising telling people what their brand was. And if you were able to spend enough money, then you were able to build your brand.”

“It’s a very different world today.  With the Internet connecting everyone together, companies are becoming more and more transparent whether they like it or not.  An unhappy customer or a disgruntled employee can blog about a bad experience with a company, and the story can spread like wildfire…”

“The good news is that the reverse is true as well.  A great experience with a company can be read by millions of people almost instantaneously as well.  The fundamental problem is that you cannot possibly anticipate every possible touch point that could influence the perception of your company’s brand.  Every employee can affect your company’s brand…”

“Many companies have core values, but they don’t really commit to them.  They usually sound more like something you’d read in a press release  Maybe you learn about them on day one of orientation, but after that it’s just a meaningless plaque on the wall of the lobby.”

“We believe that it’s really important to come up with core values that you can commit to.  And by commit, we mean that you’re willing to hire and fire based on them.  If you’re willing to do that then you’re well on your way to building a company culture that is inline with the brand you want to build.  You can let all of your employees be your brand ambassadors, not just the marketing or PR department.”

“At the end of the day, just remember that if you get the culture right, most of the other stuff – including a great brand – will fall into place on it’s own.”

– Tony Hsieh

How Perfectionistss Ruin Quaity

Capture
In the early days of software (when every application came with manual), I took a class for technical writers.  Our first homework assignment was to write directions for how to make tea.  Several of my classmates had questions such as what kind of tea? Was it in a bag or loose?  The instructor said he would provide no other details except for the original task: Write directions for how to make tea.

When class re-assembled the following week, the instructor asked the students to turn in their homework.  He shuffled through the responses and chose several to present to the class. Before presenting, he requested the class hold all comments and questions until after all the submissions were reviewed.  Then, he placed the first page of Paul Perfectionist’s directions on the projector. “That’s mine!” You could see him visibly puff up. Because his directions were first up, they were likely the standard.

Paul had put together an exhaustive set of detailed directions. No detail was too small, no action overlooked, no exception left out.  Paul wrote step-by-step how to unwrap the box of tea, what size pot to select for boiling water, how to turn on the faucet, how to put water into the pot, how to turn on the stove (or light a stove, if necessary), how to set a timer for boiling water.  He created a branch for the benefits of a tea kettle verses a pot, how to choose a cup, how to lay the tea bag in the cup.  He had an alternate scenario for loose tea, including explanations of tea balls, strainers, and cozies…a couple shots of images for tea…all-in-all, there were more than five pages of directions for making tea.

The instructor continued with the next set of directions, which was also lengthy, but not nearly as exhaustive as Paul’s.  The instructor slowly continued on replacing page-after-page of instructions offering no comment on any of the efforts.

I’ve spent a lifetime as a teacher and corporate writer; I knew where this was going.  I sat back and began to look around the room. I could see some of the students’ body language had already changed. Shoulders hunched, furrowed brows — they looked confused, worse ashamed.  Had they misunderstood the assignment?  Was this more complicated than they originally thought?  Self-doubt descended like a fog.

As the presentation continued, the directions became significantly briefer.  One student (who had asked about loose or bag), wrote “One bag = 2 Tbls,” which I recall thinking was exceedingly clever copy for tea packaging. I remember Paul rolled his eyes when I complimented the writer on the usefulness of that line, “That doesn’t even tell you how to make tea!” he scoffed.  The last submission displayed was, “Add hot water. Enjoy.”

The projector went off. The lights went on.  Paul was beaming with pride.  “So,” the instructor began, “Which of these directions do you think is the best?”

“The last one,” I said quickly and with conviction.

“I agree,” the instructor responded.

Now, if you thought that Paul had a “ah-hah!” moment, you have little experience with the detail-obsessed, perfectionist disorder.  On the contrary, Paul was PISSED OFF!  Without a second of reflection, he launched into a full-scale attack on his classmates and the instructor.  The others didn’t understand the complexity of tea, and that’s why he detailed out every approach to it. These brief responses indicated his colleagues were lazy and didn’t want to do the homework.  It’s clear they took a short-cut in the assignment, which is why they wrote so little. Paul assured everyone that he had spent a lot of time working on this, and making tea was much, much, more complicated than we really knew.  No one had even thought to include images!  What if someone didn’t know what a teabag looked like!

My personal impatience with the narcissism of perfectionists notwithstanding, I gleefully threw coal in his furnace and offered that I wrote no directions at all; rather, I documented an audience assumption that tea – a staple of every kitchen in every culture – is something the audience or purchaser would already know how to make.  It’s not an enchilada.

Other real-world rejections of Paul’s work quickly followed: Tea does not come with directions now, why would we need them in the future?  No tea company would ever create collateral or change packaging to accommodate five pages of directions. No one buying tea would ever read a five-page insert if they did. Another pointed out that Paul’s directions (literally) included a section on how to boil water! Knowing how to boil water was the same reason light bulbs didn’t come with directions. Ha-ha. The class chuckled, the fog of self-doubt lifted, and there was a sigh of relief from those who had not crafted lengthy directions. Paul, however, was not amused.  He insisted that it was possible some men could not know how to boil water or turn on a stove (although most women were likely to know this, he conceded). Then, finally after all his other defenses were exhausted, Paul played the “safety” card (aka: the Hail Mary of all corporate disagreements), and strongly asserted that without directions someone might burn themselves or ingest the tea bag, which could result in a law suit…

The Lesson

Paul was a student in a class of colleagues, so the ability to critique his work is assumed.  That is rarely the case in real-life. Imagine if Paul Perfectionist were a manager, lead or (heaven forbid) stakeholder?  Given Paul’s predilection toward perfectionism, if he were someone’s boss do you think he would be open to a less-detailed approach or would he just see that as sloppy?  What are the chances that a peer – never mind subordinate – could call Paul out on his emotional need for detail?  Even if some courageous person did tell Paul he was being ridiculous, do you think the rest of the group would jump in and support their colleague’s “sloppy approach” compared to Paul’s exhaustive completeness?  Lastly, with so much ego and emotion displayed by Paul, even if the group felt that Paul’s directions were expensive or might result in a negative outcome, how likely is it that they would coalesce to fight actively against him?  Or do think it’s more likely the group would just “deal” with Paul because they have families to support and just don’t have the energy to argue with him anymore….?

Paul and Polly Perfectionists exist in every business. What all these perfect people have in common is the same narcissistic misconception that they – alone – can assure quality.  We euphemistically call them “bottlenecks” or say they need “special hand-holding.”  In private, we call them high-maintenance PITAs, and tell colleagues to circumvent them because do nothing but cause spin and churn.

Perfectionists are the most destructive of leaders and teammates because they talk non-stop about quality, but they don’t listen to quality. Quality is not a person. Quality is not a checklist. Quality is a process.  A quality processes requires a team, and the perfectionists of the world never have a good one because teams require honesty, communication, and trust.  Perfectionists don’t understand that state of being.  Their lives are filled with fear, suspicion, and distrust.  It haunts them at work; it strains their personal relationships. A Paul Perfectionist may run a team, but he rarely considers himself a part of that team because – qualitatively – he is sure he is above the others and perfectionism is not a flaw.

Excellence is a value; Perfectionism is an insecurity.

Everyone should take pride in his/her work, everyone should have input, but when I see over-engineered and voluminous solutions, I don’t think, “Ahh, so smart!” Rather, I corner my teammate(s) 1:1 and ask questions.  Inevitably, I’ll hear “Yeah, we had to do <whatever> because <controlfreakperfectionist> is a PITA, which is why we’re <late/over budget/short staffed>. Avoid them if you can….”

Over the course of my career, I have been amazed at the number of high-priced consultants and internal project teams who churn away days and weeks of expensive time adding linguistic dandruff to presentations, plans and proposals whose only goal is to sooth the emotions and ego of someone who is sure they’re adding quality.  CapEx budgets become bloated by stakeholder reviews and timelines are delayed all because no one going to jeopardize the financial stability of their family by telling Paul Perfectionist that we don’t need five pages of directions on how to make tea.

The Conclusion

The instructor cornered Paul during break and tried to talk him down, which was not easy because perfectionists are quite sure that you aren’t smart enough to see the world as clearly as they, and who are you to criticize their drive for perfection anyway?

The instructor explained to Paul the purpose of the class (and education, in general) was to challenge pre-conceived notions. Audience is the most important consideration in any communication, and Paul did not consider his when writing his directions.  Although Paul reluctantly agreed that perhaps boiling water was a bit much, he would not relent on the other stuff.  Besides, even if fewer directions were acceptable, more paperwork and detail is always better. I mean, this is tea, sure, but in real-life, in business, there would never be a time where more documentation or direction would be worse, right?

The instructor asked Paul to keep an open mind, and then politely turned to another student who had been patiently waiting.

Paul never came back to class.

++++++++++++++++++++++++++++++++

Excerpted from: The Temp Job: A Survival Guide for the Contingent Worker. Copyright 2017 Pierce/Wharton Research, LLC.  All rights reserved.  No part of this post shall be reproduced without permission. info@piercewharton.com; Follow on Twitter and Facebook @TheTempJob

Blog at WordPress.com.

Up ↑