Team Agility

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.

This post originally appeared in my LinkedIn profile. Feel free to check it out too.

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.

Slack & Blink

I read Tom DeMarco's Slack and it made me question my own role as a process owner. The whole book seems to be somewhat manifesto against the sort of 'efficiency' that targets keeping everyone busy and also for management by objectives. The second one has been criticized ever since W. Edgar Deming, who I most relate with systems thinking.

In the end, Slack isn't against efficiency. At least that's my interpretation. It tries to make a separation between making individual parts (seem) efficient (busy) versus making the overall system efficient. I guess the lean approach would anyway consist of having enough slack to keep the flow smooth.

Another topic Slack points out is the culture of fear and how it can effectively prevent organizational learning. In a culture of fear organization you can not take time to learn new things. You always need to be efficient and busy. Inevitably this will keep people in their comfort zones because taking the time to try new things is just too risky. To transform such organization into a learning one you would first need to make people feel safe, cut off internal competition (between units or other silos) and give people enough slack for deliberate slower-than-expert training.

Slack got me thinking about process development. Just to keep in mind that busyness and effective value delivery are two very separate things. I sure hope it stays clear to me. Reminder from time to time doesn't hurt.


After Slack I started reading Malcolm Gladwell's Blink - The Power of Thinking without Thinking. It concentrates on our first impressions and thinking that we do unconsciously. I think it's very much related to Thinking Fast and Slow by Daniel Kahneman. (Now I realize that Gladwell wrote Blink six years before the other book. I just read them in reverse chronological order.) I analyzed Kahneman's book in my previous blog posts (here, here and here). Blink also supports the idea that we operate a big part of our day on an autopilot. Many of our choices are just too import to be left for our overanalyzing conscieousness. Instead they are made more efficiently, unconsciously.

Interestingly, we cannot tell how we end up with our unconscious choices. They happen 'behind closed door'. There are many studies that indicate that we don't have a clue. We can say we like this brand more than that, but usually the reasons are not known to us. And the setup of the experiment also matters. In short sipping test Pepsi usually wins Coke. But when you drink a whole bottle at home, you might change your selection. Or artist that you don't necessarily like after hearing a short sample might still be a huge success live.

Both books have been really enjoyable and worth reading. I can easily recommend both of them.

Facing the Inevitable

Layoffs, bankruptcies and people losing their jobs seems to be almost like a trend nowadays. For the previous generations it was possible to graduate, get a job and finally retire with a gold watch after working in the same company for all of your career. If someone now has something similar in mind it almost feels naive.

Of course there are always exceptions. And probably there's big variation between different companies. But I think everyone needs to admit that things happen faster than before. Fortunes are made and lost in mere days, maybe even faster. Robots handle transactions at the stock market. One of the big dilemmas seems to be that there's a lot more data available than before, but it seems increasingly difficult to distill the important messages from the background noise. Do we have time and wisdom to understand what we measure?

I have adopted some rules of thumb from what I've read. I don't anymore think that people will spend all their lives in the same company. For my own company and team I try to create best possible circumstances for them to work. Create a system that they can feel connected with and achieve something. Exchange their free time to a hopefully competitive salary (I don't have much power over this) and to tasks that are intellectually challenging, foster their creativity and when ever possible, can be identified as things that move the company towards some greater goal.

Another thing to consider is situation when company needs to let some people go. It always feels bad. But sometimes it is inevitable. I think about Nokia as an example. If you manufacture normal, non-smart phones and people don't buy them anymore, the situation is tough. There's no easy way to increase the sales. Maybe you can find a new market where people still would prefer these 'old school' phones, but that doesn't change the fact that globally the demand for them has gone down. And will not go up anymore in the foreseeable future. And if your organization consist mainly of experts in this field, management doesn't have a multitude of options. You can wait until your bank account is empty, but in the end the result will by inevitable and ugly.

In the end the choices are to go out of business or face the facts and adapt. Things that worked in the past do not work anymore and you need to come up with something new. You will need to develop new competencies and be bold enough to let go of the past.

For some this is a cruel message. For some it can be a wake up call. My best advice for everyone could be to keep challenging yourself and to learn new things. If you learned to do something 10 years ago and continue to do the same year after year... one day your services may not be needed anymore.

Stay curious and find out new things. Experiment. Stay agile and adapt to the changing environment. Learn everyday!

Loops of Learning

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:

1. Dream big
2. Hire the best people (who share your dream)
3. Stay out of their way
4. Share the success

Personal Change Management

Despite the risk of sounding like an arrogant spoiled brat, I'll write this anyway. I have realized that moving from a developer role into management isn't just dancing on rose petals. And if you still try to participate in the development work, you experience brand new problems.

On one hand you feel like a member of the team. You participate in the work and you might even be good at it. And you know that it's value adding work. But due to your other duties you constantly feel that you are not doing enough. And you can't pair work as much you would like to, because it's rather time consuming. (Although I think the results are usually better than when working alone.)

On the other hand, you have your new management duties. In my case it means both being a supervisor and a Product Owner. A lot of coordination and simply communicating with other people are needed. I need to maintain the Product Backlog and sometimes even have unpleasant conversations.

I feel that upper management and the rest of the organization (and probably in the end even my team) would like me to concentrate on my managerial work. From systems point of view I understand it. The body benefits more if the lungs don't try to act like blood cells or brains as fingers. And I consciously try to do that. But it's a bit unnatural and I still feel like I'm pulled in two directions.

I'm not sure how common or rare this is, but I've perceived that I'm not the only one suffering from this problem. As a conclusion, I think the problem is mostly just between ears. When a person changes his/her role, it is more often that (s)he isn't able and/or willing to let go of the old duties. Unlearning is hard. But if you want to initiate change, you have to start from yourself.

Behind Enemy Lines - Project Days 2014

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Development Discussions

When I think about development discussions I have a bit mixed feelings. I strongly feel that people need to be nurtured and given chances to develop themselves. They should be encouraged to find their current limits and surpass them. Organization needs to support employees professional development by allowing (or even insisting) time to be allocated for practicing and learning new things. But then again, the initiative should come from the person him-/herself.

One of the saddest things I know is when people afterwards say that "no-one developed me". In this case afterwards means when people have been fired due to their low performance or because their skills have been outdated beyond repair. Fortunately these are extreme cases, but I also feel bad when people who still have jobs are not interested in learning new things.

I seriously doubt that it is possible to learn everything you need to know in school/university and then just apply that knowledge at work until you receive a gold watch and a nice retirement package. Maintaining your attainments is simply a must. And not just in a niche speciality area. Let's say you knew everything there is to know about VHS cassettes. After the introduction of CDs, Blu-Rays and set-top boxes rules of the game changed. The things you knew just weren't valid anymore. Or they were valid alright, but no-one cared because no-one used VHS anymore.

And this is why I believe everyone should craft their own development plans. Your knowledge/career is your product and you should be managing it. Think about where you want to be in five or ten years and what skills you still need to obtain. Then keep that in mind in your next development discussion. If you don't say it out loud, how can your company help you reach those goals?

Set your own goal, keep it in mind and pursuit mastery. External motivation is so 90s. :)

Scaling Agile Peer Conference

Agile Finland arranged a nice peer to peer conference around Scaling Agile. Venue was Life Science Center in Keilaniemi, Espoo. First of all I have to say that facilities were excellent. Top floor sauna with a sea view.

Participants had been pre-selected and there were people from eight companies. All the participants were required to write an experience report about how they had scaled agile or transformed the organisation into a more agile form. The seats were arranged so that everyone could be in eye contact with all the others and discussion was very easy. 

The day was packed rather full. We started already at 8:30 in the morning and finished around 17 o'clock in the evening. As we agreed not to share too much about each others practices and processes publicly, I won't get into details. But some interesting topics/practices I dare to share were the 24 h hackathon, group Backlog and a team building event where people had to self-organize into teams. Also, a topic that was common to almost all the participants was the Product Management. That's the not-so-trivial interface between business and development. Maybe that's the unicorn of Agile. ;)

I'd like to mention a very interesting facilitation technique called Open Season. Everyone had four cards: green, yellow, red and blue. Green indicated that you want to start a new discussion thread. Yellow meant that you still want to add something to the current topic. Red meant that you need to speak right away and blue that this is boring and let's move on. Red and blue were never used, but otherwise the conversation worked very well! Actually you can find a rather elegant guide on how to arrange a peer conference from this blog entry. I think we followed it very closely.

My best take homes were definitely the new contacts. Hopefully we can grow even more agile together! Also it was nice to get to know how other companies have been scaling agile. And by the way, if you ever think of arranging a conference like this, think no more. Do it! It will be great.

Failure, It's Not a Bad Thing

I stumbled today into a new concept. It is called Day for Failure and I think it is very interesting and should be recognized more publicly. The web is full of those 'motivational' pictures about epic fails. Those are amusing. But on the other hand, I think failure is seen many times in too negative way.

Failure is a blessing! It tells you that you did something that you shouldn't try again. It's offering you valuable insight about how life works and something even more important. Failure opens a door for learning.

Mr. Edison might be the most known people to fail. Or as he puts it, found ways that don't work. But I think the main message is this: you only fail if you give up. If you make a mistake and learn, you haven't failed in this negative sense that so many people use. Or we can call that failure, but it's still a good thing.

Lean Startup along with the concept of Validated Learning has been one of my favorite books. Probably due to it saying the same thing. Experiment. My mistakes. Fail fast. And then try again. The faster we fail, the faster we gain more knowledge. And the safer and less costly we make failing, the more we can utilize its awesome power.

So next week, on October 13th and after that, start building a new culture at your workplace! Share and celebrate failures. They offer you and your colleagues information and learning you could never achieve by always staying on the safe side. And by sharing the experiences, you don't have to repeat the same failures but can try new ones.

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.