when you can’t put your finger on the problem
when you need to apply new skills
when you need to develop new skills
when you need to remind people that they can make a difference
I helped a major government contractor see how to reduce billions of dollars in erroneous insurance and health benefit claims. Their complex COBOL-based system allows, for example, men to qualify for maternity benefits. Over dinner we sketched a plan to replace the most expensive parts of the legacy system gradually and safely, and now they can save their client signficant sums of money in weeks instead of months.
Thx to @jbrains who taught us to apply quality.
One of the most influential things I learnt from @jbrains might have been “controller first”. It allows to worry about nasty details later.
Things you can learn in 7 minutes and 26 seconds. Let’s do one session for each minute, and we have a day filled :)
Every 2-3 years (or often) I feel like my passion/motivation/vision for software dies, then I need to find a “switch” to turn on my internal “engine”. As I see many “dead” developers, I start thinking that it is a sort of “common issue” along the developer’s career path. So this course was a good spark for the end of this year.
Beyond your very strong developer background, your communication skills really impressed me as well as the vision you draw in the participant's mind. Thank you again for this course; you really inspired me.
I think the most interesting take away for me was the experience in handling the complexity in a seemingly small and relatively simple-sounding story. I am sure I will be able to use this experience to good advantage.
Asheesh Nadkarni, who attended Value-Driven Product Development
I was impressed with the tangible examples [in Value-Driven Product Development]—it was more hands on and less theory which I enjoyed thoroughly.
I found (Value-Driven Product Development) to be dynamic and informative—I walked away feeling quite good about what I was exposed to—I am certain to leverage this in the future.
This was what I was searching for for years. Since I got into this productivity thingy I feel like all those bloggers and writers out there are happy people who love to work and don't know anything about motivation problems and depression. Thank you so much!
Thank you so much for the Extreme Programming is People article. One of those things that I feel I read at just the right time and really spoke to me.
Definitely the best video tutorial [I] have ever seen.
Because your talk was so good, I stayed up till 2am to watch the entire thing, and I’m passing it on to my colleague tomorrow.
D.S., who watched Surviving Your Inevitable Agile Transition
@jbrains, you blew my mind—it’s amazing how your advice spans across all areas—from code to business and life.
I heard several attendees that were able to use their new skills already the day after the course—which is quite unusual.
Thank you for this great training [Surviving Legacy Code] and all your advices.
I had some hour-long coaching sessions with J.B., and they totally blew my mind. I mean, t.o.t.a.l.l.y. He definitely knows how to ask questions and how to get you to a point where you believe you came up with all the action items on your own.
Your writings on testing influence my day to day work, and I never miss an opportunity to spread the practices you inspire.
I’ve been pairing with many great developers and in terms of tiny steps and micro commits @jbrains stands as my idol and aspiration.
Watched @jbrains do TDD - like watching a good musician play his instrument. I might know how to do everything he does, just not as fluently.
In my job interview, I quoted you three times. I got the job.
I like courses that go where the audience wants to go.
Course feedback from Rypple
We have been focusing on the Contract Tests that J. B. refers to in Integrated Tests Are a Scam. So far, this has made all the difference for us.
Rick Pingry, Gremlin Games
J. B. has the courage to say the things that aren’t being said and the conviction to stand behind them. And he does this with deep humility, humour and genuine warmth.
I had the unique opportunity to spend about a week with J. B. Rainsberger and Corey Haines, in what proved to be my best learning experience of the last few years.
I’ve seen how design patterns emerge from taking as few decisions at one time as possible. I did not expect to learn that it will have such impact on me and my everyday coding.
Course feedback through Rypple
Who would be the top three speakers on Agile I’d recommend for a great conference? Patrick Kua, Martin Fowler, and J. B. Rainsberger.
Value (of Value-Driven Product Development) in system and process simplification to me: many multiples of $100,000.
It was a real pleasure listening to J. B. Rainsberger talking about TDD and I am sure that all the people present there had a lot to learn from him.
Thanks, J. B., for a great and insightful talk about software development. Seeing the passion you put into bringing this craft to a new level makes me love my job even more.
The course is definitely an eye-opener, even to those versed in traditional TDD mindset; it gives the opportunity to view TDD from a bit of a different angle.
Joe has an amazing grasp on test-driven development and JUnit and has probably the most extensive Java knowledge of any person I have met.
I think that I’ve learned more in this training class than I have in my entire professional programming career.
In a word: intense. Lots of deep insight and wisdom. I’m still processing it all.
Luke Daley, after a workshop
Excited to hear that one of our teams, inspired by @jbrains did a "What's not to like about this code?" session and followed-up with #mobprogramming to fix the issues identified. It worked really well for them.— Marcin Floryan 🇸🇪🇵🇱 (@mfloryan) April 10, 2018
When you don't know exactly what the problems are, nor how to solve them, then you need consulting, and that's exactly the kind of consulting I enjoy doing.
I focus on understanding problems, issues, and obstacles deeply before choosing solutions. When you contact me, I will probably ask you a long list of questions designed to help me understand the problems you want to solve, the issues you want to explore, or the obstacles you want to overcome. Many past clients have asked me to push the wrong solutions at them, and I don't want to do that to you. I don't intend to offer you any solution until I have some confidence that it will help.
I specialize in digging deeply to uncover the root cause of your problems. If you allow me, I will work with you to find those causes and design a plan to help you attack them.
I was at Iowa Student Loan when we moved from Waterfall and VB6 to XP and Java (2003-2004). It was under your guidance that we became one of the most aggressively agile teams in the midwest, according to David Hussman. One of our teams was featured in Gojko Adzic's book Specification by Example due to our extensive investment in FitNesse. You pointed us towards Fit and FitNesse early on. You laid the rails of XP that lead to our long term success. I started to calculate my pairing hours for a talk recently and was surprised to realize that I had over 10,000 hours of pairing. Iowa Student Loan's commitment to pairing and TDD were a direct result of your mentoring, coaching, and zeal.
On a personal note, I wholeheartedly believe that I wouldn't be in software development today if it weren't for the hyper-focused Red-Green-Refactor solutioning cycle. I was terrible at math throughout school, especially with large math problems with multiple moving parts. TDD released me from balancing multiple parts. Once I released a small piece from my focus I was able to freely focus on the next part without any fear of breaking previous parts. It was liberating to maximize the way I thought to create and innovate. XP liberated me. Thank you for putting my career on a firm foundation.
— David Kessler
If you know what to do, and even how to do it, but something seems to keep getting in the way, then you're likely ready for coaching. Sadly, the generic consultants of yesteryear have become the "agile coaches" of today. Everyone who has read a book or two about agile software development has magically become an agile coach. It has become difficult to know whom you can trust. You need to choose very carefully the person you plan to hire to provide this service.
My network of coaches consists of people who understand the craft of coaching. They form real bonds with the people they coach and this bond contributes much to their success in helping people get out of their own way. They incorporate ideas from a multitude of disciplines to help people realize more of their ability. More than simply show you some tips and tricks, they help you understand how you work, what you can improve, and more importantly how to make lasting changes for the better.
You don't need a full-time, on-site coach. In fact, hiring a full-time, on-site coach for months at a time usually wastes considerable money. Having someone on site and full-time subtly encourages the organization to squeeze everything they can out of the coach, usually either by spreading them too thin or by trying to make too many changes at once. Both choices usually fail. I prefer to create a loose, long-term relationship with an organization, working periodically together, and after we establish trust on site, we can usually do a lot of the interesting work over the internet. This saves money, reduces stress, and helps avoid unhealthy co-dependent relationships. Rather than squeeze what you can out of me, you'll have the chance to notice when you no longer need me. Periodic, remote coaching benefits everyone involved.
I spoke with several people about my experience. J. B. Rainsberger was one of them, and after hearing my description of day-to-day life at the office, he recommended Patrick Lencioni's The Five Dysfunctions of a Team to me.
Hit the nail on the head, he did.
— Marjan Venema, "What Trust is Made Of"
If you have already established goals you want to achieve, and have identified that you need to increase your organisation's capacity in some direction, then you're ready for training.
Training, unlike coaching, focuses on increasing your capacity to produce in some way. Production capacity, like your body's muscles, atrophies without development. Even if you don't struggle to keep up with your competition, you will struggle with your customers' increasing demands. You must develop new skills to stop your organisation from shrinking, losing relevance, and shedding customers.
I offer courses like Learning Modular Design Techniques, Making Your Agile Transition Work, Manufacturing Slack, and Product Sashimi. These courses cover all aspects of software development, from the moment you conceive of a new product, through choosing your first set of features, through building and delivering those features and collecting money from satisfied customers.
"Experienced programmers plan, while junior programmers jump into their work. Some simpler personal planning techniques can help you eliminate waste when you work, write less code, design more simply, inject fewer defects, and generally deliver sooner. ... [T]he best way I know to deliver sooner is to do less."
J. B. Rainsberger, "Personal Planning", IEEE Software 2007, no. 1, p. 16.
I enjoy speaking at a variety of conferences, user groups, and meetups around the world. I can provide inspirational talks, discuss new ideas, lead impromptu discussions or present some golden oldies.
For companies that would like to help people feel more comfortable initiating a change program, such as adopting new ways of working, I can offer talks that discuss these sensitive issues. For skeptical audiences or people generally concerned about the magnitude of change involved in "going agile", I recommend Yes, Your Agile Transition Can Work. For overworked audiences who want to improve but simply can't find the time to do anything new, I strongly recommend Manufacturing Slack.
For skeptics who see emergent design as overhead, rather than an investment in increasing the capacity to deliver, I recommend The Economics of Software Design, and if their skepticism reaches more broadly to other aspects of agile software development, consider An Introduction to Agile with the Theory of Constraints.
Of course, if you have a specific topic in mind or a tricky audience you'd like to reach, then tell me about it and I'll design a session that better fits your needs.
© 2005–2018 J. B. Rainsberger