New-age Transactional Systems - Not Your Grandpa's OLTP
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Vikas Hazrati on Jun 09, 2009
Politics is an integral part of all organizations. Political process is a part of human and organizational behavior. Generally, technical people have a distaste for politics because technical matters are mostly precise and can be stated in black and white where as political matters generally involve shades of gray, which are not always easy to decipher. In a recent discussion on the Scrum Development group, Joseph Little shared a few insights to deal with organizational politics.
Joseph suggested that organizational politics is not as hard as most Agile teams consider it to be. He suggested the following action items to tide over politics,
- When boxing, do not expect to have the first punch be a knock out. Set 'em up for the kill in the 4th round. Lots of combination punches.
- The truth is hard to resist. (Yes, I know people will deny the truth and will often kill the bearer.) Keep finding ways for the truth to be repeated and dealt with. Scrum throws up the truth.
- If a bunch of people go together to a manager's office, it is much harder for the manager to resist. (Make sure you have the truth on your side, and that your idea makes sense.) Maybe even harder if the manager comes to the Team room.
- Justify your impediment removals. Do much better cost-benefit analysis. Do them as small experiments (eg, show the actual results later).
- Justifications include: higher NPV for the product, higher velocity for the team, faster delivery, etc, etc. Make the link from your improvement back to these key things.
- Make the case. Make it so obviously right that the only question is: "How do I know your numbers are right?" Managers only like to approve obviously right things.
- Ask to do an experiment. Make sure the test sample is big enough to draw conclusions from.
Dave Rooney suggested that though all the above points make sense, however along with justification, it is necessary for the team to keep producing working software. The team should ask for a finite time for experimentation and to demo back the results to win the political battle.
Eric Deslauriers further reiterated that the best way to deal with politics is facts. He quoted an interesting case in which he was asking his manager for a better computer and his requests were being ignored.
Being the tenacious person that I am, when one of my coworkers was going on vacation for a week, I asked if I could use his new Pentium while he was gone. I tracked all my tasks and timed them the week before he left, then used his machine and tracked how much time I was saving.I then used the time savings to calculate how much the company was wasting having me sit around waiting for things to happen (compiles, etc.). I got my new PC a few weeks later.
Joe Marasco, shared his viewpoints on politics in a technical organization. He suggested that technical people are generally nervous about politics because their technical prowess does not help them there. According to Joe,
While this is perhaps an oversimplification, it is fairly safe to say that technical people would prefer issues to be resolved on technical merits alone, or perhaps on some mix of technical and business objectives. What they react to, often violently, is the manipulation they see in various discussions and negotiations -- a manipulation they associate with the darker, uglier side of human behavior -- often characterized by self-aggrandizement and personal agendas.
Joe suggested that when the issue moves out of the pure technical realm and cannot be solved objectively then working with politics becomes a necessity.
Examples of legitimate political issues include decisions on marketability, customer satisfaction, business impact, and so on. Since objective, technical criteria are harder to pin down in these areas, debate, including political debate, is necessary.
He suggested that for subjective situations, the key is to get involved in good politics, which is based on consensus building, fact finding, education and intellectually honest decisions. He advised technical people to distance themselves from neutral politics which is based on lobbying, delaying decisions etc. and bad politics which is practiced by lying, bullying and conspiring.
The underlying theme of the discussion conveyed that, though politics would be a definite ingredient of any organization, the key for Agile teams is to base their proposals and decisions on facts, consensus and other attributes of good politics.
Transforming Software Delivery: An IBM Rational Case Study
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Agility at scale, become as agile as you can be
In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!
Boy, this sounds like everyone is suiting up for a big fight. I'm wondering - is this the majority feeling and experience out there?
More and more I'm personally beginning to believe that we can't change anyone else's mind. Unfortunately, the advice given seems to indicate ignorance of this issue and a belief that someone can strong-arm another into "their" solution. If this is done, there goes all the potential of a successful, hyper-productive team out of the window.
One of the sentiments given on the scrumdev list comes from a manager:
IMO, the root cause of the problem is the lack of understanding of the manager's work from the workforce, and the managers not realizing that this lack of understanding exists. One of the tasks of middle management is protecting the team from issues that shouldn't concern them, to make them focus on doing their jobs. However, if (s)he's doing his job right, some people, specially the younger ones, would simply assume that those issues do not exist or, at best, that they're not important. Since the immediate manager is the most recognizable face the organization shows to the workforce, he will incarnate all the sins that the workers detect on the organization (that are probably the 10% that he couldn't filter).
It seems to me that misunderstandings, miscommunications, and not being able to put yourself into the other person's shoes is the culprit. If so, then some of the suggestions here make things worse instead of better.
I think more than managers and team members reporting to managers, it boils down to participating in "good politics" which is based on consensus building and facts. I don't know why politics is ultimately seen to be team members versus managers, in Agile organizations that should be less of scenario.
Some of the suggestions give that manager versus team feeling but then the crux would be to build consensus and play more on facts than just wander in the gray area. Thoughts?
I don't know why politics is ultimately seen to be team members versus managers, in Agile organizations that should be less of scenario.
It seems that it happens more often during transitions - from traditional to Agile. In my experience the "Us vs. Them" problem is human nature. We have to work against our natural tendencies.
(Dave West could probably tell us much more about this aspect of teamwork.)
"Generally, technical people have a distaste for politics because technical matters are mostly precise and can be stated in black and white where as political matters generally involve shades of gray, which are not always easy to decipher."
How patronising and arrogant?
Generally technical people are people who like to get things done and are achievement focused in my experience.
Office politics is a waste of energy, destructive and almost never productive.
You assume that most technical people somehow are little children who "don't get it". This may be true for the stereotype and the minority of techos, but that is not my experience in the main.
They just think it is ridiculous, dangerous and a waste of time. (hence something to be avoided) And it is.
Spoken like a true manager.
John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.
Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.
Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.
Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).
Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.
Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.
One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.
InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.
4 comments
Watch Thread Reply