Reforming Project Management » agile

Project Kaizen Reading

Hal — Fri, 01 May 2009 01:19:31 +0000

Project management can get stuck…focused on just getting the work done. Great companies do more on their projects. They use each project to advance the strategy of the company. How? With kaizen. Take some time to read about it. Your projects and your team members will be better for it.

One Small Step Can Change Your Life: The kaizen Way kaizen starts at home…with everyday changes in how we live our lives.
Small Change: It's the Little Things in Life That Make a Big Difference! All kaizen begins with oneself.
The Fred Factor: How passion in your work and life can turn the ordinary into the extraordinary Extraordinary is just the accumulation of everyday changes.
All You Gotta Do Is Ask These authors share the secret to successful improvement programs.
Chasing the Rabbit: How Market Leaders Outdistance the Competition and How Great Companies Can Catch Up and Win, Foreword by Clay Christensen Steven Spear shares the four key practices that separate the best from the rest. MUST READ.
kaizen and the Art of Creative Thinking – The Scientific Thinking Mechanism The master of Toyota's improvement approach only recently published by Norman Bodek.
gemba Kaizen: A Commonsense, Low-Cost Approach to Management Massaki Imai's ground-breaking book on the practices that create the never-ending habit of improvement.

©2009 Hal for Reforming Project Management, . | Permalink | No comment | Add to del.icio.us
Post tags: Project and Program Management, Project management, Toyota

Feed enhanced by Better Feed from Ozh

What Do Twitter and Architecture Have in Common?

Hal — Mon, 30 Mar 2009 18:59:46 +0000

Agile software development is known by its different variants, most notably Scrum, Extreme Programming and Function Driven Development. I was reading up on Twitter for some posts I'm planning for Web 2.0 project management when I came across this quote from a recent Twitter Blog post:

Pair programming has helped us achieve more than just higher quality code and better code readability. This methodology is also about more intense and focused work sessions, automatic code reviews, and better tests. Pair programming also develops better personal relationships and improved communication which has meant a lot.

It's refreshing to hear this. I know it works. I've seen it work. I just don't see many people writing about it.

Collaborate with people closest to the "real work."

I've been encouraging architects and engineers to adopt pair design in the building projects. We've had some small experiments between engineers and trade detailers to create construction details. The efforts were successful, but the common sense is that two at one keyboard is unproductive, or worse. They just might talk about March Madness rather than design some aspect of the mechanical system.

(...)
Read the rest of What Do Twitter and Architecture Have in Common? (184 words)

Feed enhanced by Better Feed from Ozh

Projects Are about What?

Hal — Wed, 25 Mar 2009 03:01:47 +0000

One of my project blogging friends, Bas de Baar, has begun a compilation of his posts that he's calling the Project Shrink Linear Edition version 0.1. It's an unbook. I don't know if Bas is calling it that, but he's creating it in that way. I'm a big fan of his thinking and his writing. Bas hits the nail on the head when he says, "Projects are about humans."

Projects are about humans.

You'll like his writing. He mixes personal experience with stories and just enough philosophy to be interesting, but not boring.

(...)
Read the rest of Projects Are about What? (145 words)

Feed enhanced by Better Feed from Ozh

Turn Rocks into Gold on Your Projects

Hal — Mon, 26 Jan 2009 00:27:40 +0000

Clarke Ching, regularly blogging at Clarke Ching — More Chili Please, just published his second book titled, Rocks into Gold. He wrote the book in response to the sorry state of the worldwide economy, particularly for those working on projects in the software industry. He tells a story of optimism in the face of our everyday pessimism. It's a book about ingenuity, frank reality and a touch of cynicism for it to ring true.

He tells a story of optimism in the face of our everyday pessimism.

The story opens with a software development firm losing a contract with one of its biggest clients. The loss will likely lead to significant layoffs. People are devastated. One person, it could be anyone of us, finds a path forward.

(...)
Read the rest of Turn Rocks into Gold on Your Projects (153 words)

Feed enhanced by Better Feed from Ozh

Clarke Says, Multi-Tasking Is Evil, I Agree

Hal — Fri, 16 May 2008 02:22:01 +0000

I won't bore you with all the references to how multi-tasking produces waste. But do understand, the company policy to have very high utilization of staff creates the requirement for multi-tasking. Full utilization is not sustainable. Until you can lower utilization, thereby creating slack, you won't be learning and innovating. You can't be lean.

Clarke Ching, writing for Sticky Minds, uses a simple exercise to show just how evil multi-tasking is. Do the exercise for yourself and then have your boss do it. It goes like this:

(...)
Read the rest of Clarke Says, Multi-Tasking Is Evil, I Agree (233 words)

Feed enhanced by Better Feed from Ozh

The Proximity Principle and Project Success: Revisiting Project e-Tip 016

Claude Emond — Tue, 05 Feb 2008 06:43:20 +0000

In my first guest-blogger entry, I mentioned the importance of managing perceptions. I wrote that not doing so was the main cause of why only one project out of three was considered successful by major stakeholders, according to the Standish Group's Chaos Report¹. I concluded that "not managing perceptions" could be considered the 10th waste of ill-managed projects.

It is easy to say that we have to manage perceptions. But where and how should we start doing that? The Chaos Report gives us pretty good leads on that. The report identifies the involvement of end-users as the No.1 in its Top Ten List of project key success factors. I talked about that also when Hal gave me the opportunity to contribute a project e-tip back in 2003 (e-tip 016: Keep the Customer/End-User Involved). After all these years, this e-tip is still relevant and I propose to rename it The Proximity Principle and to revisit it as it pertains to fighting the 10th waste.

(...)
Read the rest of The Proximity Principle and Project Success: Revisiting Project e-Tip 016 (319 words)

Feed enhanced by Better Feed from Ozh

“Fail Fast, Fail Cheap” Sounds Like Scrum

Hal — Mon, 02 Jul 2007 03:52:26 +0000

There is such an urge to get our projects right. Not approximately right. Right, as "Do it right the first time." Projects are not like that, especially design projects. Norman Bodek has been speaking about two principal ways we learn: copying the successful actions of others and making mistakes. If making mistakes is part of learning, then we better be making many of them to produce successful projects. BW SmallBiz agrees: Fail Fast, Fail Cheap, June/July 2007, by Doug Hall.

(...)
Read the rest of “Fail Fast, Fail Cheap” Sounds Like Scrum (232 words)

Feed enhanced by Better Feed from Ozh

Day Two Daily Scrum

Hal — Sat, 30 Jun 2007 03:44:06 +0000

Another great day of work. We got through the Daily Scrum in 13 minutes (without standing). I asked for a weekly retrospective to examine what we are learning and what needs our attention. In short, team members assessed they were learning and accomplishing far more than they expected. Let's see if we can keep this going. There's a lot for us to accomplish in the coming vacation week.

Feed enhanced by Better Feed from Ozh

Another Scrum Day of Learning

Hal — Fri, 29 Jun 2007 03:22:17 +0000

We had our first Daily Scrum. It took 16 minutes. I minute too long. Our ScrumMaster asked each of us the 3 Scrum questions:

What have you done since yesterday's meeting?
What are you going to get done today?
What impediments (obstacles) do you need to be removed?

What do I know? I'm just a beginner. A happy beginner!

We got through the questions in under 10 minutes. We then asked follow-up questions to some of the team members' responses. One issue was left to be addressed by tomorrow's Scrum. Once the meeting was closed I called for a Spike¹ to address the issue with three people on the team. In 5 more minutes we resolved an assignment that in other settings might have taken a number of phone calls, emails, and interruptions. Spike over!

(...)
Read the rest of Another Scrum Day of Learning (103 words)

Feed enhanced by Better Feed from Ozh

Scrum: Inspect and Adapt

Hal — Thu, 28 Jun 2007 02:03:26 +0000

There's nothing like learning-in-action.¹. We just finished our planning session for our development project. I was surprised by how much time we spent defining what it meant to be done. In the LPS world we call that establishing conditions of satisfaction. But we struggle to get team members to stay in that conversation. "Just tell me what you want!" The ScrumMaster wouldn't let us move on 'til he confirmed that the whole team understood what would satisfy the Product Owner.

I'm looking forward to comprehending!

Towards the end of today's session, I noticed that our ScrumMaster frequently said, "We'll inspect and adapt." (He said it before we started the planning. I just hadn't noticed.) "Of course," I thought. The future is uncertain and unknowable. That's just what we do on (LPS) projects. But I also know it's not what is usually done on CPM-style projects. Conventional wisdom (and scheduling software) guides people to put a plan in place and stick to it. The result is project managers often try to get reality to match their plan. Doesn't work. Never did.

(...)
Read the rest of Scrum: Inspect and Adapt (169 words)

Feed enhanced by Better Feed from Ozh

I Hired a Certified ScrumMaster

Hal — Wed, 27 Jun 2007 02:03:16 +0000

Why would a lean projects guy hire a Scrum software development ScrumMaster? Short answer: it seemed like a good idea at the time. Seriously, I'm doing some work for an architectural engineering firm. The company focuses on designing technically sophisticated manufacturing facilities. We are developing for them a responsibility-based planning approach. It's starting out as a Scrum adaptation of the Last Planner System® (LPS). I thought…what better way to understand how Scrum can inform the changes to LPS than to perform our own development effort as a Scrum project.

(...)
Read the rest of I Hired a Certified ScrumMaster (133 words)

Feed enhanced by Better Feed from Ozh

Cross Appropriating Agile Project Management

Hal — Thu, 27 Jul 2006 22:29:44 +0000

Agile Project Management (APM) arose in the software world. The lean construction community has investigated APM to see what might be cross appropriated. Why would it matter? Agile approaches are gaining favor and producing better results for software development.

Is Agile Project Management Applicable to Construction?

Bob Owen, et al

Agile had a similar starting point with that of lean project delivery. Projects were just not getting done to the satisfaction of the users, the sponsors, and the performers. Agile also has to deal with an evolving understanding of what will satsify the client. And the client has a changing understanding of what they need and want. Conducting the project in a way that embraces learning is central to developing the project while avoiding waste.

"APM is most appropriate to project situations that require emergent requirements."

Bob comes from the IT community. He's doing research and getting his PhD in Lean Construction. He is arguing that APM would be a good fit at least during the design and preconstruction phases. He says organizations need to:

Embrace change to improve value
Establish a learning organization
Committed and loyal workforce

"APM is most appropriate to project situations that require emergent requirements."

Feed enhanced by Better Feed from Ozh