• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Bear Bibeault
  • Tim Cooke
  • Junilu Lacar
Sheriffs:
  • Paul Clapham
  • Devaka Cooray
  • Knute Snortum
Saloon Keepers:
  • Ron McLeod
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Frits Walraven
Bartenders:
  • Carey Brown
  • salvin francis
  • Claude Moore

Some thought on impediments  RSS feed

 
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Looking forward to great interest to see what Thomas has to say in his book, but I can speak to impediments in another world.

My Dad was a builder (not a guy who rides around in a big fancy pickup and stops by the jobsite once a week to give his blessing, but was actually out there building things, like we architect/developer types).
If the concrete guy couldn't come on Monday (because it was raining) to pour the basement, then the block mason (who built the basement walls) couldn't come until 2 weeks later. Which made him have to
wait all that time before he could begin framing. Then, the electrician had a job with his "regular" customer (i.e. one of the bigger builders) so he couldn't come for another month.

He was dependent on the weather for a lot of the impediments that came into his world, so he had to plan around it to the best of his ability.

I see the same in our world.

I think one of the best tools in our "impediment avoidance" toolbox is the "officially blessed" schedule from the central Project Mangement org.
If you take that as gospel, you work backwards and you can tell system X that you need their stuff on Date Y, otherwise you escalate.
If SystemX doesn't live up to their side of an Interface agreement, escalate and point out exactly what they promised and what was delivered.

Just a few thoughts....
 
Greenhorn
Posts: 7
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What you describe is essentially a Gantt chart that is indeed often used in project management. Such an approach certainly prevents impediments from happening. Without it you are almost certain to get slowed down by impediments all the time.  But some impediments cannot be managed ahead, because they happen out of the blue.

The reason I am typing this message is because I am severly impeded by a stub server that went down today. We planned way ahead. We said to ourselves: if our external partner cannot deliver that web service in time we will use the stub server for the time being. In that way we are less dependent on their schedule. And we need stubs anyway for load testing. So we asked them for some sample responses way ahead of time, so we could upload these to our stub server.

But now the boys at the stub server team broke something in the user management of the server and we cannot upload our stubs, because we cannot get authenticated with the server anymore. What's more, before we knew this was the actual issue we had to download the source code of the Maven plugin that uploads the stub files and we had to debug it in order to see the actual response from the stub server by setting up a project and a remote debugging session on the Maven plugin. Obviously the Maven plugin didn't give us very much information in case of trouble. Now, the next step is to contact the team that takes care of the stub server and ask them if they can fix the server. Unfortunately the main stub server guy that we all know is celebrating his last day at our company today (I kid you not. He is eating cake in another building as I type this). So I called this other guy in the building where the stub server team is located, asked him to walk two floors down to the stub server team and see who is around. He did and he found our other stub server guy that I forgot about, but is actaully listed in our contact list for stub server trouble. The guy that went looking for the stub server team now tells me that the remaining stub server guy is trying to get the stub server "up" on the test environment. Now I have to go ask this guy what that actually means. We got a response from that server so I figured that it was up, but that users were not correctly configured anymore.

This is how impediments can eat up your time, no matter how well you plan ahead.


 
Marshal
Posts: 13439
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

ruben depuben wrote:essentially a Gantt chart that is indeed often used in project management. Such an approach certainly prevents impediments from happening. Without it you are almost certain to get slowed down by impediments all the time.


I wouldn't go so far as to give Gantt chart such powers  I'd stop at where I think author Tom Perry would: that Gantt charts are useful tools that can help you identify and plan around risks. Gantt charts show you dependencies. A dependency doesn't become an impediment until it remains unfulfilled at the time that it is needed.
 
Junilu Lacar
Marshal
Posts: 13439
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I wrote:I'd stop at where I think author Tom Perry would: that Gantt charts are useful tools that can help you identify and plan around risks.


Hedging my bets, author Tom Perry could also be someone from the camp of Agile that considers Gantt charts evil.
 
Lanny Gilbert
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even in the Agile world, you have user stories for each Sprint. Any interactions between systems (*successful* completion of testing these interactions) should be a task on any user story that involves such.
I'm coming from a world where we have about 70 systems in our "cyber-sphere", and we run into *TONS* of impediments just because no one bothers (well, no one with authority) to insure that systems that commit
to functionality in a release (in waterfall world) or Sprint (in Agile world) to track the progress of inter-system interactions.. This causes huge problems when it all is brought together for an end-to-end flow test.

On smaller projects, what I called out probably isn't as big a deal.
 
Junilu Lacar
Marshal
Posts: 13439
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lenny, the class of problems you refer to are certainly challenging and they can be very frustrating to deal with. However, they are not entirely process-related nor are they entirely technically-related, IMO. It's often a mix of both plus maybe some other things. Ruben's response already alludes to a way to address such issues from the technical side: provide stubs. I would go even further: program to interfaces, then provide stubs. On the non-technical side, I would cite Conway's Law and suggest that perhaps the structure of the organization itself is an impediment.  And then there's culture. Your comment that "just because no one bothers (well, no one with authority)" gives off a smell of lacking a Culture of Ownership.

Have to run out. Will followup when I get back.
 
Lanny Gilbert
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"...gives off a smell of lacking a Culture of Ownership"

Yes sir.. You hit the nail right on the head!

[moderator edit: updated to reflect my edits to the quoted text]
 
Junilu Lacar
Marshal
Posts: 13439
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A lack of ownership is listed as Impediment #84 in Bill Wake's Catalog of 100 Impediments, something that Tom Perry's book references.
 
Author
Posts: 7
5
C++ Java Mac
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Junilu Lacar wrote:

I wrote:I'd stop at where I think author Tom Perry would: that Gantt charts are useful tools that can help you identify and plan around risks.


Hedging my bets, author Tom Perry could also be someone from the camp of Agile that considers Gantt charts evil.



Well, for the record: I think Gantt charts are just a tool. Like a shovel, they can be used for good or evil, but aren't inherently evil themselves. I still use them from time to time, but usually only for high level summaries.

I outline what I call an impediment lifecycle in my book. Risks are potential impediments that haven't happened yet. They are events that may or may not happen in the future given a certain set of circumstances. If we think we see a risk, we can make plans and take action to deal with it (or not). Those actions or mitigations, can help us avoid or minimize the impact of a risk. When the likelyhood of a risk becomes a certainty, our risk transforms and we call it an impediment. Prior to that, a risk is something that MIGHT happen. An impediment is a risk that IS happening. It's right there in our face - happening right now. It's blocking our path, preventing forward progress, slowing us down, or otherwise hampering progress. One way or another, sooner or later, we overcome the impediment and move on. At that point the impediment is something that happened to us yesterday. It's now something in the past. Our impediment has transformed one more time into a potential lesson learned. Not every impediment makes this final transformation. In fact, most don't. Nevertheless, any impediment that you have overcome has the potential to be something that you have learned from. That kind of reflection can teach us how to avoid the same risk again in the future. Of course that's only if we take the time to reflect on it.

So we have an evolution that takes place: risks become impediments which become lessons learned.

Here's the kicker - If you could anticipate every risk, you would be able to plan for and avoid or otherwise deal with most impediments. Of course that would require being able to predict the future. Fortunately, there are plenty of handy tools that you can use to predict the future. I recommend crystal balls, magic 8 balls, tea leaves, horoscopes, time travel, to name just a few. However, I can't recommend Gantt charts. In my experience Gantt charts are not nearly as effective at predicting the future.
 
Marshal
Posts: 64089
215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tom Perry wrote:. . . I recommend crystal balls, magic 8 balls, tea leaves, horoscopes, time travel . . . Gantt charts are not nearly as effective at predicting the future.

If you have that sort of thing in the book, it will be well worth reading.
What about risks whose likelihood is 1.0, 100%, certainty, but have not yet materialised? For example, change of legislation next year, or pregnancy of a key member of team, who will disappear for twelve months, but not until the Summer? Do they have a different life-cycle from ordinary impediments or the same?
 
Junilu Lacar
Marshal
Posts: 13439
222
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
We used chicken bones...

I often tell my teams and those who would have us "commit" to plans and estimates and hold our feet to the fire, "We're programmers, not psychics!" I know it really should be "... not prophets and fortune tellers!" but they still get what I mean.
 
Tom Perry
Author
Posts: 7
5
C++ Java Mac
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does a risk that has a likelihood of 1.0 but hasn't materialized yet have the same lifecycle as the impediment lifecycle I described?

That's an interesting question.

I think the model still holds true. Perhaps the test would be: would my behavior be any different between a risk not yet realized, and one that I "know" is going to happen. In both cases I see it coming. In both cases it's not impeding me until a given time in the future is reached. In the case of the "known" or guaranteed risk, I might be more likely to mitigate it.

...but let's stop right there and ask ourselves a question: Is anything that hasn't occurred yet ever *really* guaranteed? I mean really, really? I like the example of the law or regulation that we know will take effect in the future. Isn't it true that the implementation of the law still may be delayed? It's happened before. So I think we need to be a little skeptical of any 100% guarantees when it comes to the future. That won't stop me from playing the stock market though...
 
Campbell Ritchie
Marshal
Posts: 64089
215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tom Perry wrote:. . . the law or regulation that we know will take effect in the future. Isn't it true that the implementation of the law still may be delayed? It's happened before.

Or you could move somewhere where they simply ignore the law

So I think we need to be a little skeptical of any 100% guarantees when it comes to the future. That won't stop me from playing the stock market though...

Playing the stock market depends on the future being at least partially unpredictable.
 
Lanny Gilbert
Ranch Hand
Posts: 145
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yogi Berra — 'It's tough to make predictions, especially about the future.'

Thanks to all for making this one of the livelier threads on Big Moose Saloon I've participated in for quite some time )
 
Campbell Ritchie
Marshal
Posts: 64089
215
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Our pleasure
 
I have always wanted to have a neighbor just like you - Fred Rogers. Tiny ad:
Create Edit Print & Convert PDF Using Free API with Java
https://coderanch.com/wiki/703735/Create-Convert-PDF-Free-Spire
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!