Many of the roots of Agile development practices can be traced to principles of Lean Manufacturing and the Toyota Production System. From their origin in the world of manufacturing, these principles have subsequently been applied to service industries such as health care and to supply-chain logistics overall. Lean principles and practices focus on eliminating waste, reducing cycle time, and increasing the flow of value delivered to the customer/end user.
There are obvious differences between the manufacturing environment, with its focus on the repetitive delivery of identical parts and products, and the software development environment, in which variation is not only the norm but is necessary for the creation of end-user value.
By now I hope you have read about the 2011 SATURN Conference and its focus on “7 things you need to know.” Maybe you’re considering submitting an abstract for the conference. Whether you’re an old hand at presenting or a first-timer looking to get started, creating an abstract for submission can seem like a daunting prospect.
Here are a few tips I hope will help:
- Begin with the end in mind – This quotation from Stephen Covey is applicable to many things in life, including writing a conference abstract. Have a clear idea of the learning objectives you want attendees to achieve and work backwards from there.
- Know your audience – SATURN, for example, is a practitioner’s conference so applicability to real-world technologies and architectural challenges is key.
- Keep it simple – It can be tempting to condense your entire presentation into the submission but remember that it is an abstract. It’s worth the effort to distill the key concepts and solutions that you’re trying to convey. It will help you clarify your own thoughts as well as indicate to the selection committee your ability to deliver a crisp and cogent presentation.
- Communicate your unique perspective and knowledge base – Whether you’re submitting an experience report or a more conceptual discussion of methods and practices, make sure to communicate what makes your perspective particularly compelling and noteworthy.
It does take effort to create a high-quality abstract but the opportunity to share your ideas and get feedback from members of the architectural community will definitely make it all worthwhile. I look forward to reading your proposals.
– Nanette Brown, SEI
It seems like only yesterday that we were in Minneapolis for the SATURN 2010 Conference, and now it’s time to start planning for SATURN 2011. This will mark my first year as conference chair, taking the reins from the very capable hands of Ipek Ozkaya who has chaired the conference since its inception.
In 2011, the conference will be held from May 16th through May 20th in beautiful San Mateo County, California.
The theme for SATURN 2011 is Architecting the Future. In celebration of SATURN’s 7th anniversary, the conference will explore “7 things you need to know about the next 7 years in architecture.”
The 7 things that we have chosen are
- Architecture is Not Just for Architects (the role of developers, business analysts, project managers, testers, financial analysts, executives)
- Architecture, Agile Development, and Business Agility
- Soft Skills for Architects
- Service-Oriented Architecture (SOA) and Cloud Computing
- Architectural Knowledge Management
- Architecting to Meet Tomorrow’s Global Challenges–Health Care, the Smart Grid, the Environment …
- Model-Driven Architecting
The call for submissions is now open. We will be accepting abstracts for presentations (1/2 hour, 45 minutes, or 1 hour) and tutorials (4 hours) through November 30th.
To learn more about the conference and the submission process, visit the SATURN 2011 website.
SATURN is a practitioner’s conference. We know you’re doing great things. This is your chance to share your experience and practices with the rest of the SATURN community.
Nanette Brown – SEI
Technical debt is a metaphor developed by Ward Cunningham as a means of explaining the need for refactoring to non-technical product stakeholders.
In short, the metaphor asserts that releasing a system with suboptimal architecture, design, and/or code burdens the development organization with debt. The interest payments associated with the debt cause future system enhancements to require increased time and effort. If refactoring techniques are not used to pay down the debt, debt can continue to accumulate to the point where enhancement activities grind to a halt, resulting in metaphorical (and potentially literal) bankruptcy.
This is another post in the “From the Trenches” series about our research project on communicating the value of architecting within Agile development. I meant to post this earlier, but I’ve been in the trenches digging.
As Ipek Ozkaya discussed in our From the Trenches kickoff post, we are approaching our research on the value of architecture from the perspective of release planning. I am excited about this perspective because it moves the discussion of architecture’s value out of the realm of philosophy and into the realm of action and choice. As practitioners, we may talk to management and marketing and other decision makers about how valuable architecture is, and they may, in principle, agree. However, the real test of whether we’ve made the sale about architecture’s value is when the time comes to make investment choices, and that’s where release planning comes into play.
I’ve been thinking about the issue of modeling and documentation. While many within the Agile community embrace the concept of “modeling with a purpose,” there is also a widespread view of documentation as an after-the-fact, template-based activity that generates unused shelfware. To me, this dichotomy can best be expressed as the difference between acting “in the heat of passion” and acting “in cold blood.”
I have to admit that when I first started hearing about Extreme Programming and Agile methodologies, I was pretty skeptical. Another software fad that will come and go, I thought. What first started to open up my mind was a conversation that I had with a young developer a number of years ago. I was interviewing him for a position and he was talking about Extreme Programming and I was thinking “Yeah. OK.” Then he said that without Extreme Programming he didn’t think he would still want to be doing development because Extreme Programming had made software development fun again. And that’s when I stopped and thought to myself, “Well, yeah, you know – it should be fun. It’s supposed to be fun.” And by fun, I don’t mean “drinking beer and playing foosball” fun (not that there’s anything wrong with that). Continue reading
At the Agile Alliance conference, Scott Ambler gave a thought-provoking talk entitled “Agile by the Numbers – What People are Really doing in Practice”.
Scott has been conducting surveys focused on the Agile Community for several years. He has made the survey data available at the following URL – www.ambysoft.com/surveys. The published Agile surveys span the years from 2006 to 2009 and cover the following topics:
- Agile Adoption Rates
- Agile Practices
- Agile Project Initiation
- Agile Certification
- Test-driven Development
In my last post, I started a discussion on the relationship between Agile practices and Architecture. Last month I attended the Agile Alliance conference in Chicago to learn more about where the Agile movement is headed and where Architecture fits in.
Agile Development originated for use by small cross-functional teams, co-located with a dedicated customer representative. In this context, the strategies of emergent design, refactoring and the use of tacit knowledge were sufficient to deal with most of the technical challenges faced by the teams. Architectural practices were rarely discussed.