Tag Archives: Leadership

Methodology, managers, and projects

Posted on by

When working on a project there are a few different ways to manage those projects. One is the traditional waterfall approach, which is your top down project where you have to use Gantt charts to figure out how long you think it’s going to take up front, where you’re given a set date that can’t change without a lot of effort to do a certain amount of poorly defined requirements, and a set amount of money to do the project. This approach has been how Windows and many video games have been produced in the past. It’s not really extremely effective and really no one really likes working a project conducted using Waterfall methodologies. There are risks, projects get cancelled and the project management can seem to be capricious and opaque. This leads to lack of trust and belief that management has the best interest in mind for both the project and the employees on the project.

To address these concerns a group of people created the Agile project management methodology. The goal was to value working software over documentation. Which means that each bit of software is broken down into the minimum viable feature, or the smallest piece of working software that could be packaged and used by a customer. The goal is to manage the project through adjusting how many of these features are going to be finished by the go live date. Effectively you build small bits of work instead of finishing one giant massive piece of software.

This approach is effective for other types of technology that have a modular architecture. There’s some minimum viable product, where you need a minimum set of features for the product to actually work. For example a cell phone needs to have a combination of features to function properly. Things like bendable screens would not be in the minimum viable product, but an excellent touch screen would be. These minimum viable features can be modulated based on the Kano model – which is useful for determining if a specific feature is basic, a pleaser, or a delighter. If the feature falls into basic, you must include that feature if you’d like it to be a success. However, those minimum features don’t guarantee a successful product, you’ll need to include pleasers as well as delighters. Those are the pieces of scope that you will be able to eliminate to make sure you actually launch the product on time.

Issues with these projects come whenever there is a mixture of methodologies. When management believes projects must be managed through waterfall through a central project results office while the development team believes the project is being managed through the agile methodology. This creates serious issues whenever there is miscommunication, lack of information, or lack of understanding the real status of the agile team’s approach. This is exacerbated by the required openness in the agile approach (where you are supposed to continually learn from your mistakes and have a conversation about all the problems you’ve had – to fix them) while in waterfall it is better for people to hide and place blame elsewhere whenever things are not going well. Not because people are bad, but the incentives are in place to behave this way. With a single option of go/no go, it’s better to minimize the known risks as if things are misunderstood as going poorly it will drive management to take action. While in an Agile team, discussing the true status of the project is vital through self policing and partnering with other agile teams to address the problem. The greater the likelihood of success of the projects.

This conflict and a switch from governance in the agile methodology can and will destroy the trust the various agile teams have developed. An organization needs to fully commit to a single project management methodology or it will struggle to complete any project within scope and budget and will demoralize the leaders of projects being worked in agile, as waterfall would likely be the methodology that management selects. Leaders of Agile projects should leave organizations that undercut the agile teams, as it will not stop and will have dramatic impacts on their careers in the long run.

Words, what are they good for?

Posted on by

At work, I’ve recently been given the task of redesigning all my training documentation and plans for Lean process improvement to something else. Apparently, despite successes, some of my leadership team doesn’t believe in Lean. However, they fully expect improvements such as reduced turn around times, quality improvements, and reduced non-value add activities to just happen. That it’s simply expected to occur without any top down pressure or support. Without clear direction or proper tools to measure improvement or even productivity, how can anyone expect to drive improvement in their organization?

Lean is a tool to do that, but since some leaders don’t believe that’s the proper way to drive improvement, we’re having to monkey with the idea of what it means to be an efficient organization. Therefore, I’m going to be rebranding everything to Process Innovation because Innovation. This does an interesting thing, it forces us to change the language we use for continuous improvement. We can’t use words like Gemba (the place where work is done), Kaizen (continuous change), Jidoka (automation with a human touch), Poka-Yoke (idiot proofing). or Muda/Muri/Mura (waste, overburden, unevenness). Using these words isn’t just to try to force people to learn some Japanese. It forces people to slow down and think differently.

Regardless of your thoughts on Malcolm Gladwell, he raises some really valid points about language in his book Blink, where he discusses the example of Korea Air and the usage of English as a language in the flightdeck because it changes the way the first officer and captain think about each other. Lean emulates this idea by forcing English speakers to use Japanese words. It forces people to stop and think about what they are doing. Yes, it’s a foreign word, but the meaning drives a change in behavior simply because it forces the people listening to slow down and think. According to Daniel Kahnman, system 2, deep and introspective thinking, is lazy and lets system 1, Blink thinking, do most of the work. A change of language and specific words triggers system 2 to actually pay attention and not just accept what is said as fact.

Now with Process innovation, I’m going to have to invent my own language and rules to try to force a similar behavior. I’ll have to lean heavily on Lean, Six Sigma, and other improvement methodologies rather than just Lean. However, this might confuse Lean folks.

It’s amazing the impact of a few phrases on changing the way people behave and it’s amazing how they can cause people to react in a negative way. Figuring out how to work around other people’s language hang ups is key for a successful work life, unfortunately.