Ready to get started?  Request Workshop Date
Ready to get started?  Request Workshop Date



These questions just keep popping up, so I figured I'd share them with everyone. If you have a question that isn't covered here, please contact me and I'd be happy to answer any questions you have.

Q: Is it just you or do you work with others?

A: The Company is just me, and is incorporated in the state of Indiana! I will occasionally work with other trusted consultants when some really niche requirements come my way, but I find that the administrative overhead of running a company with dozens of employees (I tried that) distracts me from pursuing something amazing with my clients. Helping my clients create empires is more important than creating an empire of my own.

Q: How long have you been consulting?

A: I've been consulting since leaving the military in 2004, so 12 years. However, I spent part of my time in the military as a Software Project Manager, so that's about 16 years of relevant work experience.

Q: How do you feel about process improvement?

A: I like that question, and I'm going to use this opportunity to be snarky. I don't care for process improvement, but I LOVE performance improvement. Agile frameworks are resistant to process because of how inappropriately designed many processes tend to be. Some things must be process driven to improve performance, some things can be process driven, and some things absolutely cannot and should not be driven by process. I have extensive experience with Agile CMMI and enjoy working with organizations to evaluate where process is needed, and where it should be excluded.

Q: Woah... CMMI? I thought CMMI only existed to stifle innovation!

A: Here is the deal about CMMI. CMMI tells you "what" to do but not "how" to do it. How you choose to align with certain areas of the model is entirely up to you. No CMMI Appraiser will tell you that you're wrong for leveraging Agile. What they will do is quickly identify whether or not what you're doing is Agile, or if you're trying to call yourself "Agile" to hide the fact that your software development organization is really the wild-wild west generating cowboy-code. We can talk all day about this as it is an area of key interest to me.

Q: What Agile engineering techniques do you recommend to your clients?

A: There is absolutely no cookie-cutter approach to recommending Agile engineering techniques. It all goes back to Synthesis... taking in every observable aspect of your company, and synthesizing a solution. For some it is Scrum + Pair Programming. For others it may be Agile Unified Process + Test-Driven Development, or Kanban + Feature-Driven Development. Too many Agile consultants have "favorites" which severely limits their client's potential. The tool bag I bring has no limitations or prejudices. The correct recommendation is the one that works!

Q: Are you going to make us put sticky notes all over the place?

A: You bet I am! There is actually a very good reason Agile teams use sticky notes that I'll be happy to discuss over a pile of sticky notes.

Q: How does Agile Project Management work?

A: It is all based upon an evaluation of project management needs... emphasis on the word "needs". By implementing project management functions that support only what is needed, you remove extraneous processes and functions that are wasteful and exist only to perpetuate the existence of the process. Agile Project Management is complimentary in nature to all other Agile functions and I design it to be the vessel that bridges the gap between senior leaders, and Agile teams.

Q: What is the difference between a "product" and a "project"

A: Uh oh... now you've gone and done it. You're going to have the Scrum Masters and Project Managers of the world writing me nasty emails for a month. In short... a "product" is what you are trying to create, and a "project" is one of many ways you can organize work that ultimately leads to the creation of the product. In the Agile world, we don't generally think in terms of projects. Not because we don't want to, but because planning detailed work out as far as traditional project management methods require is not useful to Agile teams. Agile teams think often in terms of Sprints (1-4 weeks) and Releases (2-4ish Sprints). The great thing is that Stories, Epics, Sprints, Releases, Projects, Programs, Portfolios, and everything else under the sun can all co-exist and they all serve a purpose!

Q: What is an Agile ceremony?

A: One of the many contributing factors to the success of Agile is that product development happens on a cadence, or a pattern, if you will. Agile ceremonies are the predictable events that reinforce the pattern and ensure critical activities are occurring when they are supposed to occur. Now ask me your next question which is...

Q: Do we need to do all the Agile ceremonies?

A: One of the other contributing factors to the success of Agile is that it reinforces collaboration and communication over processes and documentation. The ceremonies exist to provide opportunities to collaborate and communicate. The rigor with which ceremonies are required depends largely on that Synthesis we keep talking about. A company with teams that naturally communicate and collaborate well may only need a daily standup, sprint planning and retro, for instance. One that has barriers to communication and collaboration may need more at first. One thing I promise I won't do is blindly and arbitrarily throw the Agile ceremony book at you and have you spending more time in meetings than with your hands on the keyboard!

Q: Favorite color?

A: Clothing: Blue, Sharpie: Red, Crayon: Purple, Sticky notes: the one that isn't quite red but not quite magenta either, Dry Erase Marker: Which ever one isn't dried out and not working and doesn't squeak when I write on the board with it.

For Immediate Assistance:
Call 318-572-0110 or Email at
Copyright 2018 Chris Kimball, Inc. | All Rights Reserved | Web Design Indiana | SFP