agile, scrum, coaching, lean
scrumphony
This user hasn't shared any profile information
Posts by scrumphony
Penitence For The 7 Agile Sins
2171 days
http://www.flickr.com/photos/21561428@N03/3734800195/
Half a year ago I wrote a blog post about 7 Agile Sins. As I’m sure, that I’m not the only one who is guilty for one or more of these sins, I collected a list of possible ways to show penitence and to do it better next time 
So here is my list of the sins and their appropriate penitence.
Stop learning
The first way for showing penitence is to help to create a learning environment in your company. One possibility to do this is to introduce so called brown bags. This is at least one corner stone to foster learning and bring new ideas in your working environment.
Don’t listen
Listening is a fading skill in our society. Most men know at least one situation where their girlfriend shouts at them, because they didn’t carefully listen. But hey, there is help underway. Listening is a skill you can learn. There are a lot of great books out there on how to become a better listener. One of them is “The Art of Active Listening“. It’s a quite short one and a good starting point to improve your listening skills.
I also recommend listening to the TED talk of Julian Treasure “5 Ways of Listen Better”. One of the things I found valuable is the acronym “RASA”. It’s the Sanskrit word for essence. The single characters have the following meaning:
- Receive
- Appriciate
- Summarize
- Ask
If you keep this acronym in mind during your next conversations, it will help you to get a better listener. So one way to show penitence for this not listening is to learn to listen.
Stop thinking
This is simple. Start thinking! I know, the guys behind XP, Scrum and Kanban are keen thinkers. But you know what: They don’t know your context. So, before you blindly follow “the book”, try to understand WHY you are doing these practises. Show your penitence by doing the following: Map each of the practises you use to one or more agile values and principles. This will be the first step on your journey to understand the theory behind the agile frameworks.
Be dogmatic
Your penance for this sin is to look beyond your own nose. There are still agilists out there who believe, that there were no successful projects before agile frameworks came in. Fortunately this isn’t true. There are a lot of successful “waterfall” and V-model based projects that were successful. And there was one entity that collected best practises and created a book out of them. So your lesson to show penitence for this sin, is to read the PMBOK (Project Management Body Of Knowledge). I’m sure, even as hardcore agilist you’ll find some valuable things in this book.
Ignore the agile values and principles
There is a great exercise described in the book “Coaching Agile Teams” by Lyssa Adkins name the “High Performance Tree”. Lyssa also created a short Youtube Video where she describes how to create such a tree. This tree has many functions. One of them is to use it as part of a retrospective. You can ask questions like “Why did x happen last sprint? Where were our roots weak?” or “On what of our high performance traits do we want to work in our next sprint?”. As the tree should be placed on one of the team’s walls, it is always visible and part of the team’s daily business. To make a long story short, your exercise to show penitence for ignoring the agile values and principles, is to draw a “High Performance Tree” together with your team, put it on you team’s wall and use it in your next retrospective.
Misuse the agile toolkit
I’m sorry but for this sin there is only one way to show penitence: Go get a priest. In our case this means to get help from an experienced coach. I have this opinion because IMHO this happens especially in inexperienced teams. I had teams that were only “trained” by reading the Wikipedia entry on Scrum. It’s quite clear that there are some misunderstandings in the beginning. But also other teams benefit from an experienced coach, who will help them to understand how to use the agile toolkit correctly.
Ignore the transparency
IMHO this is most deadly sin of all. There is a simple way to overcome this sin: Be even more transparent! Don’t put your backlogs and boards into an electronic tool. Make it visible. Put it on the walls, but not only in the team’s room, also on the floor or near the management’s offices. In one of my last projects we used a so called “master board” to foster the “Scrum of Scrum” meeting every morning.
Masterboard for 5 Scrum teams
Each row represents a team and the cards on the board only show on what the teams are working on User Story level. This really helped us to get the big picture of the whole project. Additionally we introduced a dashboard to show the project status using “traffic lights”.
Dashboard for the management team
In the upper left corner we showed the overall status for every planned release. All open issues were shown on the right upper corner. The left lower corner was used to show on what epics the teams are currently working on and last but not least, the lower right corner showed the already delivers epics. This way we were able to completely remove all status reports. Now the management was able to get the status on one single view. One way to show penitence for ignoring the transparency of your team would be to introduce a master board for your Scrum of Scrum meetings.
I hope you like one or more of my suggestions to show your penitence. I’m looking forward to your comments!
10 things to mess up your retrospective
5187 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
Food for Though #12: Dogma sucks
1199 days
Dogma is the established belief or doctrine held by a religion, or a particular group or organization. It is authoritative and not to be disputed, doubted, or diverged from, by the practitioners or believers. Although it generally refers to religious beliefs that are accepted without reason or evidence, they can refer to acceptable opinions of philosophers or philosophical schools, public decrees, or issued decisions of political authorities. The term derives from Greek δόγμα “that which seems to one, opinion or belief”and that from δοκέω (dokeo), “to think, to suppose, to imagine”. Dogma came to signify laws or ordinances adjudged and imposed upon others by the First Century. The plural is either dogmas or dogmata , from Greek δόγματα. (Source: Wikipedia)
Dogmatism is a wide spread bad habit in our industry. You can find it nearly everywhere. There are the vi dogmatists against the Emacs dogmatists. The C dogmatists against the C++ dogmatists. The Java dogmatists against the C# or C++ dogmatists and also the agile dogmatists against the rest. IMHO dogmatism sucks. It does not only suck once it always sucks. Dogmatism blocks progress and impedes yourself to look beyond your own nose. It does not help to bang your head against a wall a thousand time, just because this is part of your dogmatic believe. It’s not always true that your Scrum implementation failed because you did it wrong. There are a lot of cases, where a plain Scrum implementation won’t work in your environment, in your context. In such cases, it doesn’t make sense to increase the number of prayers to your Scrum god. It won’t help you. The only thing that helps now, is to stop being dogmatic and look beyond your own nose. There are a lot of interesting practises also from other “religions”. Even the evil god of “waterfalls” had some good ideas.
But dogmatism also blocks your self development. There a people who are dogmatic about there belief that they can’t sing, dance, write, coach, code, learn an instrument, you name it. In some rare cases this may be true, but in most cases this is bullshit. The human being is an awesome creature that can do the impossible. One first step could be, to leave your dogma behind you. Let’s try it out and leave a comment about your experiences.
5 Reasons Why a Product Owner Team Might Be a Good Idea
17220 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:
7 tricks to generate new blog post ideas
2227 days
http://www.flickr.com/photos/qisur/4351196974/
I’m currently sitting at my desk and thinking about what to write about in my next blog post. @breskeby was so kind to mention that if I don’t have anything to say I shouldn’t write a blog post. I think he is right, but on the other hand I don’t want to break my habit of writing a blog post every week. I’m caught between the devil and the deep blue sea.
But then @fjeisenberg came around the corner and proposed the topic “How to find ideas to blog about”. I liked the idea. And now that’s the topic of this blog post. Thanks Florian
1- Ask your followers on twitter
As this already worked for me, it will also work for you. Just ask your followers on twitter what they want you to blog about. If you’re lucky you’ll get one or more good idea you can use.
2 – Install the WordPress client on your mobile phone
In the past several of my articles came onto my mind, when I was outside with my kids. Or I had a great idea when sitting at my desk at work. Before I used WordPress on my mobile phone, I forgot about these ideas most of the time. But now, every time I have a good idea for an article I create a skeleton article on my blog using my mobile phone. That way you can create a pool of article ideas. Unfortunately, none of the articles in my pool inspired me today
3 – Have a theme for your blog
It often helps to have a theme for your blog. In spring of this year I started a series called “Food for Thought“. It really helped me to generate a lot of articles based on this theme. A lot of other successful blogger did the same. A good example is @jurgenappelo’s blog about Management 3.0 which is now a successful book in the agile community. I’m still searching for the theme that works for me, but some day I’ll find it.
4 – Use your twitter timeline
If you follow enough people on twitter you may have the chance to observe an interesting conversation or a new idea. Use this as a starting point for your article. Refer to the tweet and write about your opinion about the topic, instead of writing a simple tweet or comment.
5 – Conversational writing
A few weeks ago @catoliv and @mfloryan started a conversation by writing blog posts. One was writing the initial blog post and the other one was answering with another blog post. This way you get inspired by the other person and get some feed for your own blog. Find someone on twitter (or elsewhere) and start doing the same.
6 – Write about your own experience
One of my most successful articles “10 things to drive your ScrumMaster crazy” was based on real life experience of a team at that time. One day they bugged me that much, that I decided to create a list of the things that drove me crazy. There are several other articles in my blog which are based on real life experience. IMHO that’s maybe the best approach.
7 – Ask your blog readers
Yes, that’s a good idea Dear blog readers, what do you want me to write about in the future? Did you like anything special in the past I should write a follow up? Do you think there is the one topic I have to write about? What do you wish to read on this blog? Please leave a comment. Thanks!
Recent comments