Posts

Showing posts with the label retrospective

The BS Line

Image
Consider that everyone has in their mind a fuzzy line: On the left side of the line is what we like to call "the real work" (abbreviation: RW). It's what we get to do . It's the value we provide to the world. It is usually about 30-40% of the work we do, which pays homage to Gall's observation about the inefficiency of human systems. The stuff to the right of the line is what we call "bureaucratic silliness" (abbreviation: BS).  It is the stuff we have to do.  These are things we do out of obligation (when reminded), or to satisfy the internal "process police." These things feel like nonsense that we have to deal with because that's the price of being a developer, tester, manager, whatever we consider ourselves to be. The Difference We tend to take on Real Work happily and go right to it. It allows us to practice and pursue the skills that define who we are in the workplace. They further the goals of the company, the customer, a...

The Best Job They Know How To Do

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand. -- "The Retrospective Prime Directive" by Norm Kerth Software, as Dr. Ralph Johnson informed us, is distilled experience. Writing software, Ray Scheufler reminds us, is a process of making decisions. To make decisions, we have to understand the system we're working in, and the consequences of our decisions. That means that most of the work of a programmer is learning, and very little of it actually involves typing. Understanding any existing body of software is involves understanding the domain,  the user being served,  the specific problem being solved,  the solution chosen,  the techniques of safe software development,  the organization producing the project, and  the technology (language, operating system, network...

A LeanPub book for Scrum Masters?

Image
I've had a side-project that started because I've been working with dual-role (and one triple-role) Scrum Masters lately. I appreciate how hard it is for them to be good at several things simultaneously. Once I started collecting techniques for them, I figured I should publish it somehow. I was thinking of a blog, but Joshua Kerievsky (our leader at IndustrialLogic ) had mentioned possibly using something like LeanPub. I really need to learn to release a product early and use feedback to guide it to be something that really addresses a market need. I've invested some odd hours here and there on this, and have gotten some friends to look it over. Sadly, most of them who are dual-role SMs haven't had time. Still, here is a chance for me to learn in a lean startup kind of way, releasing early and often, and let the market help me develop the product further. I'm interested in hearing what you think of the cover, and the idea in general. I've not...

Retrospectives: What was that about hats, again?

Image
Did you watch Monty Python's The Meaning Of Life ?  There is a great scene that takes place in the Very Big Corporation of America, excerpted here: CHAIRMAN: ...Item six on the agenda: the meaning of life. Now, uh, Harry, you've had some thoughts on this. HARRY:  That's right. Yeah, I've had a team working on this over the past few weeks, and, uh, what we've come up with can be reduced to two fundamental concepts. One:  people are not wearing enough hats.  Two: matter is energy. In the universe, there are many energy fields which we cannot normally perceive. Some energies have a spiritual source which act upon a person's soul. However, this soul does not exist ab initio, as orthodox Christianity teaches. It has to be brought into existence by a process of guided self-observation. However, this is rarely achieved, owing to man's unique ability to be distracted from spiritual matters by everyday trivia. [pause] BERT: What was that about hats, again? T...

The First Puzzle Challenge

Image
Today we held the first ever Puzzle Challenge at my client's site. The goal of the challenge was for each team to pick a work style that aided them in getting the greatest number of puzzles completed in a very short time (10 minutes per sprint). The set of puzzles to solved was a mix of crosswords, mazes, word-search, sudoku, word jumbles, and number blocks. The teams were told that there was no partial credit at the end of the ten minute sprint. The teams were given a menu of practices to choose from: Team members could one mode of adaptation, leadership, teamwork, noise level, and task switching. A style of 11111 would mean a 1 in each of these categories, a style strongly resembling an "ideal" organization in the buttoned-down 80s. A style of 33333 is basically a productive chaos, which might have been more widely recommended in the free-spirited 60s. Teams made an initial selection, then were allowed some adaptation. In initial selection of work s...

Free, Cheap, Scheduled: retrospective technique

Image
I was telling Esther Derby about a little trick I worked out some time ago at one of my clients. The retrospectives had gone stale, with team members offering the same "we should..." list iteration after iteration.  I suspected that they didn't feel that they really had the authority or permission to change their process for the better. I had a good relationship with the CIO and wandered into his office. I said, "we have some changes we want to make, and they won't really cost any money or affect other departments, and I just wondered if you think it would be okay to do them."  The CIO looked at me incredulously, "Of course. That's a silly question to ask." "Alright, then there is this other change.  It might take a few man days out of each iteration, but it will be helpful for the team.  Would that be okay?"  He sighed, "If it's a few man days per iteration, we can afford that. Go ahead and take that time. You don'...