Proud sponsor of the Agile Lean Europe Network 2011 conference
Do you feel stuck? When most people want to improve, they try doing more, and before long, even the smallest tasks drag on forever. Do you remember when you could just get things done? I can help you recapture those days.
Call us now 1 888 OK-JBRAINS (655-2724)
My name is J. B. Rainsberger and I can help you profit sooner from your software projects.
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.
Could your business benefit from advice like this?
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.
C.S.
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 specialise 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.
If you know what to do, and even how to do it, but something keeps 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. 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 and learn more about it every day. 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 realise 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.
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.
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.
I had intended to write an InfoQ article looking back at ten years of agile software development, but I never completed one. Instead, I found these notes, and I wanted to at least try to spark some conversation around the ideas. I would dearly love to learn about counterexamples and face dissenting view points. Don’t hold back.
Over the last few years I have felt a drastic and surprising improvement in how I feel about work. I can trace a lot of this benefit to one simple technique.
Time and again I see clients struggling to complete work because they struggle to find enough contiguous time to complete a meaningful piece of work. I empathise, since I experienced this for the first time when I began to establish myself as a technical leader at IBM. As more people sought my advice, my time… Read more…
When I started applying the ideas from Getting Things Done, I felt confused in spots. What’s a project? What’s a goal? What makes them different? I share my working definitions of the terms, ones that have made the distinction crystal clear for me.
Absolute, or universal, claims make for easy targets: a single counterexample causes them to tumble to the ground. Worse, when your interlocutor defends his claim in spite of your counterexample, then you likely end up in a meta-argument about logic that ends up far afield of the original point. It entertains, but it doesn’t inform. I have made this mistake several times in the past, so I plan to work on that, and I wanted to alert you to the possibility that you could benefit from working on it, too.
It doesn’t matter how “Lean” or “Agile” you work: if you always have too much to do, then sooner or later, it will bury you! If you can’t even find the time to read an article or two a week, how are you going to read and understand the vast lean/agile literature? Simple: you won’t…. Read more…
© 2005 - 2012 J. B. Rainsberger
