Cloud Foundry: Design and Architecture
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Posted by Shane Hastie on Jul 10, 2011
Dr Rashina Hoda achieved her doctorate researching self-organizing Agile teams. She recently spoke to InfoQ about the work she's been doing and the results of her research.
Q. Firstly congratulations on receiving your Doctorate. I gather you have been busy since the last time we interviewed you for InfoQ – what have you been working on lately?
Thank you. After finishing my PhD, I've been working as a Post Doctoral researcher here in the School of Engineering and Computer Science at Victoria University of Wellington, New Zealand where I've been lecturing courses and writing more research papers. I've been supervising a final year Bachelor of Engineering student on a project which involves building a Agile story wall for Multi-Touch surfaces. The idea is to build a story wall application for Agile teams which preserves the advantages of paper-based walls such as situation awareness [6] while introducing the electronic advantage such as dynamic space utilization and state feedback. The multi-touch surface platform provides opportunities for extending this application to support distributed Agile teams.
Q. Quite a lot of your recent work has been in the area of self-organising teams; how do teams go about becoming self-organising and what are the important characteristics of a self-organising environment?
Software development teams go about becoming self-organizing by adopting one or more informal, implicit, transient, and spontaneous roles and by performing balanced Agile practices [1]. These roles are Mentor, Co-ordinator, Translator, Champion, Promoter, and Terminator which I described when we last talked. The practices include several low-level Agile practices which are bunched together into three balancing acts at a higher level: balancing freedom and responsibility, balancing cross-functionality and specialization, and balancing continuous learning and iteration pressure. These balancing acts help Agile teams achieve and sustain three conditions of self-organization [7] - autonomy, cross-fertilization, and self-transcendence - respectively.
The important characteristics of a self-organizing environment include an organizational culture of openness where individuals enjoy the freedom to voice their opinions; an informal organizational structure in practice where the lines of formal hierarchy do no inhibit flow of information and feedback; and most of all, an environment of trust.
Q. Why do self-organising teams work more effectively in the software world?
Self-organizing teams can be highly effective in the software world in many ways:
• Self-organizing teams are made up of cross-functional members that are able to rise to new challenges and organize themselves to respond to changes in project, customers, technologies, and requirements. This property of self-organizing teams is particularly valuable in the fast-paced, ever-changing software world.
• Self-organizing teams are made up of motivated individuals that take ownership of their tasks and have commitment to their collective team responsibilities. Such teams are able to be effectively autonomous and considerably decrease traditional management efforts such as task allocation and continuous monitoring and reporting.
• Self-organizing teams collaborate closely and frequently with their business customers which ensures they build products and applications that are well aligned with business requirements.
• Self-organizing teams are focused towards continuous improvement which drives innovation and creativity in the business solutions they provide.
Q. What are some of the common pitfalls and risks that self-organising teams face, and how can they avoid them?
A common pitfall that self-organizing teams face is the perception that self-organizing teams do not need any management. While it is true that management in the traditional sense of the word - allocating tasks, monitoring progress, appraising individuals, etc - is not required for self-organizing teams, the need for good leadership remains. Good leadership on new Agile teams includes mentoring them on Agile principles and practices, guiding them on collaborating effectively with customers, helping them secure senior-management buy-in, and gradually passing on these roles and responsibilities to the team members. Leadership on new teams is usually taken up by Agile coaches (Scrum Masters, XP coaches, ex-Project Managers that have successfully acquired an Agile mindset). On more mature teams, the role of leadership focuses more on ensuring the team continues to be self-organizing. This involves ensuring one or more individuals on the team are able to play the informal self-organizing roles [2] and the team is able to effectively perform the balancing acts [5] when faced with critical environmental factors such as varying levels of customer involvement [3] and senior management support [4].
Another common risk is that Agile teams may perceive self-organization as a binary state of being when in fact it is a continuum [1]. In other words, teams can be at different levels of self-organization and can move up or down that scale at different stages. Once teams perceive a certain level of understanding and expertise in Agile practices, they risk becoming complacent and thereby losing their self-organizing ability. The trick is to constantly self-evaluate and self-improve by not just improving their productivity but also improving their ways of working. In order to achieve continuous improvement, teams should include explicit time for learning in their otherwise action-packed iterations.
Q. What advice would you give to management in organisations that are trying to establish a culture of self-organising teams?
How effectively are your teams self-organizing?
References:
[1] Rashina Hoda. Self-Organizing Agile Teams: A Grounded Theory. PhD Thesis ,Victoria University of Wellington, New Zealand, 2011. URL: http://hdl.handle.net/10063/1617
[2] Rashina Hoda, James Noble, Stuart Marshall. Organizing Self-Organizing Teams. Proceedings of the IEEE/ACM International Conference on Software Engineering (ICSE2010), Cape Town, South Africa, May 2010.
[3] Rashina Hoda, James Noble, Stuart Marshall. The Impact of Inadequate Customer Involvement on Self-Organizing Agile Teams. Journal of Information Science and Technology (IST) Special section on Best Papers from XP2010, 2011.
[4] Rashina Hoda, James Noble, Stuart Marshall. Supporting Self-Organizing Agile Teams: What’s Senior Management Got To Do With It? Proceedings of the International Conference on Agile Software Development (XP2011), Madrid, Spain, May 2011
[5] Rashina Hoda, James Noble, Stuart Marshall. Balancing Acts: Walking the Agile Tightrope. Cooperative and Human Aspects of Software Engineering (CHASE) workshop at the IEEE/ACM International Conference on Software Engineering (ICSE2010), South Africa, May 2010
[6] Helen Sharp, Hugh Robinson, J Segal. The Role of Story Cards and the Wall in XP teams: A distributed cognition perspective. In Agile2006, USA, 2006.
[7] Hirotaka Takeuchi and Ikujiro Nonaka. The New New Product Development Games, Harvard Business Review, 1986.
About Rashina Hoda:
Dr. Rashina Hoda is a post-doctoral Researcher and Lecturer in the School of Engineering and Computer Science at Victoria University of Wellington, New Zealand. Rashina's PhD research focused on self-organizing Agile teams and resulted in a number of publications at different venues such as the Empirical Software Engineering Journal, the Information and Software Technology Journal, ICSE2010, OOPSLA2010, XP2009-10-11, and EuroPLoP etc. Rashina can be contacted at rashina@ecs.vuw.ac.nz. For more information on her research and links to her publications, see: http://ecs.victoria.ac.nz/Main/RashinaHoda or http://www.rashina.com
Shane Hastie is an agile coach, trainer and consultant working for Software Education in Australia & New Zealand
Continuous Delivery: Anatomy of a Deployment Pipeline
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
How ALM Supports Business Processes
Visual Studio vNext: ALM features for Agile Planning, Team Collaboration
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,
I tried openning the URL: hdl.handle.net/10063/1617
It says resolution error and 10063/1617 cannot be found.
Can I know where I can get a copy of the thesis
Thank you,
Steven
Hi Steven,
Please try this URL: researcharchive.vuw.ac.nz/bitstream/handle/1006...
regards,
Rashina
Derek Collison discusses the goals, the design premises and patterns employed in creating the architecture of Cloud Foundry, VMware’s open source PaaS, unveiling internal architectural details.
Andrew Watson talks about the work of the OMG, where CORBA is alive and well (hint: in your car), UML and UML Profiles vs. custom Modeling languages, DDS and other middleware, and much more.
Sohil Shah discusses creating iPhone and Android enterprise mobile applications based on cloud services using the open source platform OpenMobster.
Paul Sanford presents the transformations supported by data throughout its life cycle, and how that can be better done with Splunk, an engine for monitoring and analyzing machine-generated data.
A common “best practice” for unit tests is to only write a one assertion in each test. I intend to question this advice by showing that multiple assertions per test are both necessary and beneficial.
John Rauser presents the architectural and technological evolution of Amazon retail websites starting with 1994 and ending with adopting Amazon Web Services.
Michael Stal discusses system architecture quality, how to avoid architectural erosion, how to deal with refactoring, and design principles for architecture evolution.
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
2 comments
Watch Thread Reply