In contrast to Jim’s guest post the other day, here is a tale about my grass-roots attempts at implementing lean thinking with my teams within the domain of my control.

Some interest in surrounding teams has cropped up, but it’s my view that a true lean system/project requires very strong executive management support.

If you don’t have that (yet) then sometimes sub-optimization (within a team or two) is a way to flex your lean muscles and provide some gains.

At least, that’s the approach I’ve been taking.

Kanban Implementation Question

Josh,
My top goals are to get better at what I do and to formalize and align my PM skills with PMP standards. I’ve been internalizing your skillful nudges and instructions that you have shared to this point (PMStudent Blogs, Kanban, and this email).

Which brings me to a question – if Kanban is where you regulate your tasks to eliminate “multitasking” (which I applaud), where do keep the master list of tasks which drive you to your project deliverables? It would seem that you would be moving those tasks from the master list into your Kanban board and then out again to the master list as they were achieved. No?

Keep up the great insights

Sphere of Influence/Control

Great question. Working for a large federal program, we have EVM in play and I have to work within a waterfall framework. I’m convinced that end-to-end lean thinking would dramatically increase the effectiveness and efficiency of any project or program, but I’m not in a position to enact an agency-wide change. Because this is a joint project, both the USGS and NASA would have to buy in for us to start lean thinking across the whole value stream.

Translations

So I do translations between what my team does with Kanban and traditional project schedules. We still have the WBS for deliverables, and those are turned into work packages that get scheduled in the traditional way. When those hit my teams’ Kanban boards, they will get decomposed further usually, and on the fly as items come from the pull queue into active work. I roll up schedule status for work charged and completed items as the translation from Kanban back to the traditional waterfall schedules.

Especially when there are interfaces and dependencies all over the place (as is the case with my project teams) you still have to have representation on some schedule or tool that has everyone on it. So in my case the traditional element schedules that roll up into an IMS (Integrated Master Schedule) are in play so the various pieces across contractors and agencies (USGS and NASA both) can be lined up and ready when they are needed for integration.

“The most difficult situation, however, occurs when agile teams are dependent on teams that have much longer planning timeframes. Dissonance between teams with different planning horizons is common and can be difficult to resolve.” - Poppendieck’s in Leading Lean Software Development

Your Thoughts

So what do you think about all this? Is there a better way for me to approach this?

Is it better to do a Scrum-but or Lean-but if the full end-to-end implementation isn’t feasible?

Original link: Boxed-In Kanban

Related posts:

1. My Most Productive Days As A Project Manager

Feeling like your small projects aren’t giving you the experience you need?  I know where you’re coming from.

It’s how “accidental” project managers like us start out.  Small businesses, small projects, small teams. I’ve worked in environments like this in the past, and currently volunteer for several non-profits where this is the case.  My activities with pmStudent fit into this category as well, smaller “mini-projects” involving just a few people or sometimes just myself.

In an environment like this, good PM can still be applied but it must be tailored to fit.

Waterfall processes with a fancy charter and project plan all the way just aren’t going to be worth the overhead involved for a week-long project. You don’t have much room for a lot of formality or overhead.

Rock Your PM Skillz Anyway

Create a checklist or excel file which will essentially be your project plan.  This is what I did many years ago when I was working in an MIS department, and many of the projects were 1 week to 4 weeks in duration.  I had an excel spreadsheet set up as a “1 page project plan” that also served as a status report for my stakeholders.
Tailor it to your environment, and adapt it in a continuous manner to improve it as you go.

I wrote a post just a bit ago called Good Project Management is Common Sense that you may find useful as a starting point.

• I start with the why,
• then figure out the what,
• then figure out how it will be done and who’s going to do it.
• When comes out as a result of these things
• and then there’s a process of iteration where we update our draft plans in light of reality including funding

One-Page Project Management

You could literally start with a template that just has fields for:

• why (this is your charter)
• what (scope statement, pbs/wbs/task breakdown in list format)
• how (project plan)
• who (resource plan)
• a really simple schedule

The One Page Project Manager is a concept and resource very similar to what I’ve used in the past on small projects.  Check it out!

Kanban is a paradigm I am finding extremely versatile and valuable in terms of managing work flow, so I highly recommend you look into that as well for use on small projects.  I’m putting something together at http://pmStudent.com/kanban to share my experiences with Kanban and I’ve just learned about http://www.leankanbanuniversity.com/ which looks like an excellent new resource from some of the top people in Lean-Kanban.

If you want to gain some more knowledge about the concepts and practices on larger-scale projects (perhaps so you can scale them down to your needs) I do offer in-depth training at http://learn.pmStudent.com as well.

For some, sticking with small projects is going to be what they want to do.  For others, the additional challenges that come with larger projects (more stakeholders, team members, and communication channels to manage) are really what managing projects is all about.

Small, large, or anywhere in between….you can still rock.

Original link: Small Projects: How To Rock Them

No related posts.

Last weekend I wanted to read “The Goal: A Process of Ongoing Improvement” by Eliyahu M. Goldratt again. It’s been a few years since I had, and it was one of the first books that really helped me to internalize many of the concepts I take for granted today.

I was delighted to find it on Audible.com, especially because I’m already a Platinum member and get a few audio books per month as a part of my subscription.

I listened to the sample, and it sounded good so I grabbed it.

It was even better this time around. The production was great, and it was great to get re-acquainted with Alex and his crew in this wonderful novel. I’d like to share some of my thoughts on the book with you today.

• Perspective is Everything
• Common Practice is not Necessarily Good Common Sense
• Local Optimums are Not Optimal

Perspective is Everything

In the book, there are many occasions where the team is faced with a major problem and it turns out the solution was right there in front of them, staring them in the face.

They had to change their perspective. Ingrained assumptions were blocking everyone from making the shift in thinking necessary to find the solution.

Once they had made the paradigm shift, it seemed plain silly they hadn’t seen the solution earlier.

I have had similar revelations over the past few years, including limiting work in process (WIP) and multitasking on my projects as much as possible.  Many of the strides I’ve made in terms of resource and release planning, time-boxed agile methods of working, and kanban have been a direct result of my own paradigm changes.  Now that my thinking has shifted, it’s almost painful for me to remember how I used to manage my projects and lead my teams.

Common Practice is not Necessarily Good Common Sense

Many of the measures common in our professional lives do not really move us towards The Goal.  In the book, a major example was efficiency.  Parts of the system would be run at high efficiency in order to look productive, but in reality they were just creating large amounts of WIP that clogged the system and tied up material.

An example in my world of software development is the case where many people and organizations value a highly detailed plan over just about everything else.  Isn’t a better goal to produce a quality product that perfectly meets the customer needs, on time and within budget?  Isn’t everything else just window-dressing?  I won’t spoil it for you, but zooming out just a bit more gets you to the goal of the organization, which is the true Goal that should be kept in mind.

Most standard waterfall-ish teams end up putting tons of effort into design and documentation up front, code like crazy, and then try to update and create new documentation at the end.  The design WIP builds and builds, and by the time you start implementing you have to re-work your design anyway.  And when you save documentation updates for last, you end up having to go back to the code and remember what you did in order to update the documentation appropriately.  Then you release it to the customer and find out you are meeting requirements, but it isn’t really what they want or need.

WIP in software and many other domains can be thought of a perishable to an extent.  The longer it sits there as WIP, the more value you waste due to rework and time to re-familiarize yourself with the WIP.  If you put a set of functionality into play, you’d better be working on it, getting feedback on it (testing, customer reviews), or documenting it.  Every moment you are not doing one of these things ends up as waste on your project “factory floor”.

This is a major reason I’ve been driven towards mapping the value stream of each of my teams in a visual manner using kanban as our vehicle.  Minimizing WIP by focusing on one item and taking it through the entire value stream before moving to the next is a critical piece for my teams to achieve our Goal.

Local Optimums are Not Optimal

This is another critical point this book drives home again and again.  It is very easy to only look at your own little piece of the system.  Stove pipes rise up everywhere, with individuals, teams, and departments trying to achieve local optimums for themselves.

The only way to increase quality throughput on your projects is to look at the whole system, not just pieces of it.  The broader your scope for applying systems thinking, lean concepts and others, the better chance you have at making a real improvement to the bottom line.

Daily stand-ups and a shared, visual representation of the entire project team’s work and focus is a perfect example of this principle in action.  In this way (again I love my kanban!) everyone’s perspective is broadened to the team as a whole, and not just local optimums for individuals.  Several times each week, my teams and I discover opportunities to enhance throughput by working together in specific ways.  In fact, this week we discovered that for a portion of one system, we should actually stop work for a short time until a constrained resource (team member from another team) is freed up to work on it with us.  Without the shared vision we now have, part of the team would have started work on it and created rework.  Not only that, but the rework would have been pushed towards a constrained resource with a specific and unique skill set.

We may have felt productive locally getting “our part” done, but overall it would have taken more time (duration) and effort (work hours).  The local optimum would have decreased overall throughput of the system (our project).

Have you read “The Goal” yet?  If not, you can get it in audio format for free by trying out Audible.com today.

Original link: What’s The Goal?

No related posts.

Complexity in project estimation is important, and yet many if not most project managers seem to ignore it from what I’ve seen.

I have been thinking and reading up quite a bit on relative methods for eliciting estimates for projects.

I’ve enjoyed Planning Poker mostly as a means to get a team working more as a cohesive whole, thinking about the project in it’s entirety and how their own work relates to the big picture.  The process has been able to spark many “ah ha!” moments for my team members when someone who was new to a particular component or area of work became exposed to it.  Sometimes a fresh set of eyes can be very illuminating.

My first steps with teams who are new to these processes are to focus on pseudo-relative (meaning mainly absolute) sizing estimates since that is what they are accustomed to being asked for.  The next step is  talking in relative terms about complexity and size in a way we can calibrate and that makes sense to the teams.

I am going to try something new and see how it goes.

First, Planning Poker

First we  will conduct planning poker, looking at relative complexity of the stories we are estimating.  A story that everyone is familiar with will be selected and discussed as the starting point for our discussions, around which other stories will be judged in relative terms.

If you are new to planning poker, there are many great resources available to learn more about it.

Next, Relative Effort Mapping

Normal planning poker sessions result in a story point estimate you stick with.  What I would like to do here is extend and validate relative mappings with a visual tool used in a collaborative way with the team.

What’s this fancy tool?

A whiteboard and some post-it notes.  Sophisticated, I know…  just like how I do Kanban.

Each of the stories will be indicated on a post-it note.  Use the same colors to avoid any unconscious grouping tendencies.  On the whiteboard draw a 2-axis graph with complexity on the X-axis and size on the Y-axis.  Starting with the calibration story in the center, review each story quickly and have the primary story owner (who will be working/lead on it) place it where they think it belongs on the matrix after having already done the planning poker session.

Pretty simple.  Unnecessary?  Perhaps.

I’d like to experiment with it and see if it yields any new insights or strengthens the understanding of the work to be done within the minds of the team.  My hope is to discover interesting discrepancies between the results of planning poker and the relative size and complexity of the same stories on the matrix.  When experimenting, discrepancies always lead to new insights and questions to be tested further.  If I find no significant or systematic discrepancies over time I will likely abandon the practice, as that would indicate a lack of efficacy.

Original link: Project Estimation: Mapping Size and Complexity

No related posts.

I use techniques I learned as a project manager in my everyday life all the time.  Do you?

If you are learning to become a project manager, have you started experimenting with these tools and techniques on your own, so that when you do start managing your own projects you will already be familiar with them?

Original link: Project Management in Everyday Life

Related posts:

1. Project Management: How to Keep Your Work and Family Life Separate
2. Good Project Management is Common Sense

I have always respected Pawel Brodzinski for his pragmatic style and views on software development.

Recently, I started to get very interested in Kanban and have spent some time researching the topic since it is something I have not yet used in practice.  Shortly, I came across this excellent series by Pawel on his struggles and process of implementing Kanban with his team.

Then, I came across this video of Pawel presenting on the topic and just had to share it with you here.

Pawel, thank you so much for your contributions, this is really great stuff!!!

Pawel Brodzinski – The Kanban Story – Ups and Downs of Implementing Kanban from Krakow Tech Conferences on Vimeo.

Original link: Ups and Downs of Implementing Kanban with Pawel Brodzinski

Related posts:

1. Boxed-In Kanban