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 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 Olav Maassen in the early afternoon: March 21st, 2011
When hiring a new member to your team, how do you find out if she is really as good as she says? Currently the interview is a standard practice and an assessment is gaining popularity. Thanks to social networks like linkedin.com other intangible factors previously unused come into play: respect and reputation. These can now seriously effect your career (both positive and negative). Let’s take the next step: learn from games and introduce achievements.
Posted by Laurens Bonnema mid-afternoon: March 4th, 2011
- Create a list of all your requirements in Epic format (think Product Breakdown).
- Break down each Epic into work items in User Story format (think Work Breakdown).
- Determine which Epics and/or User Stories have dependencies.
- Visualize dependencies in a network diagram.
- Create an estimate for each User Story using Planning Poker Points, NESMA Function Points, Gummy Bears, anything but time and/or money.
- Assign business value to all Epics and divide this value between the User Stories based on their point-estimate.
- Sort the list of User Stories based on priority, dependencies and business value per point-estimate (triage). Having trouble sorting the list using triage? Pick another prioritization technique.
- Take an educated guess (assumption) about the number of hours per point you’re likely to spend, based on a representative sample of User Stories taken at random.
- Calculate duration based on your assumption.
- Use the calculated duration as input for a Monte Carlo analysis to create your first rolling wave planning.
- Correct the assumption every sprint based on the progressive average of the actual hours per point ánd a new Monte Carlo simulation for the remaining duration.
- Report regularly, preferably in a reporting format currently in use by the organization.
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.