Architecture refers to a very broad concept that creates a lot of confusion in the IT world. Why is it that such a common term is so vague? In this article we will give you an explanation for it. Read more
Requirements Management
In 2009 Steward Reid predicted that within 10 years 70% of all software development would be done with some form of Agile methodology. Due to the growing need for ‘’hands’’ this would result in having to employ also the less qualified testers on these projects. The first point he made is absolutely valid, the second point is only valid looking at it as a commercial opportunity (you don’t need hands if you work with qualified people), maybe he only said it to comfort the people who fear loosing their jobs because of this shift. It’s obvious that now Agile is becoming main stream there is a growing demand for qualified testers. Read more
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.
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 Read more
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
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
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. Read more
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.
Read more
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.
Read more
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.
Read more