Having been a student of Lean and Agile for a number of years now, we started adopting it in bits and pieces within our family. Here’s some examples of lean and agile in action in our personal lives.
Kanban your way to breakthrough profitability
Kanbans are an unbelievably simple way to improve throughput. It does not require you to begin with significant change which most process improvement initiatives do. It helps you experiment within your span of control and learn through those simple non-threatening experiments.
My Project World Business Analyst World talk: from waterfall to agile
When I was invited to speak at the Project World Business Analyst World in Moncton this year, I chose to talk about my experiences adopting lean and agile tools and moving away from waterfall where it makes sense.
Transforming from waterfall to agile
Introducing agility into traditional systems development processes is never easy. Firstly, you have got to want to change. Secondly, you need to have a vision of what to change to. Finally, you need the tenacity to forge ahead in the face of stiff resistance. It is usually the third that is the most difficult journey to undertake. The hardest part of the journey is during the transition wherein you show how to bring agility into executing projects. You are walking the fine line between traditional methodology and incrementally introducing change.
The power of pull
Donald, the CEO, sat staring at the phone. He just got off the phone with one of the customers. The project team had missed the delivery for the third time. And this was not the only project that was in trouble. “This is crazy. What”, he thought, “were we doing wrong? Why can’t we seem to get our act together and deliver projects to the plan? We should plan better. I better find Smith and find out what’s going on.” This scenario plays out at countless organizations worldwide across a wide array of industries. Work either waits for people/resource or people/resource wait for work.
Scope creep? Bring it on
Ask any project manager the reasons why projects fail and one of the reasons cited will definitely be scope creep. But is scope creep really that bad? I don’t think so. Your view of the scope creep will depend on how you manage projects. You can manage projects as a contract or you can collaborate.
I think there will be a scope creep when there is a contract between the solution provider and the consumer. For example, it is notorious in the construction industry. In fact, some contractors want the consumer to change the scope in the middle of the project. That’s their way of making money; it is not like you are going to change contractors in the middle of the project. But if both parties collaborate, then scope creep as a reason for project failure just melts away.