The Client Product Owner Dilemma

Sometime ago when I had stomage ache I decided that I wouldn't want to suffer any longer than necessary. This was a clearly an issue that needed to be handled in timely manner. I decided that I would skip going to a generalist doctor and went straight to surgeon armed with a black marker.

Fancy knife

Me: Hi there, I need you to appendix, it's done for.
Doc: ... what?
Me: Look, let me show you. Grab a scalpel and start here around waistline and follow this dotted line for few inches. Then reach for your clamp and get hold of the appendix and then just cut it off with the scalpel. 
Doc: ...
Me: Look I downloaded some pictures from the internet, this is what the appendix looks like and this is a picture of how it looks after you take it off and here you see what the stitches look like after you finished the job.
Doc: ... but...
Me: Oh, almost forgot, don't bother with anestesia as I´m on a budget here and I´m pretty touch and I can take it without. 
Doc: ... aaaa... ahem...
Me: So here's the specs as user stories and the all important time estimates

1. As doctor take out scalpel and make the cut (1min, 30 sec)
2. As doctor spread the cut (30 sec)
3. As doctor use clams to get hold of the appendix and Then cut it out (2 minutes)
4. As doctor use the needle the sew the stitches (4 minutes)

Me: I´ll even allod you some 15 minutes for setup time and 5 minutes afterwards the wash your hands. I  assume surgeons get paid around 100$ and this takes less than a half an hour so let´s just round it out so I shall pay you 50$ for the operation and of course you are liable if anything goes wrong.

Knife

... And this is when the guys in white jackets walked in and escorted me to a comfortable room with padded walls.

The problem is (more like one of the problems) is that product owner is supposed to have a vision about the product and clients rarely have even a remotely good idea what the underlying problem was. They may very well not even know the solution, all they know are few symptoms.

ps. Pics courtesy of wikipedia

Generation Kill Software Project

While watching rerun's of HBO:s acclaimed miniseries Generation Kill it occured to le how shockingly easy it is to draw parallels between dysfunctional army management and modern day software engineering.

Further the way from action the decisions are made, worse they are and worse the outcome. In war you endanger lives of soldiers and civilians and unfortunate casualties include livelihood of locals and lives of children and women.

Junior soldiers carry out orders with sometimes disastrous results. Seniors know better and from time to time question orders, but are left with dilemma - carry them out or refuse and possibly face disciplinary actions. It's a decision they have to live with for the rest of their lives.

Software engineering is not much different, but the outcome is of course less dramatic. Bad decisions made without proper understanding of the situation at hand still lead to unwanted and sometimes catastrophic results.  Only difference is that in software engineering casualties include motivation, professionalism, team spirit and in worst cases - careers.

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

David Anderson's Kanban class

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.