I have been involved in agile software development for quite a few years now, and for the last couple in various process oriented roles. So, I was really excited when I was involved in defining a new agile methodology. The first thought was that why do we reinvent the wheel? Why not simply use Scrum, SAFe or something else? But, taken into account the environment (which I'll soon explain), it could be feasible to come up with a new one.
In this case we are not simply working in a product development organization. Many times the job sizes are so small that they don't require a full team. And by far not big enough to use Scaled Agile Framework. There are multiple smaller customers and work includes both development of new solutions and maintaining old systems. Very complex setup.
Dealing with multiple customers in different software development lifecycle stages is a very complex problem.
Some basic principles that were not to be negotiated:
Teams. There needs to be some basic unit to share the work with.
Autonomy & self-organization. The teams need to be able to organize their work. And the developers decide HOW things are built.
Ownership. Teams need to own their results. This is why a large amount of craftsmanship is needed.
Transparency. Everything should be open. In my experience transparency always improves quality.
Backlog management. There should be one person who has authority over the job queue. The same person will represent the voice of the customer.
Continuous Improvement. Teams need to examine their working methods regularly. Measurement enables feedback and thus learning.
In practice there are two types of teams. Some handle the larger customers. Mostly one team can serve a couple of bigger clients. This way they can have internal job rotation (which is refreshing) and still there's continuity in the customer relationship. And even if there's a slower period with some customer, the team can focus more on the other. The knowledge is kept alive and there's flexibility to answer variance in demand.
The team members will learn to know each other and work together. Increasing the level of trust will enable better working methods and slowly but steadily one plus one will become more than two. Restrospectives will help the team learn.
For the smaller customers and new gigs there's a special team. In a way the work with bigger customers is easier and you can have more junior colleagues learning the ropes from the seniors. But when there is a vast number of customers in maintenance mode, you can only cope with seasoned professionals. And you need to maintain a decent level in documentation. When the panic strikes, there's no time to start looking for instructions. You need to have clear plans and a solid map to navigate the environment.
All in all, although SAFe was developed for big and complex environments, I feel the problem with only one production and mostly one product is much easier to crack than the one I'm currently dealing with. And that's why it's so interesting!
SAFe deals with a relatively simple problem: one product.
One concrete challenge when you introduce something new is the unlearning of old ways. Many times people are biased, even if they don't perceive it themselves. And of course it's tempting to accuse the new framework about all surfaced problems. But recovery can only begin after admitting the facts.
In the series of daily life inspired posts, I return to one of my favorite subjects: cookery. This time I was making some vegetable casserole. I needed to peel and shred some carrots and I fell into the age old trap: big batch size.
As you can see, I had in advance decided to use more than six carrots. While I was peeling them, I was aware that I should have peeled end shredded them one by one, in a one piece flow. But against my own good, I peeled and cut the heads off from six in a row. I was convincing myself that it was more efficient (although I was creating extra inventory).
After peeling the six carrots I finally started to shred them. Only to find out that by cutting the head off I had made the work more cumbersome. And now the fault was multiplied six times. If I'd done a proof of concept (gotten one carrot through the whole pipeline), I would have only had one faulty carrot. Fail fast!
I faced another problem later. I would have been well off with only three or four carrots. But since I had already peeled six, there was no turning back. Now my costs were bigger than they needed to be, I could have saved some veggies for the next time.
The same phenomenon is easily found in software development if you use kanban board without proper WIP (work in progress/process) limits. It's easy to pile up too much work that is waiting for testing or merging to the main branch. The flow is far from optimal, but perceiving the problem is far more difficult due to the fact that the material is less tangible, in most cases information.
The final result was quite edible despite the faulty process. :)
In Finland we have a rather nice concept called freedom to roam (jokamiehenoikeudet). It grants a big bunch of different rights that you can utilize while wandering in the nature. For example you can camp or pick berries or mushrooms (excluding backyards, gardens etc.) My next story is just about that: picking blueberries.
There are two main ways to pick the berries: by hand or with a berry-picking rake. Picking with a rake is by far faster than handpicking. But there are other aspects to consider. Blueberries are soft. The rake will break at least some of the berries. Also, they will be accompanied with a lot of extra leaves and other rubbish. That's why the method will require you to clean the berries.
From lean & quality point of view there are a few problems. First, you will need to have extra storage space. You need to keep the clean and dirty berries in different containers. And the batch size is really big. All the dirty and clean berries need their own space. Second, you will need to move the berries. In lean methodology this is considered waste. In reality, all the extra touching will also make the berries sticky from their own juice.
With handpicking you can pick straight to the final container. You don't need any extra space and there's no extra movement. This also means that the berries will stay in better shape. As a downside, your hands will get blue.
But as in any other things, you should think about your priorities. Largely it's quality versus time. If you are not in a hurry, I'd suggest handpicking. You will achieve a one piece flow. From the forest ground straight to a freezer ready form. But if you are trespassing on someone's backyard and want to get away fast, just use the rake a flee before someone will shoot you. You can then live to clean the berries at home. ;)
One should also note that this isn't as black and white with other berries. For example cowberries do not get as sticky even when you use a rake. And most of the time you don't get as many rubbish either. So there the quality is almost the same with both methods, rake is superior in speed.
Lean thinking is an interesting (and many times rewarding) thought experiment and can be applied also in ordinary life.
This post will be even longer than what I usually write, almost like a short novel. (Disclaimer: it might take longer than one toilet break to finish. ;)) It will be a story of extremely talented colleagues, supportive supervisors, growing organization and a journey of one physicist. Acknowledging the risk of sounding like self centered dick, it will be a story about me and my professional career at Napa Ltd.
Prologue
I didn't struggle much at school. I learned things quite fast without the need to repeat. Especially mathematics was interesting and I got good grades. Later in high school I selected extended levels in mathematics, physics and chemistry.
When it was time to select the place for my studies, selection criteria was to pick the most difficult one. I went to study Technical Physics and Mathematics at the Helsinki University of Technology. My major was Physics and minor Computational Science. This was the first time I really needed to study hard. The challenge felt good. I mainly selected courses based on their difficulty rather than on their usefulness: quantum mechanics, functional analysis, etc. I frowned upon economics and applied mathematics (the topics that could actually be useful in business world!) I did study a bit programming and one course of differential geometry that would come handy later. During the summers I made two special assignments about positron annihilation measurements, one practical and one computational.
Early Years
In 2007, when I had completed almost all my studies, I started to look for a thesis researcher position. Coincidentally, there was a Talent-IT fair at the campus. I wandered around and found the stand of Napa company. I had never heard of it, but they seemed to do things I could maybe contribute in and they had a master's thesis position open. Worth mentioning is that I had experience only in two programming languages: Java and FORTRAN. Insidentally they were also present in Napa's stack at the time. :)
Tom Sundell, who I had met at the fair, contacted me later and we agreed that I would come for an interview. There were two alternative topics: some kind of pattern library or a study about the hull surface representation methods. The second one was closer to what I had studied. While writing the thesis I got familiar with NURBS surfaces, Coons patches, T-Splines and learned a lot more about the NAPA program.
After completing my studies I joined the NAPA Technology Unit as a Systems Analyst. Mainly that was a fancy name for a programmer. Back then there was a clear separation between core developers and GUI developers and I was proud to work with the core challenges.
All developers were part of a big pool from where they were assigned to different projects. Releases were planned for one year at a time. I don't really know how that was done, I had zero visibility (and interest at that time) to the topic. Business people came with specifications and programmers wrote code. Everyone was an individual contributor and a specialist. My field was geometry. Some of the things I'm proud of from that time include upgrading the finite-element 2D mesher, implementing an envelope surface for a given set of planes, participating in renewal of surface modeling and implementing free-form deformation into the program.
Work was in a way easy for a developer, since all you needed to worry about was the implementation. But with multiple overlapping projects, the resource allocation became challenging. Some key contributors were needed in almost every project. I remember that my closest colleague, the more senior geometry expert, was simultaniously in 5-6 projects! At that point it was clear that some kind of change was needed and the organization was ripe for it. Sense of urgency was there.
Adopting Scrum
We had already made some experiments on using a scrumbut for some of the projects. In the early 2012 the company had made a decision to make a radical organizational change, start working in teams and define a process oriented way of working. Teams were formed around products or feature regions. My team was called Model team and we worked with modelling related topics. Teams elected their own Scrum Masters. I was really interested and got elected. And so our distributed team (people in Finland and India) started learning Scrum.
We also formed Communities of Practice. One gathered together the Scrum Masters and it was facilitated by our Chief Scrum Master. But then this person was assigned to another, more urgent role and the position was left open. There was an internal job ad for the position of Software Development Director. I applied.
I didn't have enough experience to fill this role, but I maybe had some potential. In the end the role was split. Our Chief Quality Officer took the ownership of Software Development process, but I acted as his right hand man and owner of the Scrum framework. I became the Chief Scrum Master. Maybe I could describe our work in a following way: we discussed things together, he wrote specifications and followed metrics and I interacted with the teams. I think it was fun and we had a weekly meeting where we discussed the Agile topics on a sofa. My workplace was in an open space with lots of whiteboards and I called it the Agile Center of Excellence. :)
During this time I went to a couple of really useful trainings. Agile Coaching and Leadership was about what the name implies and then Leading SAFe course. Both were really influential and had a big impact on my work life. At that time I also started to facilitate retrospectives for the whole company.
Entering Management
One day in the late 2013 my boss invited me to a meeting together with the Chief Quality Officer. There were going to be some changes to the organization and I was given an opportunity to take a lot more responsibility. My boss used to be also the supervisor for our Release Team that guards the quality of main codeline, provides and maintains tools and other stuff. He was also the owner of our Release Process. He moved to another role and I adopted all that. I became the owner of the whole Software Product Creation value chain. This meant pretty much all actions that take place in development before the software is given to customers. In addition it meant that I would be a Product Owner and supervisor for the Release Team. At that time I decided that what ever problem someone had with our technology function, processes or results, I would take the responsibility. No bouncing the problems around and asking the person to find someone else. I would take full responsibility and later then find out who could help me fix things.
My boss had been sitting in his own room, but I wanted to sit together with my team. (The room was next to the team room and was still available for private discussions and calls.) At the time there were three members in Finland and two in Romania. The guys were brutally skilled. I really understood that in an expert organization being a supervisor is mostly about removing obstacles and making sure your team can work effectively. The best implementation decisions always come from them. My role was to set priorities and make decisions when needed. Now afterwards, the time when I worked together with my team was the high peak of my working life so far.
As the Release Process owner I also wanted to plan the releases differently. I had been very unsatisfied with the level of transparency on the plans. As I wrote earlier, previously developers had no idea how the releases were planned. Specifications were just dropped on their laps. I decided that we should make things more public. In 2014 we arranged our first Release Planning Day and I have described it in more detail in this previous post. I think I can take some credit for kick-starting the practice, but most of it goes to the organization. People, especially Product Owners and Product Managers, came in prepared and played their role well. I remember one colleague saying something like "Thank you. Now for the first time I get an overall picture of what's happening in this company."
Due to some organizational changes and other events, my team size was diminished until at one point we only had me and two release engineers. We started a recruitment campaign and this was the first time I ever recruited anyone. We got one new team member into Finland and into India. Then for the first time we had a Release Team member in all our development offices.
Side jobs and other activities
Before the management I was also an Industrial Safety Delegate for a few years. I was also the first Shop Steward. Both of these side jobs originate from my urge to keep the game fair. As a mathematician I like defined rules and it would be awesome if the world followed such rules. Unfortunately I have also learned that it doesn't really happen in practice. That's why it's better to stay agile, adapt to different situations and update plans accordingly.
One nice side job was also acting as the internal facilitator for strategy renewal work. It was a real vantage point over all functions in the company. And really, really interesting.
I also worked as an internal auditor. Napa has an ISO 9001 certified management framework and holding internal audits is part of the model. Again, a really good chance to learn more about different parts of the company and how they interact.
While being responsible for so many different things simultaneously I started to drop balls. Or maybe not totally drop, but I felt that I cannot do the things as well as I wanted and as well as they deserve to be done. I really liked being the Chief Scrum Master and manager for the Release Team, but those were responsibilities that could be easily transferred to others. So I did. Reluctantly, but from my own initiative. I felt that the organization would get the biggest bang for a buck when I would concentrate on the value chain and activities that go across the function boundaries.
At this point I also became the secretary for the Portfolio Management Team. I had been driving the adoption of Scaled Agile Framework (and become a certified SAFe Program Consultant) and felt like the owner of the framework. I wanted to bring more structure to the way things were decided on the top level. Unfortunately the process for introducing new Epics was largely unknown to organization in general. I helped to transform the Roadmaps from purely technology and development focused into something that better takes into account also other activities like service development and marketing. The experiment is still ongoing.
During this time I had come to a decision. I want to see how things are done in other companies. To see in practice if I could make an impact and to help other companies too. And that is why my journey will continue from now on somewhere else.
Epilogue
Napa has been an extremely good place for me to grow. During the past nine years the company has gone through a big transformation. From individual responsibilities to team responsibilities, growing organically both in number of employees and in revenue. I feel I've grown with the company. I have faced challenges and opportunities. I'm grateful to all my colleagues, my supervisors, everyone who have supported me.
I hope my departure will also be a chance for Napa to do things differently. I'm sure they will continue finding new and better ways of working. Especially the new products and the investment in improving user and customer experiences sound really promising.
I will miss this place dearly and it will always have a special place in my heart. And who knows, maybe I'll one day return. Hopefully I haven't burnt any bridges behind me. Godspeed Napa! And enjoy working together!
When a new programmer starts writing code, s/he requires detailed specifications and clear requirements. The understanding is on a level "I need to get this piece of code working". There's not very much thought given on what happens outside this routine or how things are connected.
On the next level, the coder understands that the piece of code s/he's writing is a piece of a larger system. This system exists for some purpose, but the purpose isn't necessarily clear for the person. But generally s/he understands the system is important for the company and probably generates financial benefits (i.e. is sold).
Reaching the next level is already quite challenging. At this point the developer starts to think about the customers' business. How do the customers make their money? (...that can be then invested. Maybe in software. Maybe even on the solution you are developing...) And when you understand how the customers make money, you understand their priorities and needs. What is important for them and critical for their business.
There might be intermediate levels between the ones I mentioned, but I think this covers the basic steps. I'd encourage all developers to try to advance on these steps. The higher you are, the better you can fill your customers' needs and thus the more valuable you become. I'm not saying that code writing is easy. I'm simply saying that being able to write code AND understand the business is a tad harder and rare. Development on this path starts from understanding the user.
(Sometimes the decision maker for software purchase is not the same as the user. Users might be only influencers in a complex network. But let's leave this out of scope for now. )
Last week I participated in a value sales training (given by Talent Vectia) where I learned that 70 percent of sales representatives do not prepare for a customer visit at all. I could guess there's a correlation between this and deal closing resolution.
When customers meet a sales representative, they often think "Stop wasting my time." So don't. Make your visit worth their while. Things need to be communicated efficiently and clearly without too much fuss. And when you communicate with the customer, instead of talking about "waste", a better choice of words would be to make your visit "worthy" of their "valuable" time.
Another thing they look for is a chance to learn something new, a challenge. They probably meet plenty of sales people. Why are you any different? Challenge them! Don't make them too uncomfortable, but maintain a healthy tension.
Challenger is also the best performing sales profile type. It outperforms Lone Wolf, Hard Worker, Problem Solver and Relationship builder. I guess usually sales representatives
In my previous post I touched the topic of legacy modification. It is a difficult stunt to pull. Or well, in a perfect world with a well maintained codebase and outstanding automated test coverage it could be easy, but in reality I think that's rare.
One of the things that makes modifying legacy software especially difficult is the regression. When the system is strongly coupled, almost every little change can produce unforeseen consequences. (Yes, the Butterfly effect!) To counter-attack the diabolic regression effects your best bet is to invest in a test automation harness. But until your test harness is truly solid, you need to make do with manual testing.
In our setup we have two distinct periods: the Development period and the Stabilization period. During the Development period our scrum teams work normally in sprints. They concentrate on creating the new added value that has been agreed on in the Release Planning. Adding new code into the mainline is guarded with automated tests (unit tests + system level tests) and only allowed through pull-requests. Unfortunately due to the limited coverage, this is not enough to guarantee that things stay in good shape.
Development
Development
Stabilization
During the Stabilization period we stop adding new features and concentrate on testing the existing functionality. In practice this means testing manually those parts that are not covered by the automated tests. (This might be called classic hardening anti-pattern and frowned upon, but in this setup it's a must. New development meets Definition of Done, but it's the regression that gives us headache.)
Now this setup sounds a bit dumb. Why do we let the quality deteriorate and problems creep into the mainline and wait to be uncovered during stabilization? Wouldn't it be wiser to detect the problems early on?
Well, that's why we came up with System Testing virtual team. At least now in the beginning it consists of each teams' tester and scrum master. Reasoning behind this resourcing is that testers should naturally be interested in their product's overall quality. And unreleasable software is a really big impediment, thus the scrum masters. The concept is actually quite close to Scrum of Scrums. One main benefit is also that the teams will become aware of what the others have been doing.
The virtual team will meet biweekly for a full day of testing. Each day will be like a mini sprint: beginning with a planning session and ending with a review and retrospective. There's still plenty of forming and storming to do, but I have really high hopes for the activity. Already during the first session they were able to catch tens of bugs that would have most probably otherwise stayed under the radar (at least) until the Stabilization period!
