Big & Micro Retrospectives

Big & Micro Retrospectives

Admin aaSaturday, September 5, 2020

I'm doing retrospectives for more than 10 years. I saw it all, the good, the bad, and the ugly. Retrospectives are fundamental and instrumental part of Agile. Even if you are not doing Agile or is not agile-ish in our way of work I would 100% you need o to have some form of retrospective. Retrospectives are an important mechanism to introduce improvements. Pretty much all companies spend lots of time in planings sessions. Long planing sessions are pretty normal(4h or more). However long retrospectives are not popular at all. It's possible to work without classical retrospectives however you would need some form of Reflection and Guilds/Chapters might be a place to have retrospectives. IMHO Retrospectives is something you want to do without mercy(Maybe I'm watching too much Cobra Kai). Meaning you should do lots of retrospectives. Retrospectives have different flavors and styles however I believe there are 2 important ones: Big & Micro. Retrospectives help to change the status quo and shape the culture. Retrospectives can be hard. Specially on the beginning. IMHO Retrospectives are like going to the GYN, you might not like to get in but you will love it when you get it out(finished the workout). Let's understand why retrospectives are hard.  

Scrum and Culture

Scrum shapes for Long planing and small retrospectives(15min to 1h). However, what happens is retros become a compliance thing.  Often people do not challenge things and they often do not tackle hard and complex problems. I would say 100% you want to have longer retros and small plantings. We live in a Feature Factory world where features are the only thing that matters.  

However, having a SOLID Foundation which is called STABLE SYSTEM in Lean teams is important to have better productivity and Scale and still operate with Fast innovation pace. Facebook at the beginning had the motto: "Move fast and break things". Because in the beginning, you cannot move fast if you dont break things. Them later on Facebook change his motto to: "Move Fast with Stable infra". Mark said that the principle did not change. It's the sample principle. Which is fascinating. Meaning, When you dont have a scale you need to break things when you have a scale in order to move fast you need to do the things in s STABLE way which has 100% synergy with Lean for instance. 

Which leads to the heart of the question. How do we know what is the right thing? We have diversity, people think differently, so how we take the best from everybody and reflect upon what we did to do it better? How do we review our systems, practices, culture, and improve? I would say retrospectives are fundamental for that. 

Retrospective Alternatives

You don't need to do retrospectives. However, you need some embedded mechanism to handle discussions and improvements. IMHO the best practices to tackle that are Chapters/Guilds however even with them I would still do retrospectives. Why? Everybody is busy, we are always dealing with tons of issues, incidents, being paged, attending meetings, getting things done. Often we dont have time to STOP and have human conversations about everything thats going on. 

It's possible to book meetings and always be discussion things and do improvements. However often we are very reactive when we just operate on that why. Doing formal big and long retrospectives allow you to be proactive and improve things before problems become a big deal. 

The Case of Big Retrospectives

I'm all about Big and Long Retrospectives often taking from at least 8h and maximum 12h. I have to say I did retrospectives bigger than 12h. It's very easy to have +8h retrospective if you think about 3 simple dimensions: People, Process, and Product. People dimensions you want have sort of 360 feedback where everybody gives feedback to everybody, this makes the team stronger and re-enforces relationships. For the Process dimension, you want to review how you are working if you are missing anything or also what's not working well. Finally, there is the product dimension where you want to improve your product, your software. Having Deep and Long conversations with your team is priceless. 

How we can do that in 15min or 1h? It's very hard. What happens is lots of "blind spots" and we end up losing some many good opportunities to improve. Often people have "resistance" too long retrospectives because is hard to book 8h in someone's calendar. However, that can be done by getting ahead and booking retros beforehand and maybe 1 month early. Are you too busy to listen and improve? 

Often people are afraid of retrospectives. They are afraid of what people might say. But think about this, let it sync for a minute. If that's the case I 100% believe we have bigger issues, are we addressing these issues or just pretending they are not there. Some problems need to be addressed in 101s, not in retros. Specially problems that are very personal or not related to the team. There are some tricks about Big Retros such as:

  * Do it 1 time per month or every 2 months - so they are affordable. (1 per month is ideal).

  * Set up ground rules, Team agreements, and rules (such as turn on your video). 

  * Talk about them in 101s to make sure people always open in retros. (this is a good extra). 

  * Experiment before judging. It's easy to say 8h is crazy :-) 

The Case for Micro Retrospectives

So you also can combine Big Retros with small retros. Micro-retrospectives are 5-10minutes retrospectives you introduce at the end of everything. Every meeting, every planing, every 101. They allow you to look for "signals" which you might elaborate further down on 101s or in Big Retros. Micro-retrospectives cannot focus on the action because you dont have time to deeply discuss the problems and agree on actions. However, they are a good mechanism to collect feedback. It's very appealing to do micro-retrospectives and skip big ones, I would say you want to combine both but not skip the big ones. 

Experiments: This is the way

The number 1 thing you want to avoid in Big Retros is to not have actions. It's 100% important to have actions. If you dont do actions retros are just "complaining sessions". Feedback is critical to improvement in people, processes and product dimensions. However, sometimes is hard to get people to change without experimenting with things. The Agile(Also Mandalorian way) is to run experiments. So run some experiments, try 2-3 times before making your mind one way or another. 

Experiments are great ways to learn and to try things and they decide if they work if they don't work. Teams should run multiple experiments, Agile Coachs / Engineering Managers (Coach Engineers is the term I like to use :-) ) should use experiments as the number 1 tool to drive change. 

So go run your experiments, have fun, and grow with your team. 

Cheers,

Diego Pacheco

Hardening Production

Hardening Production

Admin aaMonday, August 24, 2020

Often successful companies have significant growth. Meaning: grow in structure. More people, more departments, more managers, more coordination and often more overlaps. Enterprise companies always end up having some form or governance issue. I remember at the beginning of the SOA world "Governance" was a very bad word and there was abuse. After 3 waves of Agile manifestation, we are with much less "Governance" look like we still have plenty of abuse. Abuse can be also called WASTE(Lean Concept). Some rules can really promote best practices and better software like: Do not share your internal data stores, Expose data via Common Interfaces like (HTTP / gRPC).  Systems tend to grow and get more complex as companies grow with them. Every single improvement(refactoring) often means more investment($$$) which also can be saying as business entropy as the time passes it only gets worst(more complex and more expensive). When we analyze refactorings individually(business impact) they might not make sense but that cannot be the only measure otherwise entropy will kill you in the long run, so there is the complex chess math going on. Bad code or bad design is not the only source of entropy, tests can be big offenders too. 

Unit Tests have can have Waste

People often value unit tests as they are the best kind of testing technique. IMHO that happens for a couple of reasons. One because there was a lack of unit tests in legacy applications, often legacy web apps and desktop apps. So it's natural to say unit test all the things. For the frontend, there are better ways to test and have value like double down on linters and static tying like TypeScript for instance. Also for the frontend, you can double down on Snapshot Testing and tools like Jest. However, backend Unit Tests have more value and are more important. We need to understand that unit tests can have waste, meaning: Flaky tests that break all the time for bad practices, coupling with external things like database IDs, or just because of mocking abuse. One thing companies always want to do is raise the bar, which makes sense however often that bar means more coverage. 

All metrics can be gamed 

That's the issue, as you as for more coverage the goal became to produce more tests, not often means produce better tests or make sure we dont have waste in tests. Whatever number you get 100%, 90%, 80%, 70% you might have WASTE but higher numbers have a higher chance to have waste there. Should we have no metrics for them? well, thats a hard problem. Since this is subjective is really hard to measure and really hard to have a clear safe a universal signal. 

The Issue with Mocks

The issue is people end up abusing from mock. Either you have the real thing and you are doing a real integration or E2E test or you want to test something else and the mocks are a way to isolate your code from other stuff so you can test in isolation. That is fine, however, the issue is most of the time people are testing mocks. There is no value in testing mocks. Mock is a form of coupling if you have a shared library mock that could be a huge step into migrations and patches. 

More Diversity (CI/CD, Observability, More types of tests) 

IMHO there are other things we can do than just (add more coverage) like have a continuous CI/CD pipeline working which will increase ownership and by having the code being potentially deployed at any time(Readiness) you increase the health of the codebase by saying you need to keep the build and test passing all times. The issue with Release Trains or Release calendars is often there are components you are not deploying and people end up no caring and creating a state of build failures and tests that do not pass. With CI/CD there is no such thing. No having CI/CD means you will afford much more waste which is bad. 

Observability and the ability to understand what's going on is also a huge improvement and observability is also a form of testing. So it's another dimension that can be explored. Finally, I would say you can look for having more test diversity like Mutation Testing, Property-Based Testing, Snapshot Testing, Chaos Engineering & Stress Testing. These other forms of testing allow you to do more with less and also uncover issues you might not catch with regular unit/integration tests. 

Hardening Production the whole point 

Finally, I would say it does not matter if works in your machine. The whole point is to work in production. Working in production means, testing in production, because able to deploy software there and test with real traffic and real production hardware without impacting the user experience, so we need to have isolation and automation mechanisms in prod in order to deal with the then. We need to understand that production is a shared responsibility and everyone should be holding accountable in regards to production. We want to harden production because is where the value is and where we deliver value to customers. The best place to be improved is the production. 

Cheers,

Diego Pacheco

Productive Disagreement

Productive Disagreement

Admin aaWednesday, August 5, 2020

Building products(software) is hard. There are so many things that can go wrong. At Scale, everything becomes more laborious. More people, more coordination needed, more things that can go wrong and more pieces and more dependencies. To scale, we create team structure and software, often in the form of SOA Services. Any architecture or Design should survive a set of hard questions; otherwise, the idea or solution might not be good enough. Having people thinking into different dimensions, with varying points of view and various schools of touch, would create disagreement with could be an excellent and healthy thing. However, not always thats is the case.

When is Disagreement not Healthy? 

I would say that disagreement is not healthy if create one or several of the following side-effects:

• Affects team morale(mature team) by not empowering that team
• Prevent progress by power from Comand Control Structure
• It's not logical or rational, and It is just a decision based on fear or emotion.  
• Becomes a Power dispute(it will proceed via John or Petter way?)
• Promotes a toxical environment with lots of politics

Some companies have toxic and un-secure cultures and environments. Often Top-down and old school. Steve Jobs once said, "There is no sense in hiring smart people and tell them what to do." IF you can't change the culture, you should consider leaving, at the end of the day it's what happens and is what people do. 

When is Disagreement Healthy?

First of all, To have a productive disagreement, you need to have a psychological safety environment. Wich requires mature people(a lot of them) and careful management. Not every company is like that, unfortunately. If you have that, the environment(be glad). Having that environment than disagreement become a valid tool to:

• Promote team ownership
• Cultivate a non-silos culture of collaboration
• Generating new ideas
• Hardening Solutions 

Ownership ends up promoted because people get into conflicts, and thats okay because of this is just ideas, it's not personal, and that makes the team grows. 

Non-Silos culture is promoted when you add other stakeholders from other teams to have that discussion and listen and participate equally. 

However, all of this is not possible if you don't have psychological safety at the company level. 

Generating new ideas is a super cool side-effect because you end up exposed to different points of view, and thats super constructive at the end of the day.

Hardening solutions is one of the best outcomes because collectively reviewing ideas, architectures, designs, and solutions is much cheaper than figuring out this issue in prod. 

I always believe in a Double-check mindset. Having Productive Disagreement is like having Doudle-check at the team or company level, which is super sweet and makes the whole team and the entire company to grow.

How to Enable Productive Disagreement?

There are many things you could do to promote a better culture and, therefore, a better working environment. Such as:

1. Get executive By In (Management)
2. Promote Psychological Safety
3. Replace Blame for Curiosity
4. Have regular 101s
5. Do regular retrospectives and clear out misunderstandings. 
6. Give and ask for Feedback.

Building a better culture is hard and takes time, commitment, vision, and continuous efforts, but it pays off in the long run. 

Cheers,

Diego Pacheco

Github: PR Template + CODEOWNERS

Github: PR Template + CODEOWNERS

Admin aa

Github is an amazing platform. Today I want to show in a video 2 super killer features which is: Pull Request Template and also Branch protection with CODEOWNERS. This feature makes the PR Reviewer life much better and improves documentation, learning, save time, and just push the team to a much better direction. Sometimes people might create too much bureaucracy, however, the other extreme to have no comments in chaos and not good. So we need to look for some sweet middle ground. So Let's get started. 

Video

Code

https://github.com/diegopacheco/github

Cheers,

Diego Pacheco

How Many Hours Should I Work?

How Many Hours Should I Work?

Admin aaWednesday, May 13, 2020

So this is a hot-button issue for many people. I',m by any means not trying to be preachy and say what's right or what's wrong, this is just some of my perspectives on the matter.  Many people don't like to work more than 6h and thats fine. Given the level of execution I like to play I really think I need more hours. Working as a consultant you really do not have holidays or day offs, you work you get to pay, do not work dont get paid. Even as you get raises and progress in your career as consultant hours will always be a thing. I have that. You easily could call me a workaholic, a victim of the system, or simply someone who gets things done. I'm not saying that people who work fewer hours get fewer things done. Every one was a different moment and whatever works best for you it might not work for me at all or vice-versa. So do not see this as a workaholic-apology. At the end of the day what matters is: (A) Are you getting things done?, (B) Are you healthy or sustainable?, (C) Are you happy in the long run?.  So for today's post, I want to share mo opinions on this matter and also a short video I made. So Let's get started.

 IMHO the issue is not the hours

Working a lot(+10 or +12 hours) IMHO is not a problem at all. Especially if you are doing cool stuff and get paid. For me the issue is getting stressed, there is no money in the world that can pay stress. Working on a toxic project or environment context, 1h is too much already so, of course, you dont want to do more than 6h or 8h. It's okay to go home early and have a life. Working more hours also does not prevent you to have a life.

Hard work pays off

I really believe the only way to ship and growth in your career is with hardworking. I dont think hard work can be done with few hours of practice per day. As engineers, we are knowledgeable workers but we are doing constant discovery of new tools, processes, practices, and approaches. There is lots of interruption at the office-space in sense of meetings, noise, and bad team-comunication anti-patterns in general. Few people claim they time back and often when people do it this is sawed as bad comunication or bad behavior. These factors also change this equation a lot. Several times engineers cannot be engineers. I really like to work, I dont like to get stress, I don't think anyone does.

Video



Cheers,
Diego Pacheco

Tools Beyond Meetings

Tools Beyond Meetings

Admin aaSunday, April 26, 2020

Right now, everything is different due to COVID-19. Even before the COVID-19 meetings were often seen as the one tool to fix all sorts of problems. Meetings can have value if you have a clear agenda and people get prepared before the meeting which never happens so meetings tend to bring lots of waste and kill engineering productivity because it becomes flow killer. The reason why meetings are a goto tool for every kind of problem because it's easier, however, the price is high: Affects Engineering productivity because it's an interruption and often things dont get done and you need more meetings. So you might be wondering what we can do about it, well there is plenty of things we can do about but in order for any solution to work we need to have Discipline which is hard, that's why lots of meetings continue to happen. I'm and always was a huge Chat fan. In the past, I used Skype, Atlassian Hipchat, Teams, and Slack for the last 6 years these tools are great because they allow us to do things asynchronously and it's one way to keep meetings away. However, you need to have the culture to work with chat oriented. Several times it's possible to slack generates more noise. So you need to mind how you design the channels what and who is what channel because is easy to become a huge interruption factory.  I'm culprit on that since I'm always throwing lots of links on Slack. :-) The issue with slack is no Boddy thinks of it as an async tool but as an online quick answer me know a thing. 

Async chat like Slack

IMHO in theory slack could kill 90% of your meetings. There are kinds of meetings that are super important like 1:1, retrospectives, planning with often does not make sense to kill. There are several meetings on-demand that could easily be a slack chat. So getting the mindset is hard because we are so used to it but once you get it is hard to come back. Having meetings it also could be a form of command and control since old school mgmt does not trust chats and old dogs do not learn new tricks. However, there is value in some meetings especially if we are talking about something highly complex, however, get into a meeting without a virtual whiteboard or google docs to draw something it could be super challenging.

Blogging & Wiki

IMHO Blogs and Wikis are amazing tools and people dont give enough credit for it because people often just see as "documentation". When you are in a small company it's easy to repeat things a couple of times but when you are in a big one this becomes unbarable. Blogs / Wikis are your ultimate tool to kill meetings because they make you scale. In order to work you need 2 hard things. First is that they need to be up-to-date and people need to read it. That's could be a hard one, often people do not like to read and asking for a meeting is much more comfortable. There are techniques you can apply in order to make your wiki blogs to live longer and be more up-to-date like:

* Have pictures and drawings about architecture and design (which you can't find in code).
* Do not write things too soon, as things might change it would be deprecated soon.
* Write down: Goals/Objectives, principles, and high-level details.
* Avoid document class-by-class, function-by-function in the wiki blog. Use Javadocs for it.
* Clean things time to time, IF you do kanban it could be a Queue Policy.

You need to start seeing that Blogs and Wikis are a powerful tool to remove repetition and gain your time again so you can be productive and get things done. 

Talent

Talent is what matters most, smart people can figure out things more quickly and make better calls. That's what you need most. It does not work out and has just 1 super architecture, you need to heave a team with great engineers. So you do not get talent go away, retaining talent is your number #1 goal, process and talent are opposite forces according to Netflix if you have more talent, less process you need and therefore fewer meetings you need. So IMHO lots of meetings could be a proof or smell that you few talents in your team or company.

Poorly Run Ceremonies

The question is why are we having a meeting?

* Because the manager needs to know whats going on?  (Status)
* Because some engineer does not know what to do? (Planning)
* Questions about a user story? (Grooming)
* Because we disagree with something and there is a conflict to resolve? (Retrospective) 
* Because we dont know the best solution? (Design Session)

So often there is a ceremony for these things why are we talking afterward, well there are stories that are complex and make sense talk more. But my point here is we dont take enough value from ceremonies and guess what? we need to have meetings. So one efficient way to reduce meetings is to run ceremonies well. The number #1 reason why these ceremonies get poorly executed IMHO is lack of preparation. So if you do your homework we can run better ceremonies and therefore reduce meetings afterward.

Better Tooling Awareness

So I would not write "better tooling" because we often have the tools but do we need how to use it? There are amazing tools like GitHub, Eclipse/IntelliJ/Vscode, Linux bash/zsh, do we know how to use these tools properly and effectively, or do we book meetings to ask people stuff we could answer ourselves with a simple script or search?

IMHO doing lighting talks about tools that make engineers more efficient is often a good idea and people tend not to think about these things because they are "too basic".  Sometimes the small little things can do great impact so you need to consider it.

Meetings often are a better thing because in the IT industry they are used for all the problems all the time. Using Slack chat, Blogging/Wiki, Having a great talent pool, running the ceremonies well and knowing your tools could help you to reduce the number of meetings and be more productivity and the cool thing about it is you can do by your self you dont need to convince your team or somebody else.

Cheers,
Diego Pacheco

Thoughts on Estimates 2

Thoughts on Estimates 2

Admin aaThursday, April 16, 2020

So this is the second video about my thoughts on Estimates. The first video is here if you did not watch it. I end up doing a second video because I realized there was more stuff I want to say and elaborate more like: Estimates not being reliable and liner. Moscow is really helpful to increase the success chance and also small things like XP Simple Design, Metrics, Team Layout, Branching Model, Architecture and so many other things which I cover on this video. So this video is a bit bigger than the first one(8 min) but not that big(12min) so I hope you guys like it.





Video


Thoughts On Estimate 2 from Diego Pacheco on Vimeo.


References

Github Flow Branching Model

Inner Sourcing

Team Topologies

Cheers,
Diego Pacheco

Lessons Learned with Remote Work

Lessons Learned with Remote Work

Admin aaWednesday, March 18, 2020

Remote work was kind of the default for me. I'm a Gypsy, always traveling, 6 months home in Brazil, 6 months in Europe / USA. Doing that for +10 years makes me feel remote native :-). Even in Brazil, I travel a lot to Santa Catarina and Sao Paulo states. I go to standard office 1-2 times per week maximum. So remote was a default for me a long time. Now we are facing dangerous and different times because of the COVID-19.  So remote becomes the default for everybody. Remote work has several advantages like You dont loose commute time, I used to lose 2h per day in a traffic jam. Also, you can have your meals with your family and you can work with much more comfort and focus. IMHO I always worked much more from HOME rather in the office for basic 3 reasons. First of all, I felt much more obligated to produce more results since I was working from home. Second I have much fewer interruptions in HOME than in a formal office. Unfortunately, there are tons of people who do not know how to work remotely and are a huge source of interruption. Interruption I dont have at all working remote from home. Working remotely does not happen just in my home but also anywhere in the world. I always like the Digital Nomad philosophy of life. Thrid reason I have much more focus because I have more comfort, better internet, make my own time and in the end of the day, my customers are not in my city or state so I do not make any difference.

Invest in your Gear

It's super important to have a good gear in-home or whatever you are. The second monitor is important, a good and comfortable chair, great mouse pad are a must-have. Will I'm traveling it's very hard for me to have a second monitor but I always prioritize good internet. Having a high tech, the high performant notebook is a must to have. You need to have the best notebook you can get because you deserve it and is your main work tool. Another important gear is the headsets because you will need to listen to music on Spotify and do conference calls.

Sofa or Not Sofa? Some people do not recommend you work from Sofa. I like to change spots, I do 2-3 times per day. I often work from the table + sofa for meetings. You will find your optimal spot for sure but keep in mind it's fine to switch places. I find the sofa sucks for coding but for meetings is the best place I go.

Collaboration tools

Working remote is all about collaboration tools like GitHub, Trello, Slack , Evernote, Pocket. For hanging out with friends and have fun there is this great and new tool called Kosmi. Kosmi allows you to play Super Nintendo, Nintendo 8bits, Pocker, Open Arena(Quake), See videos on YouTube with chat and video conference. Kosmi is a great way to decompress at the end of the day and has fun.

Slack is the main comunication tool for me. I love slack, it's the mix with old IRC and new webchat. I use the electron based desktop app for slack and it's super great. It's also important to tune up your console, for this task I recommend you to read these posts 1, 2, 3 and 4.

There are tools you can use to help you to keep focus like GTD(Getting Things Done) and Pomodoro Technique. I have used these tools for a while, I end up developing my own discipline. So I dont need them anymore but it is not a shame to use these tools they can be super helpful.

Visibility and sharing

Visibility is important no matter if you are working remotely or in an office. I think you should avoid oversharing status but smart comunication is always a good idea like, I will be OFF for the next 1h hour or I'm taking a break for lunch good and useful comunication. It's a nice practice to share what you have done by the end of the day as a final slack message.

I always believe sharing is caring. I have this blog for +14 years, I share links like crazy in all my slack channels. I believe information need to flow and people should get access to the good stuff.  One awesome effect on working remotely is that you force yourself to read more. Reading books is the oldest trick in the book and still is something people dont do it enough. Working remotely is an opportunity not only to get more things done but also to make time to do exercises and read books. Visibility works together with double-check, it's super important to make sure people clarify assumptions and are at the top of what they are doing. Since you are working remote your communication shifts from speak to TEXT is easy to make things getaway so even remote this is not an excuse.

Advice: How to Stop

That's the hard part. It's easy for us to be WIRED. Loose track of the time and end up working much more remote than in the office. There are multiple ways you can deal with that. One is to set up timers. I book on my agenda time to stop often called HARD STOP. I create a mindset to always stop before the HARD STOP period finished. We are mindset animals and we need to create a mindset to stop, otherwise, we will work too much and end up not doing fair work-life balance.

Stop working is important but a full digital stop is even more important. I book 2 times per week to learn and study during the week. Sometimes I get 1 extra period on the weekend. I use this time to learn books, make videos, see videos, do blog posts, code. But It's important to LIMIT that otherwise easily you could be just another workaholic.

Working remotely is not for everybody. That's fine. Now we are leaving different times because of the COVID-19. So everybody needs to adapt and learn. Right now it is important for everybody to be safe and stay at home.

Cheers,
Diego Pacheco

Double Down on Double Check

Double Down on Double Check

Admin aaFriday, February 14, 2020

Building Digital Products is HARD. Doing Hard things is hard but it's what we need to do. Mindset is everything. Teamwork it's critical to achieve true innovation and avoid silos. I Deeply believe it is Blameless culture and Psychological Safety environments. Trust is the foundation of any high performant team. However there is a tricky thing, you really want to have trust because you want to have people being able to DISAGREE. Disagreement is really important nowadays, it's like a network of layers and layers of testing. Everybody wants to succeed, more validations the better. Everything we do is complex, lots of different roles: UX Designer, UX Researcher, Lean BA, Discovery Architect, Delivery Architect, Foundation Architect, Agile Coach and much more. As we look to technology we have an explosion of languages, stacks, libraries, and frameworks just to have the right tool for the job, get the better performance and best user experience we can provide. Cloud computing is how everybody is running the software(EC2, ECS, EKS, Serverless) it's all great but adds complexity and variation. There are dependencies, from other people, from vendors, from legacy APIS. How do we make sure it all gonna work? We need to double down in Double Checking.

The 5 Dysfunctions of a Team: Disagreement on the Spot!

Fear of Conflict creates a lack of commitment which will lead to low accountability and BAD Outcomes for your business. You need to be able to "disagree and challenge" all decisions, dependencies, and actions your team does. We need to PAY ATTENTION to everything, on every single detail, we need to BE ON TOP of everything. It might sound a bit paranoic but this can save you from several issues.

Let me give you some examples of how you can apply it, in your, day-by-day job:

1. The Framework / Library I pick it up, does it work? Did I test all use cases? Did I check all corner cases? Did I perform the right POC? (assume no).
2. The APIs I need to use is really done? Would they really work? Did I test with every single request I will need to make? (Assume it does not work)
3. Would the team really deliver the US today? Are we really on track? Are we with ZERO blocks, ZERO Delays, ZERO issues? (Assume it won't happen, assume there are delays, issues, and blockers).
4. I have a dependency on an API or Service is not done, Would I really get them on time? Could I mock and work in parallel somehow? (Assume your dependency will not work and will not be delivered on time)
5. Is the discovery work done? Are the US with the proper acceptance criteria? The UX prototype was really checked by the business? (Assume nothing is done, assume business will change).
6. It's my POC correct? Did I cover all the engineers will need it? It's your architect correct? (No, your architect is wrong, the POC is too simple - assume they are all wrong).

Assuming the BAD output is good. It makes us PAY ATTENTION to details and DEMAND for Evidence that things are really RELIABLE and work. Having this mindset will save you from lots of trouble and will make your teamwork much better. Stop seeing disagreement and challenge questions and personal attacks and start seeing and unit tests and opportunities to validate you are not messing up. Double-check it won't kill anyone. You need to double it down on it, Trust does not mean BLIND TRUST, it means we should maximize our collective intelligence and get most out of our teams.

Boiling Pastel

In Brazil, we have a fast-food named: Pastel. You dont need to overthink to make pastel, they ask you chicken or meat flavor and you boil it right away. How is your team working? Is your team CRITICAL THINKERS who challenge each other and maximize their Outcome or it's a group of Pastel Orders who just repeat top-down orders?

Cheers,
Diego Pacheco

Getting Things Done

Getting Things Done

Admin aaWednesday, January 1, 2020

Getting more things done is something everyone wants. However, some people are better than others and can do more. Experience and Deep Technical knowledge play a hugely important role in this equation however there are other mindsets and tricks you can do to boost your productivity. Today I want to hare some of the tricks I'm doing over the years to boost my delivery hopefully it will help you do get more things done.  First of all, you need to understand the top 3 enemies of productivity: (A) Meetings / Interruptions, (B) Self-Pressure, (C) Lack of Clear Goals. First of all, meetings need to be bounded, you really should carefully pick how many meetings you do per week because meetings often can be very low on value because people often dont have a clear shared agenda, do not prepare well for the meeting and dont have a clear outcome or list of clear actions, having said so, meetings tend to proliferate, you really need to avoid meetings proliferation and get more outcome if you are doing a meeting. Meetings are kinds of interruptions, there are companies that believe they can only get things done by doing meetings, this is so old school and it could not be more wrong.

Avoiding Meetings and Interruptions 

You should carefully plan how many recurrent meetings you have, their meetings that need to happen like DEMOS, Retrospectives, Coaching Sessions, Weekly Meetings, Trainings. Aside from that, you should avoid as many meetings as possible because you can get pretty much anything done without having a meeting. I get tons of things done working with my boss and we do very few meetings, how I managed to do that? Async comunication like Chat and email. I might do 101 calls when there are urgent matters but this is fine because you are not stopping the whole team. Several companies have a culture that they can only work if they involved everybody in a meeting which is not true at all.

Meetings are only one kind of interruption, social network, small talking is other kinds of interruptions. Engineering requires focus and silence, BAD managers have difficulties to understand is almost impossible to deliver engineer work(architecture, design, coding, testing) with interruptions happening at all times.

You really should shield your team against interruptions, limiting meetings and add then to a regular calendar is a good practice. Often too many interruptions and meetings could mean(smells):
* Lack of proper roles and structure
* Lack of consistent and strong leadership
* Lack of understanding from management how real software engineering works
* Heavy Workload - working with fewer people than you should have.
* Lack of context - having a partial view could introduce resistance 

Agenda Hacks

Controlling your agenda is one of the most important things you need todo. Otherwise, people will just book meetings all the time. You should have SLOTS witch are booked times in your agenda that make easier for you to:
* Schedule meetings easily
* Limit Meetings
* Get more things done

By managing and reducing interruptions you will get more focus and get more things done. There are several ways you could manage your agenda, first of all, you could book 1h every morning for meetings(meeting slot) so this way if someone asks you a meeting you can do every day and if 3 people ask meetings on the same day, well you overflow to other days. This limit mechanism forces you to have a better and clear priority since you will limit your work. I worked with multiple layouts, having meetings only in the morning, having meetings all the time, currently what works best for me is condense my meetings in 2(first 2 days of the week) therefore having 3 days without interruptions and meetings. I realize I get much more work done and my work-life-balance works much, much much better. There will be exceptions, which are okay, however, overall is important to save this layout otherwise the structure falls apart and loses its value.

Clear Communication is a requirement for remote work

Remote work cannot happen without clear communication, context, and clarity. These 3 simple elements often are the reason why people need meetings because they cannot understand each other because people do a very poor job communicating. However, if you force your self to have better Context, Clarity and Clear Communication your chats/emails will be much more effective and the need for meetings will drop.

Often times people are lazy to write/read and are more comfortable to have a meeting, however, a meeting has a higher price. Overall is fine to have meetings for critical matters however as a long-tern goal you should focus on improving you communication skills over chat.  There are multiple tools you could use to easily communicate batter remotely like Design / Diagram Tools, Blogging, Video Recording. All these tools have lots of benefits like:
* They scale and you dont need to have meetings
* As you add more people you can send links and dont need to explain twice
* They dont block your whole team and people can read/watch in different times
* Videos + Images are great for people because visual tools make understanding easier

Video + Slides

Here is a video I recorded talking more about the subject with a companion slide deck.

Video

Getting Things Done(Organization) from Diego Pacheco on Vimeo.

Deck

Organization_GTD from Diego Pacheco

I hope it was useful for you. 

Cheers,

Diego Pacheco