Lean Oven Beets

I wanted to make some oven beets (beetroots) for lunch. The process for making those was simple and I wanted to make it as lean as possible.

Raw material was a bag of beetroots, about 30 pieces. It will represent the supplier. Then there are two necessary working phases which add value to the customer. The beetroots need to be first peeled. Then they must be sliced into bits. Finally they go into the pan.

Process Flowchart.

The production plant could be set up in different ways. But in order to eliminate waste, everything should preferably be close to avoid unnecessary motion and transportation. With only two work phases there's not many places for inventories, but one possible place would be between peeling and slicing. If you first peel all the beetroots, you need to keep them somewhere before the slicing. But if you work in a one piece flow, you don't need any extra storage between the phases. Then there's also no over production, because one beetroot is always enough to enter the next work phase.

My factory had only one employee who needed to task switch between the phases. There was also some need to move. With two employees this could have been avoided. But unfortunately recruitment for housework is sometimes really hard.

Factory setup: Sink, Work Phase 1, Work Phase 2, Pan.

Keep things tidy and in order. When the equipment is on their places they are easy to find. Keeping your gear in good condition (knives sharp) makes your process more efficient. With tools fit for purpose, like my peeling knife, you can not fail. You can cut off just the skin and no valuable beetroot is lost. In lean this mistake-proofing is referred as Poka-yoke.

Proper peeling knife. Poka-yoke.

Fortunately the supplier had provided me with so good material that there were no defects. Quality control happened visually before the peeling phase.

Because the employees were both trained in continuous improvement and empowered to make changes to the plant layout, they came up with a slight process improvement after the first half of the work. The need for movement was decreased by moving the pan closer to the slicing place.

Factory layout mark 2: More compact.

When the materials ran out, the plant was simply shutdown. No capital was left in inventories. In the end, the customer received a pan full of sliced beetroots. As she had ordered.

After shutdown and clean-up.

In the text above I have tried to identify different types of waste and write them with italics. One could argue this wasn't a process, but a project. If the work would have continued, there would have been a need for a proper disposal of beetroot peelings. They were simply piled and thrown to garbage after the work was completed. But how to do this properly in a continuous process is left for the reader as homework . ;)

Customer Value Through Lean, part 1

I haven't blogged in a while so let's do some blogging! I recently saw the below image in Twitter:

I'm not (yet) familiar with William Glasser's work, but I'm willing to believe this. Maybe that's actually one reason why I write this blog: to learn. So, let me try to teach you something about Lean. And this is somewhat personal and subjective lesson, not a result of sound scientific research. Hopefully the facts are close to reality. If you find an error, consider dropping me a comment.

Origins

Lean has it's origins in Japanese car manufacturing. Specifically Toyota had developed a very well performing production system which later become well known as Toyota Production System (TPS) and people from different countries have tried to copy. But it is not as simple as taking the separate practices and rolling them out in your environment. It's the whole package. (You might want to check The Machine that Changed the World by Womack et al.)

Some essential topics in Lean are Continuous Improvement, maximizing the flow of value and respecting people. (I'm not anymore sure about what is Lean, what is Kanban, Scrum or just good way of doing things. I've read too much about processes and methods and my mind has started making it's own synthesis...)

Wastes, Support work and Value Adding work

Many people who aren't that familiar with Lean, are at least familiar with eliminating waste. Waste can be characterized as everything in your chain of actions (value chain) that the customer is not willing to pay for. This includes waiting, unnecessary movement, time spent for finding things, defects, producing too much of something, over processing and inventory. Also I like the idea of adding underutilized employee talent to this list.

Minimizing the inventories is also closely connected to the notion of a pull system. Let's say you have three baskets. From the third one you sell products to your customers. The two first ones represent some work stages where you add value to the end product. If you want to minimize your inventories, you can wait until customer buys something from the third basket. This creates a vacant spot in the basket. At the same time it triggers you to finalize one piece of work from the second basket and move it to the third. While you do this, there will be a vacant spot now in the second basket which you can fill.

You would probably also want to aim for a one piece flow. Large patches are usually typical source of waste, because you have too much money tied in your inventory and you might end up producing things your customer doesn't want.

But the main thing is not really about eliminating waste. It's also about identifying which parts of the value chain are value adding. And with value adding I mean things that add value from the customer's point of view. Observed separately from your internal point of view they even appear as waste. Good rule of thumb is something that the customer is willing to pay for.

Third category of work is the mandatory non-value adding work. These are things that do not really add value, but are necessary. Many support functions like bookkeeping go into this category. You cannot totally squeeze them out, but you should try to minimize the amount of time spent on them.

Processes

Another key Lean principle are well defined processes and accompanying metrics. If you can't measure it, you don't understand it. You get what you measure. You can't improve if you don't know where you currently stand. There are quite many phrases about measuring, but I guess there must be something behind them.

Once the processes are defined, you can start improving them. In Lean jargon this is called kaizen. Radical changes have a different term, kaikaku. Big organizational changes definitely are kaikaku rather than kaizen. In software development if you are applying Scrum or Kanban practices, you probably already have working practices for continuous improvement. For teams the events are Retrospectives. In my own role as Release Train Engineer I hold retrospectives that span beyond team levels.

Usually processes will always have a bottleneck somewhere. This means a limiting value for the flow of value. And when you remove it (with some awesome kaizen practices), the bottleneck will be somewhere else. But you will never get perfect. You can always improve.


I need to get back to this subject later. There's much more. Slack, queue theory, WIP etc. Really interesting...

DIY Build Light Indicator

This post will differ from my typical posts. It's not about processes or methods. But actually it's related to the practice of Continuous Integration. That's one of the key engineering practices most Agile teams use. Originally proposed by Grady Booch, but later popularized as one of the eXtreme Programming practices. For many Continuous Integration is simply "that build system".

There are many free and commercial tools available for CI. I have actually played around with CruiseControl (not much and I've never actually configured any builds in CC. It was more or less fading away when I joined my company), TeamCity (this one I like a lot), Jenkins and lately Bamboo.

The problem with all these CI tools, and all other online tools, is that you need to navigate to a specific place to find out if the build is passing or not. Similar thing for a Scrum wall or Burndown chart if you use for example JIRA. For us physical humans the physical things just work well...

The build light is a remedy for this. It converts the status of the build in our CI tool to a physical form: colored light. If the light is green, the build is passing. If the light is red, someone needs to fix the build ASAP! This kind of information radiator can easily spark action and foster self-organization.

Making yourself a build light isn't that difficult nowadays. In our case the most difficult thing was to get a Phillips hue Starter kit. With that you get a light that you can control with your computer. Then you will need a CI tool. In our case we connected our build light to a Bamboo build.

Then maybe the most difficult part: you need the glue code between your CI and your lamp. But today that's not too difficult either. Node-RED has made the task of connecting our physical devices to internet lot easier. (I'm not sure if it was difficult before. I'm just assuming it was.) Instructions for connecting your hue to Node red can be found from this blog post. (Actually before you get to use Node-RED, you will need node.js installed.)

But skipping ahead a few steps you get this: voila! Now we can diminish the "is the build passing?" questions. Simply check the lighting. If it's pleasant green you have nothing to worry. :)

Our buildlight. Who broke the build!?

Practice Makes Perfect - Release Planning Day 3

It's an amazing feeling to notice that something you have deeply invested in has started to become routine. Not for you, but for the organization. I had the pleasure of experiencing that today.

We had our third Release Planning Day. I've told more in detail about the previous two times in my earlier posts. This time the agenda was pretty much the same as on the previous try. Day began with a look at our markets and business. I like to see how things are connected. It's easier to justify your daily work when you can fit it into the big picture. What ever actions we might take should in my opinion bring us closer to our Vision. The message was delivered by our Chief Portfolio Officer. (SAFe model suggests getting some high ranking executive to signal the importance of the meeting. I think we've already seen the usefulness of Release Planning but it doesn't hurt to have powerful people involved.)

Then our five Product Managers presented their updated Product Roadmaps. Most of the contents in the Roadmaps were pretty much the same as last time. This makes sense since the Roadmaps should cover long term development needs and shouldn't maybe live as much as the Backlogs. There were some comments which I hope spawned even more lively conversations after the meeting.
One impressive moment was when I realized that we have around thirty people sitting in Helsinki and the PM presenting his Roadmap from Asia over Lync. And you really could not tell much difference from a case that the person would have been there live. Except for the fact that one couldn't see him. :)

After the Roadmaps I gave brief instructions on what I expected us to achieve during the rest of the day. Then people simply disappeared. Almost before I had even finished talking. But that was good. They knew what to do and were determined to do it.

During the Team Breakout session I wandered around our premises. That was the second time a slight smile suddenly appeared on my face. There were groups of people here and there discussing the coming Release. Exactly those necessary conversations that need to take place! What should we do? Why should we do it? How should we do it?

Later in the afternoon we gathered back to the meeting premises and went through the Draft Plans. Each team had come up with a list of topics they will start to work on in the next Release period. Already many cross-team issues were identified and the plans were well in line with the Product Roadmaps.

Tomorrow we will go through the finalized plans. I'm not anticipating any big changes so we will probably just go through the main changes compared to the draft phase. But all in all, everything has worked so far just as well as one Release Train Engineer could possibly hope. But of course next time will be even better. Continuous improvement!

Focusing is Effective

If you have a hypothesis, there's probably no better way to validate it than by testing. It's one of my favorite practices from Lean Startup. Experiment. Make a hypothesis, test it and learn. Repeat.

But you also need metrics. Something that you can measure and see if your actions have impact on them. In our case we have been asking our Developers, Product Owners and Product Managers the same set of questions twice. (The poll has been anonymous and people have been participating really well.) The results show nicely how the actions we have done (our focus) have improved the results in those areas. Unfortunately they also show that things that have not been paid too much attention to are not improving.

We have made big efforts to improve our Product Management and to shed more light to our Product Portfolio. Also we have invested in training our Product Owners. The results in these areas are almost stunning. According to POs and PMs the work in Portfolio has improved by 30-40%! I could call that from zero to hero. Developers are now more satisfied with their Product Owners. Although the sample size with Developers is lot bigger than with the other two group, the numbers have gone up by almost 14%.

But unfortunately there are two sides in a coin. While we have put a lot of emphasis on the Portfolio and on Product Owners, we haven't maybe paid enough attention to core of the agile. Data is ruthless and clearly shows that our efforts in Continuous Improvement and Visibility to Work have not been too good. For this I will take personal responsibility. I'm currently both Chief Scrum Master and Manager of Releases. I have been clearly concentrating too much on one part and neglecting my other responsibilities for the organizational improvement efforts and making things visible. Point taken, now I know what to improve next.

As a statistical experiment this has been very interesting. My interpretation of the results is that they validate our hypothesis. The areas we concentrate on are affected and in a positive way. Having focus does pay off!

Behind Enemy Lines - Project Days 2014

Sometimes I notice I can be awfully prejudiced. I can't help but think about projects being all about waterfall. Hehe, I actually blame partially Lyssa Adkins about this (although in my things I admire her). Her excellent book Coaching Agile Teams talks about recovering Project Managers in a sense that they are far from being Agile

Based on this the reader may understand why I had my doubts when I was asked to give a presentation at the Finnish Project Managers' gathering called Projektipäivät. The event consisted of 20 different seminars in both Finnish and English. The one that I participated could be translated as 'Taking the Benefits of Agility into Use'. So even though the whole event was about a substance that I don't know much about, the seminar I participated felt like a safe haven.

The venue of the event was Dipoli, a building in Otaniemi, the cradle of technology in Finland. (I've also studied in Otaniemi, so it felt like a homecoming. :) ) All the presenters received a small bottle of Jaume Serra cava which I later learned was an excellent bubbling wine.

The first keynote was given by Ludovic Hauduc from Microsoft. He talked about the Future of Business Productivity and Project Management. Actually this was the first moment I gradually started lowering my defenses. He talked mostly about how the main characteristic of a successful project it that PEOPLE are involved. So it was not about the superior knowledge of the Project Manager. After the presentation I exchanged a few words with him and he said that MS Office unit is maybe not that agile yet due to the history, but they are on their path to change. Also I was curious about if they used SAFe model. But he told me they have their own way which is more of combination of different methodologies and once more emphasized the people aspect. I was very pleased about this message.

After the keynote I went to listen a seminar about Creative Utilization of Different Methodologies in a Project. Tero Huttunen from Tieto told about how the Project Managers face a big challenge with methodology knowledge. In the busy working life of today the PMs are under big time pressure all the time. And there are quite a few different methodologies out there: Agile, Scrum, XP, TDD, PRINCE, ABC, SAFe just to name a few. How could they find time to learn about all these and still have the project on tracks? (Personally I think it's about changing mindset. Giving more freedom and responsibility to the teams will make everyone's life easier. Of course given that the environment is accepting for such thing.)

Next Juhani Snellman and Elina Koskela from Reaktor talked about using Kanban in IT-projects. They also started their presentation by saying that they don't really have Project Managers and that they do everything in an Agile way. But the presentation was interesting. Kanban isn't totally new thing to me, but I haven't ever used it 'in production'. I merely know about the theory so it was nice to listen people who are actually using it (and even teaching how to use it.) My question to them was about statistics. They showed a nice cumulative flow diagram where they could show lead time and WIP. But when using physical boards someone needs to collect these statistics. From JIRA you can get that automatically, but yeah, using the real post-its has a nice wipe. (If you have distributed teams, working barely with physical boards is rather challenging.)

Then Mika Heikkinen from OP-Pohjola talked about how to use different methodologies in the big picture. Actually this was a bit misleading, because he was actually only talking about how they use SAFe. It was anyway really interesting. They have now used SAFe for over one year and have multiple Release Trains. Can't actually remember what was the percentage, but if I remember correctly they SAFe for about 40% of their projects. Could be less, could be more. But I claim that currently they might be one the biggest players in the SAFe field in Finland with their nearly 12k employees.

After the lunch break I joined the Leadership seminar. It might have been the most popular in the whole Projektipäivät event. The room wasn't the biggest, but it was really full. The facilitator, Mikko Babitzin from Tieto, had set up a second screen which was displaying the tweets with hashtags #projektipäivät and #onnistu2014. (Onnistu, which means succeed in Finnish, was the topic of this years event. Next year it will be growth which could be even more interesting.)

Vesa Rantala from Tieto shared his vast experience about working in foreign cultures and as a Project Owner. Main emphasis was once again in people and more on having personal relationship and interaction with them. Lack of asking question can also be interpreted in some cultures as not being interested in how things are proceeding. So by asking questions you signal your interest. Not really rocket science, but good to keep in mind.

Matti Vesala from Adare talked about social media and how to utilize and manage it. You don't need to be in social media, but if you accept the challenge you can get some interesting benefits. You can have your own prime time show. Not possible in television. :)

Hannu Salonen had selected 'Feedback is a Gift' as the headline for his presentation. It was both about positive and constructive feedback and about the challenge of giving and receiving it well. Really great thoughts and tips. Not really specifically for Project Managers but for anyone in a supervisor role. Or even for a leader who leads without any power over his/her followers (like a Scrum Master.) Actually I like this form of leadership the most and in the end it's the only thing that could work in today's working life. People are free to choose where they work and if you don't treat them well they can vote with their feet.

The final presentation in this seminar was given by Virpi Pikkarainen and Tiina Miettinen, two mothers and wives. (This was their own introduction.) Maybe the most important take-home I spotted was the fact that you cannot lead if you are neck deep in the details. You need to ascend a bit and take a helicopter view. Then you can see more clearly where you and the whole group should be heading.

The second keynote was given by Taneli Tikka, a serial entrepreneur who currently works in an internal start-up in Tieto corporation. They are developing the internet of things. Taneli's presentation was about transformational leadership. Good things start with Appreciation (of other people.) After that you can have Trust. Then if you throw in a bit of Enthusiasm and top it all with Learning you can be up to something really good. But remember to keep clear of being Passive or Controlling. Taneli was also referring to Deep Leadership, a methodology originally developed by Vesa Nissinen for Finnish Defense Forces. I wrote about it last summer. But anyway, I think Taneli's presentation was the most inspiring I have seen in a while or maybe even the best I've ever seen live. Charismatic person, still young and yet already long experience in start-ups and business in general.

The first day's program ended in a set of awards ceremonies. Awards were given for the best Project, best young Project Manager and for winners of Project Management Championship for students.

The second day started with the third and final keynote from Yrsa Sigurðardóttir. Her presentation was boldly named 'Project Management and Sex'. Well, it was really about genders, but this way she was able to draw more attention. ;) Currently there are no countries where it would really be beneficial to be born as a female. In Iceland the genders are closest but even there it's better to be born as male. But maybe things will change in the future. In her presentation she told about how they were able attract more women and young people into a project that was in really harsh conditions in the middle of nowhere. They made the camp really family friendly. The decrease in staff turnover was dramatic and results extremely good. Something to think about.

Later during the second day I actually got rather nervous about my own presentation. I made some final modifications and practiced some more. In the end I was rather happy with the content. Although my seminar had headers in Finnish, I wanted to present in English. Mainly because I thought it would have been recorded and I could have utilized that also in our internal communication (and for myself to take a look at how I present myself in public and how I could learn to do it better.) Unfortunately it wasn't recorded. But I kept the schedule, there was some time for questions in the end and feedback was positive. And I sincerely enjoyed. I knew my subject and I was happy about seeing people's eye contact. I think I was able to give them something.

The Roles and Responsibilities in an Agile Project and Organization from Toivo Vaje

But the final conclusion from the whole event was that projects don't necessarily mean waterfall. I think based on this event the scene has changed into something a lot more Agile. I think the two could live happily hand in hand. But I would have never found this out if I had not participated. Learning is everything. 

Using Scrum for Strategy Work

I'm continuing with the same subject I wrote about last week. Repetition is key to learning. And another important way to make things stick is to tie new information to previously obtained knowledge. At university I noticed the same thing with equations, groups of equations, matrices and linear operators (and functionals). Once you study enough maths you see how beautifully many things are connected...

But getting back to the point. I'm participating in our strategy work. Probably going into details about it would be wrong in so many ways that I won't even consider such option. But I think the (Agile) process how we are producing the new strategy is so interesting that I'd like to share it.

One way to produce a new strategy is to assign the task to a couple of persons. Then they spend some time (X months) to gather data and make relevant analyses and present resulting strategy to CEO and/or Board. Then the strategy might be accepted or some modifications are requested. Process is effective, because the people working on it don't need to negotiate much and they can move fast. On the other hand, the result is produced by the mental energy of only a couple of people. And these are also the only people who know the new strategy at the beginning.

In our case the work is split into work streams. Each work stream has an Owner, a Facilitator and a dedicated team. Teams produce their own piece of the general strategy puzzle, but they need to make sure they are aligned with the other work streams. This is achieved via cross-team communications (which is always non-trivial) and facilitated through weekly Facilitator Calls. Teams also have regular sessions when they all meet, present their current findings, challenge each others current results and generally push each other forward. This is also a session that feeds the overall strategy which will be the crystallized result of all the combined efforts.

If you have used Scrum with multiple teams you might spot some similarities. I think the work stream structure is a one-to-one match with a Scrum Team. It contains (Product) Owner, Facilitator (Scrum Master) and a (Development) Team. The Facilitator Calls are like weekly Scrum of Scrums sessions that are used for cross-team synchronization. (Of course this close relationship with Scrum is not that much advertized.)

I can't think of a good Scrum match for the session that combines the results of the different work streams, but there's one in SAFe model. These regular sessions bring to my mind System Demos. All in all the work is like traveling on board an Agile Release Train. The end result will be full-fledged strategy that is already well understood by the people who have been crafting it. And although this probably costs the company a lot more in the short term than a strategy crafted by only a couple of persons, I think it's a clever investment. If we have N work streams with M members, it totals N x M people who are already quite familiar with the new strategy. I think that is already a really nice sized Guiding Coalition.

And maybe still one thing that I want to add (because I'm so proud of it): the strategy process is out there in the open! Not in the basement, nowhere lurking in the darkness. Anyone is free to give input. People are encouraged to discuss and even the meetings are held in open space. Transparency. A cornerstone in Scrum. To me it signals trust.

Strategy, Vision, Story, Culture

First I need to admit that I'm a total newbie in any strategy work. I can openly admit that most of what I have is just scratching the surface and guesswork. But I'm getting increasingly curious about how to craft a strategy.

Even the best strategy isn't worth a penny if people don't know about it. People need to hear about the strategy. They need to be able to discuss it and ask questions. Possibly even help in crafting the strategy. I believe that's not always possible and maybe everyone doesn't even care too much about such things, but it's easier to embrace something you have been involved with early on. (I believe same things apply for leading change also. And well, strategy is about changing the company from one stage to another.) Communication becomes critical when executing the strategy.

I have recently learned that I've confused crafting a strategy and crafting a vision in my mind. I mean, if we start making a new strategy, first we should have a goal. Ambitious and challenging, yet reachable with some stretching. Or even unreachable. I was again happy to watch a video about Spotify. The second part of Spotify culture introduced the Definition of Awesome. I think company Vision should be something similar. What you aim to be in the future, the ultimate goal.

And then Strategy would be 'just' those steps that take us towards that goal. There might be big and scary actions that will need to see the daylight, but more or less this is how I see it. Now I'm facing some doubts. Spotify is emphasizing the importance of culture. Almost all companies have values. The recent presentation by Eric Schmidt from Google seems to point to the direction of culture plus right people and even directly saying that having a strategy is stupid. In today's fast moving world the strategy might be out of date quite soon after it has been crafted. Old truths don't hold anymore.

Experience is less important than skills, enthusiasm and willingness to learn. Months and weeks have turned into seconds and you can be either a dinosaur or a small and agile mammal. Those who don't adapt will become fossils and relics of the past.

But maybe strategy can also be to create an kick-ass culture while pursuing that vision. If you aim to be the best damn player with the most awesome products that customers love, that vision is not going to get out-of-date soon.

Fourth interesting concept related to the same topic is the company Story. I read about this from Ville Tolvanen's blog (who unfortunately blogs in Finnish). I like this approach of having a Story. Stories are easy to remember and they don't need to be precise. Using metaphors is often a powerful way to get the message through. Maybe the trick is to tell a story about a company that had an awesome culture and was chasing a glorious goal...

Software QA and Testing SUMMIT 2014

I participated in a Finnish QA and Testing conference. It was actually my first related to this subject. Never the less, I found the presentations to be really interesting. (The conference would actually last two days, but unfortunately I can't attend the second day.)

IT Quality from the Management point of view - Quality Assurance is much more than testing

The first keynote presentation was given by Reni Waegelein and Karri Kolehmainen from Veikkaus. Veikkaus is a Finnish provider of gambling services. The only one of its kind, they have a monopoly. Maybe the main topic was that the business is moving in ever faster pace. Earlier things happened weekly, like the Finnish lottery (Lotto-arvonta) and the main co-operation partner was post office. Now playing and transactions happen almost every second. There are 300 million gaming events per year.

So is it worth investing in quality (assurance)? It depends. One should always consider what we can achieve with the testing and what we could lose if we don't. What and how big are the risks? According to Waegelein it's not necessary to have the site always accessible. But keeping people's transactions secure is a must.

The perceived quality or the impression of it is more important than the actual level of quality. A lot of it is psychology. People usually remember from their experiences three things: the worst thing, the best thing and the end. Essential part is to find the critical situations where the quality needs to experience good quality. For websites it's usually the arrival and departure from the site.

Usually failures make good stories. They told about a time when after the Keno lottery broadcast was already over, one the official administrators found a ball outside the lottery system. In essence that meant that for customers who had played with that number there had been absolutely no change of winning. So they decided to redo the lottery. But because official results had already been announced they couldn't help but give out the winnings for the past lottery. They took a big financial hit and had to make a lot of manual work, but I think it was indeed the best choice all things considered.

Another thing they wanted to clarify was that testing doesn't produce quality. During their last big release efforts before jumping into more agile way of doing things they spent 25 thousand hours on testing a release! And when they wanted to do things differently some people thought this safety net was taken away.

But to be fast, the focus needs to move to an earlier stage. Quality assurance needs to start already during the development and even before. It needs to be part of every project. When testers are involved already at the planning it more easily means that only the necessary parts are implemented. Usually normal Product Owner would specify the product up to 130% and end up adding even more. With the testers are involved in this it's easier to stay focused.

They don't have people separately responsible for test automation. Everyone knows how it works and everyone is responsible for it. The cases are written in Gherkin which is easy to understand even for non-coders.

The Agile Project Model of Veikkaus is a combination of different methodologies. It combines selected practices Lean, Agile, Scrum, Kanban and XP. They were also aware of the Scaled Agile practices and familiar with the things happening at Spotify. Many of the things sounded really familiar. We have been studying and experimenting the same practices.

After the presentation there was a round table around the vision and future trends of testing and QA. One comment was that QA seems to nowadays be almost a synonym for all the other software development activities except testing. People had also noted that in some places people have widened their job descriptions. They aren't anymore test engineers or development engineers but just engineers. Reminds me of Scrum and everyone in the team being a Developer. The importance of (test) automation is increasing.

After a coffee break there were a couple of short presentations by tool providers. I'm not going to advertise those here, except I want to share a couple of cool pictures. Ulf Thornander talked about the tightening pace in development. We are moving from Continuous Integration to Continuous Operations. But I think this is a bit hard to reach for certain types of business, but anyway a good Roadmap for the future.

James Fenton talked about how we should integrate testing into Continuous Delivery. There were a couple of good slides, but I personally liked the one about moving testing to the left best. It's so much cheaper and productive to find the defects when the product hasn't reached production. A no-brainer, but still somewhat hard to do in real life.

How to get Quality Assurance included from the beginning of the Project?

Maija Sanisalo from UPM concentrated on the human part of QA. She told that a good QA person is visible. That's how (s)he gets involved and hears things. Having people with great skills isn't enough. They will need to be able to work together. And the quality assurance needs to be part of people's daily work. As an amusing side note she mentioned how it's important to decide that 'today is going to be a great day' and start your day with a Peter Pan or a Winner pose. It will affect your mood and consequently your whole day. (People might also think you are crazy, but you shouldn't care about such petty details.)

 

CASE Nokia: HERE Maps for Windows story: How to adopt changes without scarifying quality

The last presentation I had time to enjoy was held by Tatiana Smekhnova from Nokia, Germany. She's the QA Lead of the HERE maps. According to what I heard, Nokia has done some remarkable improvements on the empowerment of people. Or maybe HERE Maps is just so small unit that things are easier to change there.

The quality of the application is the responsibility of everyone. Processed should help in this. They had a challenge with regression testing. It could have taken five days to complete. But when you create software in short sprints, five days is way too long. So they set a challenge to shorten the time to one day.

They seem to really live according to agile values. Team makes decisions together, they review their Definition of Done regularly and they have working Retrospectives. One particular example of team making decisions about their own ways of working was that they decided that meetings should take a maximum of one hour. From the principles Tatiana showed in her slides I found also lot in common with the Management 3.0 principles. Face to face meetings, setting goals together, improving everything. I guess many people have read the same books. Maybe they are indeed good books. At least I personally believe so.

All in all as a conclusion Software QA and Testing SUMMIT was a good investment of my time. In addition I had opportunity to speak with interesting people and find out new things. Actually this left me hungry for next year. :)