AgileHolland Nieuws

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 leeds to limiting flexibility.  Still, [...]

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 [...]

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 [...]

Just like the Agile Manifesto was a shock 10 years ago, the MoreAgile Manifesto creates some shock effects now. Responsibility is scary, Business value is undefined, partnership feels impossible and change is kind of accepted but not loved. Over the next coming years expert professionals will become very rare, so employers will have to make [...]

2010 has ended and a new year has begun. 2010 offered us a lot of learning opportunities. It was a good year for the Agile community in the Netherlands and in the world. We saw more and more big corporations embrace Agile methodologies and put serious effort into making it work for them, mostly as a [...]

We encounter possibilities to focus more on effectiveness by working Agile and learning from that. Based upon our experience we value : Teamwork & responsibility over Individuals and Interaction Business Value over Working software Partnership elaboration over Customer collaboration Embrace change over Respond to Change While we value the Agile Manifesto, we state that MoreAgile [...]

Have you ever wondered how your salary stacks up against other professionals in the Agile community? Now's your chance to find out. ASPE-SDLC and VersionOne recently announced the launch of the 2010/2011 Agile Salary Survey, designed to gather income data from the worldwide Agile community.

Chris Matts who has been part of the Agile Conference submission review team gives advice to submitters of Agile 2011 candidate sessions on how improve their changes of acceptance. Chris also provides advice to session reviewers of Agile 2011, the largest annual Agile event. By Chris Matts

The transition to the Agile way of working is more than a process change. It requires a different way of interaction and behavior and a different mindset. In a large (a little less than 200 people) Agile Implementation endeavor we organized an Agile Mindset session to explain Agile principles and to push the Agile teams [...]

I was talking with a new-to-agile project manager, who said he needed take the first iteration to do design and estimation. I asked why. “Because our management needs to know exactly when the project will be done.”

“Do you think your iteration of design and estimation will provide you a perfect estimate?”

“Uh.” He paused. “From your question, I’m guessing you don’t think it will.”

“I have never found that spending two weeks will provide a perfect estimation for anything larger than a 2-week project. But I could be wrong. Have you been able to before?”

“No.”

“Oh. Do you think you can get a perfect estimate this time?”

“No.”

“Then why would you spend your time doing an estimate instead of producing something, learning from that and bettering your gross estimate?”

“Because my manager needs to know when the project will be done!”

I feel for this guy. I do. I understand why his management wants an estimate that’s better than a swag (scientific wild tush guess). But you can’t always give your managers what they want. You might be able to give your managers what they need (with apologies to the Rolling Stones).

If you are starting a project and you are using iterations, you can do a gross estimate of the entire backlog, do one iteration, see what your velocity, and guess at how many more iterations you will need. Your guess is dependent on the backlog not changing, on your gross estimate being right, and on your initial velocity being a predictor of future velocity. Put like that, your managers will realize your initial estimate is a guess, and they may well want another estimate in another iteration or two or three. That is a very good thing. You can do that.

If you are not using iterations, you can do a swag, and then know that your estimate is wrong, until you have some delivery of some sort. Until you have some part of your product working, you have no idea how far off your estimate is.

If you prefer to use kanban, that’s fine, as long as your features are minimum marketable features. If your MMFs are maximum marketable features, you have no idea when you can be done because you are not limiting work in progress. Kanban is great for limiting work in progress for the entire team, and for not piling up work where people can’t finish it. The team can’t proceed until the team finishes work.

Once you have data, you can see when the project will be done. If that’s after several timeboxes, great. If that’s after some number of minimum marketable features, great. But you can’t really provide an estimate without data. Otherwise, it’s just a swag. And if you want a swag, I can give you any swag at all. It won’t mean anything, but I can give you one.

Tweet This Post

What are the advantages and disadvantages of having the same person fill both the Product Owner and the ScrumMaster role on the same Scrum project? Is this really a workable option? By Dan Puckett

Diana Larsen and James Newkirk take a look back at the beginnings of the Agile community, talk about the state of Agile training and certification and much more. By Diana Larsen and James Newkirk

One of my favourite tools for giving and receiving feedback is the Perfection Game. It is a powerful tool to give constructive feedback in a non-threatening way. It transforms feedback from an attack or personal judgement into a constructive act of jointly improving software, articles, conference sessions, blog entries…

The Perfection Game lowers the barrier for giving feedback. It makes it much easier for me to give feedback faster and earlier, and to ask for feedback. It is useful for any situation where you want to ask or give feedback in a constructive way.

The Perfection Game is simple, but not necessarily easy and not always well understood. So how does it work?

• Someone presents their work, like a session proposal, a text, or code, and asks for feedback.
• You (the reviewer) rate the work on a scale from 1 to 10, based on how much value you can add. 10 means that the work is perfect for you. In other words, 10 means you don't see any way in which it can be improved.
• You explain why you rated the work like you did. What makes up this number? What did you like about it? What should be kept?
• You give concrete suggestions for improvement, i.e. actions that would make the work perfect.

An example of a perfection game applied to a session proposal is:

I would give this session proposal an 8 out of 10.

What I like about it:

• catchy title, the abstract makes me want to attend
• well thought out process, seems realistic for 90 minutes

To make it perfect, I would:

• explicitly describe benefits for managers, because it would be good for the discussions to have the manager's perspective in the room
• make the link with agile development explicit, so that it appeals to a wider audience

Some remarks:

• The rating is not a judgement, it is an indicator of how much possible improvement you see in the work.
• The Perfection Game focuses on the work instead of the person; feedback is in the eye of the beholder.
• Your improvement suggestions should be concrete and actionable; what would you do to improve the work?

It's also great for perfectionists like me, to see the positive things and accomplishments as well

I'm co-organizer of Mini XP Days (1 April, to be announced) and XP Days Benelux (early December). We apply agile principles to organizing it, to make it an agile agile conference. We are feedback addicted and use the perfection game both during the conference, to get feedback about sessions, and in the iterative session review and improvement process, to help presenters develop quality sessions.

The Perfection Game is useful for any work product, code, text, design ideas, documents, blog entries, anything you are creating and you want to improve – it can help you get into a habit of constructive feedback and joint improvement, so that you'll deliver better results faster.

So please do try this at home! (and work!)

Background information

• The Perfection Game is part of the Core Protocols by Jim and Michele McCarthy; I also recommend their entertaining & informative podcasts.
• The Perfection Game is similar to the scaling question from the solution focused approach.
• Perfection Game summary
• Yves Hanoulle has written an article on the Perfection Game and other Core Protocols.
• Perfection Games remove noise from developer feedback

Dan North argues that Agile best practices can help an organization only to a point, and continuing to rigidly apply them after that will stifle innovation and drive people away. Organizations need to continue to innovate, finding new ways and practices to develop software by looking at the motivations behind Agile practices and not just implementing them. By Dan North

M Dwyer of BigVisible Solutions talks about the process of transforming businesses to agility, including the concept of Agile localization in global efforts. Dwyer says that with distributed teams across multiple time zones and cultures it is good to establish a group of Agile missionaries to go forth and train people on Agile. He also discusses how to transfer Agile skills to the next generation. By Mike Dwyer

The more I work with companies that are struggling with Scrum, the more Im starting to believe that hybrid Scrum adoptions in which people pick and choose what Scrum practices to follow and what to ignore invariably lead to failure. Who...

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 [...]

A key element of Sprint planning is figuring out how much time it will take to complete each Story facing the team. It's human nature to try to quantify time in terms of minutes, but that may not always be the best approach.

As is normal at the beginning of a new year predictions about where industry and practice are heading abound. Mario Moreira and Scott Ambler predict the continued adoption of agile practices across more and more organisations, and the adaptation of agile techniques to larger and more distributed teams, with an emphasis on more structured implementations. By Shane Hastie