Interview with Andrew Hunt

This time we bring you conversation with a Programmer turned consultant, author and publisher – Andrew Hunt.

Andy is a founder of the Pragmatic Programmers and Agile Alliance. He is one of the original co-authors the Agile Manifesto, and authored several books not just on programming, Agile methods and learning, but also on science fiction and adventure. An active musician and woodworker,  Andy looks for new areas to explore, learn and share.

In this interview, we discussed about what will Agile be beyond 2018.

Q1.  It is almost 17 years ever since Agile has came into existence. Do you believe it has achieved what it aimed for, by the 17 precious minds?

Andy: I think the movement was very successful in some regards, and certainly raised the overall discussion and level of awareness of how we should and should not try to develop software. Some particular practices have seen widespread and successful adoptions, and that’s all great.

However, many organizations are still underperforming and are not able to generate value from their software development projects. They aren’t being effective, and don’t understand what the problem is. They still don’t understand what it means to be Agile.

Worse, perhaps, the major “Agile” methods themselves have not appreciably changed in all these years. The Agile methods themselves don’t seem to be very Agile, ironically.

Q2. Have you ever been disappointed by the way Agile is being implemented in any organization/team and went off track? Please share your experience.

Andy: Constantly. I’ve met teams who’ve claimed “we’re agile, we use Jira/Rally/VersionOne!” Teams where the continuous build runs on Friday. Where version control check-ins only happen once every two weeks. Where the version control system in use is Microsoft Outlook(!). Where the Stand Up meeting runs forty-five minutes. Where rough estimates with insufficient data are taken as contractual, binding promises.

I worked with a team once who was so intent on perfecting their process (XP in this case), that they practically used User Stories on cards to decide on where to go for lunch. In their zeal for Agile adoption, the process itself became the focus of their work, instead of merely a means to an end to deliver product.

Recently I had some developers tell me, with a straight face, that they weren’t allowed to do incremental or iterative development. They could only deliver once, as “gold master” at the end of a multiyear development project. No review, no feedback before then, not even internally. I tried emailing them last week to see how it went, but all the emails bounced.

Apparently they are no longer in business.

Q3. Certification or Experience – it is much discussed among Agile practitioners; what can take anyone’s career to next level, according to you?

Andy: Certification is nonsense. It is a very poor proxy by which to judge past experience or future performance. There is absolutely no substitute for experience, certainly not simple course attendance, or performance on a low-fidelity, written test instrument. There is plenty of research in learning transfer that confirms that common certification assessment approaches simply don’t work.

The whole game of software development is about communications and learning. How well do you communicate to other developers? To the users? To the project sponsors and executives? How fast can you learn? Not just tech, but the evolving system, the dynamics of the team, of the user’s experience, etc.

To get your career to the next level, those are the areas you need to work on. Improve your ability to learn quickly, thoroughly. Improve your critical thinking skills. Learn to be a better listener.

Those are the sorts of things we need assessments on.

Q4. Do you find any myths floating in the community about Agile methodology? Please share 3 such myths that are critical to be eliminated.


  • “This time it will be different.” Oh really? What have you changed? What are you doing differently? Agile is about embracing change and using it for competitive advantage. If you and your team haven’t changed anything—your process, your techniques, your skills—then you’ll struggle to even get the same results as last time. More than likely, results will be even worse.
  • “Best practices.” Best for who? Under what circumstances? In what context? There is no such thing as a general “best practice,” everything depends on context. For example, in what quadrant of the Cynefin space does your problem lie? Different types of problem spaces require different approaches, and a best practice in one area can easily be disastrous in another.
  • “Just do this process.” It is very pleasant to think that if we could just follow this particular process that all our problems would be solved. But that’s an exceptionally naive approach. A process is only one tool in the toolbox. It can help talented, skilled practitioners achieve their goals, but no process is a substitute for thinking. Or for skill.

Q5. What does real Agile mean? If you have to redefine it and introduce back to the community, how would it be?

Andy: Agile is not something you do. Agile is not Scrum, XP, Lean, or the ironically-named “SAFe.” Agile is not Jira. Agile is not git. Agile is not Docker, or DevOps, or functional programming, or any other particular tool or technique.

“Agile Development uses feedback to make constant adjustments in a highly collaborative environment.” (Practices of an Agile Developer, Subramanium & Hunt).

It’s all about feedback. From unit tests and TDD, from users and live systems in the actual user’s context, from fellow developers, from future maintainers. Being Agile means seeking constant, real-time feedback, and acting on it immediately.

A common metaphor that’s used relates Agile to steering a car: a frequent cause of crashes from new drivers is overcorrecting. An inexperienced driver will catch the shoulder of the road and yank the steering wheel violently to the other side, resulting in a crash. And so it is with feedback: small corrections, frequently applied, will steer the project in the right direction. Rapid and violent course corrections can easily result in disaster.

Q6. Where does Agile go from here? What do you wish for it beyond 2018?

Andy: I would like to see an emphasis on individuals and interactions over processes and tools. That’s the first item on the Agile manifesto ( and apparently still one of the hardest to get right. Let’s start with that and really, actually, do it.

Stop abdicating to popular tools, methods, and fads. Do what works for this team, in this context, to produce some small bit of business value constantly. Ship continuously. Learn and improve, continuously. That’s what it’s all about. That’s all you need. And that’s what we’re advocating in our work with The GROWS Method™ ( It’s early still and there is much work to be done, but I’m convinced it’s the only viable way forward.

Q7. Please share your insights on concept of Pragmatic Thinking and Learning.

Andy: Pragmatic Thinking and Learning is a book I wrote in 2008, based on several years of research, presentations and workshops I had given. It covers a number of techniques to help learning and creativity, including things like mindmaps, reading techniques, how to take advantage of hypnagogia, and other bits and pieces from cognitive and neuroscience. It’s a collection of good ideas that seem to be helpful.

Q8. What would be your message for young generation of Agile practitioners? Please share some Do’s and Don’ts.


  • DO get feedback from all the things. Code, people, process, whatever
  • DO favor individuals and their dynamic interactions over any static processes and tools
  • DO take small bites, always
  • DO change one thing at time
  • DON’T guess. Experiment and find out
  • DON’T keep code or process that’s passed its expiration date. Throw out code you’re not using. Prune processes relentlessly
  • DON’T do fortune-telling.

We are terrible at trying to predict the future, whether it’s an estimate or guessing how a design or architecture might evolve to meet future needs. Don’t guess the future, we’re bad at it (as a species). Instead of trying to make software maintainable or extensible, make it replaceable. Make it easy to throw away and replace with a more appropriate solution when the time comes. Because then, and only then, will you accurately know what you need.

Don’t guess. Know.


Andrew Hunt writes books on software development and science fiction. He co-authored The Pragmatic Programmer and many other good reads including Learn to Program with Minecraft Plugins, the popular Pragmatic Thinking and Learning: Refactor Your Wetware and the Jolt-worthy Practices of An Agile Developer. His science fiction books include the novel Conglommora and Conglommora Found. He was one of the 17 original authors of the Agile Manifesto and founders of the Agile Alliance. He and partner Dave Thomas founded the Pragmatic Bookshelf series of books for software developers. He also plays the trumpet, flugel horn, and keyboards. Find him online at

Interview with James Grenning

Today, we feature exclusive conversation with one of the original signatories of Agile Manifesto and XP Pioneer – James Grenning. It was our pleasure to converse with him. We learned more about his thoughts on Agile, Birth of Planning Poker, Agile implementation in non-IT environments, and his memories with Mike Beedle.

Let’s read;

Q1. It is said that you were Agile before it was Agile. Please elaborate a little for our readers.

James: I started learning and practicing Extreme Programming late in 1999. The Agile Manifesto was created in 2001.  Simply, XP proceeded the writing of the Agile Manifesto. My opinion is that there would not have been a manifesto, if there was no XP.  The provocative name got people looking at it, mocking it a bit. Though, they took notice and many discovered how it provided a way of working that solved many of the problems individuals, companies and our industry had. With 20 year experience prior to seeing XP, I got the problems and the solutions seemed logical.  

Q2. How was Planning Poker born? How did it transform ‘Estimation’ in past few years?

James: There is a paper on my website describing planning poker. You can get the complete story here

Basically, at an early XP planning meeting, our client’s two senior architects would debate for an hour how to implement something and finally write down an estimate. Often the same estimate they mentioned in the first minutes. We had a lot of stories to estimate; all the talking got in the way.  Most the other people around the table were not engaged.

We took a break and when we got back together, I asked participants to take a note card and write their estimate on the card, then simultaneously reveal their estimates.  (Deciding then showing helped to avoid bias of verbal estimates. a.k.a. telegraphing) After a little while people were holding what looked like a poker hand. Planning poker was born.  I wrote about it and posted it on Object Mentor’s website. Mike Cohn read my paper and asked if he could put it in his book and started giving away decks of planning poker cards at conferences.

In retrospect, planning poker was a pragmatic solution to a problem in a planning meeting.  We studied and practiced structured problem solving as part of Total Quality Management (TQM) at Teradyne in the 1980s. We learned various communication and problem solving techniques.  One was brainstorming, but not out loud. Given a question or a problem, everyone would write their ideas for solutions or causes on post it notes or note cards. The we would group common solutions and discuss the possibilities and merits of each proposal.

In verbal brainstorming, often ideas immediately get shot down.  This tends to make people not express their ideas. It also biases the participants when the loudest or senior person dominates.  The day of the first planning poker game, the two ‘experts’ dominated and no one else had a voice.

In a nutshell, planning poker was initially solving the problem of people in agreement talking too much and dominating the effort.

Q3. Which one thing, you think today’s Agile Practitioner’s are missing while implementation? Please share one of your experiences addressing such issue.

James: Most Agile adoptions I see first adopt management and planning practices.  Developers struggle because they lack knowledge and skill incremental engineering.  This is a a formula for pain and unhappiness.

Q4. If you have to introduce application of TDD to embedded C to a novice, what benefits would you like to highlight?

James: The initial problem being solved by TDD is that programmer make mistakes, many per hour.  TDD helps detect many mistakes immediately thus preventing code and product defects. The opposite of TDD is Debug Later Programming.  In DLP, programmers write code and debug it later. How long does it take to find the cause of a bug? It’s big unanswerable question. The TDD cycle is very predictable. You can read a comparison TDD vs DLP here:

TDD also produces a regression test suite virtually for free.  Another driver for TDD is the need to automate tests. You can read why Manual Test is Unsustainable here:

These are only the started benefits.  In the hands of a knowledgable and skilled software engineer, TDD has many more benefits.  The experienced practitioners tell me TDD’s test let you change your mind about design and safely refactor for you needs software’s changing needs.

Q5. When developing the Agile Manifesto, have you ever thought that it would be implemented beyond the IT Industry? How do you feel when you see Agile being implemented in HR, Marketing and other non-IT practices?

James: For starters, we never thought anyone would notice or care about the Agile Manifesto.  As far as applying the principles in other areas, I think it is pretty natural. People work incrementally. Some say it cannot work for embedded software.  I don’t share that opinion. It works for embedded software, it can work other places. You’ve heard of the wiki-speed car? A group of people are building a car using Scrum techniques.

Be it hardware, software, or mechanical, something is being invented. Incremental learning and building is part of the process.  

Q6. Agile Transformations has been an emerging trend in past few years in various domains. What it would be after Agile? Do you feel  the need of any changes in Manifesto with time?

James: The Agile Manifesto is a historic document.  As far as I know, none of the authors are interested in changing it.  That’s not to say that Agile should not change and evolve. It should. Don’t worry about the Manifesto.  It’s fine. How people adopt Agile needs to evolve. I’d like to see a big emphasis in the industry to embracing high-quality incrementation engineering approaches, those embodied in XP are a great start.

Q7. What are your plans for 2019? What should we expect coming from Wingman Software?

James: I’m cutting back my travel a bit being more selective, working with clients that really want to improve how they collaborate and engineer their products.

I’ve been doing an Industrial Internet of Things (IIoT) prototype with my brother’s company.  I think there are some important concepts in how to approach the problem and how to keep code independent of the ecosystem I’m using. That will be a topic.

I’ve had some wonderful family things that have gotten in the way of writing.  I’ve got ideas I’d like to share. Hopefully I’ll get back to writing.

Q8. Mike Beedle’s sudden demise has been a shock for Agile Community. Please share your fond memories with him while developing Agile Manifesto.

James: It is sad and tragic that Mike was taken so senselessly.  

Mike and I skied together one of the afternoons at the meeting that created to the Agile Manifesto. We skied some very tough tree runs in that famous Utah knee-deep powder.  It is a fond memory.

Mike and I did not cross paths a lot professionally.  Though he was a respected man in Agile and Chicago, the city that is my home.


James W. Grenning is one of the original signatories of Agile Manifesto. He trains, coaches and consults worldwide.  He started developing software in last 70s after avoiding computers from high school to early college years. He had worked in both technical and management practices to development teams.

He had authored much read book ‘Test-Driven Development for Embedded C’. James is one of the few experts in applying TDD to embedded C. With his 1.5 decades of training,coaching, and practicing TDD in C, C++, Java, and C# he will lead you from being a novice in TDD to using the techniques that few have mastered. Any C or C++ programmer can use this book to learn the whys and hows of TDD.