Marjie Carmen & Associates

Posts Tagged ‘Agile’

Many aspects of an empirical process make it different than a defined process. The one difference that is critical to improved project success is the “inspect and adapt” element. Since my early days teaching and implementing total quality concepts I have often stressed the need to do a few things over and over and while they are easy often times I see them missed:

1. Try stuff out
2. See if it works and solves the problem it was intending to solve
3. If not go back and revisit the problem statement, make sure you understand the problem you are trying to solve
4. If yes then
5. Try some more stuff out
6. See if that stuff worked
7. Repeat until you see the result you were looking to achieve

I used to refer to this as the Plan-Do-Check-Act cycle and there is a lot of literature on this. It is no different than what we refer to as Inspect and Adapt in Empirical Control Process Theory. Moreover, it just makes sense.

I often teach that most problems do not get better with time. Most problems don’t age well. The longer you wait to solve one often the worse that problem will get. There are many studies showing the later in the software cycle you find a defect the more expensive it is. Do you want to find out you have a problem when you have less time to fix it or more time? For this topic we’ll use software defects and changing requirements because there are some problems that if you don’t solve will in fact go away if enough time passes. So to keep this simple, we’ll think in context of software projects and whether or not it would be useful to know if we’re delivering what the customer wants with an acceptable level of quality to that person sooner or later. Inspect and Adapt.

Most delivery teams want to know this sooner versus later.

We all want more time to adjust to ensure we are delivering the “right thing” but are we willing to be uncomfortable with less planning up front to gather real data upfront vs. pretending to know all the answers up front knowing the questions will change?

We know from experience that requirements are emergent and fluid. People on the teams will come and go, reorganizations will happen, our companies might merge with others. When we are talking about a creative process such as software development responding to a creative and ever changing world, we know we must be flexible and able to adapt to a world economy and an enviroment that is quickly becoming driven by our ever emergent new technologies. Even the technologies we use to build products are changing. The one thing we can be sure of is things will change when we set out to build a product. It’s clear we’d be destined to fail or at least limit our chance at success if we tried to fit this creative process into a defined and predictive process. The statistics have proven this time and time again.

So let’s try something different, not because it’s SCRUM, not because it’s Agile but because we are working in an environment we know will evolve quickly and we want to succeed in delivering what the customer wanted, with a level of quality they envisioned in a manner timely for competitive advantage.

How do we immediately apply the Inspect/Adapt concept to help achieve these outcomes? Let’s look at the language we use in Agile/SCRUM and see if it will help?

Inspect:
Frequently!Look at the emerging product with the person who is receiving it

1.Often, weekly if possible together with the team ask the Product Owner or the person responsible for speaking for the PO, is this what you expected? Want? Are we getting close? Are we way off?

Show the Product Owner the product. Not on paper but show them as soon as you have something working, even if it’s partially working. People are people, we don’t know what we want until we see it. It’s very hard to know what we want looking at something on a piece of paper but when we see it working, even if it’s just partially working we get an idea. From an idea we engage in a more knowledgeable conversation. We have a place to start.

Adapt:

The more frequent the inspections the more on or off track you will know you are. You’ll get data/information from the Product Owner. Take the information and do something with it (in the PDCA model this would be the A-Action part of the cycle). Act. Adapt. This is also subject matter information. You’ll be learning more about the business. This is a serendipitous benefit of working closely with your customer. If you’re able to do this enough soon you’ll become a trusted advisor knowledgable in both technology and their business able to partner with them in helping them stay as competitive as possible in their sector of the marketplace.

1.Adapt the changes as needed, you might have to reprioritize the backlog refine the backlog, taking items off, putting new items on. You might even decide to release the product now as is or cancel the sprint. But you will have information to make informed decisions. You didn’t have that in the prior process model. Prior to you had a pile of documents and estimates. Now you have either a partially working product mid-sprint or a fully releasable piece of a product if you’ve completed a sprint or enough of a product depending on which sprint you’ve completed. You have more than a pile of paper.

Inspect and Adapt – Rinse and Repeat!

You can now be proactive/strategic versus reactive.

Which would you rather be? Which is sustainable? Reactive or Proactive behavior? Working long nights and weekends or a repeatable rhythmic pace?

When you had a mad dash at the end to retrofit a huge system that would likely need massive amounts of testing and would risk being dropped into production in an unstable and fragile state did you feel as though you had control over the process or the project? Also likely not close to 100% of what the customer wanted because you waited too long to ask and now you can only do a portion to get it right. You’d spend weeks fixing the system to get it to the barely acceptable level while also introducing new features and breaking more functionality and still having a barely acceptable level of quality and working/acceptable functionality. By acceptable I mean, what the customer wanted. You repeated that until your system had so much technical debt you debated for weeks, maybe months whether you should rebuild the entire thing. You might have inherited this problem and are having this conversation right now, do we scrap everything and use the latest technology and build an entirely new system or do we take what we have and fix it. Either way the answer as to how you get there is still the same, use an empirical process. Do it in small increments. Know more about the system now versus later. Which process gives you more information? Is more information giving you more control earlier on to make more informed decisions?

Why do you want to change from a defined/predictive process to an empirical process?

In the Standish group’s 2011 CHAOS Reported stated that more than half of software projects failed or were challenged. Only 14% were successful using a defined process but using an empirical process 42% were successful.

What process do you want to use?

Inspect and Adapt – it’s easier, it makes sense, less surprises, find out fast if you’re successful or you need to make course corrections.