Posted by Daniel Burm in the early morning: September 16th, 2011
Agile companies that want to create real ownership, have to say goodbye to traditional stakeholdership and embrace “joint company stakeholdership”. Remain to be an old-skool stakeholder in an agile environment and you will possibly act as a “stakekeeper” instead of a “stakesharer”, therefore withholding the company “staketakers” from focus on value and real ownership of results.
(more…)
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 Martien van Steenbergen around lunchtime: April 2nd, 2011
Scrum has much ado about Definition of Ready and Definition of Done.
The Definition of Ready for the current phase equals the Definition of Done for the previous. Likewise, the Definition of Done for the current phase equals the Definition of Ready for the next. They are the two sides of the same membrane.
So, why not simplify it and talk about the membrane only?
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 Geert Bossuyt mid-afternoon: February 25th, 2011
Agile Coaching is about guiding a person, team or organization towards more Agility.
Based upon the subject of coaching, there are 4 types of Agile Coaching
- Personal Coaching
- Team Coaching
- System Coaching
- Culture Coaching
Based upon the main focus a coach applies, 2 more types can be distinguished.
- Outcome Coaching
- Journey Coaching
Focus and subject are to be combined into 8 types of coaching.
In a successful Agile implementation all types of coaching add value
Posted by Geert Bossuyt late at night: February 21st, 2011
I regularly run workshops to highlight certain aspects of an agile way of working and to help participants achieve a deeper understanding of these topics. I would like to share two of best received workshop sessions with you so that you can run them too. Today I’m describing the “Think Left” workshop.
During the “Think Left” workshop participants will work with the four values of the Agile Manifesto to gain a deeper understanding. In small groups each of the values will be worked on in a peer brainstorming fashion to better understand each of them. As a result of the workshop participants will realize that acting more on the left side or more on the right side of the Agile Manifesto is a choice.
Posted by Geert Bossuyt at around evening time: February 16th, 2011
MoreAgile organizations support the following principles :
Complexity is a choice; we choose simplicity.
We carry out our vision and strategy
so that our people can make decisions in line with the mission of our organization.
Effectiveness is worth inefficiency.
We optimize the end to end value chain to maximize the result of our work.
We support selforganizing stable teams.
We create an environment that encourages people and teams to take responsibility and show entrepreneurship.
Our primary measurement for success is realized business value.
Our customers are the people that use our products.
Even when they are not the ones paying for our products.
We establish equal relationships on all levels
to empower knowledge sharing, commitment and shared responsibility.
We create opportunities from change, to continuously improve our products.
We prioritize all work in line with our vision and strategy.
Planning is a natural product of priority and sustainable pace.
We work smart, rather than hard, and learn every day.
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 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…)