Only one thing can be the most important. If we want to align a workshop well, aligning it for one thing, and nothing else, is the easiest. A workshop has limited time, so the scope must be limited. Decide what the most important outcome is for the workshop, and design it fully for that outcome.
Everyone is important in a workshop. If the purpose is learning, each participant needs to get a chance to grow. For workshops aimed at creating or exploring, the views from everyone are even more crucial. It is important to have a structure that works for extroverted and for introverted people. One way to do that is by using exercises that let people think on a topic in multiple ways, some of those can be found among the liberating structures.
Guiding towards the purpose, and enabling participation, is done through structure. This post is about creating structure in a workshop
For a workshop to work as planned, you need to be able to complete all steps. Some workshops can bring value when half-finished, but most need the conclusion and some make things worse if left half done.
The workshop needs full focus. If the participants lack information, the facilitator has to have it at hand; otherwise the schedule will be disrupted. Try to anticipate what will be needed, or plan for breaks long enough so that missing information can be found.
The last, but not least, part is trust. The environment has to be psychologically safe, and the facilitator must be trusted by the participants. Trust can be cognitive or emotional. The important part is to have a mandate to lead the workshop, and that everyone else feels safe to participate. You can read more about psychological safety here.
]]>Unit tests define the collaborators and the purpose of a piece of code. When reading code with unit tests, we can read the tests first, and focus on how the unit interacts with the system. The review of the computational code, like the body of a function, can then focus on the implementation.
Putting this in the framework created by Heander, we solve the conflict between clarity and understanding by separation of concerns. Each test provides context for purpose and interaction for that unit. At that time we are not interested in the implementation, just the interfaces, and can remove that part of the cognitive noise. When we have enough understanding of the purpose of the code we can move to the implementation. That should then be a pretty small unit, with well defined collaborators, that we are already familiar with from the test. We have the external context in place and can focus on implementation details.
Separating concerns like that lightens the cognitive load, and might be a part of solving the conflict between clarity and understanding.
Test driving you code in small units, does not only help with cognitive load in the moment, but also helps everyone that will read that piece of code in the future.
]]>If the code is created by an open source community, or something else that is done outside of the ordinary work, things are different. For a team working with the code in a professional setting, asynchronous code reviews should be something to avoid.
A traditional code review has two major purposes. The first is to make sure that the code behave as intended. There are alternative ways to achieve this. You can work in pairs or an ensemble. A test first approach, with a good knowledge in test coverage design, might also help with this.
The second purpose is to maintain code quality over time. This is impossible for a team that lack refactoring skills, regardless of how well code is reviewed. Perhaps it works for a product in an environment that never changes, but then code quality will also be less important. So the team will need to know how to change production code in a safe and effective way. With that knowledge, you can review code that is important, instead of code that is new.
The important code is the areas in the production code where a lot of changes happen. You can then, as a team, look at the code and find ways to change it, so that it is easier to work with. That will improve the software design skills of the entire team.
To become a high achieving software team you will need the same skills that make asynchronous code reviews unnecessary. So try to ease them out if you can. If you don’t feel safe to let code go into production without a review step, make sure to only focus on functionality (or what regulations demand). Have a linter in place that checks things like formatting as a pre-commit hook. If the code quality is so low that it hurts to put the code in production, that developer should not work alone. It is harder to teach software skills through a written review than in person.
Save the review energy for the high stake parts of the system, and go through it as a team. Then you make sure that the knowledge from the entire team is used, and shared, and that everyone is onboard with the results.
When the code never has to wait for someone else to get into production, then you can create value really fast.
]]>So if the code under test requires a lot of magic to be verified, it will not be straightforward to use in the codebase.
A rule of thumb is to favour testing frameworks that are so simple that you could easily just have written the code yourself. A testing framework is a convenience. It should not make it possible to test things that you could not test before.
When you need to construct the test data, write your test doubles and create every other dependency needed, pure laziness will create code that is modular and easy for others to use. This is the design pressure from the tests.
If you let a framework entangle your code, unit testing gets hard really fast. A Wunderbaum testing framework will mock and stub your controllers and databases, instead of helping you keep the domain logic separate and testable. It removes the design pressure, one of the reasons to write tests first.
Sometimes you end up with a codebase that needs to get under test before it can be fixed. Often that can be done through approval testing or end-to-end testing, just to have some sense of safety. In that process you might also find Wunderbaum testing frameworks helpful, since the code stinks so much you need all the perfume you can get.
But when the code just has some odour, try to avoid things that hide the smell. If your code is hard to test with a slim testing framework, you probably have code that is too interdependent, or not modular enough.
Keep your code nose fresh and think of design pressure as a friend.
]]>When you open the jar you will know much more of what to expect than just the amount of beads, but “how many beads?” was the only question needed to start the conversation.
Estimates in software is not about scheduling tasks or defining velocity. “How big is this task?” is a shortcut to a discussion on scope, technical limitations and prerequisites.
We need to understand our options when prioritizing. The scope might be interpreted in different ways. Members of the team have relevant knowledge unique to them that changes the understanding of work required. All of this will show in an estimate of size.
Instead of taking all the beads out of the jar to sort them, we just ask how many they are. Then we keep the information it generates and throw out the estimate.
]]>In short Samman coaching consists of two parts, a learning hour and working in an ensemble. The learning hour is interactive and tailored to the needs of each team. It is a way to explore new skills and concepts in a safe and well prepared setting.
The ensemble working is done in production code and is coach facilitated. I have several posts on working in ensemble and its benefits
I claim that this is far more powerful than it initially seems, at least when done right. I want to compare it to regular courses, since I think they are the closest alternative.
Samman technical coaching is done with your team. No more returning from a course and trying to convince the others of the value in what you learned. It is also adjusted to the knowledge level of your team and facilitates learning and teaching within the team. Samman technical coaching provides new knowledge, a learning culture and tools for learning together.
Learning how to deal with complex problems is hard. You need a complex problem to solve, understand that complex problem and still have cognitive capacity left to learn a new tool or method to solve it. When working with problems found in your production code, you already understand the domain. That leaves more room for learning the tools, without having to use an unrealistic and limited problem. (The coach needs to know the material well enough to teach it in any codebase.) This brings more confidence in the tools and skills, since the team can see that they can be applied in their reality. (If the tools do not work in the current production code the coach will have to adapt the plan for the learning hours. That feedback is not possible with traditional courses.)
Happy families are all alike; every unhappy family is unhappy in its own way.
– Leo Tolstoy in Anna Karenina
The goal is code that is dependable and easy to change. How to get there is different for each team. As a Samman technical coach you listen to the team and read their code. The goal is to provide as much value as possible in a digestible way. All topics are presented one hour at the time, often in small steps. That way new concepts have a chance to get repeated and to stick. As it is directly tried in the production code (it does not have to be producing value, but it can) the team can try things out at their own pace. This creates an offer of knowledge that can then be pulled into everyday use. Change is best done without fear. Samman coaching provides the specific tools that your team needs for change, but in a way that is safe and fun.
Samman technical coaching brings the team together. By using familiar production code it can teach more complex topics. As the content is tailored to the needs of the team, and proven useful to them in their codebase, it sticks and provides value in the everyday work for a long time.
]]>The previous post is on coping with IT-stress This is about preventing it.
Software is named in contrast to hardware. Computer programs should be easy to change. You can get an update into production in less then an hour, with modern methods. ( Refer to Accelerate if you encounter someone who says otherwise.) If the software is not working, for the ones using it, the software should be changed.
Half of corporate budgets for software (in Sweden) is used for customisation. Either for modifications of existing software by external parties or external developers working on in-house projects. On top of that, about 40% of IT-workers in Sweden work for companies that produce something else than software.
That is a lot of software being written with a specific customer in mind. If you are that customer, demand to be a part of the entire process. Software tailored to your needs requires your input, just as a suit or dress is made with multiple fittings.
“Off the shelf”-software has to be tried by the end users before committed to. The cognitive ergonomics when investing in software should be considered similar to ergonomics when furnishing a workshop or office.
If the software is a part of your “competitive edge”, consider having a dedicated team of software developers, who get to know you and your domain really well. Provide them with direct access to the end user and put them close to (or in) the product team.
The software team should be like a painters brush, swift in the hands of product development.
If your software team can not deliver on that, provide them with training and other support until they do. Your organisation deserves it.
The purpose of software is to make things better. It is a failure if the end user can not easily use the product. We can check that we are building the right thing as we go, if we have the end user close and work in small steps. In Extreme Programing, a flavour of agile, the customer is represented in the team. If that does not work, find another way to get constant and real feedback. This avoids delivering something that is “done”, but can not be used.
Whenever you can, demand more of software you encounter. Accelerate is a good book on what can be expected of an organisation delivering software. The DevOps report 2021 and The DevOps report 2019 are shorter reports covering the findings from the research. Remember that soft in software is soft as in changeable. If you are in charge of spending money on software, off-the-shelf or in developer hours, take your responsibility. Software development is best done with the end user in focus and in small steps. Don’t accept less.
]]>Internal quality is a codebase where the functionality is easy to change without unexpected side effects.
External quality is software that behave as expected by the user, demanding as little effort as possible.
Sometimes the two are related. Code forced into new purposes without prior refactoring might behave clunky or erratic.
A lack in internal quality can still be prevented from showing to the user. This is where we do endless manual testing, extensive monitoring in operations or add a lot of extra computational resources.
On the other hand, software with high internal quality might still have poor external quality. If the behaviour of the application is hard for the user to navigate and predict, it will still not be perceived as working correctly.
If the software has internal quality it is easier to change. This makes it easier to do user research and update its behaviour, so that it works well for the user.
Internal quality makes it easy to write software that do what we expect. External quality is software that does what the end users expect.
]]>FullStack is about what kind of software you are comfortable writing. Where the stack starts and ends depend on who you are asking. It includes at least two layers of software.
DevOps is about what parts of the software lifecycle you are comfortable with. The requirement is that you see it through at least until it brings value to the end user.
You can be a mobile app developer and do DevOps, as long as your responsibility includes the distribution of the app, and that is all that is required for it to reach the user.
You can be fullstack and not do DevOps, if you let go of the code as soon as your feature is implemented.
If you, and your team, are responsible for development and operations, that is DevOps.
]]>
- Communication overhead
- Risk of conflicting interests
- Temporal dependencies and scheduling problems
(Interruptions from auditing, or bugs found by external quality assurance, is a version of temporal dependencies.)
This consumes resources that could’ve created value.
As soon as the software organization grows enough for the developers to split into more than one team, the dependencies will change. In the worst case both teams depend on everything the old team depended on, and each other. Managing dependencies more important in bigger companies (due to math). Kent Beck has a great text on what you can do to deal with dependencies from within an existing team. The suggestions below require more influence over the organization. The goal is to create working software with as few dependencies as possible for each team, while maintaining a reasonable team size. The book Team Topologies covers much more on how to organize teams, so I include their names for different teams along my own.
This is done in DevOps. When running the code is included in the responsibilities for the team, operations is no longer a stakeholder. The same can be done with product, security and user experience. This is one of the reasons to have the customer be part of the team in XP. A cross functional team gathers all expertise in one place. The main focus is solving the business problem as well as possible. This improves all three listed problems with dependencies, since collaboration is moved to within the team.
Organize teams around their goal (user path or feature) instead of what technology they use. This also requires cross functional teams. It is easier for the code to adhere to the single responsibility principle when the team has only one goal. In Team Topologies the “Stream aligned team” is clearly intent centered. “Subsystem teams” and “platform teams” can also fit the description, if the other teams are seen as their customers. Solving the scheduling aspect of the dependencies relies on that the stream aligned teams can move forward independently of the subsystem and platform teams. (Platform teams are very different from a backend team, that still has to implement changes for each feature in the frontend.)
One way to see it is that the business logic is created by stream aligned teams. The technical advantage can be created as a subsystem or platform, used to improve the work of other teams as it gets available.
If the overhead from having specialists in each team gets too big, you can have service teams. In Team topologies those are “Enabling teams”. This flips the direction of dependency between teams. If the legal team is there to control, it is a stakeholder for the software team. On the other hand, if the software teams take full responsibility for the legality of their code, the legal team can be there to serve them. The legal team then has the software teams as their stakeholder. It can still create delays, but the control and the responsibility is with the development team. Legal advice is pulled from the legal team instead of pushed to the development team. This can be used for other areas as well. Service teams still have to manage their time, but they should at least not have to explain why their work is needed. So the conflict in interests is solved.
The core in universal design is to move away from the able bodied user as a norm. People with disabilities are not a new kind of user, they are a part of the general user. We design for different screen sizes, without having stories like “as an iPad user I want to be able to buy a ticket”. The same way we can simply make accessibility a part of how we work. This is easier with a diverse team. Universal design can also be expanded to include other marginalized groups. I don’t think that “as an African American I want to be able to use face recognition” should (need to) be its own story. It is what we want to achieve that differentiates users, not the circumstances we are (currently) in.
Read my posts on working in an ensemble! This deals with all the listed problems with dependencies, but between individuals within the team.
]]>Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
We also know from the DORA DevOps report that we want loosely coupled code. The SOLID principles can help us write code that has high cohesion and low coupling. I think we can translate those to work for organizations as well, and see how we can help the code be flexible through how we work.
There should never be more than one reason for a class to change.
This is really about stakeholders. (See this blogpost for more on how it works in code.)
Aim for as few stakeholders as possible for a team
The stakeholder can be internal or external.
(I expand on what to do to achieve this in another post.)
Software entities … should be open for extension, but closed for modification.
We want change to happen where it makes sense and only when needed. For organizations we get there by team design.
Create small, long term, self sufficient teams that collaborate.
Teams get better with time.
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
How something is solved can change, and you should not have to care about it. The design of the base class helps us find the purpose of the object from the user perspective.
Internal services are internal products
Create internal services as if they would be sold to external customers. We want each part of the system to have a clear purpose and each team to have independent pacing of their work. It also makes it possible to swap it for “off the shelf”-solutions if the service is no longer a part of the competitive edge. (And let the team take on a new project.)
Clients should not be forced to depend upon interfaces that they do not use.
We don’t want code to be weighed down by conforming to rules that does not apply to it. The same is true for teams.
Let each team own their process.
There can not be one flavour of agile in a big company. Instead, each team should be provided with the time and expertise to learn how to improve their own work. Be clear with desired outcomes and core values, let the team do the rest.
Depend upon abstractions, not concretions.
This is about integrity.
No micro management.
Give the team one stakeholder and the capabilities they need to fill one purpose for that stakeholder, then trust them.
]]>I believe that software developers are a lot like octopuses. To thrive, we need problems to solve, or we will create new problems, and in some cases, problems for others.
Most software development can be done quite simply today. We have high level languages, frameworks and libraries for technical advanced things that used to be done by each team. Now the work consists of using existing tools to express the domain and adapt them for the product. Most software today is developed where the programming part does not require you to be very clever. (In a proper, modern, environment. Unless you are doing something totally new, most are not. I am not even going into AI.)
Implementing a solution, screen by screen, or api-call by api-call, that someone else designed, is not enough of a puzzle.
So, what options are there for a developer who loves problems?
My suggestion is that programmers should be a part of product development. Give software developers business problems to solve, as part of a team. Then we can safely aim to make our codebase easy to work with, even boring, because we know that we will never run out of problems to solve. The cognitive ability will be put to use where it is most needed, to solve hard technical problems when they arise, and to support the business at all time. And that is only one of the benefits!
]]>For tailored clothes we take measurements. The model is chosen based on the body type of the person. When picking a color the complexion is taken into account. And last, but not least, the clothes are fitted before completed.
When it comes to processes we often ask for a copy of the suit. In his paper “Standing on the shoulders of giants” Goldratt states “What we have to bear in mind is that the application makes assumptions (sometimes hidden assumptions) about the environment. We should not expect an application to work in environments for which its assumptions are not valid. We can save a lot of effort and frustration if we bother to explicitly verbalize these assumptions.” This is from a discussion on the Toyota Production System. Other companies tried to copy it, but never did as well as Toyota.
Toyota Production System is like the suit. Making the assumptions explicit is as having measurements added to prefabricated items of clothing. But you can only get the best results with something carefully tailored. That is why I think that learning how to evolve an organisation and its processes is far more important than adapting the correct pattern or method. Get your organisation “tailor-skills”, practise measuring and fitting.
An organisation can use retrospectives, system wide measurements and the “thinking processes” that Goldratt developed as measuring tape and a dressmakers ruler. By looking at what others do we can get a starting point, a base pattern for a cut we like. But just copying what someone else is doing will never bring excellence.
Just as a piece of clothing will always look best on the person it is tailored for, only the organisation that invented a method can get the most out of it. So get the skills to tailor your own organisational model!
ps. When your body changes a tailor can help with altering the clothes. An organisation with skills for adapting processes is prepared for change.
]]>TL;DR; Your retros will be more productive if you do them right. Read Agile retrospectives, making good teams great and/or get someone who facilitates your retrospective.
Retrospectives are fundamental to a successful team. With continuous improvement we can go wherever we want. But there are meetings, labeled retrospectives, that just don’t cut it. So when someone says “we did retros, but it did not work for us” I get really suspicious. If you don’t think your team need retros, did you try a good retrospective?
Some people think by talking (and gesturing). That can not be done with everyone listening. Others need to gather their own thoughts in quiet. So a good retrospective has a structure that enables everyone to contribute, without taking forever.
If what you do could have been replaced with a newsletter, a suggestion box and a poll, it is not a retrospective. The different parts of a retro are combined to do data transformation. Each step then pulls new input from the participants. The result is one thought built on another, forming collective insights.
No multitasking or daydreaming. Check in, making sure we are all present. Then facilitate so that everyone feels how their time is valued. That creates focus.
One experiment at the time. If everything is important, nothing is important. Make sure that everyone feels heard. Have a fair process for picking the next experiment. That creates commitment.
We work best when in a good mood. Creativity and collaboration sometimes need a push. The retro should be a treat, not a chore.
Retrospectives also need to improve and change. Sometimes we end up just going through the motions when something gets too familiar. So a good retrospective also gathers data on the retro itself, and changes to always serve the team the best.
“We are too good to need retrospectives” is the same as “I am too fit to work out.” Teams that struggle have a lot to win from a retrospective, since you often can find high-impact experiments to try. But teams that work smoothly, will be able to use the retrospective to gain even more momentum.
]]>With people working closely, preferably in the same room, the result will be better. But with only verbal communication there would be no ticket systems, version control data or minutes from sprint meetings to tell the story about the work.
Taken to its extreme, this could be compiled source code with no other information accompanying it.
Working tightly with the customer, a relationship based on good communication and trust, there might not even be a contract. But a contract is also an artefact of that relationship, that can tell stories about it to those who come after.
Working with one thing at the time, measuring effect as we go, there might not even have to be a plan. The step we are at now will get results directing the next step. That is a great way to get value through the door. But without a plan, there will be one place less where our intentions and dreams are recorded. In worst case we end up with a compiled binary and nothing else. With no artefacts produced by processes, tools, contracts, documentation or plans, there are no clues to how the product ended up the way it is.
That is, while there is value in the items on the right, we value the items on the left more.
One of the values in the items to the right is communication with the future. Telling coworkers to come, or future versions of ourselves, the context of our decisions. When agile “goes overboard” this is one of the things that are lost. Few projects end up as only a compiled binary, but a lot is left with less context than would be helpful. The understanding of software is dependent on context. Tell the story of you software with deliberation when cutting down on accidental artefacts. Do not let your reasoning go traceless.
]]>When I started working I met a lot of people who had worked in the kind of projects that the agile manifesto was a reaction to. They had first hand experience of the pain that agile was supposed to fix. Often they had fled the old company before ending up in a team with me.
In my world “working software over comprehensive documentation” was a “no sh*t Enola”. But I still thought that it was a good idea to write some things down. I am quite forgetful. For those previously stuck in waterfall without water, documentation was the evil personified. The manifesto states “…, while there is value in the items on the right, we value the items on the left more.” But to some it still turned into “no processes, contracts, tools, plans or documentation!!!”. That made it very hard to be the new kid in the team. It made it hard, full stop. It actually gets very tricky to write working software, collaborate with customers, adapt to change or interact with people, without any kind of structure.
The inevitable pendulum of human culture, one could say. We do see “agile frameworks” with lots and lots of structure those days. So much processes, contracts, tools, plans and documentation that it could be argued that there is no room for agility in them. Are we doomed to the eternal circle of throwing out babies and bathwater?
My suggestion is that we put all our focus on what we do want. I believe that The heart of agile with its collaborate, improve, deliver and reflect is one way to do that. Things that we want to avoid will change with time. For me right now it might look like “Working software over extensive backlogs” “Customer collaboration over genius entrepreneurs” “Individuals and interactions over 10x programmers” (Ok, to be fair, I do not really value the right side of those, but I would perhaps miss them if they were branded as the new evil.) Being guided by what we fear won’t help us. It might even make us avoid the things we do want, like collaboration, since it is harder to collaborate without processes for retrospective or tools of communication.
Bridge the agile gap by focusing on what we do want! We can use the left side of the agile manifesto, The heart of agile, Theory of Constraints, Lean or any other teaching that share their general message. I would say that the essence is: Focus on what really brings value, do it together, optimise for fast feedback and use what you learn. And if you see an old oaf who refuses to write a readme, or a young brat who seem to want waterfall all over again, remember that you probably work for the same outcome, you just have different experiences.
]]>As a consultant there are thresholds made by fear everywhere. Recognising it as fear might be hard, but Patrick Lencioni gives us tools for understanding the origins of our emotions. In his book Getting Naked : A Business Fable About Shedding The Three Fears That Sabotage Client Loyalty he divides them into the fear of losing the business, being inferior and feeling embarrassed. Strategies that both challenge those fears, and benefits the customer are listed in the book. This is what I took with me from reading his work.
The fear of feeling embarrassed makes us withhold ourselves from the customer. Asking questions, that might be dumb, aids the customer by making sure that everyone actually understand what is going on and that nothing important is missed. The outside perspective from a consultant will also bring a company new insights. But that only works if the consultant has the courage to share their thoughts, even if they seem obvious or silly. Celebrating our mistakes also fight this fear and makes it easier to try things out, for us and those around us.
The fear of losing the business holds us back from giving everything. It can be in terms of giving help to a prospect customer that ends up being all they need from us. Or having our honesty bring a customer relationship to an end. The solution is to jump into the cold water. If you enter a situation where something feels off, bring it up. It is only by getting naked that the consultant can point out that the emperor has no clothes. But we tell the kind truth. It is not about embarrassing the emperor, it is about getting him a better tailor. Start helping the prospect customer before any contract is in place. Show that you bring value before negotiating the rate. Then you know that it is you, and not your CV, the customer wants. And everyone knows you can make a difference, since you already did.
The fear of being inferior is the foundation of the imposter syndrome. The naked consultant solves this by taking pride in not being proud. If something needs to be done, we will do it. If there is a way to save the customer’s face by taking the proverbial bullet, we will do it. This is enabled by a true interest in the customer’s work. Success for the customer’s company should always be closest to our heart. Only work with customers where you can share their passion. This way we have something to focus on instead of our ego. It is our ego that fears being inferior.
Being in a kind environment help us battle all of this. I wrote earlier that practise is the only thing that makes sauna and cold baths easier. I did not mention the crowd of friends cheering you on from the door to the changing room. I know that I am not enough. But when in a good environment, my team and I got this, when working together.
The DevOps report tells us that the number of elite performing companies have increased between 2018 and 2019. At the same time the medium and low performing group is still more than half of the respondents. The IT-industry needs nakedness. For those ready to jump into the cold water there will be plenty to do for a very long time. And I will fight my fears every day, as a consultant and employee, for the joy of seeing progress.
From my Finnish friends I have learned that in the sauna I am not naked, I just don’t wear any clothes. As a professional it is the other way around — I am fully clothed, but completely naked.
This is a slightly modified version originally posted on LinkedIn.
]]>You do not have to like things the way they are, but you can not act appropriately to a situation while pretending it to be another. Sometimes it can be hard to know what is really going on. But when you do know, try to see it for what it is. That is the first step towards changing it, or dealing with it otherwise. Sounds like sappy self help talk? But if it was your hard drive being full, you would not imagine that ignoring it would solve the problem. First when you acknowledge that you have a space issue you can either stop adding stuff, start deleting things you do not need, or look into options for more terabytes. Probably all three. Take the hard drive problem solving attitude with you into other, more sensitive, areas. The reality will give you a starting point to act from, the fantasy will not. If you want to look more into this you can search for “ACT, acceptance and commitment therapy”. It is really just about tools for dealing with your life the same way you would with a software problem. Find what is really going on and then fix it, or figure out how to live with it.
Think about how you think and feel. The symbolic interactionism of social psychology sees the self as a dialogue between the “I” and the “me”, where the “me” consist of what we think that other think about us. It is like writing code with the code review in mind. “I need to run the linter so that Ed sees that I care about the team”. But what we write is not code, but our identity. Meta cognition is to add another layer. “If I write the function like this, Ruby is going to say that I need better naming, and Ruby is someone I trust, so I should think some more about the name.” “This function could be broken up in two, and Tess at my old job would probably tell me to do that, but in this team we have longer functions, so I should probably not care about what Tess says right now, perhaps later. “ We can do the same thing with our thoughts and emotions. “I feel sad right now. That is ok. I could be sad since I am hungry, or since I felt misunderstood during that conversation I just had. If I get something to eat, at least I can rule that out. Still sad. What was so hurtful about that conversation? …” With a conscious relationships to the conversations in our head, we get power to change our (inner) lives.
One example is how we can use time to change our perspective. As a kid, when walking home through the cold and the dark, I focused on the feeling of finally getting home. Then I could use that sense of joy and relief as a shield against the Nordic winter. I shifted my perception of time into the future, just enough to keep walking, but not enough to worry about tomorrows homework. The same trick helps me get some rest by focusing only on the present. If I let the past and the future fill my head there will be no break. But in the present, probably in a sofa with a cup of tea, there is relaxation. Even if it is only five minutes, they are fully mine if I shrink my reality to only be those five minutes of peace. Letting regrets or worries sabotage my moment will not solve anything. Rested I am better prepared to deal with the things that I can do something about.
Mindfulness is a good word to look for, if reading more about this. That is a tool for adding monitoring, orchestration and debugging into our own thoughts and emotions.
You are not done yet. As a software developer we learn new things all the time. Communication, regulation of emotions, self awareness, relationships and other things that make it easier to be a human, are also skills you can practise. If you believe that you can learn the new features in the next release of your favourite tool, you can learn this too. There are books. There are exercises. There are videos and podcasts. But just as coding, it takes practise. Life is unfair. Not all got put in front of a computer at a young age being encouraged to tinker with it. Not all are encouraged to talk about emotions or expected to take responsibility for their relationships. Luckily there is room to catch up. Just know that you can change. And learn. And grow. In all areas of life. Believe that failure is not a sign that you have reached your limit, but a clue for what to learn next.
These tools do not always work for me. I am still learning, growing. But they help often enough for me to want more of it. And I know that with practise it will make my life even easier. Also when my life gets harder in other ways. Keep growing!
Further reading:
Debugging your brain by Casey Watts is a concise book with practical advice on meta cognition. I highly recommend it. It is also available on audio!
]]>In the IT-industry an epic is a collection of things to do. They belong together, but as a whole they are too big to do at once.
In fiction, the epic story is an extensive adventure. It turns the innocent main characters of the first chapter into seasoned adventurers, or even gods, before it ends. But there is also the expression an epic fail.
Agile development is an adventure. It is a place for exploration and growth. But if we want to go on until the author is dead and someone else will complete the story arch, we will have to pace ourselves and take one step at the time.
The epic fail enters when we lose track of the small steps. Putting all the small steps into an epic might make us forget to adapt. When the roadmap charts our journey over the night camp of the undead army, we need to be able to change course. Knowing why we are out here in the first place, will make sure that we end up in the right place anyway. So do not put your experiments into the bag of epic. It is one of the more treacherous magic items. In the bag of epics, experiments risk turning into stone, weighing you down on your agile journey. Instead, take each step for its own sake. Keep your head up and explore your surroundings. That way you will notice danger before there is no way evading it and eventually find your way home, while saving the world. Remember, not everything worth singing about is something you want to experience first hand. And as Tolkien puts it in The fellowship of the ring “Not all those who wander are lost.” and “even the very wise cannot see all ends.”
]]>In the analogy with a factory our groomed backlog items can be seen as work in process. Throughput in a system is limited by high work in process. Backlog items do not take up floor space. But they can get old and irrelevant, or stress the team by being a metaphorical mountain of waiting work. The buffer before a machine is calculated by using the throughput and the time to replenish. Therefore I suggest that the meetings for grooming the backlog should be scheduled in proportion to the team velocity and the current size of groomed items. A rule of thumb is
time to next meeting = work in groomed backlog / (velocity * 2)
This is not precise, so you do not have to measure velocity, just get it about right.
Going through backlog items is hard cognitive work, and we are not very good at doing this for long periods of time. So having shorter, more frequent meetings, will help us stay fresh and focused. Pick a time in the morning, when the brains are fresh, or after lunch and some rest where the brains have gotten new energy. Then keep it short, preferable under one hour, and focus. That way you will make better decisions and stay engaged.
We get better at things that we do often. Things that are painful, but important are good things to get better at. Hence, do painful things more frequent. For Toyota this was setup for the machines. For me it is time reporting. For some software teams it is grooming the backlog. Do a short retrospective after each meeting and focus on the improvement of the processes. Then we will get really good at preparing our work, and well prepared work is more fun to complete.
]]>