This turned out to be longer than I expected therefore I will be breaking it into two parts. The second will be on Top 3 things I have accomplished and why that may matter to you… Expect it in the next few days.
Top 3 things I learnt in 2013
Last year I had finally an opportunity and pleasure to meet Tom Gilb, who came to Warsaw to speak at AgileByExample 2013. Just after the conference Tom did a one day workshop on his EVO project management method. I was struck by his main observations about our (software development) industry, to name a few:
- goals (and success) in projects are very often defined in a way that is imprecise and does not allow measurement and tracking, like To improve usability. But what does it mean? And how will it be measured? This accusation resonates with me a lot – I blamed myself so many times of starting a project with poor (or even no) tangible goal other than Deliver a product according to spec (which is very rarely a true goal of key project stakeholders).
- Requirements (as most people understand them) are not requirements but designs. A feature to be implemented is not a true requirement. The requirement is a business goal while a feature in a system is a way someone believes this goal can be achieved. Oh boy, this one is a real pain. When doing outsourced projects for enterprises so often vendors are presented with a spec to be implemented (as cheaply as possible :D). So many “requirements” are there without any real reason. I personally believe that putting too many requirements in design documents is currently the single most important source of waste in software projects in enterprises.
- The architectures or designs in projects are rarely estimated on their cost side and expected effects before they are implemented. This is definitely my experience. I have been involved in an architecture design phase in many projects (recently mainly as a passive observer in offer processes) and I think hardly ever teams prepared two (or more) versions of architecture with cost/benefit analysis. Almost always architects prepare “the best” architectures in their own ivory towers and very rarely they are being measured on the actual effectiveness of those architectures.
- The Agile methods are focused on delivery in projects and lack in support on the product management part. Sure thing, I think no one disagrees that e.g. Scrum provides no practices on product backlog management.
I think I can sum Tom’s points just saying that some most important decisions in projects are made based on gut feelings. Tom claims we should be engineering our systems and that engineers use tangible goals and measures and targets. Just imagine a skyscrapper architect supporting his design saying that he’s not going to do calculations, he believes it’s the best architecture for the building. Kids playing in a sandbox building castles in a sand can afford that. Serious software engineers responsible for the delivery of projects worth thousands or millions of dollars (not mentioning infamous 2013 health.gov project – the most expensive IT system of all times) cannot.
EVO is a management method authored by Tom Gilb built on top of such observations. It’s been used by many organizations (incl. NASA, NATO, Citigroup and many more) for product, project & program management. I believe the basic idea is really simple: pick an important stakeholder in your project, find an area important to her, decide on a metric, find a way to improve this metric by 1% in a week. Repeat. Then start experimenting with setting targets for your metrics and including more stakeholders. If a design you implemented has no or even a negative impact on a metric – drop it and try something new. Drive your project using metrics and numbers not gut feelings.
I believe this approach can work in many areas. I would say a similar concept was described by Jurgen Appelo for bloging (here). Fellow agilistas from Agile Warsaw community (Marek Kirejczyk and Michał Parkoła) are experimenting with using EVO to drive company growth (the topic they covered on a recent Agile Warsaw meeting). I am looking forward to 2014 to see how EVO can be used in my context.
By the way – in general EVO is very similar to the Lean Startup.
I had another great learning opportunity when I participated in the Accelerated Agile course by Dan North. Dan is known for laying foundations for Behavior Driven Development. At the same time he has great record of public speaking so when I found out he is coming to Warsaw with a course I quickly applied. The course presented great deal of patterns for team work. Dan claims they can help an experienced team go beyond mainstream agile processes. It’s hard to decide on a couple of these patterns to recall here, but let me present two that I believe are easy to be implemented in any team:
- Code Critique – many teams practice code reviews regularly. And I believe it was not only me who struggled with deciding how much should be reviewed. On one hand one could review every piece of checked in code but (while definitely improving the quality) that’s clearly an over investment. On the other hand, when one makes a decision, whether a particular commit should be reviewed, it’s easy to overlook some more serious problems. Another thing with reviews is that usually they are done in pairs, which limits learning opportunities. Code Critique is an easy practice that can address these issues. The basic idea is that the whole team regularly (e.g. weekly) gathers for a timeboxed meeting. First, everybody briefly presents some most interesting code they’ve done recently, either most difficult/complicated, having some nonobvious business logic, or just presenting some learning opportunities. After such brief presentations the team decides on one or two things they want to study together more deeply. The whole concept resembles a film critique club – people together have a discussion and exchange their observations and thoughts after watching a movie. I believe it’s a nice practice to try, one that doesn’t require any preparations.
- Spike and Stabilize – another practice, that deals with coding itself. I believe that one common denominator in many (all?) Agile methods is that quality of the product is not negotiable. Developers should be producing high quality code all the time to ensure stable velocity (limit velocity drop due to increasing technical debt; BTW – you can check a really nice article on Good and bad technical debt by Henrik Kniberg here). Dan is pointing out something that will be hard to accept for some hardcore code craftsmen – often early investment in quality is a waste, especially if you are exploring some new technology. Dan suggests that a more effective approach in this situation is to write production code quick and dirty at the beginning. In other words – do spikes on production code. Why on production? We get most and best feedback from real users using real systems. But Spike and Stabilize pattern has the latter part too. After some time when the spiked solution proves to be solving the right problem it needs to be stabilized. This part requires discipline but noone ever said it’s going to be easy.
One important disclaimer needs to be made. The patterns/practices Dan was presenting (like the two I mentioned) are of course context dependent. When used inappropriately they can do much harm. Dan used Dreyfuss model of skill acquisition to describe that – a Novice needs clear rules to follow (like always use TDD or always check in high quality code). A Competent professional knows (feels?) when a rule can be broken.
Last but not least – probably the most profound takeaway from the course was the discussion which started when Dan asked a simple question: Is software an asset or a liability? Dan answers that the software itself definitely is a liability. The asset is a business capability the software provides, but as long as we can provide the same capability with less software, or maybe even no software, we should do so.
If you have an opportunity to go to Dan’s class I would strongly recommend doing so, provided you have some experience in software development and agile methods. It’s also worth noting that (at least IMO) the course is addressed towards senior developers rather than project managers, scrum masters, product owners, etc. But before you do, start with visiting Dan’s site (here) and check his blog. You can also go and check one of his Accelerated Agile talks online (e.g. here).
Power of personal vision
In November of 2013 my wife suggested I should enroll on a course at Coursera.org on Inspiring Leadership through Emotional Intelligence. EI is something I was exploring and focusing on for the past year so I thought I should give it a try. The course turned out to be definitely worth the investment and I highly recommend enrolling to another edition in the future. Here are some takeaways from the course:
- create a Personal vision – imagine your perfect life in 7-10 years. Don’t focus on a short term perspective (like 3 years) as this makes you plan rather than dream. And a vision is about dreams. There are many approaches to creating the vision, like:
- list things you would like to have done before you die. Remember to be specific (if it’s travel – then where?; if it’s learning a foreign language – then which one?) and to list many (like 30) things to go past some obvious ones.
- imagine your day in 7-10 years and write down how it goes. What are you doing and with whom?
- imagine you won 50 mln $ on a lottery. What would you do and how would your life change?
After you do it reflect on your emotions. I spent some time on that exercise. What I found was that most achievements I want to make are related to my personal life, while imagining a day in my perfect future made me focus on my professional life. That was an interesting observation for me.
- Validate your vision in your relationships. We all have a lot of social relations. I believe two most important are with your significant other and your company (as they are harder to change and consume almost 100% of your active time). When you have created your personal vision you should check how well it fits in a vision of your company and with your partner’s. For example, for your personal relationship Richard Boyatzis (the professor running the course) recommends creating three visions – one for each partner and one common. Another thing you can do is to reflect on your key relations and decide whether you believe they are more resonant or dissonant; and what are you going to do with the dissonant ones (a simple yet powerful exercise).
- You at your best – this is a form of 360 assessment. Ask 10 people that know you well to tell you about some situation when you did exceptionally well, namely – you at your best. Listen and take notes. When you start getting some feedback look for patterns. Don’t do it with your dissonant relationships.
You can find more on the course on its Coursera site (here).
Why am I telling these?
You might wonder why do I share these thoughts. An important point in the Leadership course I mentioned before was using self-reflection and being mindful as a way to build and retain your personal motivation. And motivation is something we all need. The turn of the year looks like a perfect moment for summaries and practicing mindfulness.
So, if I may ask you to do one thing after finishing the read: spend half an hour and think about your 2013 experiences. What did you do? What did you learn? Focus on achievements and successes, even small ones more than failures. At the end reflect on the emotions you felt when doing this exercise.