I’m back from what was the most intensive event I’ve been to in a long, long time. Lean Kanban Central Europe (LKCE) has a special place in my heart. If I were to pick one from all the global communities, it would be the Lean Kanban community. LKCE is consistently exposing me to new ideas. It is a place where my network of connections systematically grows – a list of people who I have first met there is so long that I won’t even dare to try to mention them all as I would inevitably forget someone.
Last but not least, I’m the part of the program board so there’s a little bit of my input in how the events have been shaped over the years.
This year’s conference (LKCE14) was special in a way that we decided to have tracks. On one hand that meant that the program board members had a lot authority in shaping how our parts of the event looked like. On the other it meant quite a lot of work during the conference.
That’s not all. I had two presentations at LKCE14: a regular one on leadership and a pecha kucha on learning.
I am a happy bunny though. I’ve had a lot of great discussions. I’ve met new people and had a chance to catch up with some old friends. Even though I had limited freedom in choosing the sessions because of my hosting duties I managed to attended a bunch of great presentations. I ran a leadership track which worked out exactly the way I wanted. I’ve learned a ton. I spent a couple of days at a workshop with a guy who knows more about product development than I will likely learn through my entire life. I had an insane amount of awesome German beer.
So, here are a few of my highlights of the event.
Martin Jensen ran a fantastic session on organizational culture. If that wasn’t enough we went even deeper discussing the topic late at night in a hotel bar and, obviously, having beers.
Organizational culture was one the themes of the whole event. There was Martin. There was, awesome as always, Kathrine Kirk. There was Marc Burgauer, who I had pleasure to host on my track. I did add my two cents worth with my presentation.
The leadership track. OK, I am mentally programmed not to brag about myself and to focus on the areas of improvement. I can’t help it though – when the track was finished I felt really proud of myself and happy. This is also an opportunity to thank Esther Derby, Liz Keogh and Marc Burgauer for being my guests and speakers on the track. You really made my day. You’re awesome.
Don Reinertsen’s workshop. I’ve been his fanboy for some time already so I had a lot of expectations. Don definitely matched them and went even further. What I will say now is that every organization that builds products should send product people to one of his workshops.
Pecha kuchas were, as always, one of the best moments of the event. The very constraining format of the session results in a lot of creativity and very focused messages. And Markus Andrezak produced pure magic by hosting the show. If not for him my stress level before popping up on the stage would likely have been unbearable.
One of the measures I use to track how much I liked an event is how little I slept. At LKCE14 I went below 6 hours a night. As if that wasn’t enough I didn’t have a single hour of wake time when I wasn’t doing something related to the event. It was super-intensive indeed.
I am already looking forward to Lean Kanban Central Europe 2015.
You have a picture. You’ve got one minute to see your picture. Describe all the things you can see in the picture and explain what you think is happening.
Ok, ok let’s just stop this exam right now, one minute is not enough time to finish this task… Why? Because Agile Testing Days 2014 was an AWESOME event! and I just can’t describe it in one minute. But the image attached above (made by our <3 Gosia) still will be pretty useful, because more or less it presents what I’ll remember from this year’s edition of ATD14.
In the background of the picture I can see the ATD2560 banner and a flying ship…..
Yep, ladies and gentlemen we are in the future. Why? Because the motto of this year’s conference was “The agile movement is thriving! How does it affect the future of agile software testing”. Opening keynote prepared by Lisa Crispin and Janet Gregory was literally and figuratively related with the future, guess why:
Star Trek anyone? The main thought of this talk was the hypothesis that ‘We can’t predict the future’. But Lisa and Janet gave us a few simple tips of how we can adapt to changes… become a shape-shifter to adapt to ever-changing needs! You can ask how can I become shape-shifter? The pattern for this is really easy… learn new skills, follow up on new technologies, constantly improve your communication skills and remember about quality of the product will still remain as the main part of our tester job. The ladies also touched on one thing which, over the last few years, I’ve been applying to my daily work: giving customers what they need, not what they ask for! The shape-shifter skills listed before are pretty damn useful for the realization of this task. You need to communicate with the client if you want to discover what he needs, you need to understand his product, you need to present new technologies to the client and finally you need to deliver a high quality product for him set in business value reality.
The banner is placed on some kind of ancient Greek building…
So, you can ask so where are we? In the future or in Ancient Greece times. No worries we are still in the future, but David Evans at the end of second day reminds us that we should respect old, traditional testing values described as the pillars of testing. David on the stage raised and described a Testing Temple.
At the top of this temple we should place the product of testing: Confidence, which is supported by safety and courage. All of those things should be propped up by the stable pillars of testing such as: Stronger Evidence, Better Design, Greater Coverage, Faster Feedback. Each pillar represents a measurable, valuable quality of testing. Our confidence should be raised by getting Stronger – Better – Greater – Faster! Our temple was almost ready and all that was left was we just needed to lay the foundations. David decided to base the Testing Temple on three types of foundations: Team Foundations, Capability Foundations and Technical Foundations. At the very bottom part of this temple we should place Leadership and our Engineering Discipline.
The temple model presented by David for me seemed to be s sorting, organizing and a reminder of what testing is. During our daily work, activities it’s really easy to forgot about our testing roots, core values and sometimes you need to rebuild your Testing Temple. A really inspiring keynote presented by an exquisite speaker.
Someone is jumping out of the box….
The morning keynote presented by Antony Marcano who talked about “Don’t put me in a box” was a bomb!
How can you answer simple question such as what do you do?
Most of us describe ourselves with noun related keywords about our job, developer, tester, plumber, forester. Our nature is to put ourselves and others into ‘job title’ boxes. Valuation and evaluation based on job title is still something that still happens, same as calling people resources. Stop. Don’t do this, DON’T PUT ME IN A BOX! Because it gives the message that they can be thrown away. Don’t be a tester, coder, designer, don’t be a machine which is plugged in when there is work to do. Try become a T-Shaped person. And remember! Focus on performing and remember “(…) quality comes from people, not process.”
(…) and this guy is holding LEGO and TDD flags.
And the (my personal) award for the best workshop goes to… Bryan Beecham & Mike Bowler! Well this time I’m a little biased. I LOVE LEGO so these two gentlemen had won this competition long before ATD2014 started, but during the 2 hour workshop they proved that they deserved it. During the first part we learned how to write TDD scenarios from scratch. On my table we tried to build a LEGO house, so:
RED, GREEN, REFACTOR,
RED, GREEN, REFACTOR,
RED, GREEN, REFACTOR,
and we have a ‘fully’ functional house!
Learning TDD using LEGO very well illustrates the process of building failed tests. The workshop hosts with subsequent exercises showcased, more and more aspects of TDD. The second part of the workshop was focused on refactoring. This part of the workshop was more directed to developers. Even though I am not working much with code at Lunar Logic, Bryan and Mike somehow caught my attention. The last part of this workshop was a kind of exercise on the scope of cooperation. Together with other workshop participants we tried to build: product → container → truck → crane → port. This exercise showed us how important communication and adapting to new requirements on all levels of building a product is. Even I learned a lot about TDD and refactoring, another lesson from this workshop was the recipe of how to run an excellent workshop. Good topic, charisma and… LEGO!
Yep, the image definitely describes the future, we don’t have robots nowadays, are we?
The last talk from Daniël Maslyn’s focuses on “Agile Testing for Future Robotics”. Daniël presented some potential paths of how Robotics can develop in the future and how Agile can shape the future of this science. Daniël asked some key questions about the future of testing. How we can adapt as agile testers to the Robotics industry? How will we test future: AI software, hardware frameworks, devices and complex scenarios for systems involving Robotics? This talk was a nice follow up to Lisa and Janet keynote from the first day, and made me realize once again during this conference how important it is to learn and absorb new technologies.
Conferences for me are more like recharging my batteries. I am looking there mostly for new inspirations and ideas, I want to learn there. After this year’s ATD I am fully recharged, but it’s time to come back from this future world and reconsider how I can prepare for what’s to come, and how I will discover myself as a …? Who knows :)
From time to time somebody asks me if I’d like to try something completely new or different. And though I’m not a very daring person, I say – yes. It was like that when I was seven and my mother asked me if I wanted to go to the music school and play some instrument, and then I devoted half of my life for it with the belief that it will last much, much longer. It was like that some time ago when I was asked by Paweł if instead of going to the programming conference, would I go to Hamburg for Lean Kanban Central Europe 2014? And I answered – guess what. And it was a good answer.
It would be impossible to cover all the thoughts I had the pleasure to listen to, since I’d have to write an entire essay about each session, but I’ll try to share at least a few of them.
First steps on a new board
The journey started with a keynote presented by Mary Poppendieck with an overview of commonly raised topics in the agile world. So, she was talking about what makes a winning team. About how it looks in a military model and how it should work within the team. How it is important to have awareness of the overall situation, goals, timing, but also on the constraints of each level. About how reliability stems from mindfulness. And also that we should change from being a delivery organization into a problem solving one. A nice talk to start with.
And then came problems. And their beauty brought by Arne Roock. What is the problem? Arne presented a definition of the gap between the perceived and requested state which lead to the conclusion that to solve the problem we can either change our perceived state, our desired state or our perception.
In his talk Arne presented to us why, when a problem is encountered, we should avoid jumping to conclusions and rather stop for a bit and start asking ourselves “why?” and this is a very important question. Not only WHY something is wrong, but also WHY we want to fix it, WHY we failed in preventing a problem. And this is important if we want to be better in the future, not only using the same known solutions for the same known problems appearing over and over again. As a helpful tool to do this he briefly presented the idea of A3 thinking which was more deeply covered later by Claudio Perrone.
The following talk by Martin Jensen treated about culture as THE competitive advantage.
A combination of well understood structure and culture provides internal efficiency and external attractiveness. That’s why we all want to work in companies with a strong culture. Even if you were to copy structures, methods, rules from other companies, you can’t copy their culture, though. But what is culture? Slogans written on walls? Definitely not. It’s about feelings, about what people think when they arrive at work, symbols, about how people behave. But it is not easy, values have to be described and understood, even everyday behavior needs discipline.
And then came two brilliant talks which actually made me truly depressed because of how often we do fail in preventing our clients from hurting themselves. But the good thing is when you know that the client will ignore your questions and suggestions there are authorities which you can send them to:
No 1.Joshua Arnold – Value and Urgency: The power of quantifying the cost of delay.
In a time when everything is on demand, where every feature is a must, priorities start conflicting. And in this case, every week of delay in launching a project is causing lost of potential income we have to realise that it’s not only the product will start earning later, but in the longer perspective it won’t be able to reach its potential level at all and in the context of periodical products we may not fit the given period of time. It creates to the cost of delay which can be measured per week and nobody likes to watch income passing away. That’s why priorities are important, knowing values – basically measured in the users willingness to pay – and when to start something or when to stop.
Another thing are black swans, those features, there are not many of them, which may have the highest cost of delay. If you identify them, you may be able to make much better decisions in terms of value and urgency.
Risk forecasting have several sources such as: work, dependencies, throughput. For all of them you need data, and that data comes from the people – a terrible system to manage. People are biased, even expert opinions have to be checked. But even if they bring not necessarily expected data don’t ever embarrass them, you’d destroy any chance of getting reliable data from them again.
Another thing are estimates. We – developers – usually don’t like them, they’re either too optimistic or not acceptable for the client. Knowing the past is very important, you can then make your forecasting more contextual. Even then estimation should be trained and practiced and it should express uncertainty, so instead of using point estimates try using ranged estimates. They are, by the way, much more honest.
The day was closed by Karl Scotland talking about kanban as a whole system which has its interventions and impacts, so we could look at it from very different perspectives. Within interventions we have studying customer needs, delays and feedback, sharing learning by visualizing it, stabilizing the process by wip limiting – for this, the definition of ready and done has to be clarified – and search, measure what may be improved and why. From the impact side – flow, potential and value are the ones, which come.
A brand new day
The next day came with a keynote by Henrik Kniberg and looking into the connection between problems and projects. Quite often people think that to start a successful project you need a good idea but it’s not what it should start from. It’s rather an unsolved problem, which has to be well understood. Then you can think about stakeholders and their needs, and simply iterate until mvp. Henrik was also talking about the distance between makers and users and how it is important to minimize it.
Than, starting from the point where a traditional hierarchy is a flow of blame in which we all are victims, Claudio Perrone showed us that as agile is focused on process and tools, we have to remember that those tools are FOR individuals. And as solving problems is a manager’s and programmer’s everyday life he described how the A3 thinking method may be helpful. It looks pretty simple, just take an A3 shit of paper and follow the exemplary schema – why do we consider something as a problem, what is the current and expected state, what possible steps we may take and what prevents us from doing them. Don’t forget to ask the 5 whys here, it will give you the chain of the facts. Then go to countermeasures and required steps, and check them so you can end with some conclusion about what to do next. Simple, isn’t it? Just remember, do it with a rubber and pencil, check often with somebody you can treat as a mentor, and share what you learnt, make it visible. So it’s not only about solving problems, it’s more about making problem solvers, since it’s not the matter of what we do but what we learn by doing this.
Depth is coming
Want to hear about politics in a lean / agile environment? Be aware, Katherine Kirk is on her way.
Corporations encourage psychopathic behaviors on all levels which may lead to psychopathic leadership. As we know, a psychopath doesn’t know compassion, unfortunately normal people can turn it off too. It all may be seen in internal politics. And politics may be even increased by lean and agile. That’s where going from a static structure and hierarchy to a rotational one may help.
Also when using agile tools we have to remember that our approach will change the outcome. Moreover, we have to know that we are in a constant state of delusion, and we have to get rid of the “I know” attitude and simply accept it. What we can do is investigate reality by looking into many sources and notice that intentions are not necessarily coherent with outcomes which causes discrepancies. What’s more, we have to test our ideas, contemplate and seek vipassana insights.
So to cool down politics follow this strategy: take a big breath, equanimity, transform understanding into insights, practice compassion and be curious, patient, sustainable and have a bit of grit.
I’m not sure if the lack of questions was because it was so obvious for the audience or rather that they needed some time to see how deep it was.
Captain, captain, may I lead?
After that experience I choose to listen to Esther Derby talking about leadership on all levels. Lets define a leader. Somebody who says “do what I want”? Nope. Somebody who inspires, uses charisma to encourage people? A bit closer but still not yet. How leadership is defined not only in this talk, is G. M. Weinberg’s definition as a process of creating an environment in which people become empowered. So when thinking about empowering people some things are important. Knowing all what’s and why’s both for the small and big picture, which translates into clarity, creating proper conditions since people want to do their work and organisation should simply support it, and remember about constraints so people know how and when they can act and what they can’t do. And if there is any bounded autonomy it should be articulated so people know how to move. So no matter on which level, steering, enabling or front line all these three: clarity, constraints and conditions have to be known and coherent in length and breadth. It will give transparency and trust. It’s not easy, it can’t be achieved fast, but it’s worth the effort.
In the next talk Liz Keogh took us on a journey through the metaphors we tend to use and how they affect our everyday work. We treat our activities as a substance, as something we can take from one desk to another, put something into it, like into a box, and then move it outside. These are very persuasive. We talk about code quality as if it was a tree which grew here, but what we mean is coding quality is where we would like to improve.
Another thing we do is breaking things into small pieces, and then to even smaller to make them go faster and faster, but after joining them back not necessarily we get the whole thing again. We are definitely more than the sum of our parts. It’s interactions which makes the whole. And interactions between people means relationships. Developers, testers, users should not be separated. They should be connected, they should interact. So, paraphrasing Liz, just think what would happen if instead of working FOR people we would start working WITH them?
Ride the power, gambling man
And then, Marc Burgauer asked us: What’s the worst that can happen? He talked about trust, about how it is important, and how it is hard. If trusting yourself is the most neglected type of trust, how we can achieve it with others? A command and control attitude can bring only loyalty through fear and as a discharge of discomfort it leads to the blame flow. Trust is not a prerequisite, it’s an outcome. It comes from everyday commitments and transparency, from sharing your world and meanings. It’s also about failures. If you haven’t failed you haven’t tried hard enough – it’s one of the mottos. If you are not allowed to fail, how hard will you try?
Ride the power was another thing Mark talked about. It’s about the mindset you need, when you are attacked and it’s mainly about four things – re-expressing your position, listing points of agreement, checking what you learnt and presenting your view inside of shared context.
The whole conference was closed by Don Reinertsen’s keynote about variability and robustness. As an opposite to fragility we try to achieve robustness, both, passive and active with more feedback loops. With the latter we still have to remember, that some feedback loops may hide information, so checking more indicators than the primary one is very important. And don’t rely only on watching statistics, go and talk to devs. But this is not everything. We live in a stochastic world and in many cases variability is considered as something bad. By being robust we want to absorb variability. But what if, with more options, we start performing better than without, if more options gave us more outcomes? That’s the real anti-fragility. That’s why we should exploit opportunities, check options and bypass obstacles, simply – be a smart gambler.
Back on the mainland
This was definitely a wonderful experience. I was not able to attend all the talks, you know, conflicting priorities. I hope they would be available on videos soon – I recommend you to check the conference page for this. And if you’re still not convinced, check #LKCE14 too.
Some people asked me if there was a sense for me – a developer – to attend such conference or if it means that I’ll start to be a manager now. As for me this knowledge is not only needed for managers, product owners, or CEO’s but for developers as well. We work closely with our clients to embody their idea of a product. We talk with them every single day. Often we intuitively know that what they want us to do is just so completely wrong. And only with our intuition, even experience, we are only devs. Why should one listen to us? That’s why having such a set of tools and knowledge is also important for us. Actually, that’s what I would teach kids at school.
So, I jumped into an unfamiliar boat and I’m really curious where this cruise will take me.
Two weeks ago I visited Gliwice in order to be a coach during Rails Girls Silesia. It was my second Rails Girls event (the first one was in April, Rails Girls Youth in Krakow). What I like the most in Rails Girls is that it’s so flexible – you can easily make it work for everyone, no matter how much experience this person has in programming.
I think the formula of the workshop is really well-thought-out. There are many approaches, and Agnieszka covered them during the Friday meeting for coaches. When it comes to preparing the environment on girls’ computers, most people use Rails Installer, as the leading platform during workshop is Windows. But it’s also possible to use some online development tools, like Nitrous or Cloud9 (it even offers Vim mode!).
When all is set up, some start with TryRuby or even Scratch, just to make girls familiar with the basics of programming. Some jump to generating the application and its content right away. Another way is to start with static HTML files, and step by step turn them into a Rails application.
What did the workshop look like?
Rails Girls Silesia team prepared everything – They organised the place, provided food and drinks, and made t-shirts and stickers. They deserve a Kudos! The first day we set up an environment, but also had a chance to get to know our teams and decide what to do during workshops. I was working with three amazing girls – Ula, Iga and Gosia. They decided to create an app which helps in managing expenses and income. They wanted to have multiple users, various bank accounts and categories of operations – sounds pretty advanced!
My team started with tryruby.org. Then we generated an empty app and talked about the basics of Rails framework, its main components and what they are for. After that, we wrote down features we wanted to implement, chose those, which create a MVP (Minimum Viable Product), and prioritised other features. The next step was designing database and relations between models.
The second day we started implementing our application. We generated the first set of components with ‘generate scaffold’ and continued with modifying the content. We had some environment issues, spent some time debugging, but most of all, had fun watching how the application is closer and closer to its final shape. As a part of the schedule, there was a time for lightning talks and Bentobox (an exercise, which helps to grasp the structure of web application and technologies that are used).
Does it even work?
Yes! But, of course, no one will learn programming in one and a half days. The goal of Rails Girls is not really instant turning girls into programmers, but rather, it is to show them that programming can be interesting, fun and not all that difficult. It is also to give them examples how one can learn programming; There are lots of great resources online, but it’s easy to get lost.
Another important aim of Rails Girls is to show them the path from beginner to developer. Sharing personal experience in creating software, especially how it started, gives participants some practical ideas and encourages them that it’s not that hard.
Among the girls who had programmed before, there was a common problem they met after learning the basics of programming: what to do next? Every software developer was a beginner at some point. I think we all know how important is to get a perspective of things you can start doing next, what application you can write, and how to choose an appropriate level of difficulty.
Being a software developer, when you consider improving your technical skills, and getting more professional experience, non profit work with beginners might not seem the best occasion to become a better programmer. However, creating software is a teamwork; It requires good communication between team members and ability to share knowledge and experience. I think being a coach during Rails Girls event is a great way to acquire and exercise these skills.
During the workshops, I met a high school teacher (her student participated in Rails Girls event, and she wanted to find out what’s this all about). There were students of various faculties: women working in marketing, and graphic designers; Some of them had some background in programming, and some of them didn’t. Working a whole long day with three people, which usually represent totally different environments of knowledge is really refreshing. A bunch of different mindsets and different approaches is an inspiring and productive environment for both participants and coaches.
If you ever have a chance to be a coach, don’t hesitate!
Have you ever had a dilemma which to choose – make your everyday life with code easier and use ActiveRecord polymorphic relations or maybe be a more responsible person and think about your database consistency?
Maybe you haven’t, but I’ve actually started thinking about it more. And while I was working with postgreSQL and digging through its documentation once again I convinced myself how powerful this tool is.
Just imagine that you can treat each type from your polymorphic relation as a separate one and set a required foreign key on each. Imagine they all act like they were just one, so you don’t have to change anything in your code and it’s all completely transparent.
So let’s make it happen. Let’s make it possible to add a foreign key constraint to each polymorphic relation type in such a way that ActiveRecord knows nothing about it.
How does it work?
We often use callbacks in our ruby code to catch some events and run some extras. It’s quite natural. But not many developers think about database and SQL as a thing you can also use to program and which may take a much more active role in your application other than just storing motionless data. Here you also can find functions. You can also find callbacks, they are only named differently – triggers.
Using great functionalities such as inheritance and partitioning, it’s pretty simple to create a partition table for each type of polymorphic relations. And you can use triggers to decide which partition to use when you want to add, update or remove a record.
Actually there isn’t anything new about it. All behaviors are well described in the postgreSQL documentation, and many forums and newsgroups show how to use it in the case of ActiveRecord. But solutions require a lot of SQL in your migrations, and what’s worse, very fragile to changes SQL. And we are used to nice, simple and intuitive code, aren’t we?
While putting all this SQL together, an idea to make it more reusable appeared. Encouraged by a client, I ended up writing a gem to handle all those magical operations I required from my database. So, thank you Aaron for pushing me in this direction, and yes, I finally found time to finish that.
It works as follows – if you have for example the models Comment and Post and both are in polymorphic relation with Like, you can add migrations for them:
The first migration adds a new partition table named likes_comments and redirects using triggers all inserts for likes on comments for this partition. The second adds another partition – likes_posts – and updates existing triggers the way that both types of like – comment and post – are being redirected to the proper partition. The main likes table remains empty.
If after some time you find that you don’t need those relations any more, you can remove any of those structures almost as easily as they were added:
The word ‘almost’ came out due to that fact that this migration will remove the whole partition which may contain your data. In such a case, the gem would prevent you from doing this and force you to handle that data manually, either by deleting them or moving them into a different table. Maybe it’s a handicap, but it’s better than loosing data by accident.
Not only sugar
It is a very fresh project and there are things I’d like to be handled better.
The most important thing is keeping the main table empty, which would be extremely easy if ActiveRecord wasn’t using RETURNING id statement for inserts. The thing is that this id is taken from the main table, and omitting it by the trigger causes a not very nice nil in the place of the new object’s id. That’s definitely not what we are used to and what we rely on. The bypass for that is either to allow the main table to save new records and then delete duplicates or to use a view of the main table.
The current version of pg_morph uses the first solution, but for the next one the view is planned to be used. It requires a bit more work to make it as transparent as it is right now, so if you’d like to see a new version sooner than later, don’t hesitate to contribute!