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

7 real values from software beyond estimates

7 real values from software beyond estimates

Admin aaThursday, December 19, 2019

Estimates are lies, estimates are not reliable. It's super common to have companies doing estimates completely wrong. There is no way to do estimates right, however there are ways they can be even worse than usual like:
A) Having managers doing estimating for engineers.
B) Not accounting holidays, Refactorings and Bugs.
C) Not comparing working items
D) Ignoring variation: Different sizes, complexities, technologies, needs.
E) Not understand when the system is stable or not.
Very often estimates are done before the project or product start and where variation and uncertain is sky high. When we take a look into PMI, which is based on bridges and buildings we still see buildings and bridges with extreme delays, extreme over budget and poo quality. If this is true for construction engineering why the hell would not be true for software engineering where we barely have 50 years of experience as a industry compared with the +2K years in construction engineering. Project after project, year after year, company after company no matter how mature or immature or how sexy or old school the project / company is, this matter always come to surface which great disagreement and often stress related to the discussions.

The Need for Mindset shifts 

Time to time, companies who want to survive and reinvent themselves need to let some old culture, values and old ways of doing things go in order to achieve better results. In order to change companies need to break old paradigms and learn different ways todo business and learn new mindsets, skills sets and toolsets.  The past does not define the future. No matter how good and how top performer you were there is a point where everything change. That happens to the top of market look Blockbuster, Codak and several other companies who were leaders and basically bankrupt. However you cannot do a different process, and use different tools, if you still think the same and your values are the same.

In order to Learn you need to Unlearn

When we were kids we "kind of learn" to learn things. Easily someone could point out that we bareilly learn how to learn and actually we was tought to "follow" and to be "complainant" but never to truly think critically and outside-of-the-box. Besides the fact education sucks, let's say you were luck and got great education even so we are not tought to underlearn, to let it go and to re-invent our values and mindsets.  I really like AWS philosophy of learning, they pretty much innovate based on the idea of "recreating" what never changed. They did it very successfully in AWS in several fronts like SOA/Microservices instead of traditional monolith solutions, Cloud-native databases like Aurora(where they decoupled storage from computing) instead of traditional monolith db architecture, Firecracker an others innovations instead of traditional virtualization. This year(2019) I had the pleasure to goto vegas on the very first re-invent and sow this philosophy in practice, for sure this is one of the reasons why AWS is so innovative and successful because they unlearn all the time.

Tell me how you measure me

There is only 2 kinds of measurement. A) By value. B) By ability to GUESS right. unfortunately too many companies only care about item B. In the end of the day looks like the only thing that matters is if you delivery all items you guessed on time. Allan kelly wrote some amazing books about no-projects and continuous digital and project myopia. Where companies endup pursuing Dates, Features, Cost instead of benefit(value).  Talking to management, business leaders, product leaders often they will say to you that they care about value, but in the end of the day, they don't know what value means, they only know what cost, time and list of feature which is a very old school management 1.0 behavior which does not work well on the digital world we live.

What Value means? What real values can we get?

I you like to deconstruct value and pretty much say 7 samples or 7 real values we can get from software beyond beyond a professional guesser(which nobody is - everybody suck doing guesstimates).

1. Sustainability / Safety / Quality 

I really try to avoid the world "quality" as much as I can but I'm talking about quality. The reason I try to avoid the world quality is because I dont think it best map the concept to the reality we need. Secondly because people often think about quality with compromises. The first thing is sacrificed is tests, people often dont have enought automation and they are swinging on technical debt which really kills they productivity.

Having a Safe or Sustainable system means this is a pre-requirement and is non-negotiable, there is no way to work without safety, we need understand that when we: kill tests, deliver crap code, dont automate and piple up technical debt we are killing our productivity and creating bad experience for the final user and really throwing away all the business investing on the product.

Even if you dont deliver all the 100 items your business want or you think you could do it you still are adding lots of value if you deliver 50 items with proper safety and sustainability. This is the first think people need to realize, the first real value in software is sustainability.

2. Culture Transformation 

Very often as a by-product, delivery projects or transformation projects often delivery new mindsets, new culture, new toolsets, new business capabilities for the company. Even if you are not delivering the 100 items you promised to the business and you tought you could do it, let say you delivered 40. There is still value if you help the customer to acquire new mindsets therefore transformed the customer.

There is a real value in learning: A) how to do proper software engineering. B) Proper software architecture. C) Proper software Design. D) Proper DevOps Engineering. E) Proper Agile Coaching. F) Proper team culture, feedbacks, psychological safety. The list goes on and on. This is often not see as value, companies need to start realizing there is extreme value in deliver a digital transformation to the customer. Even if you miss your deadline and could not GUESS properly the ALL OUTPUT they want on the DAY they want.

3. UX / CX

Customer Obsession is another super game changing value Amazon and AWS have. The only way to compete properly is doing the right investment in UX(User Experiment) and CX(Customer Experience) otherwise your competitors may outperform you.  Often UX/CX is not measured, as companies only care about your GUESStimate which you missed. Let's say you need to deliver 100 items but only delivered 45. This item as having the right UX it's a huge value that potentially could drive revenue for your company and grow your user base. UX/CX is the third real value from software delivery which again is bigger than being able to GUESS the right number of features on the scheduled.

4. Waste Reduction

Lean is all about learn how to see WASTE and REDUCE / REMOVE WASTE. Kanban is a lean method therefore is all about waste reduction as well. Kanban is also all about changing your management behavior which could be a huge source of waste. Again let's say did not deliver 100 items but delivered 35 but you did it properly which out doing feature yours users dont need and without Big Design Up to Front(BDUP) and piles of tech debt and proper priorisation, is very likely you reduced waste, this means cost savings. Removing waste is value. Even if you did not deliver as much items as your business want. This is the fourth real value from software, reduce waste and this value has lots of importante not only economically but as a mindset so your team learn how to self-improve and always tune the system, the process and the solutions. There is value on it.

5. Stable System

Dr Deming always talked about STABLE SYSTEMS and VARIATIONS. Unfortunately management still dont get this right. Several times variation is produced by the system itself and not by people, so it's not people fault but is a system fault because the system is not stable.



Variation is sometime most of managers do not understand. Also one of the main reasons why estimators are never get it right. Variation could be cased on the size of the user story, complexity level, hidden dependencies(which appear on last minute), technology which the team is not productive yet. Having a STABLE SYSTEM means we control the variation as much as possible and have mechanisms to deal with variation and reduce it as much as possible like doing: PoCs and/or Dual Track Agile Discovery Track and/or experiments. Having a STABLE SYSTEM is a real value from software because it means you understand what you're doing and you can improve the solutions effectively and also the team throughput or maintain at least.

6. The Right Solution 

It might sound obvious. However is common to have the "wrong" solution which means, features or software that people don't want or dont want to use it. YC mantra is a successful startup need to build products that people LOVE. Steve jobs once said "The life is too short to build products that people don't use it". Build the right product is complicated, it is not based on a single person point of view. IMHO the right solution is discovered, so you need to have structured discovery process like DTA(Dual Track Agile). Companies do Design Sprints and use some lean startup techniques but often they do that as as Single shot on the beginning of a project or product, however that need to happen continually and in full sync with Architects and Business Analysts.

Let's say you need to deliver 100 items but you delivered only 60 by the time your business expected, IF of the 60 items you delivered they are the "right solution" there is lots of value on it.

7. Predictability 

This is the last item I consider part of value from software. This item is very "subtle" and could easily be confused with estimates. Predictability and Estimates are different things. Estimates are lies and they are not reliable however you still have have a consistent "trend" and still do not ask your engineers to GUESS any work they will do. In order to archive it, which is not easy, you need to have a stable system, so variation is contained and managed(which often means break the stories at the same size - let's say 8h stories).  Kanban predictability work based on very simple math, like getting the weekly outcome of the team multiplied by the number of weeks. Let's say your team deliver 10 items people, in a month(4 weeks) you will have 40 items, Let's say you define a MVP release and you allocate 80 items. All items have same size, therefore if you do 10 items per week in 8 weeks you can deliver it.

The good thing about having a "delivery goal" for the team is you can tune the system based on weekly progress. Basically thats done by doing RCA(Root Cause Analysis) for bugs and user stories which did not happen on normal basis(meaning anomalies or +8h work).

This is much better than asking the engineers to estimate items because they items often have different sizes and different complexities. There are some gotchas here like, you still could have variation, meaning, unknown hidden dependencies(so you need todo a killer work on discovery), you still could have dependencies on other teams(you need todo a killer work on foundation track - TTA post). Also is possible that you introduce new technology which your teams does not master which will add variation and again affect your toughtput.

How to deal with variation again? Basically you can create solutions that simply software engineering via an engineering organization or even a foundation track on TTA, Another option is to think about "generic" solutions like component and generic services where you could reduce good part of boilerplate or "common-code" and them let the engineer be more productivity.

You also could work on a: MUST, SHOULD, COULD targets. So let's say you MUST deliver 30 items, SHOULD deliver 60 and COULD deliver 100. This way if you miss SHOULD is not the end of the world, also this technique forces the business todo better prioritization and reduce the blast radius of variation and might happen.

Other important practice is show this Burn Up chart every week to the business and NEGOTIATE if hidden dependencies appear, bugs arrive, people get sick, new stories appear. I'm not super in favor of changing dates but I prefer to use creativity and always reduce items on think in SIMPLE solutions.

What we can do better as technology professionals

First of all we do a very poor job explaining to the business and customers what value means. By doing so, often people think value only means deliver the WHOLE software on time on cost with all feature they need (classical PMI success criteria for projects).

Small & Conninouts MVPs are also key for keeping the business engaged and always give visibility that the team is delivering value even if that value is not ALL the software or ALL super usable. My experience and understanding is that for new softwares is always easier to create MVPs however even for existing softwares(digital modernization) is possible to create small MVPS but you need to know your game, be creative and sometimes trade features or process or more work on the user side.

As technology professionals we not only fail in provide better education for your business and customers on what value means but also fail in have small frequent releases to reduce tension and make progress more visible.

Cheers,
Diego Pacheco

The Modern BA Mindset

The Modern BA Mindset

Admin aaTuesday, September 24, 2019

The "analyst" is a very old role. I really think the tradicional role does not make sense anymore, we should see analyst as a discipline/skillset and not as a role. If the last 20 years of software engineer teach us something is that engineers are in the best position to work on proper solutions, however, someone needs to worry and focus on the business problem. IF you are in an Engineering Organization, engineers are great as POS / BAS but if you are dealing with delivery discipline and working with non-it people, engineers might not have the best set of skills to do the business analyst part. However, there are many things BAs and even Designers(UX) can learn from engineers. For this blog post, I will like to focus on the skills and the transformation BAs need to face today to keep up with current market needs, innovation and competition in order to be ahead of the game.

The Issue with the Traditional BA

There are 2 kinds of traditional BAs. Both anti-patterns IMHO. First of all, that BA who focus on the solution and writes word documents in software factory formats following CMMI and RUP, these word documents contain IFs in structured Portuguese are completely wrong. Yes, there are still companies who still do that. The second anti-pattern is less complicated them the first one but still not ideal at all is the BA who writes what the business want.

You might be thinking, I thought the BA Role was about writing down what the business want. That's where the trouble started. IF The BA is just writing down what the people or the business is asking him he/she is not a BA, it's a secretary. No Har feelings about secretaries, Google will kill your job in 5 years but besides that, The BA cannot be just "talking" with engineer via word specs.

This is an issue because the assumptions behind the traditional BA role are completely wrong in our modern, product-driven wold. Why? Let's examine the assumptions first.

• 1. We just need to "define" what engineers need to do and they will figure it out how to do it
• 2. We don't need to worry about how it works, only about WHAT we want
• 3. We already know the user, there is nothing to worry about 
• 4. As soon as we define everything we can push engineers and demand delivery dates
• 5. Once we define it we should not change it.
• 6. Our process It's working, we are being successful, we should not change. 

Basically, these assumptions are very anti-agile. What this means? It means we are using our lucky and eventually we could run out of luck. Let's dive deep into these assumptions, let's start with "define". Well, there is no such thing. There is no defined. We can't define. Because modern digital products are more complicated than that, There are a million of variables like It's this aligned with product strategy? Is this the right feature? Are we targeting the right users? Is this well crafted? Would this scale? Would this be clear and easy for the users to use? How this will behave in iPhone 5? What about Chrome 71? Is the tone correct? Is this natural to the user? How much does this impact the user? Do we need UI? Should we really do this? We can go on and on... So basically we need a bunch of other disciplines and skillsets to "define" a solution, so really "define" is a hideous word. IMHO I prefer the word "discover" because it's more natural and realistic.

Secondly, the devil lie in the details. We need to pay attention to how we do things, execution is as much important as strategy. A good strategy with poor execution will produce poor results for the business. So yes, we need to worry about how it works. Not only because of the UX perspective but also because we might realize that we want is not possible, or it will work differently because maybe the are tech limitations that the business does not know. Maybe we don't know our users well and we need to understand them better to drive better solutions. So the best software product is the one who is user-centric with regular and short/frequent releases, we need drive A/B tests with users in order to figure it out what works best.

Know the user is something relative and it changes over time. Consumers change over time, there are forces that change people mindsets and what people value. There are new generations around(like gen Z, millennials), diversity is here. The past does not guarantee the future, so really the only way is to continuously innovate, continue to learn until the company exists.

Going over dates is the wrong outcome. Should we worry about releasing software often? Hell yeah! So whats the issue about Dates? Well, the issue is that becomes the ONLY 1 concern. This is the wrong BA focus, we should be focusing on: Are we delivering value? Are we delivering great impact to users? Are we ahead of our competitors? Are we unique? Are we understanding our users? Are we shipping something stable? Are we ready to the massive scale of users? All these important questions get bypassed when we just think about dates. If you are in the wrong direction going fast is like getting position fast, it only will kill you faster.

Dates, Features, Requirements and other fantasy things. Why fantasy? Because they dont exist. They are "virtual" and we created. As Plato said one, the man is the wolf of the man. So basically this could be most of the times just psychological waste. Why? Because software is not hardware. The software can and should be changed. If we change our mind, we just change the software thats it. Thats should be the new normal. A/B testing is about changing the software every day for thousands of users with different versions of the software. Bing(the Microsoft search engine has +30K versions). Every single great digital product does that. Facebook does lots of experiments every day, why are you so afraid of change software? Because you dont want to admit you dont have all the answers? Get Real, baby! Engineers don need to be pushed, they are adults ot they should be at least. People need to break silos and work together. Why do we have silos? Because we inherit an industrial hierarchy and we keep following. Why? Because we don't challenge the status quo.

In summary, the Traditional BA is worried about the wrong things, doing the wrong things, but all that can and should change. This change is not only in the BA Mindset and skillset but also in management because management imposes process.

It's not about Process... It's all about process!

Management 1.0 tend to worry only about(Dates, Price, Scope) and forget that, or does not know, modern digital products don't work that way. Management tend to FIX everything with the process. It's not about process. It's not about RULES and ANSWERS for all the questions, there is no such thing. The process tends to be fixed with... new process. Agile, Lean, DevOps, UX is not about process. Looking for process is lazy, it's an easy way out, there is no easy way out, there is no silver bullet, there is no one size fits all.

The process makes sure we keep making the same mistakes over and over again. Agile is about continuous learning and improvement, traditional process often does not have REAL change, only minor adjustments. So this means the answer is not Scrum, The answer is not SAFE, the answer is not BA Certification or anything like that. It's not about process.

However, is all about the process. It might sound strange what I just wrote but it's really all about the process but not about the prescriptive process with roles, rules, and tasks but its all about the learning process. Organizations need to learn how to learn. The first step into the learning is to learn whats value and whats waste, lean can help you on that.

The Rise of Lean BA

Lean BA is a great step forward into the right path. Lean is a great way of thinking/set of principles to follow. Lean teaches you how to SEE and avoid WASTE. Also lean focus on empowering people and effective organizational learning. We leave in a VUCA world we the only way to deal with this new world is with new mindsets and principles. These principles are not that new, they were around since ever since agile and 20 years old and lean even more. The main issue is that organization still pay zero or so little attention on learning, education and they are really busy making mistakes to stop and improve. How many companies you know do more than 4 hours long retrospectives?

I need to admit, the world Lean gives me psychological safety because I'm really worried every time I need to use the "agile" world. Why? Because agile is dead, there are so many "pilantras" bad practitioners that 99% of people doing Agile(Scrum) are completely full of bullshit. When you have so many bad samples and so many wrong people doing things is very hard to get the real value from "agile" nowadays.

Lean is less spread around the world, therefore, there is less "pilantras" and less bad sample and bad leaders. In principle, I agree 100% with agile. However, when I took the "implementations" people do I really lose the faith in mankind. Lean BA means, you are a leader and you "drive" change and you are working with the execution team to LEARN and deliver great products/software. BAs can benefit a lot from lean principles but also from engineers.

Mixing BA with Engineering

Engineers are born around Chaos and Uncertainty. BAs can benefit a lot learning these skills. The world is changing and will keep changing engineers need to learn new languages every year, new frameworks every week, new javascript frameworks every second :D

Engineers are used to learning and forget everything they know every 5 years. BAs are not used to "unlear", BAs are not used to learn things all the time. This is one of the most important changes BAs need to go thought. Since 2010 I work with POs defining SOA Services / APIs. Yes tahts correct, the business define services. Why? For several reasons:

• The SOA Services(API) or microservices / Serverless like they are called nowadays is important.
• In order to re-use features and data, we need to have APIs.
• APIs are key for partners integration, user customization, and growth of the business.
• Uber EATS is built on the top of Uber, how they did it? APIs. 
• SO yes, BAs need to define APIs, but they dont do that alone, they work close to architects.

Right, so BAs need to learn how to code on the Backend? Not really. But they need to LEARN how to THINK beyond the User Interface(WEB UI). BAs need to master other interfaces like:

• Data
• AR | VR | XR
• Audio Interfaces: Alexa, Google Home
• ChatBots and contextual apps
• Mobile Experience
• NO UI Experience: IoT, Beacons, and Sensors

Are you ready to master all these software interfaces? IF you just know how to deal with Web UI you need to learn and change quickly. Engineering has other create things like:

• A/B Testing: Surprisingly many product companies still dont doe it. How we test ideas in prod?
• Observability / Domain Observability: How many features are being used now? 
• Split Traffic: How we deploy or rollback versions impacting just a handful of users? 
• GitOPS: How we release the software so stable and faster that users see this as new normal?
• DevOps: How we break silos and merge 2 areas into 1 new skillset and mindset? 

As you see there are plenty of things BAs can learn for engineers. When we think about Architecture, there are other skills that bas can learn from architects:

• Critical Thinking: How we know whats matters? How we make decisions?
• System Thinking: How we see the whole? How we fix dependencies? 
• Chaos Engineering: How we deal with chaos? How we test assumptions?
• Trade-offs: How we drive critical analysis? How we asses risk? 
• Continuous Learning: How can we do POCs? How we we learn more and faster? 

As you see BAs can benefit a lot working and blending in with architects and engineers in general. So what about the UX Designer(User Experience). There are plenty of cool things to learn too.

Mixing BA with UX

Amazon has user obsession. That's it. I could finish this section and move to the next one. Did not get it? You need to be completely obsessed with your users, here are some samples:

• Who are your users?
• Where they live?
• What they do with your system?
• What are the pains?
• Why keep using your system?
• Why the left(churn) your product?
• How much cost to acquire a user?
• How features are most used, and why?
• How many clicks they do on the ui, where they click? do you have heatmaps? 
• What persons do we have? What tone do we use?
• What are the principles behind our Design System? Do we have a design system? 
• What are the user's journeys? 
• What we are not doing? Why?
• What user observations and experiments are we doing it? without software? 
• And much, much more...

UX is great researchers, they learn a lot from a market and fast. UX Designers also do a great job with cross-pollination, they look into other business ideas and them to blend in. UX is full of science, it's not random at all. So what skills BAs can learn from UX Designers?

• Research: What others are doing? Could I use a BAR idea into a Bank? 
• User Obsession: All the previous questiosn and much more...
• See The Whole: Ux worries about the whole experience, not a single UI.
• Listen: UXs are great listeners.
• Ask Questions: A great UX know how to inquire the user and learn from it. 
• Rationale: Everything UX does there is a reason, they can and will explain to you.

So with Lean BA + Engineering / Architecture and UX, we are close to defining our brand new modern BA. Let's understand a bit more what is a modern BA, where they live and what they eat.

The Rise of Modern BA

The modern BA is a BA who thinks first of all. Modern BA focus on Business Value and Impact before worrying about dates and list of features. Modern BA cares a lot about UX and understand the users and understand the PROBLEM that the product is fixing. Modern BA understands a lot about software and works closely with Architects and Engineers to drive best SPECIALIZED solutions.

Modern BA are hard to find, the best path is not learning. In order to lean the BAs will need to learn how to deal with anxiety, chaos, and complexity. Modern BA uses modern tools beyond the intuition and writing user storys that the business ask.

Critical Thinking & System Thinking

Modern BA focuses on effective learning, not in a pointless process and it's a critical thinker who uses system thinking tools like 5 whys, root cause analysis, Ishikawa, force field analysis. System thinking tools are used by agile coachs for decades. Modern BAs can benefit from these tools in order to do a better ANALYTICAL job on the business side.

Critical Thinking is the key to judgment and making good decisions. Good decisions come from bad decisions, this requires lots of self-awareness, reflection, and retrospectives. Large Business Organizations need modern BAs in order to deal with complexity and large workloads IT needs to deliver.

System Thinking is important to see the whole and make sure the product does not fall after some user stories. Large companies are complex, digital products are complex, there are tools to deal with complexity.

Visual Thinking Tools

Visual tools dont reduce the complexity of things but they help us to understand things. Modern Ba needs to know several visual tools like Canvas, Mind Maps, Raci Matrix, Swagger, UX Tools, and many other tools.

Visual thinking tools are great for BAs structure they thinking but also great for them to teach and educate developers on the business on the problem we are trying to solve.  Modern BA does not use only visual tools but text tools as well like 5W2H, Star Methodology, User Story Formats and much, much more. Modern BAs know how to explain and drive conversations with developers, modern BAs have in mind a clean and concise vision of the problem, like:

• What problem are we trying to fix?
• What context do we have?
• What is the UX space? Personas? Pains? Gains?
• What are Tech opportunities? New Interfaces? Re-use for other products?
• What are the solutions we are doing? and most importantly why? 
• Why Are we doing this? 
• Why are we not doing that? 
• What people need to be involved? 
• Does the BA do all the articulations? Did the BA talk to all people needed? 

AS you can see the modern BA need to be proficient in many things but this is the way. Life is hard, digital products are hard, let's face reality and face the more complex things. Like learning.

Learning how to Learn 

People need to learn how to Learn. People don't know how to learn. Companies don't know how to learn. Companies don't consider learning as part of any estimation. It's like people have all the answers and they just need to do it. In Order to lean you need a master and conquer your EGO, have full patience and keep learning every day. There is no learning without FAILURE. There is no progress without Chaos.

Modern BAs need to be like Bane from the last Christopher Nolan Bat movie, shaped and defined by the Chaos. Why do we need to embrace chaos so hard? Because all these changes are hard and take time, people want to make it right so badly that makes them make more mistakes them never. Relax, chill out, you will make lots of mistakes. As long as you are learning and always learning from failures we are more than good. This might sound simple but is very hard in practice. Because often we are teaching properly how to deal with chaos and complexity.

Learning how to Deal with Complexity & Chaos

Complexity is present in modern society. However, we are still not teaching in the schools the ways of system thinking, critical thinking and thinking outside of the box. Our education down here in brazil is completely wrong. Why? Several reasons. But we consider failure bad, we are not allowed to fail, this makes impossible to innovate. So we are created to be blinded and to not think.

Therefore we are raised to deal with the simple system only, where A leads to B and C leads to C. This Linear thinking is the root of all evil. We a teacher that since kids. We are raised with the culture that study is wrong and we just need to finish school/university and them we dont need study never ever again.

However, the world keeps changing and improving, the only way for us to deal with this VUCA world is to keep learning. So education is the key.

Education is key

This might sound basic. Really it is. Simple but 99% of the companies don't acknowledge that. 99% of the managers dont acknowledge that. We just need to follow a plan right? guys plan dont work anymore the world eats plans for breakfast. As a consultant, I always worked my ass very hard to educate my customers, why? because thats the only way.

This might sound strange. But most of the consultancy companies do not educate the customer. Companies just do whatever the customer asks. It's like going to the doctor and asking the doc to cut your leg, the doc will say no, but in IT we will do it.

So education needs to be placed in the system via Internal Events, Training, External events, Lighting talks, Retrospectives, Demo, open conversations, honesty, and adult mindset. WTF is an adult mindset? Well people often dont behave like adults, people often behave like kids, because they run away from problems, they avoid difficult conversations. Adults do tought things. Thats life.

The Discovery Process

Finally, the modern BA is forged by an agile/lean principles and culture of continuous discovery. Discovery is an INFINITY process that will never end. There is not an END or DONE of discovery. If you stop doing discovery is like stop breathing eventually you will die.

The initial results of the discovery process do not matter. What matters is fast iteration and continuous learning. Having said that I finish this post of my view of the modern BA.

Cheers,
Diego Pacheco