Interesting Thoughts About Architectural Evolution July 9, 2007
Posted by Jiri Lundak in Agile, Architecture.add a comment
Tom Ayerst, whom I met when becoming a Certified ScrumMaster in Vienna in 2004, writes here some interesting notes about architecture evolution, like:
“What does this mean? The ideal architecture is as described above simple, and focused, it should also be balanced and not restrict you from taking it in any a particular direction. This last desirable trait is invisible, you don’t know you cannot go in a particular direction until you try to go there.”
and
“Over time your architecture will become less balanced and amenable to change. Getting the balance back will probably require an architectural review of some kind and some kind of more disruptive change than another simple refactoring.”
I think he is quite right. I can observe this with our own application framework we use at work. No simple refactoring will do. After multiple refactoring sessions done often as a pair, we are still trying to bring the architecture back on track. It all depends on how far away you already are from the ideal line.
Scrum Talk at Event for Swiss FDJP Project Managers June 26, 2007
Posted by Jiri Lundak in Agile, Scrum.2 comments
I will be giving a talk about our experience with Scrum in a large project at an event of the Swiss Federal Department of Justice and Police on June, 28th.
Here the slides (in German) in Powerpoint format: Scrum in der Praxis (Powerpoint).
And as PDF: Scrum in der Praxis (PDF).
The 3 Axes of Agile Architecture April 30, 2007
Posted by Jiri Lundak in Agile, Architecture, Programming.4 comments
When thinking about my last post today, I was not quite satisfied with it. The values seamed quite unfocused to me in hindsight.
Actually I think we need to condense - especially the values - some more, so that we get at the essence of the agile spirit we need to be able to measure a good architecture against it.
In the end I think it boils down to the following three axes, along which an architecture (maybe embodied by a framework) can be judged (see the figure below).
I would contend, that an architecture satisfying all three of the axes is THE agile architectural basis for software development that is able to deliver on the agile promise.
Let us have a deeper look at the individual axes:
Change-Encouraging
This axis focuses on embracing change. For an architecture to support this, it needs to be easily modifiable, extendable, refactorable. If it is hard to change, it will lead - over the long run - to clumsy code, horrible work-arounds, lots of glue code and very extensive documentation, that needs to explain all of its quirks and potholes.
If it is easy to change and the developer is free to change his application at will, without too much effort, without breaking existing functionality of his application, then the overall design of the architecture (and the framework eventually embodying it), will remain simple, clean and easy to grasp over quite a long period of time (good tending practice implied).
Quality-Enforcing
Agility has one of its foundations in the delivery of production quality code on from iteration 1 to whatever number of iterations a project takes to complete. As such an application developed in agile manner needs a foundation, that has quality build right into it. This kind of architecture makes it hard for the average developer to make stupid mistakes.
It simple does not allow to circumvent good coding practices. It allows freedom of interpretation only in dimensions, that are in the application domain. It helps the developer to test his code in an easy, dare I say fun fashion, so that he wonders, how he could ever live without the safety net he is constantly weaving.
Value-Producing
Though I mention this axis at the end of this text, it is the focal point of agile software development. When we do not produce the right thing, it is of no use to produce it as fast as possible with the highest possible quality.
That said, it is crucial to produce value for the customer. The architecture should not stand in the developer’s way to produce some useful application. It should encourage him to produce value out of the box, to be able to show his customer a thin, but fully working, slice of the final product he will get.
At the same time it should prove to be a tool in the developers hands, that allows to try out easily alternatives, that can be quickly transformed into a visible artifact to put in the hands of the customer, so that fast feedback can be harvested, which eventually flows back into the development cycle.
Complementary products like acceptance testing support and generic self-documentation should help to produce value faster.
Conclusion
To produce an architecture (embodied in a application framework) that supports these essential values, may not be easy, but at least this is a starting point to think more deeply about principles that support this value-system.
As a nice side-effect I now have a system, that allows me to have a look at existing application development framework and weight them against each other. But I will spare this for another post.
Agile Software Architecture Principles April 30, 2007
Posted by Jiri Lundak in Agile, Architecture, Programming.6 comments
It is not a secret that I am fond of Agile software developement. I have published multiple articles over the last few month on pitfalls with Agile implementation and I am even writing a book about it.
But in my chest there still beats a heart of an architect and developer. As such I would like to see still better tools, frameworks and development practices. Last friday I was the last standing man at our company, with a colleague of mine and we were fantasising about our personal take on a lean, mean application development framework. We found quite a common ground, when it came to our dislikes with the existing way to develop software in the Java world.
It is always easier to articulate your dislikes, instead of reflecting on the values and principles, that you would like to see flourish.
So what we dislike about existing frameworks boils down to the following short list:
- Configuration in monstruous XML configuration files
- The jungle of XML WebServices as the SOA silver bullet for all application integration
- Way too much code generation in the past
- Although we are fond of metadata to be leveraged in applications, we dislike too much annotations (obscuring further how things work)
- Writing still applications for the single VM, not using the power of many distributed ressources
- Frameworks, that grow to such giant dimensions, that you have to install a 60 MB package, of which you use only 1% in your application
- Frameworks, that want to be everybody’s darling, by including hunderts of alternatives (we integrate anything) for each module and for this sacrifices ease of use and efficiency in programming
- Generation of boiler-plate code seen as THE holy grail in increasing productivity
When going through these points in retrospect, I would like to synthesize some values and principles, that I would like to see in a framework, that really helps me concentrate on giving a customer what he needs, without much of the grieveance included, when using today’s breed of tools.
Here are the values I would like to see embodied by an ideal framework:
- Efficiency
- Purity
- Easy Modifiability
- Expressiveness
- Openness
These should be support by principles the framework should enforce and follow:
- Ease of use
- Transparency
- Scalability
- Maintainability
- Testability
There is some tendency towards easing the pain of development with the advent some of the newer frameworks for web development, maybe started by the hype surrounding Ruby on Rail. Other new frameworks, that fit in this category are SEAM and Grails.
While these frameworks tend to point into the direction I would like to imagine, they are still not there, yet. Too much boiler-plate code, sometimes too much XML. And if all else fails: I could still argue, that they are not Java frameworks! 
I just would like to take the Agile thought to the extreme and make it as easy as possible (in Java) to implement and maintain an enterprise-ready application. “I know I’m a dreamer…but I’m not the only one”, to speak with Lennons words.
But who knows, out of idealism, sometimes something new and revolutionary can emerge. Let’s get surprised.
Low Scrum Adoption Rate in German-speaking world? April 30, 2007
Posted by Jiri Lundak in Agile, Scrum.2 comments
A week ago I was presenting a session at the JAX conference’s Agile Day, hosted by Jutta Eckstein. Exceptional was the interest people have in Agile software development. First it was thought that only about 100 people would attend the Agile track, instead 280 showed up, showing the increased awareness.
Quite contrary to this only a few people (about 10) raised their hand, when asked who was already using Scrum. But even more surprising to me was the fact, that only about another 10 or so signaled their interest to use Scrum in the near future, when I asked them.
I think, that there is still a lot of potential to educate people to use Agile in their work. But how can we lower the entry barrier? During lunch I was talking to a group of people, that had their reservation about what to expect from Agile development. They mentioned the thought, that what was needed to provide would be some week long immersion workshop, to experience the benefits, for one’s own work.
Maybe this is missing, especially in the German-speaking part of the world.
QCon Day 5 March 17, 2007
Posted by Jiri Lundak in Agile, Team.2 comments
As I had to fly back home on Friday afternoon, the report on Friday’s sessions is quite short. Although I wanted attend the planned Open Space on “Reflecting on your Agile journey - How do we reach Mastery?” led by Deborah Hardman and Diana Larsen, I just did not make it. This mainly, because in parallel there was still an Agile track going, with too much of good content. So I had to sacrifice something. 
I decided to hear what my friend Joseph Pelrine had to say about “When Agile Hits The Wall - Dealing with the organizational challanges of Agile adoption”. Joseph’s talk was video-taped, so I hope it will be available as Video-Stream somewhere from the conference website soon. At least they promised to make the material available.
In his entertaining and metaphorically rich manner Joseph showed why there are fundamental clashes in an organization, when some part of it (like a team) tries to adopt Agile values and practices. Sometimes all goes well within one team, but as soon as the team tries to reach outside its zone of influence things seldom work out as expected. Actually even resistence and suppression can be the response.
Joseph compared going to fast with Agile adoption with running downhill - if you let go, you accelerate and accelerate until you go to fast and stumble over your own feet - a nice metaphor. Your organization might well feel fear and threat and build “antibodies”.
So the first step for resolving anything is to know the problem space and to capture the force that are at work within the organisation. Usually there is a clash in the unterstanding of “cause and effect”. Often management and an Agile team live in two different worlds. Management often remains stuck in a Newtonian world view, while the Agile team embraces a Complexity Science based approach. These are not compatible with each other.
The Newtonian point of view is that cause and effect are directly linked and can be traced and linked together in advance and with some effort can lead to the predication how a system will behave in the future.
The Agile team instead operates in the Complex realm. In this quadrant there is no direct link between an effect and its cause(s) observable, let it be predictable. Instead things can be only judged in retrospect, knowing how things evolved (this is called “retrospective coherence”).
In this realm we can not know in advance what will influence our system and how the agents within the system will react. Such a system we usually find, where people are involved, because people do not act deterministically. To many factors to influence us.
This is also, as Joseph stated, why a simple Inspect -> Adapt loop does not work. Joseph pointed out, that we need first to act, before in a complex environment something happens and any inspection is possible. So he extended the loop to: Apply -> Inspect -> Adapt.
QCon Day 2 March 14, 2007
Posted by Jiri Lundak in Agile, Architecture, Programming, Technology.1 comment so far
On the second day I participated in Kevlin Henney’s “Hands-On Agile Development Workshop”. You may ask yourself, why as a proponent of Agile development and coming from a company, that tries to employ Agile practices across all its projects I attend such a newbie-event.
Well this is mainly for one reason: Part of my role at Löwenfels Partner is that of a Agile advocat or evangelist. The other part is to coach our teams in Agile practices and values, by leading through giving an example.
So my main interest in this session was to see how Kevlin presented the session. Some things I observed about his session:
What I liked:
- Organized Scrum-like in four Sprints
- Complex-enough problem to solve
- Sprint 0 used to introduce Agile concepts in a very fun and lightweight fashion.
- Sprint planning/commitment included
- Strong test-first approach thaught effectively
- Team collaboration stressed through pair-programming, changing pair, focus on clean interfaces for easier integration of team results
- Practical stories from real world projects mixed in
- No dogmatic propagation of Agile practices, but pushing common sense conclusions
- Real struggling with personality types (people you do not know) when pair-programming and cope with that diversity
- Introduction of kind of a metric for a good unit test: nearly non conditional logic in the test itself. This leads to more readable and understandable tests, that communicate well the intention of application unter test, a lot like a good a specification.
- Nearly as much test code as application code to be tested.
- “By omitting tests we will not be able to write the double quantity of code”.
What could be improved:
- Kevlin talked very much himself. I at least would have prefered more interaction
And the reaction of the attendants? Most of them were convinced to need to apply the trained practices in their organizations, some even against the current paradigma in their companies.
Would I recommend the workshop? Definitely! We should do something similar in our organisation (at least for new employees, if not all). I will try in the coming months to build on that.
On my way to the QCon Conference in London March 10, 2007
Posted by Jiri Lundak in Agile, Programming, Technology.add a comment
I am sitting at Zurich Airport and waiting for my flight to London right now. I am attending the new QCon Conference there and am quite curious, how it will be like.
The roundup of speakers and tutorial hosts promises an information packed week. Besides quite an interesting Agile track, there are lots of sessions about technological themes that have caught my eye. After investing lots of my time recently in Agile processes and soft factors in the software engineering field, I feel it is time to go a bit back to my technical roots and have a look at architectural and “hype” themes this time.
Besides that I hope to meet many known faces, like Deborah Hartman, Joseph Pelrine, Peter Sommerlad, Steve Freeman and some other I got to know and appreciate in the past. But I am sure, there is also room to get to know some new and interesting people. And besides that London is always a place that never gets boring.
So stay tuned, as I will try to post some daily conference update on these pages.
Recruiting People With Agile Potential March 9, 2007
Posted by Jiri Lundak in Agile, Agile Development, Scrum, Scrum Agile.add a comment
We are currently in need of new developers and testers for our teams. As we try to live Scrum as an Agile development process I often ask myself, what kind of criteria we should expect of the candidates, besides the usual developer or tester skills.
Sure you can not see inside the cadidates’ mind. But more and more we try to ask Agile questions during the interview. Often I ask a question, that I hope will show the candidate’s attitude towards Agile practices and values and to see whether he would have the potential to lead other people by giving them a strong example.
One such question was recently: “The build fails. What will you do?”. The usual answer I get is: “I will fix the build.”. Then I add the tweak. “But, if your code did not break the build?”. Often people then revert back to the ‘I am not responsible for THIS!’ attitude, so they say “I wait till the build is fixed by the developer who broke it.”. The better one’s will propose: “I contact the developer that broke the build and we resolve the problem together as soon as possible.”. As I often see people not acting pro-actively, but in the ‘wait and see’ manner, I hope to get more people on board, that act on problems, instead of tending only their own garden.
Another question I recently asked a potential senior developer and team lead was: “Your team seams not to be able to deliver the functionality they commited to at the beginning of the sprint, because of quality problems. Your demo with the customer at the end of the sprint is to be compromised. What do you do?”. One answer to this question was: “I go to the customer and postpone the demo.”. Boing, a warning sign! Further questioning revealed, that this candidate did not even know what a commitment within an iteration was and how it worked.
Another small test I do with candidates is to refactor a piece of bad code with them in a pair programming fashion. I am not so much interested in solving the particular problem at hand, but in the way the person approaches the problem, how she thinks about the code and how she works herself through to understand it. Does she write a unit test first to frame the working code? Does she rename variables and classes to have a better grasp of what the code is doing?
To people previously not exposed to Agile development I first explain our development approach (Scrum) and then try to ask practical a question on consequences this has on the interaction between team members or between developers and the customer (product owner). Their answers usually reveal a good deal about themselves. How they think about the development process, what they would like to happen in a development process, etc. The additional question I then add is: “What would YOU do to improve the process?”. So I try to at least see how their attitude is concerning the development process. How do they want to live their lives as software developers? Do they think about improving something, they see, is going wrong?
What are your questions you come up with to check for job candidates’ compatibility with Agile values? Let me know about it.
