Alex Stetsenko

Part 2 of the animated video describing Spotify engineering culture is finally out! Also check out part 1 first if you haven’t already seen it.

A short video that explains in details what Scaled Agile Framework (SAFe) is as well as defines new terminology.

A valuable insight into Spotify engineering culture that has been influencing Agile adoption by other teams and companies. This is Part 1 and Part 2 hasn’t been recorded yet. Stay tuned to Spotify Labs.

This is famous 15 minute animated presentation about Agile Product Ownership.
While this is obviously a high level summary, it still gives a valuable insight about Agile and Product Owner role.

A great way to learn or improve something is to look at anti-patterns. Watching how NOT to act is not just funny but does a great job at explaining Scrum Master do’s and dont’s.

If you are serious about your user stories, there is a great article by Richard Lawrence about patterns for splitting user stories.

Richard suggests nine patterns based on INVEST model (Independent, Negotiable, Valuable, Estimable, Small, and Testable). The key is to split user stories into good smaller stories rather than create a story for each architectural layer (one story for the UI, another for the database – this may satisfy small but fails at independent).

Although this is a “must read” article there is also a shorter version in a form of cheet sheet.

Few days ago I ran into another interesting parable:

I once went to a circus and saw a huge elephant tied to a small pole with a rope, just standing there. So I wondered why is the elephant so obedient and doesn’t break away from the stick with all of its enormous strength and mass. So they told me this story: once when the elephant was very young, it was tied to the pole the same way. Naturally, it didn’t like that and tried to escape, but try as it might, the rope and the pole were too strong for it. So the elephant eventually gave up.

Later on, when it was older, the elephant still believed it could not escape from the rope, and remained standing in the same place, despite the fact it could then easily escape.

Interesting, ha? It is said something like past performance does not guarantee future results. Which usually means being successful in the past does not imply success within another company or just in future. However this parable is a wonderful example of the opposite. So it is important to realize what one may now be capable of doing regardless past experience.

It’s almost like being Agile: fail early and then start a new sprint. 🙂

Unfortunately I have not been able to find the author of the quote below. However it carries an interesting message about investing in people.

– What happens if we invest in developing our people and then they leave the company?
– What happens if we don’t, and they stay?

Recently I have come across this great old parable of stone cutters.

A man came across three stonecutters and asked them what they were doing. The first replied, “I am making a living.” The second kept on hammering while he said, “I am doing the best job of stonecutting in the entire county.” The third looked up with a visionary gleam in his eye and said, “I am building a cathedral.”

Although these three men were doing the same job, there were three different answers. I think this is a great example of motivation “in action”.

Popular in journalism, the Five Ws (also known as the Five Ws (and one H), or Six Ws) formula can be adopted in software project management.

• Who? Who was involved?
• What? What happened (what’s the story)?
• Where? Where did it take place?
• When? When did it take place?
• Why? Why did it happen?
• How? How did it happen?

Even short answer on each question above gives a good story on something happened. Especially if that took place unexpectedly. Documenting those answers could be very helpful to make a step forward and resolve the situation as well as better understand how to prevent similar issues in the future.

Speaking on preventing similar problems to occur. H. William Dettmer made a good point that manager’s value is assessed not by the importance of the tasks he\she is working on but whether he\she is solving the same issues multiple times.The quote is actually applicable to (software) engineers too who normally should resolve the problem for good instead of hiding it or inventing another ‘temporary fix’.