Bindings, Platforms, and Innovation
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
Tracking change and innovation in the enterprise software development community
Posted by Mark Levison on Nov 16, 2008 11:00 PM
Recently there has been a discussion making about transitioning teams to co-located environments and what it takes to make it a success.
Dave Rooney, of Mayford Technologies, says:
Robin Grosset said that when the transition happens, developers mustn't lose floor/desk space when compared to their traditional cubicles, otherwise they will feel it's just a management ploy to squeeze more people into less space.
Sam Edwards noted:
Initially there was very strong resistance from quite a few engineers - they felt they were giving up their privacy and "comfort zone". So we let them organize their desks with the open space, and found they ended up at the periphery, all facing away from each other (corner positions preferred to side positions). ...as pair programming began to creep through the teams, we found the engineers spending more and more time sitting beside each other, which made the actual location of their desks fairly irrelevant. My one strong piece of advice: give the engineers LOTS of time to make this adjustment - it's a big one for many of them, and impossible for some.
Adrian describes a transition he organized for a team of ~45 people:
Scott Ambler, Agile Practice Leader at IBM, while acknowledging co-location as likely to improve a team's chances of success, raised some concerns:
Finally Jay Conne shared the story of a "tech introvert" who told a VP in an elevator that he liked the interaction of team.
Agile Development: A Manager's Roadmap for Success
5 Ways to Ensure Application Performance
Effective Management of Static Analysis Vulnerabilities and Defects
When I team co-locates I don't expect people who work from home to change their habits. Their role on the team might evolve over time if only because of the isolation. In addition he is mentions the security concern with information radiators. Frankly I'm baffled if they're a security concern you would never be allowed to have them in the first place (sad) team room or not.
When I team co-locates I don't expect people who work from home to change their habits. Their role on the team might evolve over time if only because of the isolation.
I love working from home, mainly because the traffic during the commute consists only of a dog, cat, my wife and kids. They tend to be more predictable than most drivers. ;)
In addition he is mentions the security concern with information radiators. Frankly I'm baffled if they're a security concern you would never be allowed to have them in the first place (sad) team room or not.
I don't buy this, at least on it's face. To quote Brian Marick, "an example would be good about now". I worry that for the < 1% of the time that this actually applies, the other > 99% of projects would use it as an excuse not to be open and honest about their progress.
Dave Rooney
Mayford Technologies
My customer currently has a co-located Scrum team that has become hyper-productive in only five sprints they did together. They have a team room with lots of noise because some people have a naturally strong voice. I found out that after some time the rest got used to them, sometimes they call "be a little quiet", sometimes just they just have fun. My own experience is: The more clear the requirement is that you implement, the less important becomes the noise. Noise is mostly a problem when you try to solve a difficult problem alone, in the privacy of your own mind. Having done this for years, I now simply try to avoid this lonely thinking entirely and have a peer for discussion or pair programming, instead. This has proven to be far less error-prone and much more fun!
This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.
This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.
This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.
This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.
This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.
After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.
IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.
Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.
3 comments
Watch Thread Reply