Posts tagged agile

Being Agile

Agile…

This is quickly becoming the management buzzword of 2015. Just another magic pill for industry to improve what they do with what they believe is little work.

Agile, as a process (yes folks, it is normally a process), usually starts in an organization with IT in software development. Soon after companies get the “agile bug” and they want everything to be agile. Lean quickly becomes the Agile way to be.

Agile, by itself, is just a word describing a state of being. I’m sure there are many definitions, but in its basic sense, Agile is being able to adjust, change, or respond quickly. It’s being resilient and flexible. Agile approaches are based on quick incrimental iterations. Agile, at its core, is organic and a state of being, not a program.

How do you become Agile?

Look at how you are organized and how you make decisions in your company. Is your company fairly flat and accepting of risk or do decisions need to be collaborated up through many levels and do they take a long time to obtain approvals?

Does your system, to get things done, have to go through annual processes with multiple approvals and significant roadblocks, or are employees empowered at the lowest levels to embark on projects when needed to make things happen?

Do you focus on managing change (I e., reactive) or are your employees ready and actively looking for change opportunities and making them happen?

Agile cannot become the way you are without significantly addressing your culture and operating models. If you are slow to make decisions and change as a company and if you are reactive to changes after they occur, then you are not Agile.

Employing Agile methodologies like Agile Software Development or Lean are only programs…they do not make you Agile as a company.

Being Agile means fundamentally changing everything about your company…

Will that work for your company’s culture?

Process Improvement and Agile

Agile is quickly becoming the accepted method for project management these days. Once organizations start moving toward agile projects, quickly they want everything delivered in an agile manner. This has led many to ask how process improvement and agile work together.

One of the first misconceptions is that agile is not a process. Of course it is…there is a process flow in agile, just like any other project management approach. Agile has a set of repetitive steps to gather epics and stories and perform iterations. Without a process (series of steps), how would you effectively train agile to others and ensure everyone is doing it right and the same? Yes, agile is a process.

So process improvement can take a long time and often does not feel very agile. If your organization is moving to an agile environment, how does process improvement move there too?  Well, in process improvement, there are three ways to become more agile: proper project scoping and transfer, rapid improvement events (known by many names), and true lean/continuous improvement. The following briefly discusses all three.

Process Improvement Projects.  Running an improvement project using a formal methodology normally follows a waterfall approach, whether it be DMAIC, DMADV, PDCA, or whatever alphabet soup approach you use. Waterfall, as anyone agile will tell you, is not agile! The problem with these projects is they can take a long time to get to root cause and implemented solutions that the lead is confident will solve the business problem. Want it bad, get it bad…right? However, if you take that huge ‘boil the ocean’ problem from your sponsor/client and scope it down into a single area, you can get to an initial solution fairly quickly. Rik Taylor and Associates teaches a very specific project scoping tree that is very effective at getting to a manageable chunk of work. Then, Rik teaches students how to transfer that solution to quicker iterations in other areas, focused on the same problem. This turns the waterfall approach into a very agile-like iteration process. It is still not agile, but it is much quicker at getting to improvements and builds over time.

Rapid Improvement. This is know by many names, like Kaizen Blitz, Work Out, Action Work Out, Rapid, Rapid Improvement, etc. Although still a waterfall approach to process improvement, the actual improvement activity is compressed into a week or less of hands-on dedicated activity. The lead still needs to define and measure in preparation for the workshop event, but what most participants see is a week or less of activity. Also, the solutions, though generally lean-based, are identified and implemented very quickly. This can be a much more agile process.

Lean Shop. Lastly, working in a continuous improvement organization focused on business process management creates an environment and culture of agile improvement. See a problem, fix it, at the lowest level.  That is the nature of true continuous improvement. When you get to a true world of lean daily management backed by solid business process management, agile improvement iterations become the norm. True process improvement projects (waterfall) are only used for large end-to-end improvements.

Even though improvement is happening faster or constantly, it still does not mean it happens without a process. All problem solving must follow a process of understanding the problem, getting to a root cause, and improving. Failing to follow a repeatable approach will result in things like tampering, improper solutions, and improvements reverting back to the old way of doing business.

These are the ways that process improvement and agile are related. Remember, that a process, at its core, is nothing but a series of steps that allow for training, measurement, and consistency. Thus, agile follows a process just like everything else. Although all effective process improvement also follows a process, it can be performed in a very agile manner, getting to iterations of improvement quicker.

Persistence and multi modal in change pays off

Noise…that is the biggest problem in change…noise.

Many people who are concerned about the change, for whatever reason, tend to make a lot of noise.

This noise is something that we tend to react to and that causes us to slow down.

My advice in change is this…

1. Be persistent. Set a standard in meetings to have very complete minutes so those that don’t attend can only complain that they didn’t read the minutes’ not that you are moving forward without them. Have milestones and stick to them. Drive to decisions in meetings that feed the milestones and make sure that everyone knows what the milestone roadmap looks like. Don’t be pressured to deliver more or less than plan unless it completely fits…if you will hit your milestones, there is nothing you need to prove.

2. Operate in a multi modal structure. Identify all the change impacts and then develop plans in an agile function to address the risks of those impacts. Use various ways…meetings, leaders, communications, and special events to overcome the risks.

People will challenge you that you are not prepared for or you don’t have a plan to deal with something down the road, but having the plan to address it and addressing the current impact is a plan. Don’t let them stall your current effort in order to boil the ocean.

Don’t let them convince you to communicate to more people than you need to at this moment. There is a time and a place…releasing a lot of information at once to people not currently impacted by change decisions just produces more noise and now you are responding to it.

Keep moving. Those against change don’t want you to move forward so they win when the process is stalled and you start missing milestones. Essentially it’s like proof to them that this was a bad idea all along. The only reason milestones should be slipped is when external factors, not people slow them down.

Never say, “If this doesn’t work, we can always go back.” This is like throwing gasoline on a smoldering fire. You have just added significant fuel to give those against the change a glimmer of hope that if they derail this just enough, life will return to their expected normal. Out with the old and in with the new. Good ideas that are properly researched are good ideas…but good ideas fail when enough people significantly stall the ideas. Don’t give them this kind of rope.

Being persistent and having an agile multi modal approach to change will succeed. You will be frustrated and start to question–believe in the change and press forward. Not blindly, but with persistence.