Author Archives: pietrotull
If there is one thing that embodies agile mindset then it’s the continuous and constant apply, inspect and adapt -cycle that goes on and on. In mature and advanced teams this is a natural part of daily work and goes on even without extra rituals. Still there is time and place to do it formally and that is something we call a retrospective.
Since people learned to communicate people have gathered around a camp fire to share stories and tips around what worked and giving evolution a boost in the process. Retrospectives are a modern day way to achieve the same thing – learn from experience. Retrospective offers a chance for a structured inspect and adapt session. I roughly divide retrospectives to 3 categories: sprint, half year (some people call these iteration or release retros) and full project retrospective. All these have different meaning and more importantly a different scope. Sprint retrospectives are the corner stone of process improvement on daily activities. It’s one of the key artifacts in Scrum and implicitly defined in scrum guide. To do proper scrum, you have to have a retrospective at the end of each sprint. Kanban does not define retrospectives, but it’s highly recommended to do them every few weeks. Still in a sprint retrospective you can only do so much. If you only look back few weeks, you can only touch the surface. If you want to dig deeper, you need to look way back and dedicate time for it. That’s when a half year or a project retrospective comes into play. These take a lot more time and planning to do them properly. To look back a half year, you need at least 4 hours even with a small team, preferably a full day. Time needed is directly related to time frame you are looking to reflect on and how many people will attend. If you have more people, there will be more conversation and you need more time to make sure that everyone gets to speak their mind.
When done properly, retrospective empowers the team. It makes them feel like a change is a possibility, it makes them feel capable of change. Might sound like an obvious thing, but for a young guy at a new company these things are NOT obvious. Reasonable tasks that make a difference empower the team. This is also a key ingredient of creating self organizing teams. Retrospective is a tool for satisfaction and improving customer collaboration. You often run into prejudice that having clients present will hinder conversation when the contrary is true. Having another perspective only fuels conversation and diversity helps when creating action plans for the future.
“The most important thing about retrospectives is that you have them”
-Henrik Kniberg, Crisp
I could not agree more with Henrik, as long as you do retrospectives, you have hope. Format matters, but start easy and do what ever feels comfortable. Just going off site for a coffee and a donut might good way to start. Just grab a notebook and pen and take notes during the conversation. This kind of structureless retrospective can work for a short while, but you might soon run into problems. Retrospectives that don’t result into doable actions are not really worth that much in the long run. Using 5 phase retrospective structure that Diana Larsen & Esther Derby introduced in their book is highly recommended. Each phase has an explicit purpose and should not be skipped, how decide to facilitate each phase is up to you and open for variation. Just for a quick introduction or reminder what the phases are:
1. Set the stage
Create focus on the matter, agree on rules and make sure everyone understand what is the purpose of the retrospective.
2. Gather Information
Create common understanding what has happened during the project or time span you are reflecting on.
3. Generate Insight
Spot patterns and underlining themes on information gathered in previous phase.
4. Decide What To Do
The most critical phase in the retrospective so really put effort here. What you need is clearly specified doable tasks. It seems to help if you tell people to handle it like sprint planning where you take big backlog items and split them to tasks. Retrospective tasks should be something that you can write on a card and put on the team’s task board.
Something you really should do at the end of any meeting – close the meeting properly and summarize what ever was decided in the meeting. Make sure there is a common understanding of what was decided. This is the moment when you should also ask feedback for your session to improve your facilitation and retrospective planning skills. DialogSheets are a great tool for sprint retrospectives, they offer a clear structure and retrospective plan that is easy to follow and engaging. If you plan to reflect on a longer time span, try to get a neutral experienced facilitator for better results.
Retrospectives are a corner stone for any agile organization and there really is no good reason not to have retrospectives. This was just a quick overview of the process and there are a lot of good resources how to get started. The point is to get started. I would recommend reading Norm Kerth’s book on retrospectives first and then using Larsen & Derby book more as a hand book when planning retrospectives.
There is always something you do better and that is the essence of kaizen. Retrospectives are a great way to plant the seed of Kaizen to the team and to the rest of the company. If you really think that your team is doing so great that you have nothing to improve, then most likely you are the problem.
For whatever reason I recently ended up reading a bunch of Bruce Lee quotes and more I think of them, more it seems that he truly adopted the agile mentality. Agile is a state of mind, attitude, set of values to live and work by. You can do everything by the book, but no set of techniques or methods is enough, you have to be agile. Bruce Lee applied this very same mindset to martial arts with great success.
SCRUM paved the way for wide array of different methods that are labelled as agile. As with anything, debate emerged what was better and what was truly agile. Even agile leader entered a heated debate over kanban and scrum everyone totally missing the point. Key concept in agile is adaptation and Bruce Lee was down with that:
“Adapt what is useful, reject what is useless, and add what is specifically your own.”
He famously combined traditional Chinese martial arts with western boxing. He was the first true mixed martial artist. He also discarded lot of formality, scripted movements and rituals that he didn’t find useful. His goals was effectiveness.
“Use only that which works, and take it from any place you can find it.”
This is precisely what agile professionals do, it doesn’t matter what it’s called as long as it works. Other one of the key foundations of agile is the continuous inspect and adapt cycle.
“Be happy, but never satisfied.”
You should be happy, but never satisfied because there is always something you can do better. There is always room for improvement. That is the true Kaizen spirit. Agile methods differ from traditional methods in being less dependant on up front planning. Less surprisingly Bruce Lee had similar thoughts:
“If you spend too much time thinking about a thing, you’ll never get it done.”
This is just the same message about not overanalyzing nor spending too much time writing specifications before getting your hands dirty.
“Knowing is not enough, we must apply. Willing is not enough, we must do.”
This is the kind of people you would want to hire, people who get to the job and even more done instead of just talking about it.
“If you don’t want to slip up tomorrow, speak the truth today.”
Visibility and eagerness to tackle any problems as soon as they surface is another key concept of lean. We should have the courage to speak up when we spot a problem and confront them as soon as possible.
Lee was always very carefully studying his own shortcomings. Lesser known fact about Lee is that he also trained judo with an Olympic level judoka, he identified his own lack of understanding about throws and grappling and did study them to great extend. This kind of self inspection agilist do continuously by themselves and also as a group in retrospectives.
In the heart of agile is the adaptation. True agilist always finds a way around the problems and thrives to find solutions to what ever circumstances he faces. What could be more agile approach than what Bruce Lee famously said about water:
“Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend.”
Could it be that this certain mindset is actually the recipe for success. Do all great minds think along the same lines.
All the quotes were picked from here: http://www.goodreads.com/author/quotes/32579.Bruce_Lee
Last week I had the pleasure of attending David Anderson’s two day class of Kanban. His analytical take on agile development was actually quite refreshing and you can always appreciate someone willing to share his vast experience.
I’m somewhat a statistical geek myself, so his preference to statistical information over estimates make a lot of sense and really sounds good to. Estimating is hard and pretty much useless after a while, when you have some decent statistics about velocity. There is still a place and need for splitting user stories to tasks.
Maybe the biggest surprise was that he doesn’t consider Kanban to be a software management process at all, it’s something applied to your current process. So starting from scratch is not an option, you need to have a starting point.
Other key point was how correct use of classes of service can drive to customer satisfaction. Classes of service and predictable lead time will drive customer satisfaction without a doubt.
On a side note I got a bunch of new tips what books to read. Specially Switch Switch – How To Change Things When Change Is Hard (Chip, Dan Heath) sounds like a book that could help me fight the emotional resistance that change always triggers in people.
Thinking about starting a blog is nothing new to me, I’ve been doing it for few years now. Actually doing it on the other hand is. This blog is about me giving it a go.
Recently I’ve been trying to promote some more agile manners among co-workers and resistance to change unfortunately is not uncommon, thus the name AgileMonger. You might not want it, but i’ll try to sell it anyway.
Maybe when I get better at promoting agile, I can change the name of the blog and start a whole new more professional blog.