Personal Agility Canvas
“What kind of idiot would ask if they were Agile enough? What a stupid question.” ~ Random guy I heard talking at an Agile conferenceIt 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.
Accountability Partners
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.
If you’d like to learn more about how the Personal Agility Canvas works, it is part of the session I am leading for Redefining the PMO and I will also be giving a presentation on it at Agile 2014 this summer. |
Podcast Interview with Ron Lichty, author of Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams
|
Click here to go straight to the podcast. 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.
|
Review: The Apprentice and the Project Manager
|
(check out the interview here) 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".
You can check out the Apprentice and the Project Manager at Amazon or HappyAbout. |
A few weeks ago I had a chance to 
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. Catching up with Jim Benson on Personal Kanban
|
In this Projects At Work interview I got a chance to ask Jim some questions about putting items on the board just so you have a record of them and can move them over. At what point does that become a wasteful step. As always, Jim’s feedback led me to thinking about my practice of PK in a completely different way than I had in the past. You can find the interview here: Part 1(Listed as Part 3 on the ProjectsAtWork site) Part 2 (Listed as Part 4 on the ProjectsAtWork site) I still find that one of the most interesting aspects of using Personal Kanban (which I have not found with other productivity practices) is that there is the doing of thing and the learning about how you are doing things. The insight provided by the latter continues to prove to be the more valuable part of working this way. For me, putting everything on to the board does mean that I am putting up stuff just to move it over. This does create some waste. But it also helps me become more aware of the fact that I am overloading every day/week all the time and still trying to plan more in than could be done. Yes, I need more discipline in how I work. (Who doesn’t?) But the discipline is not needed as much in how I work, as it is in what work I assign myself in the first place. Reducing or limiting what I put in my backlog should make it easier to get more done, but only if I can maintain the discipline to actually stick to my board and not keep including items that are not up there and taking them as items to work on.
… and I guess admitting you have a problem is the first step to recovery. ;) * The interviews are listed on the Projects at Work site as Part 3 and Part 4 If you'd like to learn more about Personal Kanban, you can find the book here. You can find Jim on Twitter here.
|
Back in December 
The more I work with PK, the more I discover that it isn’t so much about getting things into the done column, or clearing out a backlog as it is about raising my awareness of how I think about and approach my work. It is a more mindful way of planning and managing what I have to do.PhilaPM March Meetup Recap
 Wednesday Night @HappyCog in Philadelphia…By traditional PM standards, this is an odd question.
Answering it requires admitting there are times when you don’t know what you are doing and are way out of your depth. This is not the way of the traditional PM. If you admit not knowing everything, you demonstrate WEAKNESS and might lose CONTROL. If you have no CONTROL, how can you MANAGE PEOPLE?
By Agile standards, it’s not an odd question. It’s an “it depends” question.
Once the question has been laid down for the room, however, the sharing begins. Several of the PMs around the table offer stories of impossible situations they’ve faced. These aren’t the kind of challenges that can be addressed with a change to a contract or a revised scoping doc. These are the “we had it sorted and then the bottom fell out of the world” problems. The ones you couldn’t have seen coming and which leave you with no good options. These are the problems you give talks about at conferences for the next five years.
RETROPOSTREMORTEMVIEWBLAMESPECTIVEIf you’ve been working in project management for any length of time, you’ve been involved with the meetings that take place at the end of projects. These project reviews or post mortems are generally a wee bit heavy on blame side and a bit light on the learning to improve side. That is, assuming you are actually doing them.If you are working with Agile, hopefully you are doing retrospectives so that your team can get together to explore how to improve how they work together. Retrospectives are one of the best parts of Agile and a great thing for the team… but this is a little different. This meeting, which is hosted by Happy Cog is none of the above. It is, however, one of the more interesting characteristics of this segment of the PM population. Digital PM has been around for a while, but only in the past few years has it begun to identify itself as a somewhat separate group. This meeting is full of PMs from different companies. What they have in common is that in one way or another, they all manage projects that are involved with digital media. Some of their projects are less than a month long. Some last more than a year. Some of their clients demand a traditional approach to managing the work. Some demand an Agile approach. The PMs working in these organizations are generally working with fairly small, design centric teams. Their hybrid model is evolving from needing to be able to work a variety of ways, but being able to fully lock into neither. Their agility is their flexibility and this sharing is part of their approach to continuous improvement. Ten years ago, the project management that existed in this space was simple, basic and practiced by people who were just beginning to cut their teeth. Now it is led by experienced professional project managers and leaders who are schooled up in Agile and waterfall and are collaborating on hybrid tools and techniques that allow them to leverage the best of both. Their pragmatic, collaborative, framework agnostic approach to finding the best way to work with the team and deliver for the client is an exciting and emerging thing. PhilaPM is organized by Brett Harned, Brenna Heaps, Sloan Miller, and Justin Handler. The group has evolved to the point where they are now working developing a new logo, name and website. Until that happens, you can find them here - http://philamade.com/ If you aren’t from Philly, but do work in digital media or if you are just a PM who could use a little inspiration, you may want to check out some of the following… ConferencesDPM2014 http://blog.dpm2013.com/2014/02/24/save-the-date-2014-digital-pm-summit/DPMUK http://www.dpmuk.com/ Groups in the US and CanadaAustin http://www.meetup.com/Digital-PM-Meetup-Austin/Boston http://www.meetup.com/Digital-Project-Management-Boston/ Boulder http://www.meetup.com/Boulder-Web-Project-Managers/ Minneapolis: http://www.meetup.com/Twin-Cities-Interactive-Project-Management-Meetup/ NYC http://dpmconnect.com and http://www.meetup.com/projectmgmt-72/ Philadelphia http://philamade.com Portland: http://pdxdigitalpm.com Vancouver http://www.meetup.com/Vancouver-Digital-Project-Managers/ Groups in EMEALondon, UK http://www.meetup.com/london-digital-project-managers/Manchester, UK http://www.meetup.com/Northern-Digital-PM/ Oslo http://www.meetup.com/Oslo-Digital-Project-Managers/ Groups in ASIAPACMelbourne Digital Project Managers http://www.meetup.com/Melbourne-Digital-Project-Management/Sydney Digital Project Managers http://www.meetup.com/Sydney-Digital-Project-Management/ |
