Posted by Geert Bossuyt at around evening time: October 16th, 2011
Market Driven Development (aka Agile Fixed Price)
I propose a paradigm shift in developing software to deliver business value.
For a team to satisfy a business need,
it is not the amount of work that defines the time needed,
it is the available time that defines the amount of work that can be done.
The deadline is part of the need, and not the result of estimation or planning techniques.
With the deadline being part of the need, the Team and the Product Owner have a shared budget ( = number of Sprints ) to realize the Vision.
Instead of using Poker to give insight in the estimated time of delivery, let’s create a Market Place where Product Owner and Team ‘negotiate’ on the complexity of each story.
Posted by Niklas Odding in the early morning: May 3rd, 2011
This Blog is a kick off to for many writings about architecture in an Agile World. We will explore the topic from all the views possible, in order to gain a better understanding about it. By doing so, we hope to create a community of followers, who would also like to contribute or discuss about this topic.
Xebia is helping many organizations in the Netherlands, France, the United States and India with implementing an agile way of system development. In most of the cases the Scrum method is applied and very good results are achieved. Business and IT are working much closer together, resulting in more quality and much more customer satisfaction. However, lately we also see a trend in problems that seem to occur in (almost) every organization. Software is developed in a fast way with high quality, but it takes forever to get it in production. The more teams are being formed, the more interdependencies between the teams occur (more…)
Posted by Niklas Odding mid-morning: February 28th, 2011
In my last blog I presented an illustration which shows the two primary aspects of the architects’ role. On one side they play a role in strengthening the heartbeat. On the other side, they play a role in envisioning the future.
The focus in this blog is on the solution architect or application architect. The way the Enterprise architect deals with Scrum will be explored more in detail in a later blog. This blog combined with the previous 3 blogs can be also downloaded as a whitepaper from the Xebia website: http://www.xebia.com/architects_scrum
What is the role of the architect?
Last blog I presented the illustration as shown below. In this blog I will focus on the parts of this illustration in which the solution architect / application architect plays a role
Posted by Jeroen Borgers at around evening time: January 20th, 2010
Previous time I blogged about the last step of the seven steps, step 7: Share the responsibility for the whole chain, a non-technical but rather a communication and behavior thing which I found crucial for success. We now have reached the end of this series and I’ll sum up the topics we’ve dealt with and draw some conclusions. (more…)
Posted by Jeroen Borgers at around evening time: June 15th, 2009
Last week I blogged about setting your performance goals: defining your requirements. This time I’ll blog about the importance of a Proof of Concept for performance.
The IT world is very sensitive to trends. Having been around in the IT industry for 15 years, I’ve seen a few. A technology is hot for a while, and then quickly becomes out-of-fashion and yesterdays news. It will be replaced by something which is much better and what everyone follows almost blindly.
(more…)
Posted by Jeroen Borgers at around evening time: June 10th, 2009
Last week I blogged about how performance problems manifest themselves: frustration, loss of revenue and disruption of development; and how adding hardware is a questionable solution. This week I’ll blog about the first step to assure web performance.
It can be a valid choice to run the risk of performance problems in production and deal with them in a re-active manner. However, it is usually wiser to be pro-active and prevent them. This approach brings more certainty, peace of mind and also saves money. It consists of seven steps. Step 1: Define performance requirements.
(more…)
Posted by Erwin Bolwidt mid-afternoon: May 8th, 2008
What is the Best Requirements method? That’s a mighty big and difficult question to ask, for several reasons. Everyone has a different idea of “best“, but also of “requirements method“.
While I could try to analyze various methods according to various statistics, it would still only give a one-sided view on the subject. In addition I only know a few methods very well so that would leave out other methods.
A different approach, the one that we take here, is to ask you, the participant in the requirements process.
(more…)
Posted by Balaji D Loganathan at around evening time: March 5th, 2008
Around 6 months back me and Vikas Hazrati gave a XTR on Adobe Flex to my colleagues in Xebia India.
We took some resources from Adobe Dev Net site and eventually found a cool article explaining how Flex Data Services works with Spring using Spring Remoting features and so on.
We were quite amazed with the UI capabilities of Flex with its server side integration. If you look at that article now, its start with a disclaimer saying “Effective with the release of Adobe LiveCycle ES, the Adobe Flex Data Services 2 server product has been rebranded as a Solution Component of LiveCycle ES.”
(more…)
Posted by Erwin Bolwidt in the late afternoon: January 18th, 2008
Many courses and books on requirements will tell you that a good requirement describes the “what” of a need of a customer (or more generally, stakeholder). They will tell you that you shouldn’t write down the “how” (they call that ‘design’) because it pushes you in a technical direction and causes you to miss out on other good solutions.
That’s good advice in the sense that you shouldn’t restrict yourself to a solution if another solution satisfies the needs of a customer better. But when is something a design, and when is it a requirement? If you’ve thought about it, you realized that it is hard to draw the line. (more…)
Posted by Viktor Grgic in the early afternoon: January 16th, 2008
It is always about well-defined requirements stupid. 
Building or choosing out-of-the-box software products like an ESB within the company’s SOA strategy can be very well supported by a number of requirements distilled from the QUINT2 ISO model:
Functionality: Suitability, Interoperability, Compliance, Security, Traceability
Usability: Operability, Customisability
Efficiency: Time Behaviour
Maintainability: Testability, Manageability, Reusability
Portability: Adaptability, Replaceability
This is the selection from the complete QUINT2 model. It does not mean that other requirements are not important, but usually less than these. If you fill out these requirements properly, which is still a daunting task, then you will have done pretty good requirements gathering. Besides these aspects, there are also security requirements: availability, integrity and confidentiality which should always be considered.