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…)
Posted by Geert Bossuyt around lunchtime: September 30th, 2010
The tester is a member of a Scrum team. This is a different mindset from the traditional views on testers in software development. The agile tester focuses on delivering value instead of on testing. The agile tester is responsible for delivering what the business needs instead of just finding bugs. Most importantly: the agile tester is not responsible for testing!
Recently I published an article on testing in a Scrum team for the Eurostar 2010 newsletters. It’s about the mindset of an Agile tester. This blog post summarizes the core of that article.
Posted by Marnix van Wendel de Joode in the early afternoon: September 2nd, 2010
In Agile, everyone agrees on the concept that continuous improvement is a good thing. In Scrum and also in most Kanban practices we even have a ceremony to support this, namely The Retrospective. This periodically occurring meeting (often every other week) with the entire team plays a vital part in the process and in team dynamics.
In most retrospectives, focus is on improvement. Questions are asked like ‘What is going wrong or could be done better?’, ‘What can we do to improve things?’, ‘Did we actually improve?’. While there is real value in these questions (and they should definitely should be asked), there is another part of a retrospective that is also very important: The Good Things.
Posted by Wilco Koorn mid-morning: August 23rd, 2010
Last week I enjoyed to opportunity to speak at the Agile2010 conference in Orlando, Florida. Of course, I also attended many of the other sessions as well. The conference has in my view an excellent atmosphere. Where I expected to find lots of consultants in their typical formal style of dressing I found 1400 people mostly dressed in T-shirt, jeans and sneakers instead. This must be the result of the Agile movement itself where people are first class citizens right?
The portfolio of Agile2010 contains ‘hardcore technical’ sessions like tutorials in Clojure coding, real ‘softcore’ sessions like “Behavior Driven Development for Life” which advocated using Neural Linguistic Programming techniques straight from psychology and also sessions around themes like Leadership and Coaching. Don’t worry, the conference organizing committee splits these nicely up in ‘Themes’ and ‘Stages’ so even if you only look at the program by a glance, you’ll hardly ever end up in an unwanted session.
This is what I picked up from the conference in summary (you’ll find all the details below):
- Conference focus (or lack thereof)
- “Religious wars” between Scrum, Kanban, Xp, Lean, …
- Agile adoption in organizations worldwide
- “Value points” (compare to “Complexity points”)
- “Switch”
- Company improvement backlog
Next I’ll elaborate a bit about my own experience as a speaker. The combination of what I picked up and my speaker experience will give you a good basis to decide if you want to put next year’s edition (Salt Lake City August 7-13, 2011) in your agenda or not be it as an attendee or as a speaker. Enjoy!
Posted by Geert Bossuyt in the early morning: June 11th, 2010
There are many misunderstandings about Agile and what it is or is not.
I’ve met some people who were really convinced that ‘Agile’ and ‘Scrum’ are like synonyms. Or who think ‘Agile’ is a synonym for ‘flexible’.
Both are not true. If Agile would have just been about flexibility or responsiveness, I suppose they would have called it ‘The Manifesto of Responsiveness’ or something like that. However they didn’t so there must be more to it than just the Responsiveness.
Agile is a mindset. A set of principles to guide you in the choices you make.
Posted by Geert Bossuyt at around evening time: June 3rd, 2010
Story planning is a technique to facilitate commitment.
The ultimate goal of Story planning is to make a sprint planning that is really understandable and clear for every body. Something you understand so good that you can really feel whether it is doable or not. This is what you need to be able to commit. As a person and as a Team.
It’s a way to implement the Sprint planning and Sprint review session(s) and it serves as a great base for the standups and has proven to be very useful in many different cases.
When it’s hard to complete an entire story before the end of the Sprint.
When there are so many tasks in a Sprint that everyone has lost the overview.
When for some reason there is an anxiety to commit to a Sprint.
When planning a Sprint is taking a lot of time ( more than 1/2 hour/sprintweek )
The outcome of working with the Story planning is a highly focused and committed Team with maximal fun and productivity as a result.
Posted by Geert Bossuyt at around evening time: May 25th, 2010
Scrum claims to be ‘Very Simple, but Very Hard’ with its 3 principles and 3 roles. Indeed, the rules of the game are easy to understand and the Scrum process that links everything together is one of the leanest ever seen. The hard part of Scrum is understanding why it works and how to make it work. If you implement Scum on the right side of the Agile Manifesto you’ll be having a very hard time making it work. More important than the rules and roles of Scrum is the spirit of the Agile Manifesto. Scrum is meant to be a practical guide for ‘doing Agile’.
It’s not easy to implement a process with roles, rules, principles, meetings and timeboxes in a way that brings ‘Humans and Interactions over Processes and Tools’ alive. How to create an atmosphere where commitment and the product backlog are not seen as a strict contract with the Product Owner and project management, but where ‘Customer Collaboration over Contract Negotiation’ is a normal thing. ‘Respond to Change over Follow a Plan’ seems a perfect match, however many Scum implementations seem to have a large focus on delivering releases on fixed dates, no matter what… And many Teams love ‘Working Software over Comprehensive Documentation’, where QA and management still demand All Documentation.
The point is… It’s hard to implement Scrum in a real Agile mindset.
(more…)
Posted by Geert Bossuyt late at night: May 18th, 2010
I have been experimenting with standups a lot over the last 4 years and I found a good way to get the most from it.
In my experience a good standup only serves one goal. It is to unite every mind in the Team into One Mind so there can be one view on status and one view on focus. Or put otherwise : One commonly understood answer to the questions ‘Where are we now?’ and ‘Where do we want to be tonight?’
If every member of the Team leaves the standup with a clear understanding of where the Team wants to be at the end of the day, then they will make choices during the day that lead towards the actual realization of this goal.
The structure of an effective standup looks like this :
- Welcome the Team in a happy and energetic way
- Decide together on the actual status of the project.
- Decide together on the focus of today.
- Find a way to achieve this Goal in the most effective way.
- Send away the Team with a wrap up of the focus of the day and a reminder to have fun.
Do all this from a point of view of the TEAM and avoid talking about individual achievements or goals and you will increase the effectiveness of your Team.
The amount of energy and interaction during the standup represents the quality of the Team. A boring standup will never lead to an inspired working day.
To bring your Team alive, you should bring life into your standups!