It was back in ‘97 that these presenters first opined that: while much attention had been focused on high-level software architectural patterns, what is, in effect, the de-facto standard software architecture had seldom been discussed: the Big Ball of Mud.
Somewhat to our astonishment, since then, no one has ever undertaken to dispute this premise.
A Ball of Mud is, of course, a haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle.
Is Agility’s utilitarian focus on process rather than design its secret weapon, or its Achilles heel?
Set-based design (also known as set-based concurrent engineering) offers a paradoxical way to make Agile teams even more effective by actively exploring multiple options. In this back and forth conversation between the presenters, we’ll talk about the relationship between Agile, Lean ideas, and the Toyota approach to product development. We’ll describe the specific mechanics of how you can get started with set-based design, and the benefits you can see. Finally, we’ll dispel the notion that this is just another form of analysis paralysis.
What can programmers learn from the thought of Aristotle, Kant, and Mill? More than you might think. Find out what three of the greatest minds in history think about things like craft, art, virtue, and happiness, and how they would run a software project.
We’ll link philosophical ethics and ideas to the processes, tools, and methodologies of software development as we discuss a critical question: is successful development primarily a matter of finding the right rules, creating the right outcomes, or cultivating the right virtues?
The study of Group Relations is important to the development of Agile practice. Software development is performed by groups of individuals. When individuals become a members of a group, behavior changes. The group becomes focal & the individuals become background. The group behaves as a system and exhibits system-level behavior. Groups as a system exhibit very primitive emotional behaviors that can derail the group from its stated primary task.
Group relations theory says that a group behaves as a system, and that the primary task of the group is……
Deploying to servers has replaced shrinkwrapping CDs for delivering software. In the internet enabled era, the application is the infrastructure.
The basis of all Agile engineering practices is reproducibly building from source code. If software is delivered on servers, and those servers can’t be reproducibly deployed from bare metal to working services, how Agile can you be?
Continuous Integration is great, but what about Continuous Delivery! What are you waiting for?
This talk will outline innovations in tools, process, planning and culture emerging at the front lines.
Pragmatics is an agile development shop rated at CMMI Maturity Level (CML) 4 and striving to achieve CML 5. By maturing our agile disciplines, we feel we will not only improve the performance of our agile teams, which will ultimately benefit our agile development practices regardless of our appraisal rating, but will also lead to our being appraised at CML 5. We feel that a mature, highly disciplined agile development company rated at CML 5 will be very intriguing to potential customers looking for contractors that can deliver on time quality products. That is, we feel they will flock to us.
The method of Modeling in Color (MIC) has its foundation in object-oriented analysis and design; however, given today’s modern service oriented architectures (SOA), the approach is more relevant than ever. In any SOA, MIC can provide answers to difficult questions like: How are services properly designed? What’s the appropriate level of granularity for those services? Basic MIC techniques will be discussed and how to break a Color Model into discrete, loosely coupled components will be examined. How to convert the componentized model into XML schema and into XML web services will be explored.
Priorities shifted twice a week. My favorite lightweight practices were all too heavy. Facebook thinks I might be a spammer. On November 5, the code became totally worthless. It was the best project I’ve been on!
Come and hear about a project that was too strange for normal, comfortable agile methods. I hope you can learn from my experience, and make sure you are bringing the right tools and processes to your next project. Focus on the principles of agile (communication, simplicity, feedback, courage) instead of the practices (CI, pairing, iterations, etc).
Agile fails without executive leadership. Although pockets of Agile can flourish for a while, only executives have the power to make an entire organization change.
The agile community has tried to sell executives on Agile rather than involve them. This workshop involves participants in discovering and documenting patterns for Agile executives to use. It builds on our previously-presented CTO research.
This session is appropriate for executives with Agile experience and for gurus who commonly work with executives. Others should wait for the results.
Ever heard a programmer say “I think the code’s trying to tell us something”? A joke, right? A metaphor. There’s a social world, where people tell people things, and there’s a world of objects that, at most, exert passive pressure.
But what if we deny that the two worlds are separate? What if we treat everything as a moving mashup of objects, ideas, individuals, and groups? This workshop will present some recent perspectives from sociology on that question, and will ask participants the following: if you believed in one of those perspectives, what would you do differently on your project?