Lessons from Kent Beck and Martin Fowler’s “Planning Extreme Programming”

The first edition of “Planning Extreme Programming” by Kent Beck and Martin Fowler was published about 18 years (that long) ago, and already it says so much about how planning for software projects can be done well. It talks about programmers and customers, their fears and frustrations, their rights and responsibilities, and putting all those knowledge into a planning style that can work for development teams. It doesn’t have to be labeled XP, but it does need to help people be focused, confident, and hopeful.

Here are some noteworthy lines from the book:

• Planning is not about predicting the future. When you make a plan for developing a piece of software, development is not going to go like that. Not ever. Your customers wouldn’t even be happy if it did, because by the time the software gets there, the customers don’t want what was planned; they want something different.
• We plan to ensure that we are always doing the most important thing left to do, to coordinate effectively with other people, and to respond quickly to unexpected events.
• If you know you have a tight deadline, but you make a plan and the plans says you can make the deadline, then you’ll start on your first task with a sense of urgency but still working as well as possible. After all, you have enough time. This is exactly the behavior that is most likely to cause the plan to come true. Panic leads to fatigue, defects, and communication breakdowns.
• Any software planning technique must try to create visibility, so everyone involved in the project can really see how far along a project is. This means that you need clear milestones, ones that cannot be fudged, and clearly represent progress. Milestones must also be things that everyone involved in the project, including the customer, can understand and learn to trust.
• We need a planning style that
  • Preserves the programmer’s confidence that the plan is possible
  • Preserves the customer’s confidence that they are getting as much as they can
  • Costs as little to execute as possible (because we’ll be planning often, but nobody pays for plans; they pay for results)
• If we are going to develop well, we must create a culture that makes it possible for programmers and customers to acknowledge their fears and accept their rights and responsibilities. Without such guarantees, we cannot be courageous. We huddle in fear behind fortress walls, building them ever stronger, adding ever more weight to the development processes we have adopted. We continually add cannonades and battlements, documents and reviews, procedures and sign-offs, moats with crocodiles, torture chambers, and huge pots of boiling oil. But when our fears are acknowledged and our rights are accepted, then we can be courageous. We can set goals that are hard to reach and collaborate to make those goals. We can tear down the structures that we built out of fear and that impeded us. We will have the courage to do only what is necessary and no more, to spend our time on what’s important rather than on protecting ourselves.
• We use driving as a metaphor for developing software. Driving is not about pointing in one direction and holding to it; driving is about making lots of little course corrections. You don’t drive software development by getting your project pointed in the right direction (The Plan). You drive software development by seeing that you are drifting a little this way and steering a little that way. This way, that way, as long as you develop the software.
• When you don’t have enough time you are out of luck. You can’t make more time. Not having enough time is a position of helplessness. And hopelessness breeds frustration, mistakes, burnout, and failure. Having too much to do, however, is a situation we all know. When you have too much to do you can prioritize and not do some things, reduce the size of some of the things you do, ask someone else to do some things. Having too much to do breeds hope. We may not like being there, but at least we know what to do.
• Focusing on one or two iterations means that the programmers clearly need to know that stories are in the iteration they are currently working on. It’s also useful to know what’s in the next iteration. Beyond that the iteration allocation is not so useful. The real decider for how far in advance you should plan is the cost of keeping the plan up-to-date versus the benefit you get when you know that plans are inherently unstable. You have to honestly asses the value compared to the volatility of the plans.
• Writing the stories is not the point. Communicating is the point. We’ve seen too many requirements documents that are written down but don’t involve communication.
• We want to get a release to the customer as soon as possible. We want this release to be as valuable to the customer as possible. That way the customer will like us and keep feeding us cookies. So we give her the things she wants most. That way we can release quickly and the customer feels the benefit. Should everything go to pot at the end of the schedule, it’s okay, because the stories at risk are less important than the stories we have already completed. Even if we can’t release quickly, the customer will be happier if we do the most valuable things first. It shows we are listening, and really trying to solve her problems. It also may prompt the customer to go for an earlier release once she sees that value of what appears.
• One of the worst things about software bugs is that they come with a strong element of blame (from the customer) and guilt (from the programmer). If only we’d tested more, if only you were competent programmers, there wouldn’t be these bugs. We’ve seen people screaming on news groups and managers banging on tables saying that no bugs are acceptable. All this emotion really screws up the process of dealing with bugs and hurts the key human relationships that are essential if software development is to work well.
• We assume that the programmers are trying to do the most professional job they can. As part of this they will go to great lengths to eliminate bugs. But nobody can eliminate all of them. The customer has to trust that the programmers are working hard to reduce bugs, and can monitor the testing process to see that they are doing as much as they should.
• For most software, however, we don’t actually want zero bugs. (Now there’s a statement that we guarantee will be used against us out of context.) Any defect, once it’s in there, takes time and effort to remove. That time and effort will take away from effort spent putting in features. So you have to decide which to do. Even when you know about a bug, someone has to decide whether you want to eliminate the bug or add another feature. Who decides? In our view it must be the customer. The customer has to make a business decision based on the cost of having the bug versus the value of having another feature – or the value of deploying now instead of waiting to reduce the bug count. (We would argue that this does not hold true for bugs that could be life-threatening. In that case we think the programmers have a duty to public safety that is far greater than their duty to the customer.) There are plenty of cases where the business decision is to have the feature instead.
• All the planning techniques in the world, can’t save you if you forget that software is built by human beings. In the end keep the human beings focused, happy, and motivated and they will deliver.

Advertisements

Lessons Learned from Scott Adams’ “How to Fail at Almost Everything and Still Win Big”

Last week I had a lovely time reading “How to Fail at Almost Everything and Still Win Big” by cartoonist Scott Adams. His views on success and happiness, and his formula for increasing the odds of success through failures are intriguing, based on his life experiences. He shares ideas about goals and systems, skills, happiness, priorities, and personal energy, which provides a guide for living well. Some of those ideas are ones I already exercise, while others have provided answers to goals that have failed me in the past as well as reasons to why I’ve acted a certain way before. It’s refreshing to learn something new about existing patterns of behavior.

Here are some favorite quotes from the book:

• A goal is a specific objective that you either achieve or don’t sometime in the future. A system is something you do on a regular basis that increases your odds of happiness in the long run. If you do something every day, it’s a system. If you’re waiting to achieve it someday in the future, it’s a goal. Goal-oriented people exist in a state of continuous pre-success failure at best, and permanent failure at worst if things never work out. Systems people succeed every time they apply their systems, in the sense that they did what they intended to do. The goals people are fighting the feeling of discouragement at each turn. The systems people are feeling good every time they apply their system. That’s a big difference in terms of maintaining your personal energy. Goals only make sense if you also have a system that moves you in the right direction.
• One of the most important tricks for maximizing your productivity involves matching your mental state to the task. For example, when I first wake up, my brain is relaxed and creative. The thought of writing a comic is fun, and it’s relatively easy because my brain is in exactly the right mode for that task. I know from experience that trying to be creative in the mid-afternoon is a waste of time. By 2:00 PM all I can do is regurgitate the ideas I’ve seen elsewhere. At 6:00 AM I’m a creator, and by 2:00 PM I’m a copier.
• The way I approach the problem of multiple priorities is by focusing on just one main metric: my energy. I make choices that maximize my personal energy because that makes it easier to manage all of the other priorities. Maximizing my personal energy means eating right, exercising, avoiding unnecessary stress, getting enough sleep, and all of the obvious steps. But it also means having something in my life that makes me excited to wake up.
• It’s useful to think of your priorities in terms of concentric circles, like an archery target. In the center is your highest priority: you. If you ruin yourself, you won’t be able to work on any other  priorities. So taking care of your own health is job one. The next ring – and your second-biggest priority is economics. That includes your job, your investments, and even your house. You might wince at the fact that I put economics ahead of your family, your friends, and the rest of the world, but there’s a reason. If you don’t get your personal financial engine working right, you place a burden on everyone from your family to the country. Once you are both healthy and financially sound, it’s time for the third ring: family, friends, and lovers. Good health and sufficient money are necessary for a base level of happiness, but you need to be right with your family, friends, and romantic partners to truly enjoy life.
• There’s a formula for success. You can manipulate your odds of success by how you choose to fill out the variables in the formula. The formula, roughly speaking, is that every skill you acquire doubles your odds of success. Good + Good > Excellent. If you think extraordinary talent and a maniacal pursuit of excellence are necessary for success, I say that’s just one approach, and probably the hardest. When it comes to skills, quantity often beats quality.
• I find it helpful to see the world as a slot machine that doesn’t ask you to put money in. All it asks is your time, focus, and energy to pull the handle over and over. A normal slot machine that requires money will bankrupt any player in the long run. But the machine that has rare yet certain payoffs, and asks for no money up front, is a guaranteed winner if you have what it takes yo keep yanking until you get lucky. In that environment, you can fail 99% of the time, while knowing success is guaranteed. All you need to do is stay in the game long enough.
• The single biggest trick for manipulating your happiness chemistry is being able to do what you want, when you want. I’m contrasting that with the more common situation, in which you might be able to do all the things you want, but you can’t often do them when you want. The timing of things can be more important than the intrinsic value of the things. It’s hard to become rich enough to buy your own private island, but, relatively speaking, it’s easier to find a job with flexible hours. A person with a flexible schedule and average resources will be happier than a rich person who has everything except a flexible schedule. Step one in your search for happiness is to continually work toward having control of your schedule.
• No one wants to believe that the formula for happiness is as simple as daydreaming, controlling your schedule, napping, eating right, and being active every day. You’d feel like an idiot for suffering so many unhappy days while not knowing the cure was so accessible.
• The happiness formula:
  • Eat right
  • Exercise
  • Get enough sleep
  • Imagine an incredible future (even if you don’t believe it)
  • Work toward a flexible schedule
  • Do things you can steadily improve at
  • Help others (if you’ve already helped yourself)
  • Reduce daily decisions to routine
• Always remember that failure is your friend. It is the raw material of success. Invite it in. Learn from it. And don’t let it leave until you pick its pocket.

Takeaways from Rob Lambert’s “How To Thrive As A Web Tester”

Rob Lambert released a new book on testing early this year, with title “How To Thrive as a Web Tester“. Like “Remaining Relevant and Employable in a Changing World” and “The Problems with Software Testing“, the new book only takes a few hours to read through and is focused, this time offering ideas which challenges testers to think more about how they perform their day-to-day work and their skill set. Rob wants us to flourish as testers, and the book provides us with tidbits of actionable items.

Here are a few gems from the book:

• Understand who your customer is.
• Your job is to keep up to date with what’s happening, ask how it might affect your job or how you approach testing. Your job is to get involved with new ideas, movements and embrace the technology that floats your boat.
• Pick something and learn it. It will likely be out-of-date soon, or surpassed by something else. Don’t let that stop you though – just pick something and learn it. What never goes out-of-date is a Tester’s ability to find problems, ask tough questions and work well with others. Focus on developing those skills and you’ll make a great Tester whatever the tech stack you’re working on.
• The tech moves on, the way we deliver it has moved on, the pace of delivery may change but the same problems exist; how to get people to work well together, how to understand customer’s needs, how to scale, how to make profit, how to dominate a market, how to learn, how to build an effective and efficient businesses, how to stop bugs affecting customers. Same problems, different tech.
• Your job is to ship software. Sure, if there are problems that will affect the customer or company, you’ll stop the release, but you’ll also work tirelessly to see how you can improve to allow safer releases, better monitoring, better rollbacks, better roll forwards and a more seamless release mechanism.
• You need to remain relevant, employable and effective to a wider business community. You cannot rely on your employers for your career development and security – that is your own responsibility.
• Let go of your job role, or what your job description says, and take ownership of the actual work and any problems that surround it. Take on problems others aren’t owning. Or offer to help those struggling with fixing tricky problems at work. There are always problems, and most problems exist between job roles.
• Testing is the art of asking questions and seeking answers. Never stop asking questions. Study how to ask good questions. Study how to listen for answers. They can come from anywhere, at any time. Good Testers know when to ask questions. They build the muscle memory needed to match patterns, to know when and where to ask, to know what to ask, to know who to ask, and to follow instincts.
• Good Testers solve problems. Even problems that are outside of the responsibility of Testers.
• If you aren’t as good as you can be, it’s because you haven’t yet decided to be the best version of yourself yet. It’s as simple as that.
• We are all, thankfully, different. There is no single model we should all fit. The world would be a pretty dull place if that were the case.

The Harajuku Moment

On a chapter from Timothy Ferriss‘s book titled “The 4-Hour Body“, he talks about something significant called the Harajuku moment, described as:

.. an epiphany that turns a nice-to-have into a must-have.

The expression actually came from a realization Chad Fowler (programmer, writer, co-organizer of RubyConf and RailsConf) had in Harajuku with friends some time in the past, while window shopping and lamenting how unfashionable he was. He noticed the tone of helplessness in his own words as he talked about his obesity, and felt angry at himself for being an idiot who went with the flow, making excuses, for many years.

After that defining moment, he turned things around and lost nearly a 100 pounds.

Two years in a row of annual physical exams (2015-2016), I was told that I have hypertension. The previous years I also felt that I tire quickly, becoming more so as the days went by. I’m just over 30, skinny, and believed that I should still be in my prime but was not. I wondered why things turned out the way they did, and eventually recognized that existing habits did not help me become the healthy person I thought I was.

I’m now performing weight-lifts and body-weight exercises 4 times a week, and is in my best shape in the past 10 years or so. What’s interesting is that making the change was actually fun and somewhat easy, very unlike the grueling and exasperating experience I initially thought it would be. I plan to keep things up, gaining as much strength as I can and keeping body fat percentage minimal.

What the Harajuku moment tells us is that, often, on most days, we have insufficient reason to take action. We only have nice-to-haves. We tell ourselves it would be nice to get fit, go on a date with that someone we really like, have a well refactored code, travel internationally, or learn a new skill. But the nice-to-haves do not give us enough pain to move forward. That’s why we sometimes feel we’re stuck in a rut.

Our nice-to-haves must first turn to must-haves before we can take advice and act.

Favorite Talks from Agile Testing Days 2017

There are two things that’s wonderful from last year’s Agile Testing Days conference talks: content focusing on other valuable stuff for testers and teams (not automation), and having as many women speakers as there are men. I hope they continue on with that trend.

Here’s a list of my favourite talks from said conference (enjoy!):

• How To Tell People They Failed and Make Them Feel Great (by Liz Keogh, about Cynefin, our innate dislike of uncertainty and love of making things predictable, putting safety nets and allowing for failure, learning reviews, letting people change themselves, building robust probes, and making it a habit to come from a place of care)
• Pivotal Moments (by Janet Gregory, on living in a dairy farm, volunteering, traveling, toastmasters, Lisa Crispin, Mary Poppindieck and going on adventures, sharing failures and taking help, and reflecting on pivotal moments)
• Owning Our Narrative (by Angie Jones, on the history of the music industry so far, the changes in environment, tools, and business models musicians have had to go through so survive, and embracing changes and finding ways to fulfil our roles as software testers)
• Learning Through Osmosis (by Maaret Pyhäjärvi, on mob programming and osmosis,  creating safe spaces to facilitate learning, and the power of changing some of our beliefs and behaviour)
• There and Back Again: A Hobbit’s/Developer’s/Tester’s Journey (by Pete Walen, on how software was built in the old days, how testing and programming broke up into silos, and a challenge for both parties to go back at excelling at each other’s skills and teaming up
• 10 Behaviours of Effective Agile Teams (by Rob Lambert, about shipping software and customer service, becoming a more effective employee, behaviours, and communicating well)

Notes from Scott James’ “Bony to Brawny: No B.S. Techniques To Stack On Slabs Of Lean Muscle Mass And Get Strong As Hell Regardless Of How Skinny You Are”

I have always been a skinny dude. And I have always thought that I won’t change, that it’s just the way things are for me. But keeping the same diet and sedentary lifestyle for many years has taken its toll in recent years and, although I have not been sickly, my energy levels just did not feel the same as it has been when I was younger. I tire easily now than before, even when I don’t really go out much. Perhaps it’s just age doing its thing, like we are supposed to get tired faster as we get older. But it is a nagging feeling, it does not feel good at all, and is something that I decided I want to find a sustainable way of correcting this year if possible.

Reading Scott James’ ‘Bony to Brawny‘ book (and actually changing diet and exercise habits) is taking multiple steps forward towards that goal.

Some takeaways from the book:

• The funny thing is I have literally never regretted a workout – it just doesn’t happen. The release of endorphins and the feeling of knowing you’re making progress towards your goals while improving your health, mobility, and well-being is intense.
• If you’ve been skinny all your life, chances are you haven’t been eating much in terms of calories. When you’re entering a bulking phase, the amount of food may seem overwhelming. Focus on liquid nutrition. Consuming two shakes (depending on how many calories you incorporate) plus two solid meals will without a doubt place you in a the caloric range you need to be hitting to pack on some solid lean muscle mass.
• There is no food out there that’ll make you gain muscle at a quicker rate than another food. The food itself won’t build muscle – the calories and macro-nutrients it contains will. Try fish, chicken breast, eggs, cottage cheese, almonds, brown rice, milk, and sweet potatoes.
• Eating fat will not make you fat at all. Fat is essential for regulating hormones. Excess calories make you fat – not any particular macro-nutrient itself (protein, carbohydrates, or fat).
• For optimal performance in sports and resistance training, as well keeping your appetite in check, consumer at least 30% of your daily calories from protein, with the remaining 70% coming from a breakdown of carbs and fats. If you neglect your protein intake you will not be able to be able to build and retain lean muscle; if all you’re eating is carbohydrates and fat, you’ll be packing on the pounds in the form of stored body fat.
• In order to build that muscle mass and shred that fat, you need to create the demand for your body to do so. After ongoing demand, your body begins to adapt, and adaption is growth. This demand is solely created inside the gym – i.e. lifting heavy weights! An exercise regime based on compound movements will force your body to adapt – heavy squats, deadlifts, bench presses and overhead presses in the low rep range will create the demand far better than any isolation based workout regime based around light dumbbells or machines.
• Without a caloric surplus, you won’t pack on any muscle mass. At the same time, if lifting is neglected and dieting is honed in on to the utmost detail, you’re still on the road to fat gain as your body is not being forced to adapt and grow (using this caloric surplus to repair your body and build muscle)
• As a newcomer, you will find the demand is quite easy as your body has never experienced such stress before. However, as time goes on, you must apply progressive overload in order to keep the demand going. Increasing the weight you’re lifting, increasing the time your muscles are under tension, adding in a few additional reps – these techniques are designed to place an increased load on your muscles each and every workout. In essence, the demand must become greater and greater with each workout. When you’re demanding the same thing from your muscles week after week (same weight, same reps, same time under tension), the demand to go above and beyond has vanished, and so will your progression in terms of size and strength). The guys in the gym repping the same weight week in week out won’t get far. The guy adding that extra 2.5 lb plate to the barbell each workout will. It adds up over time.
• In order to get big you need to focus your energy on your heavy compound movements. Don’t major in minors, aka: spending your time floating around from isolation exercise to isolation exercise. This is a sure-fire way for a skinny guy to see sub-par size gains. Movements or exercise that do not give the muscles the required resistance, but are the kind that involve a great number of repetitions, never break down any tissue to speak of. These movements involve a forcing process that cause the blood to swell up the muscle, and simply pump them up. The insane, full, pumped feeling you get in your arms and chest when training is merely the increased blood flow tot the particular muscle group being worked. The pump does not equate to muscle growth.
• If you’re new to low rep training, it’s worth noting that you will not get the immense pumps you may be used to from performing high repetition training. As a general rule, most things that are satisfying in the short term aren’t beneficial at all in the long run.
• Once you are comfortably hitting the top end of the rep range, I recommend increasing the weight. You should be able to perform a minimum of four reps with the new weight. If you’re unable to perform four reps with correct form and range of motion, the weight is too heavy. Add 5 lbs/10 lbs to each dumbbell/barbell exercise once you are comfortably hitting the upper range of the prescribed repetitions.
• Each and every repetition should be controlled and timed. 2 seconds down – 1 second hold – 2 seconds up. If you’re performing your repetitions any faster than this, your muscles won’t be under tension for particularly long. To ensure you get the maximum bang for the buck in terms of size and strength, focus on the 2:1:2 tempo. Rest for 2-3 minutes between sets of heavy compound exercises. Rest for 1-2 minutes maximum between sets of isolation exercises.
• We don’t build muscle in the gym by banging and clanging around with heavy weights. We’re actually destroying our muscle fibers – which is telling our bodies that our current physique is insufficient. Resting after a workout and the nutrition components of your bulking phase are where the growth comes from. Lifting four times per week with adequate sleep and recovery will net you far greater results than training six times per week with minimal sleep and no downtime.
• Sleep plays a key role in the following bodily processes: regulation of glucose in the body, promoting good blood pressure, the perfect way to recover and repair damaged muscles, promoting hormonal functions and processes, promotion cognitive functions and processes. Your sleep should be within the 7-9 hour  bracket per night, keeping in mind this is high quality, uninterrupted sleep.
• If you’re not making any size gains, this will be the result of one of two things:
  • You’re not lifting heavy enough. In order to grow, we need to provide ongoing progressive overload during our workouts. Ensure you’re working in the prescribed rep ranges for your heavy compound exercises and give it your all. If you’re calling it quits on your set when it starts to feel uncomfortable, you’re not going to get too far.
  • If you’re lifting regime is solid, then the issue is likely to be related to your diet, or most specifically the lack of calories you’re consuming. A failure to build muscle mass is most commonly due to an insufficient number of calories coming in. Re-calculate your total daily energy expenditure and apply a more aggressive caloric surplus if necessary.
• Pick a workout routine, follow it, eat well, and get adequate rest. Follow this consistently for six months. During the course of this time, track your weight, your body fat, your arm size, your chest size, how you feel after each workout, and from there you can reassess and make the necessary changes.
• When your progress slows down or completely stops, whether this be in strength gains, shedding that unwanted body fat or gaining muscle mass, it’s time to take a step back and look at what you’re actually doing. Doing the same thing over and over again while expecting a different outcome is the definition of insanity.
• Progress is the ultimate motivator. It’s the positive feedback loop of putting in effort, seeing results and therefore continuing to grind away day after day because you know what you’re doing is making a difference.

One Room, Working Together

For the past few weeks a number of programmers and myself have been tasked to build an initial prototype for a system rewrite project, handed to us by management. The merit of such project is a matter of discussion for another day; for now it is enough to say that the team has been given a difficult challenge, but at the same time excited about the lessons we knew we will gain from such an adventure.

There’s been several takeaways already in terms of technology know-how – dockerized applications, front-end development with Vue, repositories as application vendor dependency, microservices – just several of the things we’ve never done before.

But the great takeaway so far is the joy of literally working together, inside a room away from distractions, the team working on one task at a time, focused, taking turns writing application or test code on a single machine, continuously discussing options and experimenting until a problem is solved or until it is time to take a break. We instantly become aligned at what we want to achieve, we immediately help teammates move forward, we learn from each other’s skills and mistakes, we have fun. It’s a wonder why we’ve never done much of this before. Perhaps it’s because of working in cubicles. Perhaps it’s because there’s nearly not enough available rooms for such software development practice. Perhaps it’s because we’ve never heard anything about mob programming until recently.

I’m sure it won’t be everyday since we have remote work schedules, but I imagine the team spending more days working together like this from here on.