Posted by Wilco Koorn mid-morning: August 23rd, 2010
Last week I enjoyed to opportunity to speak at the Agile2010 conference in Orlando, Florida. Of course, I also attended many of the other sessions as well. The conference has in my view an excellent atmosphere. Where I expected to find lots of consultants in their typical formal style of dressing I found 1400 people mostly dressed in T-shirt, jeans and sneakers instead. This must be the result of the Agile movement itself where people are first class citizens right?
The portfolio of Agile2010 contains ‘hardcore technical’ sessions like tutorials in Clojure coding, real ‘softcore’ sessions like “Behavior Driven Development for Life” which advocated using Neural Linguistic Programming techniques straight from psychology and also sessions around themes like Leadership and Coaching. Don’t worry, the conference organizing committee splits these nicely up in ‘Themes’ and ‘Stages’ so even if you only look at the program by a glance, you’ll hardly ever end up in an unwanted session.
This is what I picked up from the conference in summary (you’ll find all the details below):
- Conference focus (or lack thereof)
- “Religious wars” between Scrum, Kanban, Xp, Lean, …
- Agile adoption in organizations worldwide
- “Value points” (compare to “Complexity points”)
- “Switch”
- Company improvement backlog
Next I’ll elaborate a bit about my own experience as a speaker. The combination of what I picked up and my speaker experience will give you a good basis to decide if you want to put next year’s edition (Salt Lake City August 7-13, 2011) in your agenda or not be it as an attendee or as a speaker. Enjoy!
Posted by Rik de Groot around lunchtime: August 20th, 2010
Planning has an important role in Agile. The team uses planning to estimate the complexity of a requirement (userstory). The number of complexity points handled in previous timeframes then helps to decide what could fit into the next timeframe. However the complexity changes in time. Things get easier doing it a second time or easier ways are found for problems. This makes the planning even harder. Creating a reference base might bring stability in planning. These references make it possible to create a release planning without planning all the requirements upfront.
Posted by Sander Hautvast mid-morning: August 20th, 2010
This is number 8, the third article in a top10 of middleware management pitfalls. The previous article dealt with infrastructure. This time I´ll discuss the application itself.
There has been much cool stuff lately about devops and devs and ops working together in one team, like at sky.com. The uncool reality for a lot of companies is that dev and ops are separated in different departments and don´t communicate well. Immature applications, at least from a middleware perspective, are what you get.
Posted by Iwein Fuld mid-afternoon: August 17th, 2010
In the current market it becomes more and more likely that developers in the same team will not be in the same physical location. This is caused by outsourcing, but also other reasons like ever increasing focus on open source projects.
In a distributed scenario pair programming has huge benefits over meetings and sending comments on issues around. It is (still) the fastest way of sharing detailed information between people, and it actually gets the job done where a meeting does not.
The added benefit of pair programming in a distributed team is that it bridges the gap between the local team and the remote team that is caused by the fact that informal communication is impeded. Research has shown that pair programming works in distributed teams [1]. The challenge is to find out how to make it work for you.
In my previous blog on Pair Programming I focussed on the different styles that I see in my daily practice and ways of improving the dynamics in a pair. This applies equally to colocated pair programming and distributed pair programming. At my current client I bumped into the issues particular to distributed pairing, so in this blog I will outline habitual and technical prerequisites for successful distributed pair programming.
(more…)
Posted by Robert van Loghem in the early morning: August 16th, 2010
In my previous post, “future of deployment, part 2″, i talked about the new ear, which is an image, with an OS and your application.
Now before diving into part 3, which gets you going in creating your own virtual appliance aka “the image”, there is one really big thing i forgot to mention; Some of the benefits of delivering a virtual appliance and getting it from your own development to the production environment! and i’ll list the benefits for administrators/ops and developers.
(more…)
Posted by Jeroen van Erp just before lunchtime: August 12th, 2010
Scene opens…
An idyllic landscape unfolds before our eyes, in yonder distance we see a figure approaching us. He goes by the name of Arthur, King of the Britons…
(more…)
Posted by Sander van den Berg in the early evening: August 11th, 2010
Over the last 4 month’s we have written a series of blogposts describing 11 principles of Lean Architecture. This post will be the last of the series, the wrap up post.
Posted by Denis Koelewijn in the early evening: August 10th, 2010
This is the eleventh and last 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 eleventh principle we discuss is called “Freedom where possible, standardize where needed“. (more…)
Posted by Geert Bossuyt around lunchtime: August 8th, 2010
The art of coaching is not as easy as it looks. One of the main reasons for this is that being a successful coach is not measured by what you do but by what is achieved.
I’ve discovered a few ‘patterns’ in my own coaching behavior that leed to on ‘working hard’ instead of ‘achieve results’. And I’ve found some alternatives for these behaviors that will help me to become a great coach.
I would not like to use the word ‘anti-patterns’. It’s better to speak about wolves in sheep’s clothes. Some amazing results can be achieved working like this. However, on the long term it will neither help the coach become any better, neither help the organization to live on without the coach.
Love the sheep, but be aware of the wolf !
What wolves am I talking about :
- Do whatever is needed to make the change a success.
- Do whatever is expected from the coach.
- Focus on the biggest impediments.
A coach who manages to do all three above is a great coach, right ?
(more…)