Posts Tagged “anti-practice”
Have you been put in charge of a development team but you don’t know what you’re doing? Do you want to get ahead in your organization and don’t care about the price others have to pay? If so, the Best Practice Carpet Bomb might be just the thing for you.
You only need two things to execute this Anti-Practice. First, you must to select a handful of time-intensive best practices. Second, you will need time – enough time to drop one best practice on your team each month.
Try checklists in the first month. They’re in fashion right now. Checklists save lives in the operating room. And anything that helps guys with starting salaries of three hundred thousand dollars has got to provide some boost to your team. Right? Pass the word down that over the next month every member of your team needs to compile five checklists. No, it doesn’t matter that we don’t have a plan for where to put them or how to use them. It doesn’t matter that a forty person department times five checklists equals two hundred new documents that need to be organized and maintained. They’re checklists and they save lives. The more the merrier. And, because this is the new best practice that everyone’s talking about, this just makes us more agile.
Try something completely different the second month.
How about frequent demos? No, not the end of sprint demos to present our shippable product. We DO need to do those, but they’re so 2002. What we need to start doing – because it’s an up-and-coming best practice – is demo to each other so we can show off how cool we are. Team to team. Individual to team. Team to office manager. Whatever audience we can get. And we need to consider our audience and our presentation posture. We don’t demo real applications because they can break during the demo and make us look bad. Screenshots, scripted talks, and multiple rehearsals – that’s the way to do it. No, it can’t be more relaxed just because you work daily with these people. This is about putting the time and effort into effective communication. And that is SO agile.
On to month three. How about mandatory and standardized incident reporting whenever anything breaks? Or let’s mandate that every new idea gets the A3 and paper prototyping treatment. Yes, every new idea. Wait wait I’ve got a better one. Let’s all start internal blogs and we can spend our evenings blogging at each other. Well, no, that’s not an established best practice. That’s ok. We’ve adopted enough best practices from other teams. It’s time to start making our own. We’re gonna be the next Google.
Now, remember, in month three your teams must also sustain the best practices from months one and two. Otherwise, what would be the point of adopting best practices? They are, after all, best practices, which makes them crucial to our success.
The same rules hold true for months four, five and thereafter … until your team crumbles into a pile of malfunctioning bits that have adapted to satisfy a succession of noisy organizational mandates in the place of quality delivery.
And you know the best part about using best practices to wreck teams? You can blame those very teams for their failure. Had they done as you had instructed them, and implemented the best practices correctly, they would have succeeded in their delivery goals. Time your exit right and you’ll be promoted because of your ability to lead and innovate using best practices. You’ll be off to bigger, better opportunities while some poor sap gets conscripted to clean up behind you.
No Comments »
For some this is a heinous anti-practice. For others it’s standard operating procedure. Either way it’s the fast track to project ruin.
Plan and Ignore is the practice of quickly drafting a project plan (typically to satisfy an external demand; typically in Microsoft Project) then tossing the plan and never looking back. This happens for any number of reasons. Some people don’t know how to plan. Some people don’t know how to track. Some simply don’t want to invest the time to do either activity correctly.
Plan and Ignore should never be confused with even the simplest forms of agile planning. Even the lightest-weight planning (such as a product backlog, t-shirt size estimation, and a burndown chart) can keep a team free of this anti-practice trick-bag.
The fundamental problem with Plan and Ignore is that no one actually knows the status of the project. Behind? Ahead? Safely on track? Likely no two people on the project team will give you the same answer.
And when your team has no consensus on its status all manner of bad mojo can result.
If you are actually behind, the people who don’t see this will likely be busy cathedral-building and apple-polishing instead of developing the much-needed ladder that the team will use to climb out of its current hole.
Furthermore, lack of agreement on a team typically raises the attention of management, especially when that lack of agreement is around status. But management often does not know how to be helpful in situations like this. They’ll demand to see status against the current plan, go hulk-mad when they discover that there is no current plan, demand a new plan be drafted, and waste yet more precious time prying tracking data from team members who are frantically trying to not fall further behind.
Finally, if management doesn’t cop on to the lack of consensus then the team will know they are behind only when they reach a consensus on the matter. Typically this happens one week before a major milestone, at which time the team recognizes the obvious – that it is no less than four weeks behind. And that’s when the fit will really hit the shan.
No Comments »
Martha: What did you do?
The Doctor: I named her. The power of a name. That’s old magic.
— Doctor Who, “The Shakespeare Code”
I like to put names to things, especially problems. I’ve found that by naming something, particularly those things that are not immediately intuitive, the individuals who pick up the name have a much easier time understanding and tackling the issue, idea or problem that the name represents.
This is one reason why I like to write about anti-practices, like Defensive Scrum, Schedule Chicken and Management by PowerPoint. Once there is a commonly-understood (or at least catchy and intuitive) name for an anti-practice it becomes much easier to dispell that anti-practice.
Naming an anti-practice does not dissolve it into a puff of foul black smoke. Naming an anti-practice can, however, clearly mark where the positive patterns and behaviors can be found and where the negative patterns and behaviors should be left.
We often repeat the names of anti-practices in our daily work lives, either to identify current bad behaviors or to warn against future misconduct. People sometimes ask, specifically, what an anti-practice name means, and we get an opportunity to describe the negative behaviors the name is meant to depict and the repercussions of those behaviors.
Slowly, we can build individual and collective support against negative behaviors and in favor of positive patterns. All because we chose to give something a name.
No Comments »
Ostensibly originating in Rebel Without a Cause the game of chicken entails a test of courage between two or more individuals. Each participant is seated in a speeding vehicle (50s sports car, farm tractor, failing project schedule, etc.) racing toward a certain demise (cliff, head-on collision, delivery failure). The chicken is the participant who abandons his vehicle (or comes clean with management) first. The chicken either loses the contrived, Hollywood-scripted contest or gets reamed by management. The participant who bails from his vehicle last (or avoids having to come clean with management) either gets the girl or is rewarded with another project to go and wreck. In rare cases, I suppose, he might get both.
And therein lies the true and long-term damage of this particular anti-practice. In Hollywood movies chicken is a one-time contest. For project management, schedule chicken is an iterative game, where the most dishonest and deceptive participant wins and is encouraged to hone his destructive behavior so as to win again in the next round. In management environments that foster schedule chicken, transparency and honesty are inadvertently discouraged and even punished.
Furthermore, we cannot ignore the project teams strapped to the backs of these vehicles as they speed toward the inevitable. Even though the dueling PMs have a terrible tendency to do just that.
I have met project managers who are consistent victors at schedule chicken. They hop from one project wreck to the next, while the incurious executives eye them as can-do rockstars. Sometimes the project teams don’t know what hit them. Sometimes they do. But even then, no one’s really listening to the opinions of the bit players.
I’ve found only one effective defense against hard-core schedule chicken. Don’t play the game. Establish my own rules before the contest has a chance to start. Go über-transparent from day one. Let management know what’s really going down on the project, both good and bad. And keep management up-to-date on a weekly schedule. The key to disclosing the bad is that I must always have and present a strategy to explain how I am going to correct for it.
This über-transparency keeps me from ever heading toward the cliff. It guides me and my teams to correct issues and risks as they arise, and the project timelines and project teams are better for it. Further, über-transparency can send management looking for the same wealth of information from other project managers, making it more difficult for them to get a running start at the cliff.
Even if other PMs continue to play schedule chicken, by not playing my project teams and I cannot lose.
No Comments »
The business side of the house can be difficult at times. They can challenge our estimates, claim that work is not half as difficult as we make it out to be, drop last minute delivery requests in the middle of our development cycle, and even (in occasional fits of complete frustration) threaten to offshore the lot of us.
So, what’s a lowly, victimized development department to do?
Turn to Scrum, of course. And play defense. Specifically:
- Recruit ScrumMasters to protect the teams.
- When the new ScrumMasters wants to discuss what’s right for the company, stress that the ScrumMasters were hired to protect the teams.
- Grab a hapless business person, hand him a Black Book, crown him product owner, and tell him his number one priority is to live PivotalTracker.
- Be specifically clear that the Product Owner’s number two priority is to communicate every user need in the “as a … I want … so that” story template.
- Threaten to take the teams on strike until there are 100 storied story points prioritized in the backlog.
- Go flash mad the fifth time someone asks “what’s a story point worth?”
- Remind business people that chickens are not allowed to speak at daily meetings.
- Deflect complication and nuance by declaring big business ideas as too epic in nature to consider for development.
- Threaten to abend the sprint every time the business wants to change something.
- Demand that the ScrumMasters protect the teams by ensuring they are capped at forty-hour work weeks. Ignore the fifty-plus-hour work weeks that are saddled upon the ScrumMasters. Scoff at the difficult working conditions of the business users.
- Finally, don’t forget to whine vociferously that the business doesn’t get Scrum.
You could call this Scrum. I wouldn’t. I’d call it an anti-practice.
Whatever you do, please don’t call it agile.
1 Comment »
Please read the next four sentences before letting the dogs loose on me.
I love wikis. Really. And I am not a SharePoint fan. Really.
Now, I only need four more paragraphs to explain.
First, a wiki is supposed to help us make information maintainable. One way we do this is by centralizing and restricting topics to one per page. In order to review and revise a topic in its entirety, all one needs to do is edit the topic page. All the links into the page automatically send readers to the latest revisions.
Second, a wiki is meant to make information more accessible. Topics can be linked to directly, from both within and outside the wiki. By linking to referenced topics at every opportunity, we allow the reader to enter into the conversation at any level of granularity. The reader can then follow links across topics to gather the necessary background information and focus on his or her particular area of interest.
Third, a wiki is an evolving conversation. Pages are created and revised by numerous authors to reflect the current understanding of and thoughts around a given topic. Many pages never, truly, leave a draft status. The goal is not to collectively polish. The goal is to communicate in a collaborative, efficient and effective manner.
Fourth, a wiki is NOT a forum where: (1) each page is a document instead of a topic, (2) the pages rarely link to one another, and (3) each page carries enough information to be consumed outside of the context of wiki itself. If your wiki looks like this, then what you’ve constructed is a poor-man’s SharePoint (a wiki anti-practice). And your SharePoint wiki is not likely to thrive, since it has none of the benefits of a wiki (maintainability, accessability, consersational tone) and all of the drawbacks (clunky editing, clunky formatting, clunky or nonexistant permissions). If you want a navigatable hierarchy of polished, stand alone pages that do not converse with one another then you’d be better off using SharePoint and Microsoft Word (or open-source alternatives).
No Comments »