Tag Archives: Scrum

Publishing Your Ebook For Nerds – Lessons Learned

Working on wrapping up my third e-book. It’s a book on how to make and manage effective backlogs, or the lists of things both teams and developers do. The first two were kind of a lark — although I was trying as hard as I could, I realized that this was something that was going to take a while to learn.

This time around my e-book is much larger, and I’m hoping to hit the mainstream, both in terms of content and quality. Most all organizations have the job of coordinating their work both globally and locally, and I’ve made the book as a lesson wrapped in a story. I figure either you’ll like the lesson or the story, maybe both.

After spending several days fighting tools, I thought it’d be good to capture what I’ve learned. If you’re a tech person who wants to write an e-book, this’ll help you get from words to e-book format.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Why I’m Leaving My Home Office

When I’m not helping a large client, I work from my home office. I’ve been working this way for around ten years.

Today I’m leaving my office for a while to try coworking.

Why would I leave the comfort of my home to travel an hour to the nearest town to work with a bunch of strangers?

Productivity, that’s why. Random human encounters, being around other people working, the social atmosphere of an office — all things you don’t find in a home office.

It occurs to me that if co-location is so good for Agile teams, it might be good for sole founders as well. And in this business, there are no universal rules, only what works and what doesn’t work.

So for the next month or so, I’m going to try coworking.

I’ll let you know how it goes.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile Video Series Kicks-Off

A month ago I was talking to a client when the subject of Agile reporting came up. There was a lot of discussion around tools and meetings and all sorts of complexity that might occur in a large Agile program.

Feeling a bit flustered, I walked away and started drawing on a nearby whiteboard. What’s the maximum amount of visual indicators you would need to run a large, complex Agile program? It’s a small, finite number, and maybe by just getting it all out on the wall it would be clear that the real work is in running the program, not all the tooling and pretty displays. You should be able to capture, report, and analyze program status in just a few minutes per day. The rest of your time should be spent, well, working.

Took about an hour to draw it all up, and folks liked it enough to put a big “Don’t Erase!” on the board. Last I saw it was still on there.

But what really sucked was that I could see myself having the same exact conversation with another client in a month or two’s time. And having to draw it all over again. Was there some way to capture these kinds of whiteboard chats so they could be reused and shared more easily?

Turns out yes, yes there was. Using a graphics tablet and some software, I could capture a whiteboard chat and not have to repeat it. Way cool.

So then I thought, what’s the most helpful question I could answer for folks on the net? Something that they would have a difficult time getting from others?

I felt the answer was “How to prepare for Agile Adoption” because there are so many opinions, it’s tried so many different ways, and vendors have a conflict of interest — many times they’d much rather take your business and hope they can straighten things out later than tell you up front you’re doing it wrong — especially if you’re willing to sign the contract with somebody else. By being a talking head I could offer up my years of experience and not have “skin in the game”. I’m just sharing what I’ve seen.

Well this was getting to be a lot more fun than electric cooking, so, of course, I had to do a few more. After all, what would be the fun in just two? Today I finished up “Scrum Vs. Kanban”, which is a look at the two methodologies and how to apply them in your organization.

I have a list of a dozen or so topics I’d like to do, but I’m not sure if I’ll be able to do all of them. This is a new format for me and I like it because it combines teaching, movie-making, and technology development.

For those of you interested in the business side of things, the videos provide a calling card for me, they point traffic at my micro-publishing site, Tiny Giant Books, and since they’re about management in general and not some specific technology, hopefully they should hang around on the web for a long time.

But the biggest reason to do these is that all the pieces just came together. I had the tools, the material was already put together, I had deep knowledge in an area that many might find useful, and it looked like an opportunity to help lots of folks. It was just a no-brainer kind of moment.

If you have any ideas for topics or feedback from the videos you’ve watched, let me know! I’m enjoying learning this new media, and it the more feedback I get the better the result for everybody.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

It’s the Small Things

One of the things I’m noticing with some of my fellow coaches is their desire to work at the program and enterprise level. It seems there’s nothing like coaching a bunch of teams at once to really get your feet wet. Things look better at scale!

Well yes, and no. I’ve been fortunate to have several work experiences with teams and organizations of all sizes. Last year I worked with a team of two guys in a broom closet. A couple of years before that, I worked with an organization that had over 20K IT folks working almost a thousand projects. On six different occasions I’ve had the pleasure of helping to set up and run programs — teams of teams. A couple of times more than one program at a time.

I’m not trying to brag, just let you know that I have had the relevant experience to talk about this. I’ve been there, done that. While yes, it’s kinda cool working with groups of teams, it’s also very easy to make a lot of mistakes that you never realize you are making. Here are the most common ones.

  1. Premature optimization. The first thing large groups of teams want to know is: what’s the standard? Because you can’t manage a lot of people without processes and standards. (At least in their minds)

    Coming from Agile, many of us know better than to focus too much on process, but clients insist. They want job aids for everything from stand-ups to sprint closings. They expect coaches to all deliver identical advice on any topic.

    This is a really bad trap, because the entire premise of Agile is that individual teams and situations are so varied that we must push a lot of process decisions onto the individual teams. The purpose of our Agile rituals and delvierables is to identify the work and possible paths for solutions: what problems do we face? What types of actions might help the most?

  2. Us versus Them. One of the worst things that happens, often without the coach even knowing it, is that they begin to fall into an “us vs. them” attitude. Who are these teams? How come they keep doing stupid stuff? Why won’t they listen? Over time, you subtly stop being a servant for the teams and start wondering why the nincompoops just won’t do what they’re supposed to do.
  3. Tools will fix anything. Once we get sufficiently detached from the actual problems the teams are facing (and this can happen inside the team, you don’t need a program for it) we start buying into the idea that the tool can fix the behavior problem. Need folks to start making comments when checking code in? Just force it to happen! It’s magic — because you’re not actually dealing with the problem, just the symptom. You’re using a hammer that’s close-by to pound on a problem that’s close-by. Many times the thing you are pounding on is fitting a square peg into a round hole.

The more I work with both large and small groups, the more convinced I become that the vast majority of problems organizations face are at the team and individual level. If teams don’t provide timely and accurate information to people outside the team who need it? You’ve got junk. If teams don’t manage their quality and testing? You’ve got junk. If teams don’t communicate and problem-solve effectively? You’ve got junk. If teams keep trudging along punching the clock without creatively re-framing their problems in order to make life easier? You’ve got junk.

So yes, it’s lots of fun to be helping and working on a 100,000-hour+ program. It’s even more fun to be helping set enterprise policy. But those things are way less important — and way more likely to actually hurt things instead of helping — than the small things that the teams and developers do everyday.

Trust me, it’s the small things.

Note: One of the things most people fail to understand about groups of people is how naturally decentralized they are, even in highly-centralized organizations. People think “We’ll just make a policy to do X” without any idea of how it actually is going to play out. People think if somebody is in charge of a large group of people that they can just tell folks what to do. There’s a ton of myths about how large groups of people are actually led — enough for another entry!

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.


Shot a video for my ScumMaster book last night.

I think that’s mostly it for the landing pages — at least the big parts. I have a few more reviews coming in and I need to run some standard checks on the pages. Then, of course, the rewrite.

Somebody told me the video wasn’t that good — my head is down in the bottom of the frame and it runs on too long. Meh. I spent three hours shooting it. What do you think? Should I re-do it? Or is it good enough for now?

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Playing Around with BoxShot 3D

Been having fun with the little ray-tracer app I bought to make an image of my e-books. Like all things nerdy, it has a lot of little options, but it’s surprisingly easy to use, too.

What I’ve been reading is that people are much more likely to buy an ebook if it looks like it might be a real book. Kind of weird, but people are like that.

Here’s a shot I finished yesterday morning. I think it looks pretty close to being real!

Box shot of scattered ScrumMaster books

It was really cool because it would do the alpha masking so I could output a transparent png file, shown. Bonus points if you can read any of the text on the back of the book (which was never intended!) I had to make it look real, yet on a tight budget and zero time, so I just faked it all. I felt somewhat like a counterfeiter or forger — how close to real could I make it look?

But like all of these things, if I’m not careful I could spend a lot more time in a quest for perfection, and with a startup spending that kind of time on one thing is never advisable.

Still, cool.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

E-books Are Not That Easy

Seems like all I ever read about making an ebook is how easy it is.

Either that or a story about how somebody has created the perfect online app to let you self-publish.

I’ve just self-published my first “real” e-book. It’s a step-by-step guide on how to set up an Agile team. The title is ScrumMaster. Here it is:

3-D Image of ScrumMaster ebook cover

I found there were all kinds of details to keep track of — whether or not you use a magic application or not. Here’s a brain dump of just some of the things in no particular order.

  • Market research: initial. Determine the size of the potential market, what the buying indicators are, and where the competition is.
  • Landing page for your book (that you own). That’s domain registration, formatting, JavaScript, email hookups — the whole shebang.
  • Actually writing the book.
  • Converting the book into EPUB or another format. Bonus points if you write the book in a text editor and make your own BASH script to pack it all up.
  • Finding reviewers.
  • Creating a cover image.
  • Creating a 3-D image of your book as if it were a real book.
  • Creating a marketing plan.
  • Locating a distributor. Amazon pays me 17 bucks for a 50-dollar book. Can you say “assholes?” LuLu pays me 43 bucks, but only if you buy on their site. Do the math. Platform vendors own authors and small publishers.
  • Setting up an “I’m interested” email list in MailChimp. Integrating that list with your site.
  • Locating or creating any relevant artwork that you want inside the book.
  • Testing the book on various reader formats. Yep, it’s back to the bad old days of browser compatibility. Looks great on my DX. Sucks on my Nook.
  • Validating your book. Just like HTML validation, it’s not strictly necessary, but if your book validates at least it makes you feel better.
  • Dealing with special tags. Kindle has a page-break tag. Should you use it? I didn’t. I’m not sure what the correct answer is.
  • Worrying about copyright issues. Remember that picture you took of the Sprint close with 15 guys all working at the story board? Got model releases from those guys? I didn’t think so.
  • Market research: execution. If you finally get a book completed, then the real work begins: marketing campaigns. From your initial research you know there is a market, now how to you reach them? Who are the thought leaders? Where do the people hang out? What are their selling points? Some of this you’ll only find through execution, but after you qualify the market though initial research, you had better be continuing the research as you put together the e-book.
  • Getting reviews. It’s a social world, and people buy based on social signals. Can you provide enough social signals to a potential reader to allow them to make the purchase? That means a lot of people explaining your book’s benefits to strangers. Where are you going to place those reviews, anyway?
  • Beta test. Yes, books, like computer programs, have beta tests. Who’s in your beta program? How are you going to manage it?
  • Buy an ISBN. Have you seen the price on ISBNs? Try over a hundred bucks for just one number. Then you need a new number for every format your book is published in.

I’ll be upgrading my book to version 2.0 over the next week or so. This is just “first publish,” which I imagine to be something like the first time your program starts working — pretty neat, but a long way from anything solid. The world is full of computer programs that solve all sorts of problems that nobody wants. I’m sure it’s also full of e-books that nobody wants. I still need to check how the book appears on LuLu and Amazon, tweak the sales copy, and receive and process about an half-dozen technical reviews. The content is the least of it — as a domain expert I imagine my content is 90% on-target. It’s all the other stuff. If my marketing and sales pipeline don’t work? Hang it up. It was a waste of time.

E-book publishing is not as easy as writing a MS Word document and pushing a button, no matter what the bloggers say. Even if you spend a couple of thousand dollars (I know somebody, not me, who spent over $4K on his e-book) it doesn’t guarantee much of anything.

E-book publishing looks very much like writing your own app. Yes, you shouldn’t spend all your time in the weeds, but just like any startup activity, the technical details of doing it and the actual business details of making it all work are two completely different things. The trick is making both the technical work and the business work mesh into one product. All this work I’ve done? I’m just barely getting started. Now the real work begins. Don’t believe what they tell you. E-books are not that easy. Not at all.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Perfect Agile/Scrum Stand-up

When people first arrive in Agile/Scrum, one of the first things they ask is “Doesn’t Agile mean we don’t need requirements?” followed by a close second of “Scrum is too rigid. We definitely don’t want something so restricting”

It seems like you’re either a cowboy or a Nazi. There are no in-betweens.

It’s like this: Agile is all about dynamic process tailoring. That means, yes, that teams control the degree of paperwork and process they need to accomplish. But it’s also like this: there are some “recipes” that the community has found over and over again that work. You’d be a complete fool to ignore them.

What happens with high-performing teams is that they have very few things they do that are defined and reproducible. But for those very few things, they are very disciplined. Being Agile, strangely enough, means being extremely disciplined about a very few things and leaving the rest of the details to make up as you go along.

The crux of all this ambivalence is, in my opinion, the stand-up. Since nothing proves a point like actually seeing it, in the video that follows, note the following things:

  • It happens quickly. Stand-ups are high-energy. People are standing-up, moving around. Nobody is sitting in their chair with their head in their notebook or cellphone.
  • Nobody is reporting to anybody. This isn’t a status report. There are no questions and answers.
  • We point at the things we are doing. It’s all about Visual Process Control. That means the things you are doing are publicly visible, they represent status at any time, and they are manipulable.
  • Decisions are made after the stand-up. The stand-up is a game of identifying tokens: what has happened, what is going to happen, what obstacles individuals are facing. After the tokens are all identified, the “real” work begins: the tokens are resolved. Technical discussions and ad-hoc discussions begin.
  • There is no Project Manager. If you can look at a stand-up and find a project manager, it’s a bad stand-up. Stand-ups are about team commitments, risks, and issues. Not roles.
  • Everybody is in the same room. Body language and other non-verbal communication channels count. A lot. Everybody isn’t standing around talking into a PolyCom.
  • It’s scalable. If done correctly, team stand-ups scale very easily. A manager could attend several stand-ups each day, get a close-up view of how the entre program is going, and still have most of the day free for coordination and planning activities.
  • The team is small. You can’t have an Agile team with 30 people on it. Do not do this. It does not work.
  • The story board is not that complicated. This is about the limit of complexity for a story board that I am comfortable with. Past this is drudgery. If your storyboard has the colors of a Christmas tree and a sufficient number of post-its to draw a 40-foot picture of Godzilla, you’re over-complicating things. Stop that.
  • It’s a problem-solving exercise. Immediately after the stand-up is over, the Product Owner talks to anybody with questions or problems and works them out.
  • We work out problems visually. Notice how they pull the story/task over to the flip-pad and work through the problem? See how the options and structures are all presented visually? Here’s a tip: doodling or drawing structures and flow on paper has about a hundred times more effectiveness that trying to write it down or vocally discuss it. Model things.
  • Big Picture is not present. Nobody is looking at long-range issues. Nobody is talking about things happening 4 months from now. Nobody is tapping their foot and asking “are you through yet?” The entire thing works on local optimization. That means that inside of sprints teams locally optimize to finish their commitments. It’s only at the boundary of sprints — demos, retros, and IPAs — that the big picture is important.

Finally, notice it doesn’t match the video. The perfect Agile/Scrum stand-up demonstration does not exist. Teams are different. Everybody has to adapt. As I said in the beginning, Agile is all about adapting. The point is to try things the “best” way — as the community has determined them — and then adapt for your particular situation. That way you don’t miss out on anything, and you also have good reasons for the way you’ve adapted.

Want to rock out your Agile team? Here are the e-books for you.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

BigCorp Agile and Feedback Loops

I’m working with a new large client — a great company with outstanding folks which will go unnamed — and I’ve had a bit of troubling adapting to the corporate world after a year or so working startups and providing Agile coaching advice to small teams. After thinking about it for a while, I believe it all boils down to feedback loops.

Continue reading

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

The Other End of the Telescope

Ran across a very insightful quote the other day that I’m going to mangle and paraphrase:

The main goal for a technology team isn’t the product, it’s the recipe for the product.

Many times we act like the way technology is put together is known: all we have to do is come up with a list of things that need doing — creating this list is where we add value. How we work together, how large groups create a dynamic, productive environment is simply a matter of learning something and repeating it.

The opposite is true. Creating technology to meet some random list of things is a trivial exercise — sometimes a painful, never-ending, death-march, but a trivial exercise. There isn’t a lot of creativity going on. Heck, most of the time there isn’t a lot of computer science going on either, just connecting up the wires. The part that we add creativity to is putting together all of the different people we have in this particular situation and with this particular problem in such a way that the solution happens quickly and people are pleased with the result.

We have shortcuts that sometimes work — a lot of agile is about creating and sharing those shortcuts — but sometimes they don’t work. I’m seeing a lot of Kanban being used in certain situations because sometimes it beats Scrum. Sometimes not.

The technical part of technology development turns out to be a no-brainer: any decent programmer can do a heck of a lot of things. The people and process part of technology — the part they teach you in various classes, seminars, and business schools — turns out to be so brutally non-trivial that huge organizations fail for lack of mastering it. I believe the reason why is that once we take the class or get the certification we believe we understand it when in fact we do not.

It occurs to me in technology development that most times we don’t even know what the important problems are that we are solving, focusing on the technical, easy-to-grasp instead of the social, difficult-to-work.

If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.