Modern software development is mostly a team sport. Even with AI tools becoming more and more common, most companies organise their product development into teams that own specific parts of bigger software assets. And these teams can then have different ways of working and agreements. Social patterns (how to organise humans and handle communications) is not a new field of study.
I originally found these patterns from the book Organizational Patterns of Agile Software Development by James O. Coplien and Neil Harrison. It was written in 1995, so exactly 30 years this year.
Sacrifice One Person is a social pattern where one person from the team takes care of any small distractions that come to the team. This is something that probably many teams in different organisations have tried. I'll give a description of how that is done in the company I'm working in.
Implementation
The role is called Investigator and shifts are one week long. All team members are part of the rotation. The shifts affects only the working time, on call is handled by different people. Pagerduty application handles the rotation. It also alerts people if there's problem in their service.
One person answers, others continue work.
The Investigator shift is also visible in the calendar. Person who is one duty, has a full week calendar block that remind them and others that it is their turn. Every team also has a team Slack channel and if anyone needs help from the team, they can ping @Investigator. With this handle the person on duty will automatically be pinged and everyone else can continue their work.
Results
When this social pattern is well adopted, it significantly decreases distractions and frees a lot of team resources to continue working on the normal backlog work. Without this pattern, probably the whole team would be pinged or the burden would concentrate on the few most senior individuals. By agreeing on the practices (for example that @Investigator pings need to be answered within agreed timeframe) it also improves the service level for internal customers. Because they have an agreed and supported way of getting reply to their questions and inquiries.
Depending on the amount of technical debt, wideness of team scope and size of the customer pool, Investigator shifts can also be stressful. Many teams have then agreed on supporting practices for their Investigators. There can be regular calls during the week or even two Investigators, if the expected weekly workload is very extensive.
With all the potential stress, many developers still seem to like the role. It is a chance for them to diversify their work and often learn something new.
This social pattern has been tried and proven to be useful. So I would highly recommend implementing something similar in your organisation.
Software development is a team sport. It is true that even a single person can make huge contributions (like Linus Torvalds on Linux), but in most cases great results are produced by great teams. In this post I will concentrate on agile software development in a setup where own products are being made. I will try to tell how I would extend the team and what kind of tools or practices could be used.
Staffing the first team
Product Owner
Everything starts with an idea. A good rule of thumb is that there's a problem significant enough that it is worth solving. Before coding even a single line of code, make a hypothesis of the possible solution. Then validate it as fast as possible. For example Lean Startup practices might serve you in doing this. Having a Product Owner (PO) might be a good idea. PO can start collecting potential product feature ideas and requirements into a Product Backlog.
Architect
When you are pretty sure that you have an idea worth implementing and you start creating a team, maybe the first person to recruit is the architect. Someone who will have an overall technical vision about structure of the solution.
Coders
Next you probably want to add a few more coders to speed up the development. In the early phase of the product lifecycle it's tempting to divide the responsibilities so that there's a single person responsible for a part, but I would advise against doing so. It will limit the shared code ownership and most probably create bottlenecks. All parts of codebase should be familiar to more than one person.
Design and testing
Depending a bit on the case, next I would get a designer or a tester. If the solution needs to be operated by a user, I'd go with designer. If most of the magic happens in the backend and no-one cares how butt-ugly the product is, then first concentrate on making sure things work. Don't get a tester, but a person who is familiar with testing and can create automated tests. But testers think differently than coders, so better get one onboard.
Now you probably have quite standard software development team. Either get someone who has prior knowledge about agile software development to act as scrum/kanban master or select a person from the team that is most interested to learn the topic. With the help of this person the team will start an exodus to become a self-managing, self-organising cross-functional team that turns Product Backlog items into working software.
Scaling up
Splitting
Natural way to scale is to increase the team size by recruiting more and more coders and maybe domain experts. Once the team is so big that regular meetings like daily scrum are no longer efficient, it's time to start thinking about how to split the team.
When you split the team, think carefully how the new teams divide the responsibilities. Let the tech people decide what suits them best. When you have the second team, make sure that also contains all needed competences, including test automation.
Centralized competences
Some roles might not be needed full time in the development teams. It might make sense to centralize these to a different team that can support multiple dev teams. Architecture and design can be such skills that they can be in a common team.
When the work is divided between multiple teams it is also a sign that your operations need to raise to a new level of professionalism. It is a good idea to recruit someone to take ownership for the documentation. Security is also more important and maybe worth having someone concentrating on it. And since there are multiple teams (possibly) working on the same codebase, someone should spend a bit more time on setting up proper integration and deployment practice. Also it is worth thinking about how the teams coordinate and synchronize their work. Some scaling framework could be beneficial. For me Scaled Agile Framework is the most familiar. It also provides guidance on how to plan and execute things when you have multiple teams and also implement continuous improvement.
Get going
When you have recruited people to fill more than one development team and staffed another team has some centralized capabilities, it is time to plan how you shift the gear. This part requires a bit more effort on planning and discussion. I find it practical to have a person write down instructions that offer not too much, but enough details about how the new setup works. Then it is time to just agree on starting day and get going. Execute the initial plan, stop to reflect how did it go, adjust and repeat. That's how iterative and incremental practices work.
Tools
There are some tools that have become almost industry standard for supporting agile software development. Some tools have a lot of different features integrated to them and can handle a big part of the development pipeline. But I will give here an example of pretty traditional setup.
Backlog handling
For handling the Product Backlog, a pretty easy choice is Atlassian Jira. You can create and prioritise backlog items, track bugs and follow progress. If you are using Scrum, Jira offers possibilities for having burn down charts for your sprints. You can also easily visualise the workflow with kanban board and customize the columns to reflect your development process steps (like coding, code review, testing, etc.)
Version Control
The only version control tool that I would recommend is Git. There are multiple commercial tools that you can use that offer different additional benefits. Here are a few: GitHub, BitBucket, GitLab. Access rights control to the source code is probably the main thing, but maybe next in line is the possibility to use pull requests. Instead of pushing things straight to master you should consider a workflow that fosters shared code ownership and transparency. Code should be reviewed by someone else than the writer before merging.
Continuous Integration
Some Continuous Integration (CI) system will help you to automate your process. If the code needs to be compiled, the system will do it. In addition it can start the execution of automated tests, usually starting with unit tests. Some examples of CI systems are Jenkins, Drone, Bamboo, CircleCI, TeamCity and Travis.
Static Code Analysis
For static assessment of your codebase quality I would recommend adding a tool like SonarQube to your pipeline. It can help you measure how readable your code is and how good your test automation harness is. It will cover also security vulnerabilities.
Deployment
Then you probably need some place to deploy your solution. Either you invest in hardware or you use cloud services. The most common public cloud platforms are AWS, Azure and Google Cloud. If you are using containers, you can orchestrate them with Kubernetes. If you can spend a bit more bucks, you can use an enterprise solution like OpenShift.
Documentation
Quite a standard way to build and maintain living documentation is through Confluence. Pages have version control and editing is very similar as in Wikipedia. They can be exported in multiple formats, such as pdf, word or html.
Possible pitfalls
Recruitment
If creating awesome applications and products that users love would be easy, everyone would do it. But it's not so simple. For starters, there's a shortage of skilled workforce. This means that people who know the craft also know their value. And since the whole world is getting digital, there are lots of companies that are willing and able to fight for the talent and offer high salaries and different perks. So, even if you can recruit a team, you might lose members because some other company 'buys them out'.
Culture
Another thing to understand is that the results that an organisation is able to produce are a lot more dependent on how well the people work together than how good the individuals are. It doesn't mean that you can achieve great results with mediocre people. But it does mean that even with highly skilled persons you can fail miserably if they don't get along. Culture makes a huge difference. If people feel safe to show their vulnerability and admit mistakes, everyone will benefit. With retrospectives and conscious continuous improvement efforts teams and teams of teams can raise to a whole new level of performance.
Edit 1: Added some sub-headers for easier navigation of topics.
I'm not really much of a manager. Probably a slightly better coach, but mostly I'm a leader. I can give people direction and help them find the path. I don't like to tell them exactly what steps to take, just where I want them to end up. And when possible, I can walk in front of them or with them depending on the situation.
But I have a problem when I don't know where we should be going. Usually the company Vision and Strategy give guidance. But when the strategy work is still ongoing, one needs to make do without one.
In uncertain conditions it might be good to go to basics, identify the 'axioms'. When there are many unknowns, what can you rely on?
What can you rely on?
What me and my team decided to do was to improve our own group work. We are a loose group of people who work in the customer front in different roles. We are also guiding the work of others as project managers and team leaders. If we can work together seamlessly, it benefits the whole unit.
We decided to work more in pairs and coach each other. Some wanted to expand their profiles, some wanted to still concentrate more on their current role. We also decided to invite each other to our retrospectives and to arrange sessions specifically for sharing knowledge. Then we decided to change our work planning meetings (that had previously concentrated on resourcing) to sessions that combine resourcing, ongoing projects and new sales cases to get a better visibility to where we are and where we are going.
Add visibility. Prepare for changes.
These changes will increase staff liquidity, our visibility and our ability to respond to changes (which I call agility). Regardless of what the new strategy will be, these changes will help to implement it.
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.
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!
Think about software development. I'm assuming you have an image of someone writing code in your mind. Well software development is that, also. But it's also much, much more.
In my company I'm responsible for the software development in this more broader sense. When I think about software development, everything begins from the customers. Developing software is solving customers' problems. Selecting what problems to tackle as a company is a strategic choice. Strategy narrows down what you develop and helps the company focus. Probably it also states in which markets you want to compete in.
Strategy helps the company define it's portfolio. What customer problems we want to solve and what kind of solutions we offer? The solutions can be products or services. Strategy should guide you in this. If it doesn't, refine the strategy.
Let's now assume that in your offering/portfolio you have product(s). Each product should have a vision. What the product will be in the future? What customer problems will it solve when it will be in it's ultimate, final form. (This form will never see the daylight. Vision serves as a distant goal, something to strive for. It's an idealisation that will be even more magnificent when you get closer.)
Vision will help you define a roadmap. Where as vision can be hazy, the roadmap should be really concrete and tangible. I think of roadmap as a guidebook for the next steps toward the vision. If your strategy is planned for the next 5-10 years, roadmap could cover maybe 3 years. It's worth noting that it's still a high level plan and as for any agile plan, subject to changes.
In software development roadmap is implemented in releases of new software versions. They are usually developed in iterative and incremental fashion. Old functionality is modified and improved with new features and bugs and defects are fixed. Many times companies try to shorten their release cycle. The ultimate case would be Continuous Deployment where every change would be deployed to customers. But this is very much industry specific. In some cases the overhead of taking new software version into use is so big that customers don't want to do that often. Then it's practical to select a release cycle that suits both the company and the customers.
In agile development, software is usually created by small teams in an iterative fashion. The length of these iterations or sprints is usually limited to less than a month, a little bit depending on the selected methodology. Sprints are like mini-projects; they are planned, executed and in the end there are sessions for examining the results and for learning from the experience. ...and then cycle starts over again.
Daily work in sprints is carried out by the development team. Developers are experts in their field and select the most fitting methods for the implementation. They have the authority for carrying out daily decisions.
We got to the part where the coder writes source code. But as there are many layers in onion, there are many layers in software development. Writing the code is just one of them. Never the less, it's an important craft if the software is to be of any use and even more so if it is to be maintained.
Last month I wrote about my intention to try Cycle Time as a metric for software development. Back then it was still hypothetical, now it's real. Maybe it's still a bit early to draw any final conclusions, but it's already evident that I failed miserably in communicating the reasoning behind the change. And the criticism is well deserved.
I selected the average Cycle Time during past month as the metric for each team. In a way it is a good metric and gives indication about how quickly the value was realized after the work on a backlog item was started. But all backlog items aren't equal and also work type and intensity differ during the release cycle. In the beginning of the release cycle teams mostly work on the new development. Nearing the end the period emphasis is shifted more towards testing and bug fixing. Issue life cycle tends to be much shorter with bugs than when creating new functionality.
It is also questionable if one monthly average number can help in decision making, in essence serve as an actionable metric. You can see the trends in longer time intervals, not much more than that. Another angle is that a team can be really mature and produce outstanding results even though they don't split their Stories into very small parts. Their average deviation can be small and thus predictability high.
Then again I feel that the metric got a little unfair criticism when it was compared with Lead Time. In the end the company is interested in how the customers experience our products and services (Customer Experience = CX). But this includes many topics that are out of scope for software development. Like the company brand(s), how salesmen conduct their business and how the customers are served by the customer service. I think the software development part of the system (company) can greatly affect the User Experience (UX).
I would love to get the big picture correct. So personally I feel that the CX is more important than UX alone and Lead Time more important than Cycle Time. But in both cases the internal part is relevant component of the whole and deserves a metric of it's own. (It would be so cool if I could somehow bundle measuring UX and Cycle Time somehow... Probably there's no such easy connection. I think relationship between Lead Time and Customer Experience is much easier to show.)
Now the current bleeding edge is to try using the whole information provided by the JIRA Control Chart instead of simply one number. I haven't yet figured any cons, but on the pro side you get trend lines of where the performance is developing and standard deviations. Of course you can still identify the release cycle from this data, but you can draw other conclusions too. Increases in rolling average or standard deviation can signal trouble. And when the figures are followed regularly, the team can be aided in a timely fashion.
Currently I feel like I'm making too rushed decisions. I'd like to involve other people more and ask for their input already before I make an experiment. Now I mostly just measure the impact and make amendments, but I'd like to concentrate on this more. Let's see if the Santa Claus and New Year will bring a difference. In case this will be my last blog post this year, I already wish you all Merry Christmas and Happy New Year!
I'm currently reading a book about Organizational Patterns of Agile Software Development. In addition to the interesting patterns I was especially attracted to the chapter about anthropological foundations. The book also opened my eyes to see that processes alone are not enough. I've written about this before, but my view was reinforced once more.
Continuous improvement with processes usually only deal with Single-Loop Learning. We inspect the results of our immediate reactions and then make corrections. Usually this is ok for a team that is building software in iterations. It's about following the rules. But when we go a bit higher, it maybe isn't enough anymore.
The second level, Double-Loop Learning was introduced to me by the Lean Startup book. In that method we still make small modifications as often as possible to learn fast, but we also can choose to either pivot or persevere. Do we want to keep on chasing the selected goal or should we select another target? Already this felt to me like something really awesome. Someone has even described the ideas of Lean Startup as possessing super powers. (I wouldn't maybe go that far, but it's a good book.) On this second level we create more insights about our actions. It can be also characterized as Systems Thinking.
But I wasn't aware, at least consciously, of the next level: Triple-Loop Learning until now. Jurgen Appelo writes about it in his blog post and Thorsten Gragert's wiki site offers a nice a summary including the below figure. The 3rd level deals with principles. In organizational context I'd associate it with company values and learning about learning.
Figure adopted from www.thorsten.org
By digging a bit more I found this article about Learning organizations. Interesting concept. They have the following five main features:
systems thinking
personal mastery
mental models
shared vision
team learning
I think I need to give this a lot more thought. And try to lead my organization further on this path. Maybe I will coin a term #BeyondAgile. :)
And finally, as a somewhat sidestep, I'll share a some tips I have spotted from many successful organizations:
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...
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!
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.
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.
-SEAL_students_carry_an_inflatable_boat_along_the_beach_at_the_Naval_Special_Warfare_Center_at_Naval_Amphibious_Base_Coronado.jpg)
