Adequate Introspection as a Growth Enabler

After some recent conversations with my colleagues, I'm more and more convinced that identifying and accepting flaws in one's own behaviour and skills is a big requirement for self-improvement. During my life I've met multiple people who tend to find the reasons for failures always from circumstances, environment or from other people. This might be a good psychological coping mechanism for safeguarding one's self-image, but it's also pretty bad for self-improvement. People who do not find anything to improve in their own actions rarely do anything to do things differently. Because why would they? It's the other people who should change.

 

Life is hard if you cannot trust others. 

This might also be related to trust. Probably it's not a good strategy to admit and advertise your weaknesses to people that you do not know well. They may use that information against you. That's why building trust is also key for unlocking personal and shared learning possibilities. 

As an example of how things could optimally go, let's think about a well functioning team. When people trust each other and are ok with showing their own vulnerability, they can expose ideas or plans to others and get feedback.When everybody knows that the team is building something together, it's no longer about individuals and their ideas. Ideas are criticised, bent and stretched and built on top of each other. When the best possible solution is found as a result of combined effort, everybody benefits from understanding it. And everybody grows and learns. This is the one of the biggest benefits of well functioning team.

 In a well functioning team people collaborate.

But everything starts with trust and safety. People need to be able to be vulnerable and tell if they do not know something. If they need to wear a psychological armor all the time, (working) life is hard. As a leader you can enable trust by leading by example. Trust others. Tell if you don't know. Ask seemingly stupid questions (that often are not that stupid. No-one else just dares to ask them.) Before you can trust others, you need to be in peace with yourself. And admit that if things that you participated did not go perfectly, maybe you need to do something differently next time.

New Agile Framework

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.

By the way, I have written another blog post about this new framework in Elisa Hub (unfortunately only in Finnish). Feel free to check it out too.

Problems in Working Together

Maybe from my posts people can get a false idea that everything always goes as planned. Well, it sure isn't like that. In the following story there's plenty of lessons to learn and things to improve.

Two Teams

There were two teams working on a legacy product, let's call them team A and team B. (There were other teams too, but these teams are starring now.) Team A was working on the very core services and low level functions that other teams, including team B, depended on. Due to the fact that automated code coverage was not on very high level and the code base was really complex and not in mint condition, there were many times moments that things broke down even though all automated tests passed. And because team B was working on the application layer, they often found these problems. And they suffered.

Team A did mistakes. But they were always keen to correct their mistakes and open about development ideas. Approaching them was easy. You could walk into their team room and just state your business or ask for help. And they would help you out for sure.

The working model for the teams consisted of fixed deadlines. On a specific date things were to be done. Prior to this date was a so called stabilization/freezing period that was dedicated for bug fixing and testing that all parts of the complete system worked. One can imagine that closer to the deadline pressure was increasing.

During the stabilization period team B was blocked by some defects. They didn't proceed in testing because they didn't want to test same things again after the fixes would be completed. Unfortunately team B didn't make things easy. Usually they approached team A with JIRA issues. And we are talking about teams that handled plenty of issues a day, so prioritization and keeping track of all changes was a challenge. So sometimes it happened that the issues did not progress very rapidly.

At the time of deadline team A was done with their testing and didn't saw major blocking issues. Team B was about halfway done and still had issues open. And they were complaining that team A was blocking them. In the end both teams ran out of time and the common product was not releasable in time.

In Hindsight

Both teams made mistakes. One of the major ones was communication. In a small organization it should be more than ok to use the Adidas-method: walk to your colleague. Don't keep things in a desk drawer. Let the other person know about the problems in a timely fashion. Don't rely only on the tools.

Another major mistake is relying too much on automated tests if you have low coverage. I think it's a sure recipe for disaster. If your code coverage is 35 %, it means there's still almost two thirds of your code that needs to be tested manually. It is laborous, time consuming and demotivating, but it's a must if you don't want to give out buggy software.

In our setup cutting scope is possible. The rule of thumb is that schedule and quality are fixed, but scope flexes. This principle was not obeyed and the scope was not adjusted in time. And quality debt had been accumulated during development resulting in big amount of late bug finds.

Finally the whole fixed schedule model can be questioned. Is it the practice that creates most reliable and high quality software? Of course continuous attention to quality, vigorous testing and cutting the scope in time will make a big difference. But most of the time people are weak and things tend to take all the available time. I have started to lean more and more towards concentrating on getting things done and letting the schedule flex a bit.

Another text book answer would be that if something is difficult, you should do it more. If it's hard to keep three month deadlines, cut the time in half or even shorter. Then you will iterate more rapidly and get better faster. I'd like that too.

Different Roles in a Full Stack Team

I don't think life is a box of chocolate. But it keeps surprising me never the less. In my case that means that I keep finding value in different activities. Such that I have not done myself or that my teams have not done very much. Maybe it could be best described as evolution.

I started as a coder. Although people didn't say it out loud (often), making modifications to 'the core' was more spectacular than making modifications to the graphical user interface. Mostly the illusion came from the siloed organizational structure. People who do something like to think they are somehow better than those 'other people' who do other things. Which is silly, of course, but still very human. :)

But anyway, I was a core developer. I worked with a big legacy core and could do magical things with it. I could create new features and implement new parts according to the details people gave me. Testing was something that was often mentioned as a valuable thing, but generally praise was given more to people who coded.

At some point I started to realize that testing is, in fact, important. My code wasn't perfect. My mind, the mind of a coder, was thinking how the system should be used. I didn't give a lot of thought to how the system wasn't supposed to be used. But many times users come up with very creative ways of doing things if the tool allows. When someone tested my code, it became better. It had less bugs. So testers were, and still are, useful.

When you work as a group or as a team it makes sense to have someone who makes sure that things happen. I don't think it needs to be a coach or Scrum Master (but it's ok too). More senior team member with right personality and skill-set can be even better.

Then lately, since Apple introduced iPhone, usability has become increasingly important. If the team has a dedicated designer, that's truly awesome. But even having usability built into the working practices is good. It's easy to get carried away with improving the algorithms and trying to write really clean code, but forget the fact that in the end someone should be able to use the system. And hopefully be able to do it without consulting a thick manual. So design and usability are important too.

Finally comes the role of architecture. It's possible to live without named architects, but I don't think it's possible to develop software with multiple teams if the architecture is neglected. Architecture might emerge, but it might not be the architecture you want to see. I dislike the idea of lifting architects to a podium or letting be live in an ivory tower. In my view architect could be a role. For the sake of clarity it would be just good that someone (even if team members take turns) will check occasionally the big picture and make sure all development efforts serve the grand plan. So I consider architects to be important too.

As a conclusion my view of different (necessary) roles in a team has changed over the years. Originally I thought only coders were needed, but now I know it takes a bigger family to grow flourishing software. And in this post I've intentionally scoped out many important business roles. Without proper Product Management and sales there probably won't be anything to develop. But let's leave something also for the future. :)

Maintenance vs New Development

Blogoverse is awesome! Here everything I say is the truth, because there are no counter arguments. In reality it's not always that easy to get people convinced. :)

I'm giving here an example situation and my opinion for a solution. The readers are more than welcome to offer their opinions and join the discussion.

Our releases are planned in cadence. Teams craft their own objectives which we call simply Release Plans. Then the Release Train Engineer (which is me) gathers those so anyone in the organization can quickly get an idea of what will come most probably is coming out in the next Release. The Release Plan is a list of features and changes to the software that we predict to be ready by the next Release Day.

Now, depending on the magnitude of technical debt, maintenance burden, customer contacts and possible fire-fighting issues, some teams have a lot less capacity for developing new features. It can be that over half of their time is usually spent on something else than new features. Like fixing bugs or refactoring. Taking into account all the facts, that's ok.

Somewhat due to misunderstanding and also because it doesn't feel nice to present an empty Release Plan, the teams urge to have also the maintenance issues in their Release Plan. This would make it easier to communicate why they are not able to create so much new business value. Seeing how some people have failed to understand the difference between Release Plan and what activities the teams are doing during the release period, this seems like a valid point.

But personally I find this to be a dysfunction. I think it's the team's choice anyway how they spend their time. And since we have all the maintenance issues in our Product Backlog, the people who are interested in what's happening in the team's daily work can check the situation there. Or participate in the Sprint Reviews. Or go and have a chat with the team or just look at things are going. There's no lack of transparency, people just need to go and have a look.

I see an analogy between this and the work of individual team members in a Sprint. For me the essence of Agile software development is that we have skilled and disciplined individuals who are the best judges of how to do their work (and spend their time). No-one should be micro-managing them and telling how to do their job. It's an issue of responsibility. And trust. If you are more into waterfall, go get yourself a Project Manager. ;)

But as the Scrum Master is educating and coaching the team, I find myself responsible for educating the organization. Don't worry, I'll do my best. Challenges make life interesting!

Second Release Planning Day

Before the summer I wrote about our first attempt to do a whole company Release Planning Day. Since we do releases in regular cadence, now was the time to try this activity again.

After the first trial I had received feedback that doing everything in one day was maybe a bit too overwhelming. One concrete remedy was to divide the activities to two days. Another improvement that I was happy to witness, was that this time the Product Managers really prepared for the event. They discussed and worked on their Roadmaps together with the teams during the past couple of weeks. And this activity really paid of in the quality and in the level of realism.

People took the event seriously. Even though one of our Business Owners and a Product Manager were visiting customers abroad, they took the time to do their part in the agenda. Their presentations were broadcasted over a VOIP connection. But for me the message was clear: this event is really important.

The first day started as during our first time. The schedule for the day had been delivered to everyone already via email, but I briefly revisited the agenda. Then our Business Owners gave an overview of the market situation. What is happening now and how we should prepare for the future.

Next the Product Managers shared their Product Roadmaps. We are still working on these and lot had changed since the last Release. Mainly many not-so-well prepared themes had been dropped and returned back to the funnel stage. There were clear pros and cons for this approach. Now the organization was able to focus the attention on the few Epics, but on the other hand, the longer term visibility was missing from the plans. But I'm confident we can work that out in the future.

We are still figuring out our Architectural Runway and how to coordinate it on the Program level. But as the manager of our System Team, I used some time to tell about the tool changes we are about to carry out during the coming Release Period.

After the common sessions it was time to split into teams and start forming the draft plans. Teams collaborated with the stakeholders and tried to formulate the needs of the business into a realistic set of PI Objectives. Actually, in our company language we call these Epics, since that's how they are called in JIRA Agile. The lunch hour was also incorporated into the first Team Breakout.

The next common session was the Draft Plan Review. Every Product Owner presented their team's draft Release Plan. This way it was easy to spot if something was missing or required coordination with other teams. There were no major surprises. It was as if people had actually discussed their plans together. Oh boy, who could have seen that coming!?

After the Review there were two options. Teams could continue planning today or go home and rest. The next common session was scheduled for the morning of the next day. Since we have development team members in multiple time-zones, I thought it was ok to offer possibility to carry on the planning on one site and pick up earlier on the next morning on the other site. Also the splitting gave people more time to do the planning. And at least I felt rather exhausted in the afternoon already.

I don't actually know how the teams decided to do. Maybe some continued the planning, maybe some went home early. Anyway, the next morning we gathered again to a common session to go through the finalized plans. Most of the plans had not changed much since the draft phase, but I believe it was good to have time to digest them a bit and work out the dependencies if any. There were still some questions and comments but generally people were satisfied with the plans.

In the end I wanted again to have a vote of confidence for the plans. Just so that nobody could walk away from the event and say it was not their plan. At first it felt a bit silly. And it was. So in the end I turned holding the microphone to the crowd and yelling "DO YOU BELIEVE IN THIS PLAN!!?" And they did. :)

Release Planning Day

Earlier this year I wrote about our Release Pre-Planning. This time I wanted to take things a bit further. We had previously been discussing about the Release Planning Event described in the Scaled Agile Framework. Going for a two day meeting with the whole company sounded like something that could be useful, but would maybe require move convincing than I could do in a short period of time. But if I started with just one day...

So I made a preliminary plan for a one day's Release Planning Event. Rough schedule with the important events and list of requirements from some of the key actors like the Product Managers and Business Owners. Then I communicated this to our technology head who received a nice buy-in from the whole management. Of course something like this could not take place without a proper management support. After this I invited everyone in the company to the event.

Fig 1. Schedule of the Release Planning Day

As a groundwork, the Product Managers were asked to put their Roadmaps in order and the Business Owners to prepare for a short presentation about the current state of our business. All the necessary meeting rooms were booked. The main meeting hall has high level audio-gear with microphones and loud speakers. We have development teams on multiple sites. (Actually I booked almost all of the meeting rooms in the office to make sure people would concentrate on this event. ;) )

At the start of the day I gave a really short overview on what would be coming. Then we quickly moved into the business context. Our two Business Owners told us briefly about the most recent trends in the markets and what could expected in the future.

Fig 2. Different levels of planning.

Next, our Product Managers presented their updated Roadmaps. Figure 2 is very close to the view I have on breakdown of different levels of planning. Outside the outermost circle I would still like to have company strategy, but I'm lazy with the pictures. As the Roadmaps are still rather new concept for us, they again raised a lot of discussion, but in a constructive spirit.

Surprisingly after first hour and a half, we were still on schedule! After going through the Roadmaps I explained the plan for the rest of the day. The purpose for the whole day was to craft Release Plans for our product teams. In addition to those, I wanted people to identify the possible dependencies and potential risks. Making those transparent would help us address them later.

Then we had the first Team Breakout. People moved into their team rooms together with the stakeholders. Target was to get some kind of draft plan that could be refined later. This time period included also the lunch (most people are more productive if they get a decent meal during the day.)

One o'clock in the afternoon we met again with the whole company and started to go through the draft plans. This was also a time to face the reality and notice that some Product Owners and one Product manager were not present hence making it impossible for some teams to craft their plans. This was remedied by agreeing that those plans would see the daylight next week. No panic there.

But going through the draft plans helped to identify a couple of topics: as quite often, some of the plans were really optimistic. And there were dependencies between the teams and some general confusion about what to do. We didn't settle these problems right there and then. They were just identified publicly and settled later by the teams themselves.

Originally I planned to have a physical board for writing down Risks and Dependencies and a webcam for having it visible in the remote offices. Then I realized that it would make more sense to have the board in digital format, so in the end the things were written to a Confluence page.

Second Team Breakout helped to build more realism into the plans. At the end of the day we met again at the common square. This time the plans looked a lot more realistic and people gave a (really symbolic) vote of confidence on the plans. Some of the plans could have been refined a little more, but the results were satisfactory. We had plans for eight teams working in three countries!

After the day it was quite clear that this will be a practice we will keep on doing. Personally I was really happy to see people take this seriously but with a small twinkle in their eyes. People participated, teams got their Release Plans and people from business and development worked together. In the end, I believe that's the essence of Agile Software Development.

Some things that were left for the next time: estimating the business value of the release objectives and things regarding the architecture vision. Also worth considering if this could be worth spending the full two or one and a half days on the topic. At least I think it's better to have it in one go than to plan for weeks.

Importance of Trust

It's fascinating how important trust is in Agile software development. It appears in many studies as a characteristic of effective teams. And trust can also be found as a decisive factor in whether distributed team succeeds or fails.

It's easier to trust someone you know. Even meeting a person once can make a big difference. After that one contact it is much easier to continue the conversation via some other tools like VoIP. That's the reason why even teams that are destined to work remotely should have at least some time under one roof in the beginning. This investment will pay off in the long run. (Face-to-face conversation is the best form of communication (co-location). )

Another place where trust is needed is the interface between business and development. (Close, daily cooperation between business people and developers.) The lack of trust from business can be perceived as too much attention into implementation details. Management should only decide what is being built and why and the teams should decide how it is built. It's also not uncommon to hear that developers are slacking off.

But I think the deal needs to go both ways. If the developers don't want business people to meddle with their work, they should provide them with visibility and concentrate on working on the issues that make most sense from the business point of view. Not necessarily on the things that are coolest, can be built with latest tools or offer the biggest mental challenges. Hopefully in many cases these can be combined and making the things the users need can be fun. But in reality this is not always the case.

To me, one essential thing in Agile software development is the acceptance of uncertainty. The only certain thing is the fact that things change. If you want to stay successful, you need to be able to adapt to different circumstances. And you need to have people around you who you can trust. Show them the direction and trust that they will find the way. (Projects are built around motivated individuals, who should be trusted.)

(The sentences in parenthesis are quotes of principles behind the agile manifesto.)

Finally, I want to share a wisdom my father used to say: "Trust is extremely easy to lose and very difficult to win back." Works both in business and in personal life.

Children are Excellent Teachers

I recently had a discussion with my son's kindergarten teacher and she told me how my son's group has been teaming up very nicely. They play together and everyone has found their place. Some are carrying sticks, some build things from those while some of the others are more involved with the planning. When, inevitably, there's conflict, they say they are sorry and the situations resolve quickly. And when they do sports, everyone is rooting for the others like crazy!

If preschool children can do this, why is it so hard for us grownups?

When the organization is still going through the agile transformation, it's probably not uncommon that people only think about their own tasks. "I have done my part. It's not my fault if the others don't keep up." But in an cross-functional Agile team you are not merely accountable for your tasks. There are no "your tasks". The team has goals and the team members are ALL equally responsible for the results.

This will probably become clearer over time. But in a bigger organization, I'd like to reach the next level. I see an analogy between one team and a Sprint and between several teams and a Release. My personal vision of a larger organization is such that teams working on the same product pull one rope. If one team is struggling and the others have finished their commitments, they will help. No team is left behind! And maybe in a larger organization this would scale up still one level, but I have no first hand experience about that.

Great things are achieved through doing things together!

People are Weak, Teams are Strong!

If you are familiar with Scrum, you have probably read that Scrum is different. It's different from the management point of view, but also from the developer perspective. In an expert organization where everyone has been a sort of a super hero, it feels weird to suddenly be part of a team. No-one is telling you what you should do next. And you have to be in close collaboration with your team members; possibly for the first time during your career.

Although in literature I often see that the lack of management support is a big impediment for Scrum adoption, I'd say that the employees themselves can also create interesting challenges.

It takes time before people accept the fact that they can get more done when they work as a team. If you have five tasks and five people it is not the most efficient way to start working on all of those at the same time. If you are familiar with Lean this is probably crystal clear to you. But in real life, it's not so easy to let go of the old habits.

Alone you can do small things, but if you are aiming to go higher, I advice you to take a team with you!

On a Ride with Heroes (or Bad Apples)

I went back to work today and read two interesting articles. First one was about "bad apples" in teams. Probably quite many are familiar with these people. At least I can admit that I have seen these.

It is very odd that when the company is going through a challenging period of moving from old way of working into a more Agile way, some of the most senior people see as their divine right to protest. In the past these people have been the heroes of the company: solving the impossible problems at the last minute, making that needed fix in no time and knowing almost everything about their domain.

Somehow these company's finest become anti-heroes. They start to undermine the Agile adoption process by not sharing information with their team members. We often call these people "cowboys". And because of their superior knowledge (especially when dealing with complex legacy software), just showing door to these people is not the option that management is eager to take.

In my opinion, the option the company is left with is to motivate these individuals. Try to see what makes them tick and show them how Agile can work for them. And maybe pipe down about the process talk and concentrate on how they can maintain their status as experts also when working together with a team. But it is not easy for the team. That I can assure you.

The second article was about Ericsson adopting agile. It is always soothing to see others have some similar challenges and we are not alone with our problems.

Creating value through Agile Coaching

I just spent one week at the summer cottage relaxing and going through my thoughts. One thing that I pondered was that do I practice what I preach? I do agile coaching and I'm interested in lean startups. Am I really adding value to my readers with this blog or am I just making waste?

I truly hope that the unique combination of different disciplines that I bring to the table offer some value for the readers. I have been recently interested in Scrum, agile frameworks in general, lean startups and lean thinking, testing, Deep Leadership, software craftsmanship and from my previous career working with legacy software. I'm pretty sure there are many others that have similar backgrounds, but hopefully no-one else with exactly the same. But if you do, please tell me how I should continue. ;)

My tips for today are simple:

• Empower the team
• Try to make them realize limiting work in progress brings results
• Trust and collaboration is the key
• If possible, test your ideas with real customers
• Don't be afraid to pivot if you need to
• Seize the day and enjoy what you do (each day)

Respecting Other People

I think one key ingredient in forming a working team is the respect of other people. People may have different skill sets and they may live in different countries. For as long as we see each others as individuals and equals, we can achieve great results.

I think some people, and maybe more often people with academic backgrounds, have a tendency to look down on others. With distributed or virtual teams this is even easier than in normal teams, since you don't have to see the others face to face so often. It is easier to start thinking about "us" and (or even versus) "them".

I would place respecting individuals and trust as the top characteristics to look for in people who are supposed to work in multinational distributed teams. And of course willingness to learn. But that's probably a must have in knowledge work anyway.

I think in a Scrum Team the Scrum Master should be the champion of these values. Constantly showing example of respecting others. Architects or newly graduates, it doesn't matter. Everyone in the team brings their contribution and help pursuit the common goal. And everyone deserves their place.

Live as if you were to die tomorrow. Learn as if you were to live forever.