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.
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.
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.
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 sound like an 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 the future.
“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.
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.
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.
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 labelled 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