Snips and Snails, and Puppy Dog Tails, is that what Agile Leadership is made of?

Let’s face it, we are all doomed. But it’ll take some time before this madness ends. And during that time the world is becoming increasingly complex. The speed of change is faster than ever and more and more is demanded from the leaders. Managing actions and expecting results won’t get you there. Leaders who affect on experiences and beliefs are creating culture that welcomes change. It is quite easy to change those in present and in the future. Have an open mind, search for positive exceptions and find positive explanations. You will create more positive culture for learning and creativity. And by using techniques from NLP it is possible to even change the meanings of one’s experiences and beliefs in the past.
And this is why Agile Leadership is needed. These are some of the topics we went through on our two and a half day course of Certified Agile Leadership by Agile42.

Cynefin – Embrace the Suck

complexity-cynefin.jpgI’d like to return on one word from the past chapter: complex. It is the most interesting domains of the Cynefin Framework. The field of unknown unknowns is where one can

47e6eb3a1b82db01831fa600c120635f

deduce cause and effect only in retrospect. There are no right answers. Thus we as leaders need to create safe to fail experiments. We cannot solve complex problems with best practices. Software development is very much in the complex domain. Agile offers many tools for solving problems in that domain: reflection and improving, collaboration and continuous delivery. If you’re good, you will push many problems to complicated or even obvious domain for example by utilizing automation. Welcome the complex and do some magic!

Giving Your Team the AMP up

team-motivation.jpg
Motivating your team is sometimes difficult. Relying on extrinsic motivators such as money or using the good-old carrot and stick approach does not work when your tasks call for even rudimentary cognitive skill. And even when they do work – the mechanical tasks – you are using a shrinking pie. Offering teams the AMP – Autonomy, Mastery, Purpose – utilizes intrinsic motivators. And they do work! And yet again Agile has tricks for this one too. It introduces pull and self-organization for autonomy. It offers collaboration, feedback, and trial & error for mastery. And it gives you holistic responsibility for purpose. And there are many factors in this growing pie of motivators. Listen to your team and you will learn what will make them tick!

All Hands on DECK!

self-organization.jpg
Self-Organization is extremely important. The more responsibility the team has the more flexible, robust and innovative the team will be. As a leader one should make sure that the teams has a right direction and suitable environment. Removing unnecessary constraints is equally vital. The team will increase it’s own knowledge base as it goes on. And this will speed up the development. Aiming to Self-Designing Teams should be a standard in any agile organization. This means for example that team itself designs who belongs to the team and who does not. Of course those teams also manage their progress and process. And execute their tasks.

When Your Heart and Brain Are Happy Together

emotional-intelligence.jpg
To be a successful leader in an agile context one needs to have emotional intelligence. It falls into self- and social oriented parts. It also splits into how aware one is of oneself and how one handles things. So, emotional intelligence consists of self and social awareness, self management and social skills. Does things like self-confidence, empathy, self-control, initiative, visionary and good communication skills sound like the qualities of a great leader? Another wonderful thing is that one can develop each of these attributes.

Agile Meets Antifragile

Let’s step onwards from the team level to consider the whole organization. We should think more on what happens to the organization when risks realize or some crisis emerge. A fragile organization worries nothing and acts in a naive way. In an emergency it breaks, even in a catastrophic way. A robust organization can resist known stressors, and it should be a minimal level for any company. In a contrast, a resilient system reforms itself during disturbances. Finally it retains the same identity than before. Antifragile systems are the sovereign champions in the organizational map. They can increase their capabilities and grow stronger in response to stress. They are the truest of agile and learning organizations!

antifragility.jpg
To achieve this, there are some things one could experiment. Engage people more. Be empirical and apply local validation. Introduce teams to iterative & incremental development. Have some defined metrics. Create emergent standardization when you can. And this is basically what Agile Leadership is made of.

But Wait! There’s More!

Ok, say that you agree on all the above. But to shine and thrive as an agile leader you need good knowledge and understanding of agile values and principles. You need to deal less with things that are going wrong and help things go right more. Systems thinking will be useful. You should:
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
You should know at least three different leadership styles and be able to choose the right one for each occasion. Practice Benjamin Franklin’s Thirteen Virtues. Follow simple advice of Michelle Eileen McNamara “It’s chaos. Be kind.”

 

The forgotten part of successful craftsmanship

From late Middle Ages master craftsmen have produced beautiful and practical products. To create these products they used valuable resources from their limited inventory. The creative process required that they had a vision of what they where about to build. Without the vision, a goal, craftsmen would only waste valuable and useful resources.

Why should we focus on our Vision? At least two big reasons:

Purpose & Motivation
Decision making

image

Purpose & Motivation

In our daily life we wake up every morning. We do our morning routines and then we spend most of our waking time doing work. We all want to feel that our work is meaningful.

A good vision describes what we want to achieve and why. If a vision is compelling for us we can find purpose, feel our work is important and meaningful. Finding purpose will result in higher motivation.

If you are working on something exciting that you really care about, you don’t have to be pushed. The vision pulls you

– Steve Jobs

Decision making

Craftsmen are not machines, they have brains and have to do many decisions on a daily basis. How are we doing these decisions? How do we know, if the decision is bringing us closer to our destination?

A shared vision shows us where we are going, like a map is telling where we should drive. Navigating with a low detail map gives us sense of direction and this helps us to make those decisions. A vision shows us the direction but doesn’t restrict us. We should always be curious and creative, innovate and find new solutions.

Limited problem solving scope

Usually agile projects run in sprints. Teams plan their work for next few weeks and define a sprint goal. During a sprint we encounter situations where we have to make decisions. When the vision is not clear decisions are often made using the short term goal. It would be much more valuable if we would focus on the big picture.

Where is the vision?

In my experience many agile software projects fail to communicate the vision. As a result, teams find them working without a clear direction and this leads to poor commitment.

Successful start-ups are good at sharing their vision. Why? For two reasons, they need to know what they are doing and to attract outside investors.

We should ask ourselves, where is our vision?

In your work, find or define a vision that everybody can relate to. A good vision shows direction, gives purpose to our work and is emotional.

Thoughts on Tampere Goes Agile 2017

Last weekend (27th-28th October) I had the honour to attend Tampere Goes Agile as a speaker and guest. This was my first speech in agile conference and I was of course a bit nervous about it. On Friday night we met with other speakers to discuss about next days conference. We got an unfortunate information that the closing keynote will be cancelled. During our dinner we planned the ending of the conference to be a panel discussion around the topics that we found controversial among us. That decided we chose panelists and yours truly was also included. Well, I was anyways going to be nervous the whole day so why not.

trega1.jpg

Saturday started with opening keynote from Mika Turunen on gaining speed for teams. After that I headed to hear what Artur Margonari had to say. His talk was about using and customising existing frameworks and models for agile transformation. Interesting talk how he had applied SAFe®, LeSS with bits and pieces from Spotify’s ways of working. He stated that using best fitting parts for the problem at hand. In his work that worked fine and added transparency between teams and management.

Another interesting speech was about fixed price projects by Teemu Toivonen. He underlined the fact that even within the fixed scope projects can be done in agile way. A lot of the effort goes to managing expectations. You can’t predict the future and the further you go the harder even guessing goes. Or can you tell what is going to happen in next 10 months? If you keep your time for development short your guesses have better odds to be right and responding to changes is possible.

My topic was how to turn negative emotions within the team to a positive goal. Starting from individual level. Starting with finding your problem from distant feeling that something is off. After that working our way towards a happy productive team that wants to develop and move forward. I talked about avoiding the problems that occur when going through this process. There are many of them and I cant say that I included them all to my speech. Well, it’s still a start.

 

trega2.jpg

In total Tampere Goes Agile was a pleasant experience. I met a lot of nice folks and was surprised that many of the themes that used to be ignored were actually a subject to a true discussion. Not just for shouting opinions pro and against.

What can we expect in future? In the closing panel I said: I hope something new and better comes and clears the table. This does not mean that everything old is bad and must go. But as we are constantly changing and improving, there should be new way just around the corner. And of course, we want to be a part of it. Hopefully we can help. At least I don’t want to be the one who holds back change.

 

How not to suck as an agile team member?

Do you think of agile development as an act of freestyling and cappuccino drinking with no plans attached? Let’s just do something and deliver it to the customer, they will surely appreciate it?

I have news for you: that could not be further from the truth. My experience says that agile team and agile team member needs two thing above everything else. Those things are discipline and communication. The latter is quite self explaining (I’ll come to that later) but discipline? Is that like waterfall?

Agile is about reacting to changes and delivering small deliverables often. And to be able to do that a team must have a structured process and agreed ways of working.

Let’s take for example DoD which stands for Definition of Done. DoD tells the team what are the conditions a requirement has to fullfill in order to be called “done”. Like unit tests and code review. What happens if somebody is not disciplined and didn’t write unit tests for a task? The rest of the team thinks that they are done! And yes, I do know that there are ways to make sure that no untested code get’s into master branch in version control. Another example could be a scrum board. What if a team member doesn’t update his/her progress in real time? The rest of the team doesn’t have a clue how the team is progressing. Discipline.

One attribute of a successful agile team is continuous improvement. Of their processes. It is impossible to have a perfect process in place from day one. And if you don’t improve you rot. Teams start with some process and work actively to improve it. One way to make improvement happen is to agree on an intermediate goal and actively work to reach it. Everybody in the team has to do their part. Discipline.

So discipline makes sure that the team is moving into right direction and the whole team is in the same boat. And communication is the way to make sure discipline is in place.

Serverless 101 and Siili CraftCon

The second official Siili CraftCon was held before summer holidays 2017. It is an internal craftmanship conference for all craftmen and -women in Siili. This time it was half days and three tracks worth of pure skillz with topics such as “how to be a tech lead“, “data driven design“, “RPA” and more.

I had the pleasure of speaking about serverless architecture to the whole crowd as a closing presentation. Since I am a keen agile/lean fan I am also totally in love in serverless architecture and everything it has to offer in terms of reacting to changes and feedback and the ease of implementing new features and trying out new things.

Serverless means that you only need to think of you business logic. Everything else is taken care of by your chosen vendor. All big name vendors have their own serverless platform and services. In this context I am talking about PaaS (Platform as a Service) and FaaS (Function as a Service) side of serverless.

Some may include SaaS and (m)BaaS solutions into serverless context. SaaS stands for Software as a Service and like the name implies it includes software you configure for your needs. Some examples are Google Apps, Dropbox and Slack. (m)BaaS is (mobile) Backend as a Service and it provides some backend services, such as authentication, mainly for mobile applications.

FaaS is a subset of PaaS and means you write your function in you chosen language (or in a language that is supported by your chosen vendor) and deploy it. You also have to configure how the function is called. It can listen to events or can be triggered by an http request via an API gateway among other ways. Your vendor takes care of scaling it to your needs and you pay only for execution time. Wikipedia explains FaaS as “A category of cloud computing services that provides a platform allowing customers to develop, run, and manage application functionalities without the complexity of building and maintaining the infrastructure“.

PaaS includes lot more than just FaaS. Widely available PaaS services include messaging, databases, big data, analytics, file storage etc. They all are services you launch and configure. You can insert your FaaS function in a PaaS workflow and use all other available services with it. Again your vendor takes care of your infrastructure needs like scaling and backups and you pay for what you use. Wikipedia explains PaaS as “A category of cloud computing services that provides a platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure“. See how it differes from FaaS?

In short, serverless means you are responsible only for your code and your data.

In Siili we have a lot of internal serverless development also on top of all the fancy stuff we create for customer. We also have cloud sandboxes freely available for all Siilis for learning and trying out serverless stuff.

Thoughts about technology leadership

Nowadays we see the software development more like product development. It’s more common to work in teams instead of separate rooms alone (and communicating over tools). Today the team can really affect the working methods, tools etc. (like Agile Manifesto says).

Still there’s organisations who still prefer to use the old “traditional” way of managing top to bottom style, but assuming working agile. Strict processes might be recommended or required when we are dealing with for example life-critical systems.

If we look at the picture of Evolution of Management (above), it says that management and authority and trust is moving inside of teams. That’s a good direction because especially in software development the coders really have to know what to do to write the right business logic – so they have the actual authority to build the right solution which is based even more on Lean startup approach. There’s no responsibility handovers anymore – people are taking responsibility as a team, not based on roles or hierarchical levels – e.g. It’s not a designer’s responsibility to test  or code the system. Everyone must do everything they can to build a perfect solution regardless what the actual roles are – there’s only team of people, not team of roles.

About leading the people instead of commanding and controlling the resources and processes: it’s understandable hard to reborn as a leader instead of commander especially if the career has started in waterfall era. Nowadays managers are required to have a great social skills like empathy and flexibility. Today’s leadership in technology field is all about continuous improvement by making blockers or waste visible and focusing to removing them.

I see technology as a material like wood or metal. Technology can be crafted by developers. Somedays developers need to craft the tools of their own to do the things right, actually that’s pretty rare because there’s a pretty high level of standardisation of tech tools (for VCS or ALM).

The main focus of tech lead is to reduce the time between getting to know what to do and production installation:

Screen Shot 2017-09-07 at 9.54.32

Technology leadership is rarely evolved only in technology nowadays, because we have so much out-of-the-box tools or overall solutions for implementing the common scenarios, such as forms, wizards, web shops etc. It’s more about dealing within the team in social level (to enhance the team dynamics) – and at my point of view it’s definitely shouldn’t be related to technology at all. I see that the technology is going more high-end (naturally), but human-to-human communication should be in natural face-to-face form instead of communicating over tools. When interacting face-to-face, we have all senses in use, but if we work constantly remotely, it’s always harder to communicate over Skype – then you have only voice, maybe video, but there’s so much information you don’t see, and I see that harmful to team dynamics. It’s important to encourage the team to work as much face-to-face it’s possible – especially when the development is just started. It’s understandable not to strictly avoid remote work either – flexibility is one of the key assets of modern work culture.

Screen Shot 2017-09-07 at 9.56.36

Agile implementations like Scrum gives the framework to focus on the right things to answering the needs of rapidly changing world. As a tech lead it’s important to see also the social level as valuable as code – I mean how the team members support each other and really focus on the process and improving constantly.

There’s pretty effective principle for leading the tech team: If the product is broken in production, the problem is in the process – so fix the process to build the perfect product (actually it’s never perfect, or it shouldn’t be because of Kaizen).