agile, scrum, coaching, lean
Scrum
7 Agile Myths
11342 days
http://www.flickr.com/photos/michaelransburg/3855808163/
Today I had a lightning talk at the ACE!Conference in Krakow (as you probably know, I’m a lightning talk addict 
) and talked about seven Agile Myths. You’ll hear about these myths most of the time on management level, but some of them can be found on the development level, too. IMHO it’s important to be aware of these myths to be prepared for possible discussions.
Agile = No documentation
This is one of the most famous myths and I think we have to blame the agile manifesto for this. The line “Working software over comprehensive documentation” is often misunderstood with no documentation at all. But how could agile Frameworks like Scrum survive in highly regulated environments like the medical or financial industry if this would be right. For sure there is documentation, but we don’t waste time on documents that deliver no value to the project.
Agile = Anarchy
The biggest fear of any manager is to lose control over their agile teams, because they think self organisation is the same as anarchy. Yes, the role of management changes but they still play an important role in their company. They are needed to define clear visions and goals and the constraints of a project. Only within these “fences” the team can work self organized. They are also needed to help the team to gain their full potential. This has nothing to do with anarchy.
Agile = faster
IMHO it was a bad idea to name an iteration in Scrum a sprint. This implies that everything is real fast in agile. But at least in the beginning the complete opposite is true. Building in quality into a product takes time and quality is not discussable. You’ll be able to harvest the fruits later as you’ll have less bugs and the software is more maintainable and that’s the point where agile is bringing you up to speed.
Agile = silver bullet
Yes, this true. Just kidding There is no silver bullet in software development. I repeat: There is no silver bullet in software development. Sure, the process of software development has some impact, but in the end it is all about the people in a team. I saw awesome products created by a “waterfall team” and crappy software by agile teams. In the end it is all about the right people at the right place or as written in the agile manifest: Individuals and interactions over processes and tools (this also applies to Scrum, Kanban, XP and any other process).
AGile = simple switch
Simple said: No it isn’t. The frameworks itself can be explained within 10 minutes, but what is often forgotten are the needed mindset behind and the principles that agile methods are based upon (Lean Thinking, Pull vs. Push, empiric process control, iterations and increments, self organisation…). In bigger corporations it may take years until you can talk about an agile company. You won’t believe it, but it is not enough to send your team to a two days ScrumMaster training…
Agile = Easy
How can it be easy to deliver a possible shippable product every 1 – 4 weeks? In the past you weren’t able to do it after one year. It is a lot of hard work to get there and it is for sure not an easy thing to do. And I don’t want to mention continuous deployment here…
Agile = software development
Often the agile journey starts in software development, but it should not stop here. To have an agile software development team in an non-agile environment is like planting a tree in the desert –> it won’t survive. The whole company culture has to change, everybody needs to adhere to the agile principles like lean thinking. Otherwise your agile transition will end in a blind alley and a lot of frustration.
What agile myths do you know. What are your experience with those myths? I’m looking forward to your comments!
BTW, here are the corresponding slides of the talk:
View more presentations from Marc Löffler
And here is the corresponding video of the lightning talk:
Lightning Talk from ACE! Conferences on Vimeo.
An agile cloze
1530 days
http://www.flickr.com/photos/monkeyminddesign/4553428118/
I was just inspired by an german christmas cloze. It even inspired me so much, that I decided to write an agile cloze and let you fill the missing pieces 
So, here you are.
The best way _____________________.
Scrum is ______________ but XP _________________ with or without Kanban.
I currently read ______________ and think _____________.
___________ is the best thing that happened to our company because ____________.
Would you believe _______________.
_____________________ awesome.
If ______________ the world would be a better place.
Happy __________________.
You can either leave a comment or create a blog post based on the above cloze. I’m looking forward to your “fill-in”
10 things to mess up your retrospective
6554 days
http://www.flickr.com/photos/metabolico/583204694/
It’s about time for a new list. Today, I decided to write a list on how to mess up your retrospective. There are a lot of possibilities to do this and the following tips will help you doing so
1 – don’t prepare anything
As the retrospective is the simplest and least important meeting of all Scrum meetings, it doesn’t need any preparation. Just come together and start. Wait, where are the pens and the post-its? Forget about it! Just sit together and chat a bit.
2 – Start immediately
As there is no need to set the stage, start immediately with gathering data. Immediately start the retrospective with asking the two questions: “What went wrong?” and “What went well”. That should be sufficient to get great results.
3 – Don’t check if the tasks of the last Retro were done
We don’t care about the old crap from the last retrospective. If it was important enough, it will make it again to our retrospective results. And again, and again, and again, and again….
4 – don’t use post its
Post Its are evil! Endless trees have to die to create this evildoing. You have silent and introvert people in your team? Then maybe it is time for them to learn to speak up. It also helps to reduce all of this retrospective waste, with all of these things that can’t be solved anyway.
5 – Forget about the Insight
Insight? Isn’t it clear why you failed in your last sprint? Maybe you should also skip the “Gather data” step and instantly start to “Decide what to do”.
6 – No DUE date
Due dates are for waterfallers. As we’re working in an agile environment, we don’t need any due dates.
7 – no responsible
Repeat after me: “We’re no waterfallers”. A responsible person is a concept from the stone age. We as a team will make sure that the task will be done.
8 – No time box
This whole concept of a time box is exhausting, isn’t it? Can’t we just skip it for the retrospective? Just sit together and talk and for sure we will have something valuable in the ehh, when it is over, eventually…
9 – try to solve everything
You collected a big list of issues? Then you should try to solve all of them. It can’t be that you ignore some of the problems of the last sprint. Define a task for each identified impediment or problem and solve it in the next sprint.
10 – Always use the same scheme
Always ask the same questions and do the same exercises in all of your retrospectives. This will create a comfy environment for your team and you ensure that you’ll always have a energized and creative team. Your retrospective results will be awesome. Ignore all of this fancy new methods to facilitate a retrospective. This is all new age shit.
I’m looking forward to your experiences, when trying these things out. Please leave a comment
5 Reasons Why a Product Owner Team Might Be a Good Idea
20587 days
http://www.flickr.com/photos/yckhong/363310776/
During this week I read an interesting article called “Is Scrum a –ism that doesn’t work for real?“. One of the things that @marcusoftnet mentioned in his article was this:
The product owner is an unicorn
I continue to read and had to agree with him in many points. The rest of the week I kept thinking about this and came to the conclusion that in some environments a product owner team would be a better fit. But what could be a good reason for a product owner team?
1 – Responsibility
One good reason might be a shared responsibility. In some companies it seems to be difficult to define THE one and only PO with all needed responsibilities. Even worse, I saw product owners, whose decisions were overruled by their bosses and managers. This does not only have a demotivating effect on the PO, but also the development team becomes insecure when working with her. When you have a PO team, it is much more difficult to overrule them.
2 – Diversity
Another good reason for the team approach is the diversity you get when you have a team. My ideal PO team consists of a product manager, one person from marketing, one from UX and a techie. That way you have all needed knowledge in the team to create an awesome backlog. I saw a lot of bad POs who were unable to create a good backlog, because he missed some knowledge in an important area e.g the market or technical know how. This will all vanish if you have a PO team.
3 – Availability
Ever heard about ScrumMasters taking over the role of the PO, when he is not available? Bad idea! But it does happen and not only once. This is another good reason for a PO team. Even if one or two members of the team are not available (ill, on vacation), the team is still able to work. No availability issues anymore.
4 – Teamwork
A good backlog is the result of great teamwork. I never saw a backlog that was created by a single person and still was in a good shape. I know that there are no rules that the PO should be the only person to create new items in a backlog, but many teams think so. A PO team forces them to work together. Of course they still have to work tightly with the development team, do backlog grooming sessions or even ask a developer to help to maintain the backlog. A PO team will help to foster the collaboration in a team.
5 – Fun
Last but not least, working in a team is much more fun. I know this should be also the case if you have a single PO, but I never saw a PO that sat in the same office or even floor than the development team. I even saw POs that were not only sitting in the same office but at a completely different location. With a PO team you force them to work at the same location and I swear it is much more fun to work this way.
What do you think? What are your experiences with POs? Do you also think that the role of the PO is a unicorn? I’m looking forward to your comments.
UPDATE:
Thanks to @maritzavdh here are some links for further reading:
5 Signs That Your User Stories Suck
9615 days
http://www.flickr.com/photos/arlette/3260468/
About one a half years ago, I wrote an article about how to mess up your user stories. In the meantime I saw other “User Stories” that gave me creeps. That’s why I decided to write this article. So here is my new list of signs, that your user stories suck…
1- Your user Stories Are Only a Wrapper
If your user stories only consist of one task, this is a sign that you just using them as a wrapper. I don’t know why, but it seems that some people believe, that they have to use the user story format for everything. A user story is “a promise for a conversation”. If there is nothing to discuss and it is a simple task, than write it down like this. Don’t wrap a pseudo user story around it. In most cases this is also a sign that your user stories are too small.
2 – Your user stories can be done in less than a day
If you have 40+ user stories on your Sprint Backlog, it gets really hard to get a commitment from your team. Some people might say now: “Wait, isn’t it great if they were able to create such small stories?”. Yes, it is great, but not if all of these stories are tasks. In such cases, these stories belong to a bigger story and don’t make sense on their own. Check if your stories are meant to add new functionality, if not something is wrong.
3 – Your user Story Doesn’t Describe a Feature
This is somewhat related to 1 and 2, because in most cases these signs come in together. If your stories are describing tasks for the developer, instead of describing a new functionality, something went wrong. I saw POs writing user stories that described thing like “Write document X” or “Create acceptance test Y”. In those cases I’m asking for the DoD of the team, because those things clearly belong there. And if you don’t want to add them to the DoD, create a task but don’t rape the user story format.
4 – You Use It For Everything
It’s great that you decided to use user stories to create your backlog. But you know what: You can use any format that you like. There is no rule in Scrum that you have to use user stories. You’re not forced to use this format for everything that is in your backlog. In a lot of cases it just don’t make sense, e.g. when you want to add non-functional requirements. Instead add those non-functional requirements to the acceptance criteria of your user stories. If they apply to more than one, create an epic and add it there. But please, don’t use the user story format for everything that is in your backklog.
5 – You Lost Your User
Did you write stories like: “As a project manager…”, “As a product manager….”, “As a developer…” or “As a test technician…”? Than you have lost the real user of your software. It won’t be the project manager or product manager who will use your software. Start over and ask yourself who will use it and write your user stories with their view in your mind. Another possibilty would be to create personas. But always have your user in the focus.
I’m looking forward to your comments. What signs did you observe?
Recent comments