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 Nicole Belilos mid-afternoon: April 27th, 2011
In Agile, we prefer Individuals over Processes and Tools. However, we hardly ever hear about these individuals, as we tend to focus on teams. In my daily life as an Agile coach, I see the effects Agile has on individuals, how they love it or hate it, resist or adopt, struggle or embrace.
I want to blog about these individuals who are the key to any Agile success. My tales are true stories of real people. I have only changed their names and some small facts to preserve their privacy.
This blog is about Chris, a tester whose resistance to Agile was very big. Read what he went through, and be surprised by the end of this story.
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 Serge Beaumont in the early morning: February 28th, 2011
Every Agile team has to deal with whatever they’ve put out in the wild next to their “regular” work. How to handle the – by definition – unknown load of production emergencies when you’re trying to achieve a stable pace? You can deal with emergencies by performing triage to either reject, defer or accept. You can set up a buffer to absorb some of the uncertainty, and finally you should make sure that you take the time to reduce the number of emergencies by building quality in. If you find you are mostly doing maintenance, you can consider doing Kanban.
(more…)
Posted by Niklas Odding mid-morning: February 9th, 2011
In my last post I stated that there is a lot of emphasis on the fact that architects have to help to get the scrum team to work better, faster en with more quality. By following the agile values the architect will help “strengthening the heartbeat” of the scrum teams. However the activities of architects should encompass more. In this blog I will explain what this is and how to incorporate this in your way of working with scrum teams.
Posted by Geert Bossuyt in the wee hours: February 1st, 2011
What is it about waterfall we want to avoid ? It’s mostly the transition moments ! A lot of information is simply lost when you transfer it from one person to another. Another thing we want to avoid is to create a strict order in things because this leads to limiting flexibility. Still, Sprint Zero, is a commonly used practice, and it implies to happen before anything else right ?
So how to do a Sprint 0 in a smart way ? Use these principles :
- A length of more than 1 week for Sprint Zero is way too long
- Spending half of Sprint Zero on training and teambuilding is only nearly enough
- To do more than strictly needed to start the first sprint is too much
- The outcome of Sprint Zero is a jump start for Sprint One.
Posted by Niklas Odding around lunchtime: January 26th, 2011
This blog is the second of a series of blogs in which I will examine the role of architects in Scrum. Last week I started with the forgotten questions of Scrum. In this blog I will look in more detail to the Agile Manifesto and the agile values.
Architects and the agile values
Most of the literature concerning the role of architects in an agile context focuses on the Agile flow itself and how architects can avoid disturbing that flow. Mike Cohn, in his book “succeeding with agile” makes the distinction between coding & non-coding architects. In where he states that the coding architects will have less trouble finding their new role in de Agile development process.
An architect within a team has to be able to code himself. He is a team member, who has more experience in structuring the application being build compared to other team members. By using that experience he can add value to the team. Scrum has no particular role for non-coding architects. The question rises if this is totally true. (more…)
Posted by Niklas Odding mid-morning: January 18th, 2011
This blog is intended to be the first of a series of blogs in which I will examine the role of architects in Scrum. I will start with what I think that are the forgotten questions of Scrum and in next blogs I will examine how the role of the architect changes, what kind of architects are needed and and which activities architects should be doing to be successful and valuable.
The forgotten questions of Scrum
In the 1960’s Alfred Chandler already wrote that the organization structure of an organization is tightly related to its strategy and based on its organizational processes. In the optimal world according to Chandler: Structure follows processes follows strategy. (more…)
Posted by Erwin van der Koogh just before lunchtime: December 10th, 2010
Why a good Scrum is like World of Warcraft
Today I saw a brilliant TED talk by Tom Chatfield called “7 ways games engage the brain”. While watching the presentation and going through these 7 ways, I realized that while I have seen these playing games, I have also seen these happen in a good Scrum.
The 7 ways are:
- Experience bars measuring progress
- Multiple long and short-term aims
- Rewards for effort
- Rapid, frequent and clear feedback
- An element of Uncertainty
- Windows of enhanced attention
- Other people
I will go through each of the points comparing World of Warcraft to a Scrum.
(more…)
Posted by Geert Bossuyt in the late afternoon: November 28th, 2010
Scrum and Agile are not synonyms. Scrum describes a process ( a set of activities) but its only Agile when you do this activities in an Agile mindset.
You can easily be Agile without using Scrum, and it’s definitely possible to do Scrum in a way that is not Agile.
Having a good metaphor can help speed up the understanding.
If Scrum is like riding a bike, then Agile would be the sense of balance.
(more…)