Last week I talked at the ALE Bathtub conference about the evolution of retrospectives. Fortunately, the talk was taped so that I can share it with you. I hope you’ll like it. I’m already looking forward to your comments.
Last week I talked about “Spicing up you retrospective” at the ALE2012. I did a similar talk in June at the ACE!Conference in Krakow. But after the talk in Krakow I had a chat with Bob Marshall and he pointed out that fun isn’t the (only) answer to make retrospectives better. He also pointed me to a blog post were he wrote about these issues. So, the following article is mainly based on his ideas.
For me, there are two main retrospective challenges:
- Create a motivating environment and keep the people them engaged
- Work on the identified items
On first sight it seems that these two challenges may be caused by:
Repetition –> Boring Retros
Same problems –> No effect
Tasks are not visible
Tasks are too big
But these are only the things you see on the surface, if you dig deeper you’ll find the real root causes.
IMHO, the main root cause is a missing purpose. Any retrospective without a purpose is a complete waste of time. (the same applies for any other meeting). It doesn’t make sense to change your retrospectives regularly and introduce new ideas as long as there is no purpose behind. But how can you inject purpose into your retrospectives? The answer is: by using hypotheses. To do so I adapted the original retrospective flow by Diana Larsen and Esther Derby the following way: (more…)
Last week I spoke at my favorite agile conference of the year in Krakow, Poland: The ACE!Conference. If you haven’t been there yet, you have to be there next year. I’m quite sure it will be even better than this year. I talked about my hobbyhorse: Retrospectives. Here is the video of the talk I gave:
And here are the slides of the talk:
I’m looking forward to your comments.
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:
And here is the corresponding video of the lightning talk:
Have you ever been sitting in a sprint planning and heard the following sentences:
- “Can we split this user story and at least start with the GUI?”
- “I’m not sure if the hardware will be available on time to integrate this story but we could use an emulator instead.”
- “There are no wire frames yet, but we could start with the back-end.”
- “The acceptance criteria are still quite vague, but I think I know what the customer needs.”
Does some of these sentences sound familiar? I observed these conversations several times in the past. All of these quotes are based on the same problem: The user story is simply not ready for the next sprint. Still, some teams pull these user stories into there next sprint to implement at least a part of it, to make the PO happy. Stop it! It doesn’t make sense at all. None of these user stories will be done at the end of the sprint, because important parts are missing. These teams have to be reminded that every user story has to be implemented, tested, integrated, documented and shall deliver value to the end user. If you already know at the start of a new sprint, that you won’t be able to finalize a user story: ditch it!
But what can you do to avoid these discussions? There is a simple solution: Introduce the “Definition of Ready” (DoR)! The DoR defines, when a user story is ready for a sprint. If it doesn’t comply with this definition it will be ignored in the next sprint planning. As the “Definition of Done”, the DoR is defined by the team itself and therefore varies from team to team. If you’re e.g. developing a web application, hardware may be not that important for your team, but if you’re developing software for e.g. a medical device it is could be important. Sit together with your team and your PO and define what the DoR has to contain in your current situation. Agree, only to pull those stories into your sprint, that are ready for sprint.
Most agile teams I know implement a DoD, but the DoR is still only rarely used. I hope this will change in the future. Don’t waste your time implementing half-baked user stories. You can use your time better than that.
What are your experiences? Leave a comment!