One wouldn’t normally relate Valentine’s Day to the office life of developers, designers, QA people and other guys involved in software development process. Such qualities as love, compassion, care and empathy do not obviously stand out as prevailing in our work. It’s mostly rough and tough. The word SCRUM is actually derived from rugby, a guys-only sport where the winner is the one who stands tough and pushes hard. As people work to create software, they quite often tend to be unyielding, protective of their opinions; they’re used to pushing, and sarcasm often comes out as closest to ever having any empathic perspective on your colleagues.
Have you ever been in such a situation, as a designer or as a writer or as a developer that you’re given a task, you work on it all alone, you come out with more and more drafts, and everyone seems to be criticizing your work? It takes stamina and a good deal of emotional stability to be able to withstand sometimes pushy remarks. No, I don’t mean to say that colleagues intentionally want to make you feel resented. All they want is to get work done, and their comments have the sole purpose of helping you complete whatever you’re doing as best as you could. They’re beta-consumers, the first to take a look at what you’ve created, before you shoot your design or a piece of text to the outer world.
Here’s the point. Like I mentioned in one of my previous posts, we’re a company with trust established as one of the signature values. I’m not showing off, just citing the fact. So, a possibility that someone is saying something to hurt another person, is totally left out. However, even in this healthy environment, and with all the love for the work that people have, the universal laws of biology have a life of their own. The work is demanding, creative, and even as rewarding as it seems – your brain and your neurons just get tired. It’s purely physical. People are made of flesh and bone, they’re not made of hardware. With this tiring, people become hypersensitive to the remarks about their work, and may start taking them personally. One can’t get away with it. So, I’d like to highlight the need of awareness about this quality of human psyche.
If a colleague is fatigued, stressed out about some work, or if some personal factors add up to the stress, what if we try to feel the challenge that our fellow human is undergoing, and instead of being purely work-focused, give a little bit of personal attention and some help to each other? It’s not that hard really. Sometimes, if someone is stuck with a design draft or something of that kind, instead of giving some remarks on what this person does, wouldn’t it be wise and nice to switch the focus from judging to helping? At the end of the day, it’s not only about helping your colleague. It does contribute to the task at hand. You can save your colleague by dropping in new fresh ideas, or see if there’s any other way to help him or her. If you don’t know how to brighten up the life of someone who spends their days near you in the office space, go ahead and find out. Wipe the dust off of your right brain hemisphere or the heart chakra or whatever other scanners and sensors you could put to test for the other folks . This would also provide a side balancing effect for your own brain, giving it some rest from analytical tasks for a change. Maintaining the culture of compassion in a geeky environment might look like a weird idea, but what your company is worth if it’s not about people? People are the greatest asset, but somehow they’re not usually treated as such. So, is there any other better day than February 14, 2013, to emphasize the need for human relating, as well as the need to be more loving, compassionate and non-judgemental about others?
Happy Valentine’s Day everyone!
January 13/14 is the Old New Year holiday. Seems like today is the latest appropriate time to look back and recall the most interesting blog posts by TargetProcess in 2009 :)
Based on visitors count, the posts are ranked as follows (descending order):
1. Lean and Kanban Software Development Digest: In May 2009, this digest came along right on time as Kanban adoption started to grow. We’ve been sifting through the Lean/Kanban buzz and considering if Kanban might be a good tool for our development process, so this post has the most valuable findings we’ve made and shared with agile community.
2. Refactoring vs Rewrite: This post is a real train of thought of a Product Owner trying to make a decision on how to proceed with product development — rewrite or refactor. Can well be used in textbooks for software product management :)
3. Mind Maps: Scrum, Extreme Programming, Lean: Another by-product of our research on agile development processes. The specific value of mind maps is that they help grasp complex things with visual representations.
4. Tale: Deadline and Technical Debt: Once upon a time… Who could ever expect that the fundamental principles of product management can be outlined in a fairy tale ? :) There we go: smart Arthur, the cunning king, quest for princess — the metaphorical expression of the danger of technical debt in software development.
5. 5 Wrong Reasons to Apply Kanban. For some reason (no pun intended), 5 wrong reasons ranked higher than 5 right reasons. Maybe it’s just human psychology — to go from “what’s wrong” instead of “what’s right” …
6. How We Use Kanban Board. The Real Example: Once we figured that Kanban process is just the right thing for us and put it in action, we shared this experience with our blog readers.
7. 5 Right Reasons to Apply Kanban: There they are :)
8. Zero Defects? Are You Kidding Me? : Can this juicy frog be sure that it swallowed the very last bug? This post is a warning against the so-called “zero defects mentality” in software product management.
9. Simple Rules, Complex Systems and Software Development: Complex systems function at their best when guided by simple rules. Look at ants, birds, space rockets and … software development.
10. BDD and User Story Specification: Examples — This post includes some real user story specs in BDD for TargetProcess product. Enjoy and use.
These are the TOP 10 posts in 2009 from TargetProcess agile blog (click here for more)
Happy OLD NEW YEAR! :)
Many complex systems are based on simple rules. A set of several simple rules leads to complex, intelligent behavior. While a set of complex rules often leads to a dumb and primitive behavior. There are many examples.
How ants search for food? They do not have cell phones, cars and mini-markets near the nest. They should have something simpler to communicate.
Here is how ants work:
- Travel randomly in search for food.
- Take a piece of food and head straight back to the nest. On the way back to the nest lay down an odor trail.
- Notify nestmates of the discovered food encouraging them to leave the nest. These newly recruited ants will follow the odor trail directly to the food source. In their turn, each ant will reinforce the odor trail until the food is gone.
Sounds simple? Take a look at this very nice ants colony model. Drop some food and enjoy the action.
Birds flocks are beautiful. You may think that the movement gets orchestrated by one savvy bird. But this is not the case. A bird flock is guided by three simple principles (every decent bird knows them):
- Separation: steer to avoid stumbling upon local flockmates.
- Alignment: steer towards the average heading of local flockmates.
- Cohesion: steer to move towards the average position of local flockmates.
Simple? Yes, it is. Look at the picture on the right. It’s just amazing!
Game of Life
Game of Life was invented in 1970 by John Conway. It is a cellular automaton and simulates the birth, death, etc., of organisms based on certain rules:
- Each cell with one or no neighbors dies, as if of loneliness.
- Each cell with four or more neighbors dies, as if of overpopulation.
- Each cell with two or three neighbors survives.
- Each empty cell with three neighbors becomes populated.
Simple rules. But these rules lead to fantastic diversity of the forms. Different types of the forms have been discovered e.g. still objects, oscillators, gliders, spaceships, etc. It is impossible to predict the state of a system after several thousands steps. Cellular automaton has properties of a complex system such as emergency and butterfly effect. Small changes in the stable structure (for example, adding one more living cell) may cause death of the whole cells population.
Moreover, it is possible to build a computer based on Life! It is possible to implement logic based on stable structures and execute simple calculations. The Game of Life is a Turing machine! How can someone suggest that such a simple system based on four rules has so much power?
Take a break and have fun with Life game simulation.
Simple Rules and Software Development
Is there any relation between simple rules and software development? Sure, there is. Software development process should be simple. Process complexity leads to mechanistic and dumb behavior.
- Information exchange and collaboration vs. standard status reporting meetings.
- Learning vs. stagnation.
- Emergent behavior and creativity vs. Following rules, standards, instructions.
Agile methodologies are simple. Scrum is a very simple thing. It has just several rules, roles and artifacts. Well, it is a lot harder to really implement Scrum. It is hard because you need to break stereotypes and habits. Many people are resistant and don’t want to try new things. However, Scrum works. It works because of its simplicity, it lives in accordance with complex systems.
Scrum stimulates learning, feedback, communication and cooperation. Emergency is possible in Scrum.
Here is one sample of unnecessary complexity — too many hierarchy levels:
A potential problem, unlikely in small and medium organisations, is deep organisational structures. According to Peters and Waterman (1982)18, both Toyota and Roman Catholic Church have only five layers of management in comparison to Ford’s seventeen.
Do you by any chance happen to have a software development process description in a huge 100+ pages document? Are you still in business?