And now, if I turn the image 90 degress clockwise, what do you see?
Most people will see a frog on the first drawing and will still see the same frog in the second drawing, but some people will be able to see a horse in the second drawing, and a few people will recognize both the frog and the horse already when looking at the first drawing.
Which one is right? Why some people see first a frog and why others see first a horse?
Our perception of the world that surrounds us can change as quickly as we learn and absorb new knowledge and experience. And that it’s totally ok!
The way you see or understand a situation presented to you is based on the frame of reference you have at that moment in your brain. It doesn’t necessarily represent reality. What you get is an interpretation of the reality based on your beliefs and experience, your mindset.
Another person with a different background and life experience might interpret the same situation at hand differently and build a different reality. That’s the reason why is so important to be super careful about what you think and really reflect on how these thoughts and interpretations are influencing your actions and behaviors.
The problem is when you don’t recognize this dynamic and believe that the map you have, which most of the times you don’t even know that exists, is the only one that matters and the truth. That’s when people start to become pushy, dictatorial, etc.
When you don’t accept that there are other maps and consequently other interpretations of the same reality, you’ll not advance yourself as a person. You’ll be a prisoner of limited interpretations. Yes, some maps are better than others. They have a better representation of the terrain and the key for me is that one can develop a mechanism for recognizing such better maps and improving her own maps.
Acknowledging this natural law and being open to evolving your maps, your frame of reference, is what will really make a difference in terms of personal and professional evolution over time.
There’s a lot of resources explaining more in details many roles in IT, but one in particular I think it’s not well defined or explained. The Feature Lead.
I have an overall idea of what this role should do and which behaviors or skills people on this role will have to develop or show in order to make the most out of it and really create an impact.
In order to share these thoughts I’m drafting an e-book that will bring a more detailed perspective on this subject. See below an excerpt of the first chapter.
What is a Feature Lead?
The Feature Lead is a role – a set of responsibilities – that can be deployed inside software development teams as a mean to empower people to take ownership and make decisions regarding the development of new features, creating a more fertile environment for growing self-managed teams as well as a culture of experimentation and learning.
The feature lead is the equivalent of a product owner on the technical side of things. That means that the Feature Lead will be responsible for taking care of all the technical issues that involves the development and especially the delivery of a new feature end-to-end.
Did you know?
The definition of what a “feature” is, as we know it nowadays in software development, was described by Peter Toad in 1997 in his process for software engineering called The Coad Method, that later evolved to become the Feature Driven Development process. The core of the Coad process was an artifact, created during the analysis phase, called “a feature”. It was similar to a requirement, except by the fact that it was written using a domain language which the project sponsors could understand. The main concept is that a “feature” should be written in a way that the sponsor could agree that the feature had meaning and was required in the system [1]. Doesn’t this sound like an old relative of User Stories?
Key points:
It’s a role and not a job title.
A feature lead is responsible for feature delivery.
Did you like it? See below the outline of the e-book:
When I look back to my understanding of agile and lean software development, when I first came in contact with these topics years ago, I do realize that I missed it totally at that time. Now, some years later, I do think I have a better understanding about it to a point where I feel comfortable to share with you some ground knowledge that I came to learn later and that made me see these topics from a totally different perspective.
Why do some people say that software development is an activity in the domain of complex systems or a complex adaptive process?
At first, you have to have an overall understanding of what complexity means in software development and where it comes from. The whole concept is far more closely related to a new way of thinking on how to do things than to a formal model that you can apply. But, don’t get me wrong on that because I’m not telling that this has nothing to do with science. Complexity is the subject of a whole research field in science. The act of programming a piece of software is something that can be simple and formal also. Thus, the complexity comes from all the other elements that are part of this process nowadays and the new way of thinking I’m referring to is mainly related on how to best handle all these interactions in order to extract optimal results out of them.
What I’ll share here is mostly empirical knowledge acquired during my journey – something based on my previous experiences. That said, let’s jump to the main characteristics of a complex system and understand how it influenced the current approaches we use nowadays in software development.
1 – Large number of inter-related elements
As far as I understand, a system is a set of inter-related elements that work together and depends on each other; no matter if simple or complex, every system will be composed this way. Complex systems have a larger number of inter-related elements when compared to simple systems. Also, complex systems’s elements frequently are not single elements but other systems that can also be complex. Thus, we can craft a definition of a complex system as being a system of systems. The human body, for example, is a good example of a complex system. Our body is composed of several inter-related systems with specific intents that only have a meaning when working together and in balance. Also, the environment where we live have a huge impact on our bodies, indicating that the environment itself is also part of the system.
As well as the human body, modern software development is composed of multiple systems that only make sense when working together and in balance. The market, customer, company, stakeholders, managers, leadership, developers, office space, computer, weather, and many more components are parts in this system. It might sound strange to consider the weather or the office space as part of the system right? But in fact, it’s not. The layout of the office or the weather conditions can also play a decisive role in how effectively you are to navigate through a complex system. A decision to be made on a really hot day on an uncomfortable place can be influenced by such factors. There’s a lot of research proving that, and this is something that rarely we take into account, right?
When I see software development approaches insisting on treating people better, providing better conditions for them to work, create better work environments, I immediately connect such efforts to the fact that they’re as well part of the complex system that is supposed to build quality software and play an important role on final results.
2 – Non-linear
You might remember from your math lessons what linearity means but anyways I’d like to give a quick and dirty explanation. Linearity is an observed property of a relationship; you have to have at least two elements interacting with each other – usually, each element provide an input – in order to observe linearity. When measuring the combined result of this interaction, a direct, constant and predictable proportionality can be observed. The result of the interactions between these elements can be represented by a straight line on a graph. Thus, linearity is the idea that combining the input of two elements will yield the sum of the respective output [1]. Increasing or decreasing one of the elements n times will result in also increasing or decreasing the result n times. Now that we understand what linearity is, is easier to understand what is non-linearity. Non-linear relationships are unpredictable and increasing or decreasing one of the elements n times will not affect the result in the same proportion. Have you heard about the Butterfly Effect? This is a very good example of non-linearity.
Modern software development is non-linear because even a minor change can product disproportionated consequences. I bet you have heard that a small bug caused was the cause of a big disaster, right? Did you remember what happened with NASA’s Mars climate orbiter that caused a $ 655 million machine to be useless due to a conversion issue[2]? The size of the bug/issue is not even closely similar to the size of the impact that it caused. In day-to-day software development we made this same mistakes when we ignore for example the economics behind a decision to implement first a feature A instead of feature B, or when we ignore the impact that having a bad workplace can cause to your company’s results or even when we ignore the fact that not testing your software before shipping it to production is not a good idea nowadays if you want to iterate fast and build something sustainable by managing the technical debt you create and making things easier and safer to change later.
]? The size of the bug/issue is not even closely similar to the size of the impact that it caused. In day-to-day software development we made this same mistakes when we ignore for example the economics behind a decision to implement first a feature A instead of feature B, or when we ignore the impact that having a bad workplace can cause to your company’s results or even when we ignore the fact that not testing your software before shipping it to production is not a good idea nowadays if you want to iterate fast and build something sustainable by managing the technical debt you create and making things easier and safer to change later.
3 – Dynamic
The capacity of staying immutable is not something that appeals to complex systems because they change constantly and the outcomes cannot be predicted accurately. Usually, the outcome generated by a complex system is greater than the sum of its parts. In such systems, problems don’t have a unique solution. The challenge is to find one that can possibly solve temporarily the problem until the circumstances make it change again, forcing you to find a different solution for the “same problem”. Well, not exactly the same problem, although most people still believe it is. This phenomenon is called “emergence”. You might have heard already about evolutionary design right?
To understand better what dynamic means for complex systems, lets take a look in the car and the forest example. Imagine a car. Now imagine an experienced car engineer. Do you think that this engineer is capable of disassembling this car and reassemble it in a way that it stays exactly as it was initially? I do think so. Now think about the forest and all the elements that interact with it, such as: the weather, the wind, the animals – including us -, and everything else that affects the forest. Do you know any engineer capable of disassembling and assembling a forest? I don’t believe so. It is impossible to define the forest exclusively as the sum of its parts because forests are complex systems that constantly change and have relationship with lots os external systems that are also complex systems – winds, for instance -.
Modern software development is also dynamic. There is a principle in modern software development that says that the software design should emerge and not be defined upfront. Any clues why? Exactly! Is because while the circumstances changes – business scenario, user needs – the software design will also change in response to this “emergent” circumstance.
The best way to deal with this characteristic, is to use an experimental approach that can be able to fast respond to emergent changes on the environment. In modern software development we don’t impose solutions. Instead, we experiment in order to facilitate the path forward to be revealed. Thus, experimentation followed by sensing and concluded with a response is fundamental nowadays in software development companies.
Complex systems have a past that heavily influence the present. The decisions and happenings in the past shaped what the system is now, and this is something that cannot be reversed. This kind of systems evolves in response to environmental changes. The extent and depth of these changes are what makes the system reacts and change. This is a characteristic of evolutionary systems. Systems’ components and external elements evolve together on a series of small changes that leads to a certain momentary state.
Modern software development isn’t different. It’s heavily based on the premise that what we do should be a response to an external change. If the business context change, we should change. If the user needs change, we should change. If the market change, we should change. If the state of the art in technology change, we should change. This is something we know nowadays as “Adapt or die”.
We have seen many cases of big corporations that just disappeared because they were not able to change or adapt to modern times. Also, we constantly hear about the benefits of a start-up structure that due to its flexibility can easily change directions and explore quicker new opportunities or trends. In software development, we transitioned from the idea of specialists to the idea of generalists landing on a middle ground ofter referred to as “cross-functional” professionals. Such professionals have to expand their knowledge to other areas not directly connected to their specialty.
5 – Uncertainty
When you analyse a complex system by looking at its past, it’s somehow easy to reach the conclusion that you can predict how future events would be or that there’s a clearly defined co-relation between cause and effect that you can use for predicting future outcomes. Don’t fall into this pitfall. If you’re thinking like that, you’re forgetting that a complex system is unpredictable due to the constantly changing environments to which they are interacting with.
Modern software development is strongly dependant on the environment where it takes place. Oftentimes we refer to this environment as a “context”. I do believe that every context is different and modern software development practices should adapt to such specific contexts in order to bring any results. I’ve heard many stories on how people tried to use a certain approach that worked very well for company X but for their company it simply didn’t work. That’s because they missed to consider the context. Every process, practice, framework is created based on a certain context. If you don’t compare this context to yours when applying these ideas, you’ll certainly have trouble to make them work properly.
6 – Unordered nature
Unlike ordered systems, where cause and effect can be predicted with reasonable accuracy, complex systems can’t have such predictability. The complex interactions between its elements make cause and effect super hard to predict. Bear in mind that most systems involving living relationships are considered complex systems: people, culture, value, ecosystems, etc. And the best way to fight against this characteristic is to react to changes by using experimentation, prototypes and continuous adjustments.
Modern software development evolved into a scenario where it became unordered. Apart from very small cases where studies have shown successfully anticipation of customer behaviours, most of the time companies they to assess the current context and experiment something to see if this something is the answer that best fits the environmental needs at that particular time. Modern approaches to software development became much more adaptive and responsive to external changes nowadays.
Conclusion
Studying and understanding what a complex system is and how we can work with it could help us understand why do we have all these different ways of developing products and why they are framed in certain ways that sometimes seems to be so uncontrolled, chaotic. The point that all these approaches are trying to make is to find a way to enrich interactions between system’s elements, best react to environmental changes as fast as possible, and increase the chances to find the right answer for that particular moment with less cost. Acknowledge that the work we do is complex and you’ll be on the right track. If you try to solve nowadays problems with old tools, that I’d say that you should urgently reconsider your options.
An open question for further discussion
If producing software is a complex adaptive task and in order to deal with such tasks we need to apply experimental and very flexible methods in order to find the most appropriate answer, how suitable are these large scale approaches to such scenarios? Aren’t they too prescriptive to survive in such environments or trying to control an environment that cannot be controlled? Aren’t they trying to create order or bring linearity to a system that is by nature non-ordered and non-linear?
I watched Jez Humble’s talk at Agile 2017 and among many insights, one particular thing caught my attention.
He based his continuous delivery philosophy on the UNIX design philosophy.
I’m a big fan of UNIX and everything it powers nowadays. However, this connection between UNIX’s design philosophy and Jez’s Continuous Delivery approach was very intriguing for me. You can watch the talk here. Skip to minute 4:30 to watch the UNIX part of it.
I’ve read the referenced paper on his slide and surprisingly enough I discovered it very up to date as for what we’re having nowadays as trends in IT. You can read the paper UNIX Time-Sharing System: Forward. (McIlroy, M.D.; Pinson, E.N.; Tague, B.A.) here.
A quick Look at UNIX system design style and some parallels I made
Make each program do one thing well. To do a new job, build an afresh rather than complicate old programs by adding new features.
This principle could perfectly be a description of the overall idea behind Microservices. Also, I can related two of the SOLID principles with it: Single Responsibility and Open Closed.
Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
This sound a lot like an API and its relatives like Design by contract, APIs first.
Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
Impossible not to remember of a Prototype reading the principle above. Also, Iterations, Sprints, Fast feedback loops, Spikes.
Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
Workflow automation and supporting tools for software development such as IDEs, Analysers, CI/CD, Platforms, high-level languages, etc.
Opinion
An insight I had while reading the paper was realizing how pretentious or arrogant some inventors/creators are when they believe that they truly invented something revolutionary or even when we master certain skills that we ignorantly think is new but are nothing but old very good software development most of the times with a cool name or wrapped up on a framework.
This kind of material should be more available to every developer. I’m sometimes concerned with people that take courses on HTML, CSS and JS and assume they’re good developers right after finishing the course. They have so much to learn as I do even after all these years of software development. Also, all the agile movement should acknowledge that in the great majority of the cases they just made smart things invented in the past more accessible or sellable.
So in general, I started to believe that part of the truth on how to build quality and sustainable software resides in the past and it’s just waiting for us to discover it. Perhaps this will reduce a lot of the hype we’ve seen lately and we’ll be able to focus more on what we really like, well at least the great majority of us: Software Development.
This article is not about the Scrum Master, Product Owner, and Dev Team. Curious? I’ll explain what I mean.
If I ask you to propose a way to organize a team that allows the team to be as independent as possible and is also capable of enabling self-management. Which approach would you suggest?
I have the feeling that suggesting Scrum as an approach for this particular situation came to your mind. Although Scrum is a very good framework to introduce the agile way of doing work it doesn’t perform very well when it comes to helping your team to be agile. It tells you what, but it doesn’t tells you how.
I’ve seen recently many teams moving away from this standard way of setting up agile teams to a more tailored solution that takes into account the company’s culture, regulations, the type of industry. I believe that agile coaches or change agents with a certain experience have acquired sufficient knowledge to create or suggest a tailored solution that will fit better the organization’s needs.
Following a generic recipe, which is essentially what frameworks are, is not your only option when it comes to enabling an agile mindset and structure. Instead, you can think and use these generic tools as a reference, cherry picking or adapting what is there according to your environment’s needs.
For instance, you should take some time to analyze and understand where are the bottlenecks, communication ruptures, etc. Understand first the environment you’re in and after think of a solution that will survive on such conditions.
Different perspectives are what you need in order to create different experiments that will allow you to really leverage agile practices inside your teams in order to get better results. I’ve thought a lot lately about many agile related learned concepts that aren’t making much more sense anymore considering the different scenarios I saw. Contexts and people changed and I believe this is one of the reasons why I’m having such thoughts and feeling.
Having the abovementioned in mind, I’d like to share a different perspective to take into consideration when trying to build an agile team. Forget about which framework you’ll use, just make sure you have three voices inside your team.
The Three Voices
If you’re serious about autonomy and self-organisation and you really want a team that “is” and not just “do” agile than pay attention to these voices.
A team without one of these three voices will not be balanced and will most likely depend on external people that speak one of the missing voices. Still, even having all the voices, there’s no guarantee that the team will be able to self-organize because voices are just one part of the equation that results in autonomous and self-organizing teams. However, having the voices will increase your odds of success.
1 – Voice of Viability
Who takes care to check if what’s demanded is viable or not?
This voice is responsible to say to the team what are the market and business needs and what are the potential solutions to fulfill these needs.
A rough example: A company that produces software designed to manage cargo ship construction, will not likely decide to add smiles to the app’s chat because that’s not what the market is demanding. It’s not a viable solution for that particular business.
2 – Voice of Desirability
Who takes care of checking if a solution is desired?
This voice inside the team will be responsible for saying if something is being desired or not but customers. In order to do that, this voice has to understand the customer world.
It’s not very hard to imagine some viable solutions, but which ones will custorems be more willing to buy? Which ones have higher changes to succeed? These are questions that the voice of desirability is reponsible to answer.
3 – Voice of Feasibility
Who takes care of checking if what’s is viable and desired also feasible?
This is the most technical of the three voices. Usually the people that will transform the idea into something concrete – that can be consumed by users – are the ones that can express this voice and say if something is feasible or not from the technical perspective.
Make use you have these three voices inside your team, and your problem regarding autonomy and self-organization will be half-solved or at least will have higher changes of being solved.
Conclusion
If you ensure that your teams have these three voices inside and those voices can talk to each other frequently and in synergy, you’ll be able to build the framework you need for your team and organisation.
What’s the best structure for software development teams? How should I structure my team? Should I use the Spotify Model? Which other options do I have?
The questions above and many others come to the minds of people who need to structure a new team or want to restructure an existing one. Most people in this situation believe that the simplest way to do that is to follow a recipe. That’s what we have been seeing currently in the market. For instance, the “Spotify Model” is often mentioned as a recipe for structuring a cross-functional team that works.
Although fantastic, the ideas contained in the approach shared by Henrik aren’t suitable for all cases. In order to achieve success, you’ll have to have the same ingredients – context – that Henrik had. Otherwise, you’ll have hard times implementing some of the ideas.
Some time ago I did reflect on how we usually structure cross-functional software development teams. I did the analysis based on two perspectives:
Conway’s Law
Flow of Value
Conway’s Law
Conway’s law says that “organizations which design systems are constrained to produce designs which are copies of the communication structure of these organizations”
According to Wikipedia:
The law is based on the reasoning that in order for a software module to function, multiple authors must communicate frequently with each other. Therefore, the software interfacestructure of a system will reflect the social boundaries of the organization(s) that produced it, across which communication is more difficult.
I’ve heard a lot, and probably you as well, that Kanban is used as a tool to establish a flow and manage it. This flow isn’t about JIRA tickets. Instead, it is means flow of value, whatever your business definition of value is.
As a principle, everything we try to optimize should be favourable to improve the flow of value and not only favourable to speed or throughput. This means not all improvements are related to speed. Some might even slow down your current speed, but that’s totally acceptable if the flow of value will be improved. We know as well from Systems Thinking that local optimizations, such as focusing only on increasing throughput – are not the best way to optimize a system, especially a complex one.
There’s a fantastic book called Principles of Product Development Flow, which is not fun to read I have to say, that is super insightful and highly recommended for those who want to know more about what flow really means.
The two ideas aforementioned helped me to formulate a principle to guide my analysis.
Cross-functional team’s structure should have Flow of Value as a principle and fight Conway’s law to avoid knowledge segmentation and enable the creation of a learning organisation.Click to tweet
The Question
Based on the principle above, I decided to explore the following question during this analysis:
How should cross-functional teams be structured to allow for a flow of value and to fight against Conway’s law?
I’ll continue the analysis in the next parts of this article. Sign-up below to know the answer and suggestions on how to improve your cross-functional team setup.
A Feature Lead is a role, not a job title, that can be implemented inside software development teams. It might be starting point for developers aiming to become Tech Leads. This role is the equivalent of a Feature Owner but on the technical side of things. That means this role will take care of all aspects involved in developing and delivering a new product capability or feature.
Yes, it’s not something revolutionary and I didn’t invent the term Feature Lead. So, this article is just a description of what the role is about and some specifics of what is required from a person that wants to perform this role in terms of behaviour and attitude in order to become really good at it.
1 – Management and Leadership Skills
Until now the only thing you had to manage was your own tasks. When you become a Feature Lead you’ll exercise additional management skills. You’ll have to oversee the development of a whole feature, which includes not only having an overview of all pieces of work related to it but also tracking and reporting progress against a roadmap or a particular goal to people outside your usual relationship circle.
2 – Improved Communication Skills
You’ll have to communicate at different granularities. if your manager asks you about the status of the feature you’ll probably include technical details on your report. If a product owner asks you about the same thing you’ll provide less technical details. And, if a director or a C-level person asks you about the progress you’ll have to be even more succinct and still be able to deliver the information needed.
As usual, speaking all these different languages, the technical, product, and business, doesn’t come naturally to everyone. Some will struggle a little bit more to be able to understand these languages, others will have less trouble to get there. But one thing is sure: You’ll not learn this in a week. It’ll take you some months, perhaps a year, to feel comfortable with all these languages.
3 – Willingness To Step Out Of You Comfort Zone
If you don’t want to do what needs to be done, don’t accept this challenge. In order to be a Feature Lead you’ll have to step out of your world and start exploring other worlds as well. As mentioned before, you’ll have to visit the business world frequently, you’ll have to visit the product world as well. The leadership world is definitely one you’ll have to check as well. And many other worlds. All these travels might bring you some pains.
If you’re neither prepared to travel to all these worlds nor willing to putting yourself in an uncomfortable position, then I’d say that the Feature Lead thing is not for you. If you don’t like to hold people accountable, provide feedback more often, pay attention to what’s going on with the team, solve conflicts between people, then think twice before entering on this journey.
However, if you’re motivated to accept the challenge and open to do what it takes then you’ll see that this is a fantastic opportunity for you.
4 – Understanding of Business and Customer Needs
Oh yeah. It’s time for you to understand the impact and cost of what you’re doing. I’m not saying you’ll have to become a business specialist, but be prepared to discuss and understand business and customer need and align distinct perspectives with the development of the feature. This might have an influence on the scope of your solution as well as on how you’ll approach the technical solution. You’ll coordinate, negotiate, and make decisions that will impact both business and product performance.
5 – Systems Thinking
When you step out of your own world as an individual contributor, you’ll have to understand the implications of your decisions on others.
You’ll have to start thinking not only on you but on your team, other teams, the product, other departments that will interact with that part of the product you’re building, customers, etc. Your decisions will have an impact on different parts of the systems and you’ll have to be aware to analyse that when making them.
Final note
As you can see, performing the role of a Feature Lead is not that simple as it looks like. I’ve heard people diminishing this role but I think they didn’t understand its complexity and value as well as all the hidden opportunities in terms of professional development. Yes, you’ll still be a Software Engineer, but a much better one.
Recently I’ve read some statements that keep coming to my mind at least once a week maybe more.
1 – Make it work, Make it write, Make it fast
I’m a big fond of the concept of “Right first time” but lately I’ve seen so many time being wasted trying to figure out what would be the “Right” thing to do. Many unnecessary conflicts, concerns, non-validated assumptions, etc. This made me think more often about extreme interpretations or even shallow interpretations of such concepts that when not fully understood or discussed could lead to inefficiencies everywhere.
When I have such thoughts I remember of this concept that says: Make it work, make it right, make it fast! I don’t remember exactly when I’ve heard it for the first time but I’m sure, unless my brain is tricking me, that I’ve heard it during some research about game development (which is something I kept coming back to from time-to-time) and it was related to Blizzard, one of the big players in the game industry.
Later, after some additional research, I discovered that this term is actually attributed to Kent Back and it was part of the UnixWay for a long time.
Anyway, the whole idea is that when solving a problem in an iterative way you should consider to first make something that works, even if it’s not the right perfect solution. Ship it and learn from the feedback you’ll get in order to go to the second step, make it right. After rounds of improvement based on feedback then you’ll have to at some point make it fast. That will be the last step. That’s at least the intepretation that makes more sense to me.
I just feel that many times this simple and pragmatic approach will bring much more value than trying to use a sophisticated one just because everybody else is doing. But that’s just a feeling. I don’t have any data or experiment that can prove that, so maybe in the future, I can experiment with this approach and see what happens.
2 – The tiniest thing shipped is better than the best thing planned
This was something I’ve read on a blog post published by Amy Hoy on how to overcome procrastination.
This statement resonates with me because it sounds very responsive and lean, which is something I like. Also, it has a connection with the first idea as well, I believe. Living in the world of ideas and planning is super comfortable and can make you feel in control of things, but the truth is that the time will pass and all you’ll get is pure fantasy.
I spend so many hours planning stuff. I do that every day as part of my job, and I do that every day as part of my personal development. I try to make it as lean and efficient as possible. However, my feeling is that last year I tried to have the “best thing” planned instead of just shipping stuff to the real world, even if it was something small. Although I shipped, for instance, an email plugin for JIRA named Issue Events Mailer, a crap todo list style bookmark app, and another small attempts into the real world, I just have the feeling I could have done more if I had this “mantra” in my mind every time I questioned myself if what I was doing was of any value.
3 – A good plan is worth its weight in (future) gold
Also, I learned during these years of professional contact with lean and agile methodologies how bad too much planning can be. I’m not saying that plans should not exist, but we have to understand how much effort we should put on them before actually putting it in practice. At some point more planning is pure waste of time and energy that could be used for other valuable actions or tasks.
In the past things were so expensive that a well-thought plan was mandatory. The cost of repairing an error was too big. This is still true for some industries or fields of knowledge nowadays but for the great majority of software-based projects, for instance, I see these practice of thorough planning not optimal. Today is cheaper to quickly iterate, ship something, learn from it and use the feedback as input for a new iteration. That’s the base of lean and agile product and software development. Very quick cycles of plan-do-check-act. This makes me think that often just having alignment and shared understanding around the problem we’re trying to solve will be enough to a team or a person to start developing something and especially delivering something that can be used and criticized – in a constructive way – early and often.
Yes, I might have generalized things a little bit. Reality might be not as sweet as I’m painting above, but in general I believe that this principle and the previous ones should be taken more into consideration when we do or plan our plans.
Finding the right email notification plugin for JIRA is not an easy task. You’ll find plenty of options and you’ll simply don’t know which one you should use. Also, most of them seem to be so expensive for what they offer in terms of value that you sometimes just give up on your search.
Using native JIRA notification feature is not intuitive and will require a lot of time in terms of research, configuration, notification schema setup, cross-project discussions when you’ll have multiple projects affected, in summary: frustrating and exhausting. People are even tweeting their frustrations and making fun of the situation:
I’ve experienced nothing more frustrating than configuring my Jira notifications.
JIRA offers an all-or-nothing approach according to my previous experience. You either receive a lot of email notification or none. This might be one of the weakest features of JIRA from my perspective.
Agile in 2018:
Shaking your mouse every 29 minutes to keep your Slack status from being away and ignoring Jira email notifications.
The pains above plus the problem I was trying to solve were exactly the reason why I created Issue Events Mailer, an easy and flexible way to send email notifications based on JIRA Issue Events.
Give it a try for 30 days. It might be what you’re looking for.
I was simply not finding something simple and cheap at the same time – paying $1000 dollars for a plugin that sends e-mail was not an option for me and for many other companies as well. But I really wanted to solve the problem I was having at that time. Thus, I decided to create the plugin to solve my own problem and offer it to others as well as an alternative to expensive JIRA email plugins.
This is that time of the year where most of us set resolutions for the new year that just started. We usually feel confident and hopeful that the new year will be a better one and we should do some things differently this year so we can improve and become better human beings. Classical examples are:
Start doing more exercise.
Read more books.
Heave a healthy diet.
Write more.
Learn X.
Get Y.
And the list goes on and on. This year I decided to use a different approach, one that I informally have used in the past years and now I decided to use in a more formal way to inspect in retrospect the year that just has passed.
This year I used a Past Year Retrospective to map and have an idea of what I did during the whole year of 2018, what was my main mindset and also to understand some frustrations and pitfalls. The result was quite interesting, because not only I was able to visually see what happened in my mind and how I thought and behave in some cases but also I was able to get some insights on how I learned, how I spent my time and money and some other interesting personal insights.
My Past Year Retrospective for 2018 – Image was blurred due to personal info on the page.
I found this exercise so nice and so insightful that I decided to create a template to share with you. You can find the link to download the template at the end of this article.
As you can see in the image above, the idea is deadly simple. Just grab a blank sheet of A4 size paper and start putting the main topics that you remember from the past year on the paper. After a minute you’ll start making connections between them so you can visualize the relationship between them, causality, and even repetition. This visualization exercise is super important, I do this a lot professionally, especially during retrospectives – because it’s a powerful way to clearly see what’s going on and a starting point for many other exercises or actions. Once you have this visualization done you can use it to extract a lot of answers for questions like:
Where I’m investing most of my time?
Where do I get knowledge from? Is that good or bad? Which type of knowledge I’m getting?
Where I’m spending my money? Is it being well invested?
Where I’m struggling?
Where there was visible progress?
As you can see, creating the visualization will help you organize your information so you can answer critical questions that will help you to set more realistic expctations and actions for the new year.
On the right side of the page, I added a column with some sections to capture some qualitative data as well. On the back of the page, I added 3 more columns to complete the whole set of information that will help me to set more actionable resolutions for the new year.
The Past Year Retrospective Template
As I said the template is super simple and with low value if you don’t put some effort to really remember your whole year month-by-month and add the info to the paper. That’s when the value will be more evident to you.
Front of the Past Year Retrospective Template
The front-page contains a big space on the left and a column on the right. The big space is a free area where you’ll jot down topics that happened in the past year and you’ll make the connections between them. Example:
Example of a visual mapping – topics influencing each other.
The back of the page contains 3 columns.
Back of the Past Year Retrospective Template
The first one is for writing the good things you did or happened to you during the last year. I write them as bullet points, so that’s my recommendation to you. The second column is dedicated to things you’d like to achieve in the new year. Write items using bullet points as well. Don’t mind to be very specific or to overthink here at this column, it’s just the starting point for your future plans. The third and last column is designed to bring the financial component to the retrospective. Write here the expenses you think you didn’t manage well. I wrote, for instance, how much did I spend on Amazon shopping and was able to figure out that was not that bad this year compared to 2017.
That’s it. I hope you enjoyed this method and you’ll give it a try. Feel free to share your thoughts in the comments below or drop me a message on twitter @jcfausto
Recent Comments