Time to Bury the Construction Metaphor

Using the construction engineering metaphor is probably the most common and well known way of explaining or describing software engineering. Almost every aspiring software professionals dreams of having a fancy title like architect at some point of their career. Unfortunately it's misleading, creates a lot of confusion and just wrong in so many levels.

People ("even software people") still use construction metaphor to explain why we need fixed price contracts etc. They seem to forget the fact that even if construction engineering has about 6000 years of history data to help in estimation, big construction efforts still are finished late and the total costs grow way beyond original budget. When you talk about construction, the design cost are negligible compared to actual construction costs and it makes a lot of sense to do the up front planning as well as possible. Changing foundations after building few floors is not possible. Can you imagine building a bridge half way through and then deciding that you need to make it wider to accommodate rails for trains.

Software is different. It's becoming the norm to talk about emergent design, which means that software design is not done up front, but it emerges little by little. I know this one phrase explanation does not cut it and there are people who give actual talks about emergent design, but it's out of scope for this blog post.

In software engineering it's very common to start building something and end up with something completely different. Needs change, understanding evolves and requirements change.

"Only constant is change"

 The famous quote by Heraclitus is very true at least considering software development. In software development construction costs are non issue and it's worth building as much as possible. Sometimes you just end up doing the wrong thing and that can't really be helped.

"I didn't fail, I found 10 000 ways that don't work"

That is very agile mindset really shines. Sometimes you just can't prepare and you end up building the wrong thing. In those cases failing fast is a lot better than failing slow. Taking a cue from Edison, what I really want to say is that you want is make software that don't work fast enough so that you still have time to build the right thing. Eventually you'll get it right.

In software you want feedback. It something doesn't work - great, now we know, we have some information. Now it is up to us to decide what we want to do about it. Faster the feedback loop the better, but you still you need to validate the feedback. Keep in mind that comments from actual end-users are the most important kind. How can you add value, if you don't know who the people gaining that value are.

So with that being said, it time to give our respects to old and dated metaphor. May you rust in peace, you just don't have a place in modern day software development.

Empowering Teams With Retrospectives

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. What? 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. Why?
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 sounds like a 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 future.
How?

“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.
5. Close 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.
Conclusion
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.

The Agile Mind of Bruce Lee

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 labeled 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