The Art of War (Recommended Translations)
art of war
Categories: art of war
Later today I'll be giving my Personal Agility Canvas presentation for the PMI Agile Community of Practice. In this webinar (like the one I did recently on Redefining your PMO to Support Agile) I'll be referencing Sun Tzu's The Art of War. There are literally hundreds of translations of this classic text. IMHO, the best way to really understand the ideas and tools introduced in the book is to read a number of different translations. After the last session I had a number of requests for which versions of the book I recommend for those who are new to it, so I though I would post them here to save some time.
The Art of War (Pocket Edition) - Thomas Cleary
This is a great starting point. Cleary offers a simple translation that is easy to get through if this is your first time with the text or if you've had trouble with it in the past. He has larger versions that go into more detail and offer more commentary, but this is still my favorite - plus, it's smaller than an iPhone and you can carry it with you everywhere.
The Art of Strategy - R.L. Wing
R.L. Wing introduces each chapter with an explanation that looks at the meaning behind the text on three different levels : Conflict with the Self, Conflict with the Environment and Conflict with Others. For me, this helped open up the way I interpret and use the tools that are presented throughout the text.
Sun Tzu's The Art of War Plus It's Amazing Secrets - Gary Gagliardi
Gary Gagliardi's way of diagramming the tools and explaining how they fit into interaction with others is brilliant and his explanation of the Five Measures is what helped me understand how to apply it in everyday life. I would not start with this one, but if you have a decent grasp of the ideas, this is a must for understanding how to apply The Art of War.
Please join me on October 1 at 2 PM EDT for a ProjectManagement.com Webinar
BREAKING GANTT - Project Reporting in Agile Transition
In working with organizations that are transitioning from a traditional (waterfall) approach towards Agile, one of the most common questions is how to handle tracking the work. If you are no longer producing Gantt charts, and they won't learn to read a burn-down, what do you do? To complicate things even further, many of the Agile tools offer you access to far more reporting than your organization may need. So how do you tell what is important and how to track and report on work in a way that will help keep executives informed and not get in the way of adopting Agile?
In this webinar I'll be presenting some tips and tools I have found to have a positive impact when helping an organization let go of their dependence on traditional project tracking in favor of Agile reporting.
Please Register Here. I look forward to speaking with you on October 1.
“What kind of idiot would ask if they were Agile enough? What a stupid question.” ~ Random guy I heard talking at an Agile conference
It was kind of a troublesome moment for me. (I have lots of those whenever I find myself in a crowd of Agile banty roosters who all want to play “mine’s bigger” with their Agile-ocity-ness-ish.)
For me, I ask that question all the time. I wear my hard earned experience in waterfall as a scarlet PMP that has been seared into my soul. When I was taught about project management, the guy who taught it to me started by saying “When I’m done with you… everything is a project.” And with that statement, he began to re-wire my brain. Once you learn to see things the way a PM does, there is no going back. And no matter how long I practice Agile, that will always be with me. I am a project manager in recovery.
The good part is, that if the question is “How will I know when I am Agile enough?”, I already know the answer… Never. The moment you think you’ve got Agile sorted is the moment you stop being Agile. So, somewhere in the back of the Agile recesses in the brain, you need to nurture your inner Captain Willard.
I often get the question about being Agile enough when I am teaching Scrum classes to PMs or people who are deep with the waterfall. They either want to know the “right” way to do it, or when they are “done” learning it and can say they are Agile.
I decided to work on developing some way to address the question that would be both simple to use and relevant for people who are just stepping out of the waterfall, and people who have been doing Agile for awhile.
The result is the Personal Agility Canvas.
The Personal Agility Canvas is modeled after the Business Model Canvas (which you can learn more about here. I kept the basic layout because I thought it might be somewhat familiar and that might make it easier for people to digest. The Personal Agility Canvas is intended to be a way to personally reflect on your ability to improve your approach to Agile, establish goals, and develop a plan to achieve them. It is not intended to be something you fill out and then are done with. This is intended to be something you come back to again and again as part of your own personal effort to inspect and adapt.
In teaching the Personal Agility Canvas during the Redefining the PMO workshops, I have found that not providing step by step guidance on how to work through the different boxes can cause result in stress for the students. To help get you started, here is an example which has the boxes numbered (hyperlink) according to the order in which I normally teach them. In my own use of it, I begin with Goals, then move to Value Proposition and iterate repeatedly through the boxes until I am ready to define the Action Plan. If you are creating your own Personal Agility Canvas, I’d recommend working through the boxes in whatever way makes the most sense to you. As long as you end up with a measurable Action Plan at the end, it’s all good.
Here is a description of each box:
Value Proposition - What is your personal value proposition? How do you deliver value to the teams you work with, the company you work for? How will an improved approach to Agile better enable you to serve your team(s) and organization?
Goals - What are your goals with moving further in your transition to (adoption of) Agile? How will you know when these goals have been achieved? (You need clearly measurable acceptance criteria for this to work.)
Strengths - What abilities, experiences, behaviors will you be able to leverage to strengthen your transition to Agile?
Desired Changes - What have you already identified that needs to change in order for you to better support an Agile approach? (This may include things like behavior, speech, mindset, interaction patterns)
Fears/Concerns - What about Agile, or transitioning to Agile causes you anxiety or stress? How does this impact you?
Interactions with Others - In evaluating your interactions with other people (teams, clients, peers, etc.) what is not in sync with the principles of Agile? (You may need assistance with seeing this clearly.)
Environment - What about your (individual and/or team) physical workspace is impeding your ability to improve your approach to Agile?
The Mark Inside - This will likely be the most difficult box to complete. William Burroughs said “Hustlers of the world, there is one Mark you cannot beat: The Mark Inside.” The idea here is that whether we are aware of it or not, each of us is often our own worst enemy. We con ourselves without even realizing it. How are you blocking yourself from truly embracing an Agile approach? Where are you second guessing the thought leaders who have come before you or hedging your bets with your practice?
Actions Needed - After completing all the other boxes and re-reviewing your goals, you need to develop a plan. These should be concrete steps you can take in the short term to help you move towards becoming more Agile. Once you have completed these actions and achieved the goals, it is time to start your canvas all over again.
One last suggestion. Find someone you trust who will give you honest feedback and hold a mirror up to show you things you cannot see. By sharing your canvas with an accountability partner, you can make a commitment to someone other than yourself. Ideally, each of you will pursue these goals because this is something you are committed to, but there may be times when your motivation lags. When this happens, it may help to have a voice in the back of your head reminding you that you promised someone you’d have it done and that they are expecting to hear from you when it is finished.
And on that note… here is an example of a Personal Agility Canvas I completed for myself earlier this Spring.
If you have any feedback on the canvas, how it is working for you, what might make it better, please let me know. I do not expect that this current version will be the final one, but it is the one I am using now.
Podcast Interview with Ron Lichty, author of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams
A few weeks ago I had the opportunity to interview Ron Lichty, Agile throught leader co-author and of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams. One of the great things about the books is that Ron and his co-author Mickey W. Mantle have culled their collective experience and offered up a set of tools they have found useful over the years in working on software projects.
Ron and Mickey take the approach that software developers are a unique group within the knowledge workforce and that they require an adjustment in how we treat them, how they treat each other and what we can do to help them work with non-developers.
One of Ron’s current areas of focus is rooted in the question of “Why do we need managers if Agile teams are supposed to be self organizing?” Ron’s has found that only about 5% of software managers have had actual training in how to manage people. We basically just expect developers to be able to move into a managing role and just know how to do it based on their experience in not being a manager. Ron looks at the critical role that management can make in helping companies transform to Agile and the importance in making sure that they are trained both in management AND in how Agile works so that they can be better prepared to help, rather than impede the Agile teams as they are getting off the ground.
A few weeks ago I had a chance to interview Kamal Manglani for Projects at Work. Kamal is an Agile coach who has written a book, The Apprentice and the Project Manager, that was recently released on Amazon and HappyAbout.
The book includes a narrative based in the past and the present. Stories from earlier work experiences as an apprentice mechanic and current experiences working as a technology project manager are used as a metaphor to explain some key concepts that factor into Agile and Lean.
Explaining an Agile process/framework as a call and response narrative is not a new approach, but what is unique and refreshing about Kamal's book is that in taking a practical approach to getting work done and coping with very specific situations, the author has made a choice to steer clear of promoting one method over another and just kept it to a very pragmatic, straight up approach.
If you are new to Agile and/or Lean, this book would be a great starting place to introduce some of the key concepts without drowning you in jargon and trying to sell you on having found "THE WAY".
For me, as someone who has spent a lot of time working in both traditional project management and in Agile, my favorite section of this book was the chapter on Financial Health. It is great to see a book for people who lead projects include an easy to understand explanation of why it is so important to factor finance into our decision making process and how to go about doing that in a responsible manner.