Posted by Gero Vermaas in the early morning: May 27th, 2010
This is the forth post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. The forth principle is call “All hands on deck early on” (initially coined by James O. Coplien). The essence of this principle is that all stakeholders of a project are involved at the start of the project.
Posted by Mark Bakker in the early morning: May 27th, 2010
Summary
In the first part of this review (the JavaEE6 back-end) I tested a small application which is a JSON REST service to be used as back-end for a JavaFX front-end. My conclusion for now is that JavaEE6 has a lot of new features which makes it a lot easier to use Java EE without extra libraries like Spring, Seam or Resteasy. I was able to make a back-end application which was noticeable fast with a low overhead in bandwidth and CPU usage.
Introduction
In a search for the current best technology platform I am building a small real-world application for personal use in different languages and frameworks. First up is Java EE 6 and JavaFX 1.3.
I think this review can be helpful for others as well. If you just want to see the implementation you can skip the functional and technical requirements. If you are interested in the application and want to help creating the new version; please send me a reply:-).
Posted by Geert Bossuyt at around evening time: May 25th, 2010
Scrum claims to be ‘Very Simple, but Very Hard’ with its 3 principles and 3 roles. Indeed, the rules of the game are easy to understand and the Scrum process that links everything together is one of the leanest ever seen. The hard part of Scrum is understanding why it works and how to make it work. If you implement Scum on the right side of the Agile Manifesto you’ll be having a very hard time making it work. More important than the rules and roles of Scrum is the spirit of the Agile Manifesto. Scrum is meant to be a practical guide for ‘doing Agile’.
It’s not easy to implement a process with roles, rules, principles, meetings and timeboxes in a way that brings ‘Humans and Interactions over Processes and Tools’ alive. How to create an atmosphere where commitment and the product backlog are not seen as a strict contract with the Product Owner and project management, but where ‘Customer Collaboration over Contract Negotiation’ is a normal thing. ‘Respond to Change over Follow a Plan’ seems a perfect match, however many Scum implementations seem to have a large focus on delivering releases on fixed dates, no matter what… And many Teams love ‘Working Software over Comprehensive Documentation’, where QA and management still demand All Documentation.
The point is… It’s hard to implement Scrum in a real Agile mindset.
(more…)
Posted by Sander van den Berg in the early evening: May 20th, 2010
This is the third post in a series of blog posts discussing Lean Architecture principles. Each post discusses one principle. Applying these principles results in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive.
The second principle we discuss applies to an important faces of architecting and is called “Think Big, Act Small“. (more…)
Posted by Geert Bossuyt late at night: May 18th, 2010
I have been experimenting with standups a lot over the last 4 years and I found a good way to get the most from it.
In my experience a good standup only serves one goal. It is to unite every mind in the Team into One Mind so there can be one view on status and one view on focus. Or put otherwise : One commonly understood answer to the questions ‘Where are we now?’ and ‘Where do we want to be tonight?’
If every member of the Team leaves the standup with a clear understanding of where the Team wants to be at the end of the day, then they will make choices during the day that lead towards the actual realization of this goal.
The structure of an effective standup looks like this :
- Welcome the Team in a happy and energetic way
- Decide together on the actual status of the project.
- Decide together on the focus of today.
- Find a way to achieve this Goal in the most effective way.
- Send away the Team with a wrap up of the focus of the day and a reminder to have fun.
Do all this from a point of view of the TEAM and avoid talking about individual achievements or goals and you will increase the effectiveness of your Team.
The amount of energy and interaction during the standup represents the quality of the Team. A boring standup will never lead to an inspired working day.
To bring your Team alive, you should bring life into your standups!
Posted by Marco Mulder in the early morning: May 15th, 2010
In my experience as a Scrum trainer and coach, I have seen too many Scrum teams that fail to do what Scrum was invented for: Inspect and Adapt.
Do the following statements describe the situation of your team?
- Little is done about problems discussed in Retrospectives.
- Sprint Reviews have no impact on what is build in subsequent sprints.
If so, you may be interested to read my article on the Scrum Alliance website: Effective Retrospectives & Reviews.
Posted by Denis Koelewijn just before lunchtime: May 13th, 2010
This is the second of a series of blog posts discussing Lean Architecture principles. Each post will discuss one principle and applying these principles will result in an architecture (process) that is better connected to the business, better able to deal with change and more cohesive. Last week we discussed the first principle Always involved. In this blog entry we discuss the second principle that applies to the architect role and the architectural artifacts and is called “Travel Light“. Travel light should be taken literally, how much does the architect have to carry around running from stakeholder to stakeholder? How much material does he need to explain the business needs to the development team, what does he need to explain the vision of the product to the business, to involve operations early on, etc., etc. ?
Posted by Geert Bossuyt at around evening time: May 12th, 2010
Statement for discussion :
”
The Team should be organized optimally.
The rest of the organization should be adapted to the needs of the Team because the Team is where the real value is created.
“
(more…)
Posted by Sander Hautvast in the early morning: May 12th, 2010
This is the first blog in a series that describes the top 10 of Java EE middleware management problems. It´s title could also be “single point of failure”. This is not about software. Instead, it’s about the person in your middleware team that everybody relies on, and clings to when things get difficult or even worse, get totally out of hand.
Posted by Iwein Fuld in the early evening: May 9th, 2010
Without exception in all teams I’ve developed software in people have expressed their aversion against pair programming. It’s not that developers don’t want to try, or that they don’t believe it will help. On the contrary, they are usually very enthusiastic about trying it and give it more than a fair chance. After a few days they sit alone behind their keyboard coding like zombies with headphones. What’s going on? Is pair programming too hard? Doesn’t it pay off? In this post I’ll try to explain what I think is happening, and I will give you some clear pointers to avoid the traps. At the end I will go into distributed teams and what part of the game changes there.
So what are people saying when they have stopped pair programming and you ask them why:
- I’m faster on my own
- Can’t pair with that guy, he’s getting on my nerves
- Pair programming is too tiring
- We’ve split up the work and we’ll get it done faster if we use two keyboards
- There’s too much background noise
- I’m just slowing her down
Some of this might sound plausible, so let me axe that down first. No you’re not faster on your own, you’re just creating more crap for your colleagues to puzzle over and eventually delete. The code you write alone sucks. That guy that is getting on your nerves is trying to tell you (clumsily) that your code sucks, try to listen to him and you’ll turn into a better programmer. Or maybe you can teach him something and he’ll stop getting on your nerves. If your code is so simple that you can split up the work in advance you’re writing it on too low an abstraction level, or you need to work on this in two pairs. If you’re slowing the other guy down, that’s a good thing. That will prevent him from writing code that you cannot maintain. If you don’t feel worthy of your colleagues code, get over it, or get off the team.
(more…)