Since kid we learn to copy our parents behavior. We hardly ever listened to our parents, but instead we copy their actions, attitudes, religion, political views, behavior models, vocabulary everything. This behavior adoption is also known as “learning” and it goes on without much critical thinking until we arrive to teenage and start rebelling everything they say.
This mindless copying actually seems to one of the big difference between humans and our closest relatives in animal kingdom: chimps. I remember watching a documentary on differences between human and chimpanzee children. When showing a predefined set of movement to open a box that contained a reward (candy). If the set of movement included unrelated moves that did not help opening the box, the chimpanzee actually skipped these moves and went straight to candy whereas the human children repeated the whole set of movements that did not seem to have any function.
Humans are great at repeating rituals that don’t seemingly have any function at all and this comes very naturally for us, imitation is the most important build-in learning mechanism we have and this is why the best way to lead and teach is by example.
The managers are appointed, but leaders emerge. These are commonly seen as being pretty much the same, but I see them quite differently. Firstly manager is appointed as an authority that has certain control of the team. This does not imply leadership. Leadership must be earned. Leadership implies followers and nobody willingly follows someone they don’t trust and respect. Respect and trust be earned. In the best case the manager will eventually win over the team and earn their respect and trust and becomes a leader. One way to gain trust is to give trust. Trust your team and give them a chance to raise up to the occasion.
The best a manager can do war her team is to be an enabler, a servant of the team. It is the manager’s job to help the team do their job and make sure they have what they need. That includes knowing what needs to be done. The team can function without the manager, but the manager is nothing without a team. A good manager allows the team to grow and self organize.
It’s essential for manager to foster teamwork and spirit and to steer clear from internal competition within the team. Internal competition has traditionally seen as a good way to encourage and motivate members to do a better job, but this has been proven wrong. Management guru Edwards Deming has written about the subject at great lengths and any manager new or experienced should pick up his books and try to learn some. It’s much better to reward team members for working together for the benefit of the whole team instead of individual praise that can easily lead to envy, defensive attitudes and rotten team spirit.
The manager needs to show by example how to give and get feedback. He has to show that it is ok to to give feedback and he has to be able to take it as well. He needs to make sure the team understand what is expected of him, but it goes both ways, he needs to learn what the team expects of him. It is not enough to say, you have to do as you say.
Feedback in general is something we all need and want if we really want to improve and learn. Even bad feedback is information. Giving feedback to his peers and own managers is a good way to show example that everyone can do it. Feedback is communication and is essential for any organization that wants to be a proper learning organization. Any manager who wants to be a true leader, has to show example and act accordingly, because actions speak louder than thousand words.
Minimum Viable Product is not a new idea and it has been around for a while now. Like any buzzword that takes of it has had it’s fair share of confusion around it and plain miss interpretations. Some people to see it as overly simplistic idea where you get started with the absolute minimum.
While it is still good idea to get the first round of feedback from colleagues, friends and family as they certainly can provide some very useful early feedback even for something as simple as a login page, but a login page is hardly a product and some way of being viable. Minimum Viable Product is not just minimum, it is VIABLE.
In short the idea is to do a simplified version of any given product and then put out out there in the market to start gathering all important real end user feedback. The product has only the key functionality implemented.
This makes sense not only because it saves time, but it may also lead to vastly better product. Simple product tends to be simple to use and majority of software features are never or hardly ever user. Analysis based on Pareto principle can be applied to software engineering and leaves us with a statement that says “20 percent of the features provide 80% of the value”. The features that are never used is widely considered as one of the greatest causes of waste in software engineering.
Not used features have been implemented making the code more complex than it needs to be. More code lines mean more bugs and harder and more time consuming maintenance. Bug fixing will be targeted to fixing bugs that affect features that users don’t need etc.
Scrum co-creator Jeff Sutherland also makes a point on this. He talks about value curves where he explains that after delivering 20% of the highest priority stories the value produced starts to decline and it’s time to re-prioritize to get a new value curve. Scrum methodology fits well into developing a minimum viable product.
The fundamental challenge with Minimum Viable Product is not just minimum. A login page is hardly a product, it still has to be VIABLE. This leaves us with the biggest challenge when it comes to Minimum Viable Products – what is viable? This can very hard to define and various greatly depending on the existing market. When creating something new when the market is in virgin state something very simple can be enough. When there are already players in the given market, something viable can be a lot more complete product.
Still we history has shown that consumer tend to value good user experience over bunch of features. Just look what happened with iPhone, when it first came out, it did not have copy / paste, no multimedia messages, no 3rd party apps and hardly anything we take for granted now.
To get started we have to make assumptions about customer demand and needs. The Minimum Viable Product helps us validate these assumptions. There various ways our assumptions can be wrong:
The customers don’t want given product
our assumption of minimum viable is too restricted and is not useful for customers
the customers would settle less than was originally thought
Only number 1 is clearly result capable of killing the business.
Harvard Business Review offers two versions of Minimum Viable Product: validating and invalidating. This post touches mostly validating minimum viable prodcut. You can read the whole article here: http://blogs.hbr.org/2013/09/building-a-minimum-viable-prod/.
The good people, the important people are called to meetings a lot, they spend lion share of their time sitting in a meeting room with other important folk. They are always busy and occupied. They spend their time in important meetings, because they are so important that the meeting would be meaningless unless they attended. As a driven, motivated and ambitious being you also want to be considered important for the company. After all having your plate full meetings conveyances your importance to company and is by far the most important metric for your own career development.
“I participate in a meeting, therefore I am important”. –Rene Descartes
They have their calendars so full that they don’t have time to do actual work so they sit at the meetings with their laptops doing the work they should have done days ago and in the process don’t actually pay attention to what ever that meeting was about. This will prolong the meeting meaning that they will be late for the next meeting which will then prolong even more. Then follow up meetings will be programmed. This vicious circle tends to get worse and it can even be contagious. Some people tend to invite even more people to these meetings robbing them the precious productive time and it is surprisingly hard to say no to these invitations.
“One cannot participate twice in the same meeting” – Heraclitus
Busy people are not available people .They are not there to help and tutor younger colleagues, they are not present to offer their opinion or expertise when problems arise. They are too occupied to do their jobs.
“We participate in the best of all possible meetings” – Gottfried Wilhelm Leibniz
Unfortunately busy people does not equal productive people. The really productive people fill their calendars with nothing so they have time to actually be productive. These productive people posses the most productive commodity: time. Time is what they need to get the job done.
Agile or Lean or Agilean? There is a lot of confusion about the relationship between these two . Some people say they are completely different, some say they overlap and some say lean startup is a fusion of the two.
If we take a look at the Lean Software development principles according to Mary Poppendieck in her book on Lean Software Development:
- Eliminate Waste
- Build Quality In
- Create Knowledge
- Defer Commitment
- Deliver Fast
- Respect People
- Optimize the Whole.
Then we take a look at the original Agile manifesto.
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over
processes and tools
Working software over
Customer collaboration over
Responding to change over
following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
There of course quite a few things that overlap it we dissect these statements.
“Eliminate Waste” is the principle of getting rid of things that don’t produce value. Retrospective is a very recommended practise where teams try to hone their process and see what is working and what isn’t. Essentially getting rid of waste.
“Build Quality In” seems to have similar qualities to “Working software”. Also Test Driven Development is a very common technical practise usually considered an “agile” practices. Also Poppendieck agrees this is essential to Lean when applied to software.
“Create Knowledge” underlies the importance of communication so that people know what they are doing and understand the problem domain the same way. This is again very essential to agile as well. The manifesto states that “customer collaboration over contract negotiation” which can be understood as a way of creating knowledge.
“Defer Commitment” has it’s relative in the agile world. Let’s take scrum for example. You only work on the items with top priority in the product backlog. You only work and talk about just enough items to fill the sprint backlog. All the rest are just titles. Product backlog item is just a promise of a further conversation.
“Respect People” is clearly similar to the first phrase of the manifesto “Individuals and interactions”. Both approaches put a lot of importance to people.
“Optimize the whole”. This might actually something where there is actual difference. Agile is very open to transparency and openness and scrum is very open to everyone attending defined practices like daily stand-up to listen or management participation is recommended for retrospectives, but still it is generally very concentrated on the development team.
Agile and Lean might not be equivalent, but they certainly have quite a lot in common when it comes to values, principles and even roots. I consider Lean to be an approach to improve effectiveness and it does have roots in manufacturing industry. Primarily Lean is about getting rid of things that are useless – in lean terms – waste. Agile on the other hand come into being when 17 experience software professionals got together and talked about giving a common name to practices they had found useful. Practises that were similar in nature: reactive, adaptive etc. A lot of those things also had roots in manufacturing industry, especially in the way Toyota worked and still works.
Saying Lean and Agile are not equivalent is one thing, saying they have nothing to do with each other is another.
Scrum is definitely the most successful agile methodology so far. Everywhere you go you can now hear the word scrum in the most absurd context. Scrum roles and titles have partly replaced more traditional titles.
Scrum becoming mainstream is not only it being superior to any other option. Today there are two major organizations offering their courses and certification services: Scrum Alliance & Scrum.org.
Kanban is not as far with certifications, but the kanban community seems to be heading that way as well. Last year the Lean-Kanban University started to hand out accredited kanban trainer -badges and more recently accredited kanban coach -badges appeared so the writing on the wall is clear.
Certifications might not be much to be proud of these days, but does not mean the classes are not any good. Still these classes are as good as the teacher and I for one got very lucky with the instructors I had in my both certified Scrum classes.
I had the privilege to attend a certified Scrum Master class by Jim Coplien and he is one of the so called gatekeepers of the official Scrum guide and he´s been around since the digital stone ages. As expected his expertise exceeds far beyond scrum and I still consider it the best crash course in agile. Later I had the chance to attend Scrum Product Owner class by Gabrielle Benefield and that also was as good as a two day class can be. Not because of Scrum, but because of the vast amount of experience she shared with us was not only enlightening, but also inspiring.
If my memory serves me correct, I attended the first official Kanban class by David Andersson in Finland. Kanban definitely has merit as a methodology, but you could still tell that the course content nor trainer was not as polished as the aforementioned Scrum counterparts. Now more and more Kanban trainers are popping up and with more trainers and organized courses the courses and their content will get better due to more experience in the kanban community.
Classes are as good as the trainers and the certificates are just a semi necessary by product. Certainly classes by different trainers have similar agendas, but the trainers definitely have more than enough room to accommodate attendee requests and add their own spice to it.
Still certificates themselves should not be considered essential. After all you can get a bunch of certificates even from w3schools.com. The bottom line is that although the certificate might not be much to brag about, these well established classes can still provide a lot of value.
There are certain things that you seem to miss just when you don’t have them. After experience some rather obvious problems in communication you finally see how much you value the. Last fall I was part of a team very we simply did not share a language. Officially the language was English, but one member of the team was less than proficient in it and prefered to talk in his native tongue unless we were in direct talk or in an “official” meeting settings.
This of course lead to situation where a lot of communication in my team was conducted in a language that I personally did not understand. Not only did I feel left out, but I also missed out on a lot of something that I call “passive” communication, I did not know what they were talking about, whatever the problem was, what conclusions they got etc. All that is hugely important as only a fraction of all relevant communication in a project happen during “meetings”. Meetings should be avoided anyway.
Small but important design decisions happen throughout the day and these are the decisions that in the shape how the project ends up looking, specially from the code point of view.
Geographical distribution is equally bad or sometimes even worse. It is very easy to disconnect from rest of the team and get sucked into your own silo even more. The counter this it is essential to communicate at least via instant messaging channel that should be widely used within the team and the nature of the banter should not be too official. Jokes should fly and funny links passed essential. The team needs to bond.
This leads me to argue that working from home works best in cases where the team is well functioning and barriers of communication are already removed. Working from home does have some obvious benefits
- less time in commute
- calm environment
- quality of life can be better.
I am not against that, but I think that at least at the beginning of a new project or when joining a new team the team should sit together to get to proper and productive mood.
Well, not any situation is perfect and as a professional you always have the responsibility to do your job and contribute even if not everything is perfect. Voicing your concerns and making your criticism is the first step, but people who actually act instead of just complaining are so much more valuable. Nobody wants to sit next to a cry-baby.
Too much is too much and sometimes it just might be the best thing to take a cue from Daniel Temme, but just don’t do it too often. I have personally discarded a client for having too many jobs during the past 5 years.
No matter what line of business you have, you always want to have good people. People who can make things happen, who are willing push for solution and questions that you didn’t even think in the first place.
I don’t have fixed list of things I look for, I rely heavily on my intuition how I feel about a candidate, but there are some things I can list and that is what I will try to do here.
I want people that I want to work with. I want people who can contribute to a good atmosphere where people feel comfortable to talk out, provide feedback and ask questions. They should be more of a catalyst than a handbrake for communication. This social matchup is essential.
Secondly the right kind of people tend to do stuff on their own, they contribute to the community. They have github accounts, they participate in user group meetups, they don’t limit themselves to one language. They read books and blogs, they follow interesting people on Twitter. They have opinions and are not afraid to share the. They are curious. Curiosity is a virtue for software professional.
Technical skills and understanding
What separates talent from the rest and this is rather clear even in more junior candidates is that they want to understand how something works. It’s generally not enough to read tutorials and make slight modifications. Good people tend to know know also how things work beneath all the magic of Django or Rails etc.
How do I do it
First would be just talk where I try to scan how well the candidate is up to speed where things are in the software world and how well he/she understand the concepts. I always try to crack a joke or two to relieve the atmosphere. An interview can be a nerve wracking experience especially for younger people. If I can get the candidate to relax I’ll get a better read what they are all about. Before going on to the exercises I make sure the topic what is considered “good code” is raised.
Having the candidate bring over a code he has made and having a chat about is always good. Specially if it’s rather old then questions like “what would you do differently?” or “what do you think about your code now?” make for good conversation.
Then I give the candidate a small piece of fairly poorly written java code and set the question in a way that an intern or trainee would ask for feedback for that method. Good candidates tend to find bunch of things wrong quickly and the best ones also know the difference what is clearly wrong and what is more of a matter of opinion.
It’s time to walk the walk
What happens depends largely on my feel of the candidate so far. With juniors I go for a pair programming exercise where I sit with them and do something like a simple coding kata to see what it would be like to work with them. How they react to feedback and suggestions and especially what kind of suggestions they have.
For more senior candidates I give them a existing piece of (crappy) software and ask them to implement a feature. The software is of course poorly tested bug ridden mess. Good engineers quickly see what a mess and illogical piece of crap the software is and don’t waste time refactoring most of the crap before trying to implement a then trivial new feature.
If I’m not quite sure or how it went I still do the pair programming stuff I usually do with the more junior candidates. Sometimes the refactoring exercise does take a bit too long and the setup might not be familiar to some candidates (wrong keyboard, wrong IDE etc), but when we work on a small project together I can easily guide and help through the most common simple downfalls like shortcuts etc.
I tend to make some controversial comments or rather stupid design choices to see if the candidate picks them up. The good ones always eventually do, it might take some pushing or going quite extreme, but they finally do 🙂
For a while it really seemed that these exercises were too hard, but finally we got some good candidates that actually breezed through these and made them like just as easy as I thought they would be.
As you can certainly imagine this is a rather time consuming process and takes a lot of time. I don’t always have time for everything and almost always these topics are scattered into many small sessions.
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.
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.
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
- As doctor take out scalpel and make the cut (1min, 30 sec)
- As doctor spread the cut (30 sec)
- As doctor use clams to get hold of the appendix and Then cut it out (2 minutes)
- As doctor use the needle the sew the stitches (4 minutes)
Me: I´ll even allow 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.
… 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
While watching rerun’s of HBO:s acclaimed miniseries Generation Kill it occurred 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.
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.