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 Apr 27, 2010
Most organizations hire Agile coaches to carry out an organization wide Agile transformation. The intention is to have a lean and fit organization by the time coaches walk out of the building. Often, the transformation begins with a pilot team. However, it is very difficult to achieve transformation that improves the end-to-end delivery process and is sustainable if the transformation just begins at the team level and the surrounding organization is not involved.
Agile coaches share their thoughts on what goes wrong with organizational transformation. Dave Nicolette categorizes the problem into two meta failure modes.
One is the “Agile community problem” which focuses too much on individual teams, software and testing disciplines and helping the teams improve. Most coaches are hired to help teams and not to focus on organizations. The other meta problem is the “Not our fault” problem.
I've observed a general tendency for management to dump all of their fire-suppressant directly on the point where they see smoke emerging from their process, without first discovering where the fire itself is located. Since traditional organizations are characterized by (among other things) blame-shifting and information-hiding, any problems in the delivery process are shunted downstream, and any metrics to be reported at a given point in the process are sanitized. The scorecard always looks beautiful until the work reaches the end of the delivery process.
Dave mentioned, that the teams might not be the best place to start the improvements. Coaches should by themselves and should be allowed to investigate the organization for finding out the potential weakest links in transformation and they should start addressing those.
Rob Myers suggested a list of pitfalls, which are identifiable pretty early in the transformation process. Rob suggested “Training the leadership team early” as one of the most critical precursors.
According to Rob, the management should be trained in Agile before the entire process begins so that they have an idea of how the teams should work and understand the true concept behind “servant leadership” and “self organizing teams”. Jean Tabaka also put this as a critical adoption failure. According to her,
An executive who announces "We are going agile," but does not provide rich resources, rich commitment, and readiness to change measures of success, simply demoralizes teams. Successful adoptions of agile can be associated consistently with a passionately engaged executive sponsor.
Rob, further made the following recommendations for the organizations going Agile,
Thus, the organization has a lot to keep in mind. However, sometimes it is also the Agile coach who is at fault. Lyssa Adkins suggested an interesting list of seven coach personalities which are sure to create problems in the transformation process. Her list has the following persona's for Agile coaches who lead to failed transformations.
Thus, it is imperative both for the organization and the coach to tread with caution. The key lies in rising above the pilot team and look at the organization as a whole. As Dave summarized,
What we should stop doing is dropping onto "uh team" in the middle of an ocean of dysfunction, as if from a rescue chopper, and expecting meaningful and sustainable organizational change to occur just because we stick a few story cards on a wall in some conference room cum team room. It ain't gonna happen, my droogies.
Transforming Software Delivery: An IBM Rational Case Study
18 agile and lean practices for effective software development governance
SCM best practices for multiple processes, releases & distributed teams
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!
Hi,
As you mentioned I think Challenges of Scaling Agile in Enterprises can be divide to two parts:
The first the challenges inherent in agile itself and second those imposed by the enterprise. Actually adopting agile practices and techniques is not sufficient, because agile is mindset and we should change organization culture, management model, organization hierarchies and many other factors should be consider. Perhaps this transmission is very hard for large scale organization, so it’s very important to select right pilot project and follow to mentioned recommendation as you said in above.
Additionally another critical decision is Coach from Internal or Coach from external, this mean that there are very important that organization try to train agile from internal manager, (perhaps existing leaders) or someone from another company. I think training from internal is very efficient, because he/she know organization culture and psychology.
I agree with your article wholeheartedly. I started Agile on a single team in my organization without the rest of the org adopting or being trained. We were successful, but not without a lot of effort on my part to continue to push back on traditional practices.
After 3 years, and a very successful product launch, we are now taking Agile up to the full organization. Here again we are struggling with changing the organizational infrastructure. There still has not been an effort to train the organization, and that is making the transition more difficult. People are reading a phrase or two out of an Agile book and thinking that makes them an expert.
If you are considering adopting Agile at the organizational level, heed the cautions offered in the article.
In many cases, after training the leadership team and (if you're lucky) changing some practices in the leadership team, attention seems to turn almost entirely to the team transitions. Unfortunately, this can be even less effective than just starting with bottom-up transitions.
The leadership team still needs attention through coaching and support. Yes, the leadership team is talented, influential and sees the whole picture. That is why they are there. But the sheer number of decisions and distractions means often change is harder to establish, even with well-intentioned teams. Often, the fact that coaches are establishing self-organized teams translates into a view that leadership can ignore the transition when this is often not the case.
The leadership team has two clear responsibilities: To set an example by following through on any changes they may decide on to better understand agility (typically, transparency at the very least); To be vigilant in identifying and removing organizational impediments that threaten acceptance of the change.
Therefore, the focus on the leadership team doesn't stop until the transition is complete.
Vikas, thanks for the orginal article and Debbie for your reply. At Suncorp (a financial institution in Australia) we started the Agile transformation of our 17000 people across numerous subsidiary companies and locations in late 2007/early 2008. We were lucky though as we did have support, energy and a true believer in our Group Executive, Jeff Smith, who drove the change from a few successful and motivated teams to the whole organisation.
When we couldn't find quality Agile training in Australia to support our experiences, Suncorp created their own training organisation, the Agile Academy (www.agileacademy.com.au) in conjunction with trained internal coaches as well as eliciting assistance from our partners with external coaches to support the transition. This has seen 3000 internal staff trained and hundreds of external people undertaking our external Agile courses through the Academy over the past 2 years.
Without a doubt though, training was one thing, but as you said Vikas, management have to be on board and understand what's happening in the first place to support their teams. For us too, coaches were and are essential to our continuing success. Sorry for the plug for the company but as you can tell, even though our journey has not always been smooth, success has been high and we are seen as one of the leading Agile organisations in Australia. What this has come to mean is that many if not all of us at Suncorp have joined the ranks of the true Agile believers too.
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