Agile Archives - jcfausto

Tag: Agile

3 Voices You Should Have Inside Your Team

This article is not about the Scrum Master, Product Owner, and Dev Team. Curious? I’ll explain what I mean.

If I ask you to propose a way to organize a team that allows the team to be as independent as possible and is also capable of enabling self-management. Which approach would you suggest?

I have the feeling that suggesting Scrum as an approach for this particular situation came to your mind. Although Scrum is a very good framework to introduce the agile way of doing work it doesn’t perform very well when it comes to helping your team to be agile. It tells you what, but it doesn’t tells you how.

I’ve seen recently many teams moving away from this standard way of setting up agile teams to a more tailored solution that takes into account the company’s culture, regulations, the type of industry. I believe that agile coaches or change agents with a certain experience have acquired sufficient knowledge to create or suggest a tailored solution that will fit better the organization’s needs.

Following a generic recipe, which is essentially what frameworks are, is not your only option when it comes to enabling an agile mindset and structure. Instead, you can think and use these generic tools as a reference, cherry picking or adapting what is there according to your environment’s needs.

For instance, you should take some time to analyze and understand where are the bottlenecks, communication ruptures, etc. Understand first the environment you’re in and after think of a solution that will survive on such conditions.

Different perspectives are what you need in order to create different experiments that will allow you to really leverage agile practices inside your teams in order to get better results. I’ve thought a lot lately about many agile related learned concepts that aren’t making much more sense anymore considering the different scenarios I saw. Contexts and people changed and I believe this is one of the reasons why I’m having such thoughts and feeling.

Having the abovementioned in mind, I’d like to share a different perspective to take into consideration when trying to build an agile team. Forget about which framework you’ll use, just make sure you have three voices inside your team.

The Three Voices

If you’re serious about autonomy and self-organisation and you really want a team that “is” and not just “do” agile than pay attention to these voices.

A team without one of these three voices will not be balanced and will most likely depend on external people that speak one of the missing voices. Still, even having all the voices, there’s no guarantee that the team will be able to self-organize because voices are just one part of the equation that results in autonomous and self-organizing teams. However, having the voices will increase your odds of success.

1 – Voice of Viability

Who takes care to check if what’s demanded is viable or not?

This voice is responsible to say to the team what are the market and business needs and what are the potential solutions to fulfill these needs.

A rough example: A company that produces software designed to manage cargo ship construction, will not likely decide to add smiles to the app’s chat because that’s not what the market is demanding. It’s not a viable solution for that particular business.

2 – Voice of Desirability

Who takes care of checking if a solution is desired?

This voice inside the team will be responsible for saying if something is being desired or not but customers. In order to do that, this voice has to understand the customer world.

It’s not very hard to imagine some viable solutions, but which ones will custorems be more willing to buy? Which ones have higher changes to succeed? These are questions that the voice of desirability is reponsible to answer.

3 – Voice of Feasibility

Who takes care of checking if what’s is viable and desired also feasible?

This is the most technical of the three voices. Usually the people that will transform the idea into something concrete – that can be consumed by users – are the ones that can express this voice and say if something is feasible or not from the technical perspective.

Make use you have these three voices inside your team, and your problem regarding autonomy and self-organization will be half-solved or at least will have higher changes of being solved.

Conclusion

If you ensure that your teams have these three voices inside and those voices can talk to each other frequently and in synergy, you’ll be able to build the framework you need for your team and organisation.

Person seating on a bench by the river looking at the horizon and thinking

3 Statements That Don’t Leave My Mind

January 8, 2019 / jcfausto / 0 Comments

Recently I’ve read some statements that keep coming to my mind at least once a week maybe more.

1 – Make it work, Make it write, Make it fast

I’m a big fond of the concept of “Right first time” but lately I’ve seen so many time being wasted trying to figure out what would be the “Right” thing to do. Many unnecessary conflicts, concerns, non-validated assumptions, etc. This made me think more often about extreme interpretations or even shallow interpretations of such concepts that when not fully understood or discussed could lead to inefficiencies everywhere.

When I have such thoughts I remember of this concept that says: Make it work, make it right, make it fast! I don’t remember exactly when I’ve heard it for the first time but I’m sure, unless my brain is tricking me, that I’ve heard it during some research about game development (which is something I kept coming back to from time-to-time) and it was related to Blizzard, one of the big players in the game industry.

Later, after some additional research, I discovered that this term is actually attributed to Kent Back and it was part of the UnixWay for a long time.

You can read more about it here: http://wiki.c2.com/?MakeItWorkMakeItRightMakeItFast

Anyway, the whole idea is that when solving a problem in an iterative way you should consider to first make something that works, even if it’s not the right perfect solution. Ship it and learn from the feedback you’ll get in order to go to the second step, make it right. After rounds of improvement based on feedback then you’ll have to at some point make it fast. That will be the last step. That’s at least the intepretation that makes more sense to me.

I just feel that many times this simple and pragmatic approach will bring much more value than trying to use a sophisticated one just because everybody else is doing. But that’s just a feeling. I don’t have any data or experiment that can prove that, so maybe in the future, I can experiment with this approach and see what happens.

2 – The tiniest thing shipped is better than the best thing planned

This was something I’ve read on a blog post published by Amy Hoy on how to overcome procrastination.

You can read it here: https://stackingthebricks.com/how-to-overcome-procrastination/

This statement resonates with me because it sounds very responsive and lean, which is something I like. Also, it has a connection with the first idea as well, I believe. Living in the world of ideas and planning is super comfortable and can make you feel in control of things, but the truth is that the time will pass and all you’ll get is pure fantasy.

I spend so many hours planning stuff. I do that every day as part of my job, and I do that every day as part of my personal development. I try to make it as lean and efficient as possible. However, my feeling is that last year I tried to have the “best thing” planned instead of just shipping stuff to the real world, even if it was something small. Although I shipped, for instance, an email plugin for JIRA named Issue Events Mailer, a crap todo list style bookmark app, and another small attempts into the real world, I just have the feeling I could have done more if I had this “mantra” in my mind every time I questioned myself if what I was doing was of any value.

3 – A good plan is worth its weight in (future) gold

This one came from the same article mentioned above and also resonates with me because I learned that no plan survives contact with enemy

Also, I learned during these years of professional contact with lean and agile methodologies how bad too much planning can be. I’m not saying that plans should not exist, but we have to understand how much effort we should put on them before actually putting it in practice. At some point more planning is pure waste of time and energy that could be used for other valuable actions or tasks.

In the past things were so expensive that a well-thought plan was mandatory. The cost of repairing an error was too big. This is still true for some industries or fields of knowledge nowadays but for the great majority of software-based projects, for instance, I see these practice of thorough planning not optimal. Today is cheaper to quickly iterate, ship something, learn from it and use the feedback as input for a new iteration. That’s the base of lean and agile product and software development. Very quick cycles of plan-do-check-act. This makes me think that often just having alignment and shared understanding around the problem we’re trying to solve will be enough to a team or a person to start developing something and especially delivering something that can be used and criticized – in a constructive way – early and often.

Yes, I might have generalized things a little bit. Reality might be not as sweet as I’m painting above, but in general I believe that this principle and the previous ones should be taken more into consideration when we do or plan our plans.

The Most Used Retrospective Exercises This Year

December 28, 2018 / jcfausto / 0 Comments

I’m not sure if there are any statistics about this, but last year I decided to keep track of many stuff. One of these things is which retrospective exercises I used and how often.

The idea was dead simple. I kept a text file where I recorded for every retrospective I facilitated, which exercises I used. There were 46 distinct exercises in total. You can check the full list below.

Quick note: In total, 73 retrospectives at least. Not that bad. At some point, I stopped tracking because I changed my position from Agile Coach to Tech Manager and there were some moments of transition where retrospectives were not possible as well for the teams otherwise the number would be much higher.

Some analysis.

As you can see above, the winner was the classic brainstorming exercise. This one is a very good choice when you don’t have too much time to prepare or you’re not in the mood for an awesome session. That’s for sure a good choice for suchlike moments. I usually follow the brainstorming exercise with some solution discovery exercise such Lean Coffee so we can figure out some actionable stuff.

It was a surprise for me that the Perfection Game was one of my favourites as well. The experiences I had were always positive with this exercise. I’m not exactly sure why, but people usually like it and I do as well. Perhaps it’s because of its objectivity and quick way to figure out what to improve. If you don’t know this one, I highly recommend it for your next retrospective. Give it a try and let me know if you and the team enjoyed it as well.

Another insight from the data is that I didn’t use often the first approach we all learn when it comes to retrospectives. The “Went well, Went bad” approach. I know why this one was not used too often. It was intentional. I wanted to provide to teams different approaches and also compare same approaches between teams. I see retrospectives not only as a super opportunity to teams but also for me to experiment, learn, and compare approaches between teams in order to understand better their dynamics and peoples reactions to such exercises. This helped me so far to maximize in the great majority of cased, the return of time invested by the team on retrospectives.

Retrospectives nowadays became such a cliche that I try to be very careful not to just provide the “fun” part of it, but also make sure that the “professional” purpose of it is also delivered to the teams. By professional, I mean to use it as a tool to foster continuous improvement inside agile teams.

The funniest one, for me at least, was the Unlikely Superheroes exercise. Although I did it once, I have good memories of it and how people also had fun during the exercise while trying to portrait their strengths and weakness into a superhero character. Since this was a very personal exercise, no pictures were taken otherwise I would be able to share here the coolest superheroes that were created during the session.

What about you? Did you keep track of your retros? Which method did you use? How to know if you’re heading in the right direction? How do you know which exercise works better for you and for the teams? Share with me your perspectives and techniques. I’d love to learn more about it.

I have my own personal way of preparing for retrospectives. It’s nothing revolutionary or fancy, but it helped me a lot to facilitate and learn from each retrospective. If you’re interested in knowing about this procedure, leave a comment here or just drop me a message on Twitter @jcfausto.

Book Review: The Bottleneck Rules

December 3, 2018 / jcfausto / 0 Comments

Last week I’ve read a very interesting book about bottlenecks. The book was recommended by Mike Burrows during an Agendashift training I attended some weeks ago, and its name is The Bottleneck Rules by Clake Ching.

I usually like to read these recommendations because I think it’s a good way to understand how the ideas on these books influenced other people’s works, Anyway, let’s jump to the review.

The book is a quick read, the type of reading you can do in a few hours. But don’t’ get yourself fooled by its size, because it’s indeed a very good book to help you understand and manager better bottlenecks. The book explains very well what a bottleneck is, the types of bottlenecks – according to Clake’s own taxonomy -, and how to deal with each type of bottleneck in order to achieve better performance without necessarily working harder.

The major contribution of the book, apart from explaining with lots of examples what a bottleneck is, is the FOCCCUS procedure, which provides as a guide on how to properly address bottlenecks.

FOCCCUS stands for:

Find
Optimise
Coordinate
Collaborate
Curate
Upgrade
Start again (strategically).

But, what is a bottleneck?

According to Clake’s definition, which I personally like, a bottleneck is: “a resource that can’t keep up with the demand placed on it”.

And what is a resource in this case?

“a resource is a person, a machine, a computer CPU, a traffic intersection, a slow internet connection, and even an airport runway”

I’ve said many times over my career a statement along the lines of: “This step here seems to be the bottleneck in our process”. After reading this book, I’ll probably never say that anymore. I’ll probably say something like this: “We’re seeing a bottleneck here on this step of the process, let’s figure out which resource is causing it”.

Another insight from this particular topic is that in order to analyse a bottleneck you’ll have to map which resources are involved and then figure out which of the resources is the actual bottleneck.

You cannot solve a bottleneck without knowing the resources involved.

I remembered a story told some time ago where a coach was coaching a group or middle managers on a traditional company and once the coach entered the room, the first thing he said was: “We’re here today to find a bottleneck, but just so you know: The bottleneck is in this room”. Just a fun memory I had while writing this article. Let’s move on.

Once you find a bottleneck, it will look obvious.

That’s another interesting observation made in the book. Be aware that bottlenecks once identified will always look obvious. That’s because you’re looking at them in retrospect, and now the “Hindsight bias” is working on your brain. As said in the book: “You’ll find it invisible in a minute and deadly obvious the next”.

Some Types of Bottlenecks

Wild bottlenecks – Often hidden and they’re either unmanaged or poorly managed.
Tamed bottleneck – Don’t have as much capacity as we’d like, but they are visible and managed.
Deliberate bottleneck – Designed to deliberately limit the flow through a system.
Right-stuff bottlenecks – Are tamed bottlenecks and their work has been properly curated so they are working on the right stuff.
Right-placed bottlenecks – Are not only tamed but they are where they’re supposed to be.

A note on the “Deliberate bottleneck” type: If you’re familiar with Kanban, this is one of the reasons why we use WIP limits. WIP limits are bottlenecks, but the type of bottleneck deliberately placed to limit the flow of work in progress through the System.

Why identifying and managing bottlenecks could be a good idea for you?

The bottleneck determines a system’s output. No matter how fast other resources are performing, your global performance will be limited by the performance of your bottleneck. Sad, but true.
There’s a myth that says that “If everyone is busy, we must be productive”. Busyness is not a synonym of productivity. You don’t need to work harder to get more done, you must work smarter! If your team runs faster than your bottleneck, they’re just being busy, not productive. Take a look at the book cover illustration again. There are some people pushing rocks down, but there’s only one person moving them forward. This person is representing the bottleneck and no matter how fast others push rocks down, there could be only one rock moving forward at a time. That’s exactly what system’s thinking teach us regarding the benefits of global optimisation over local optimisation.

Be careful about easy solutions

Once you identify a bottleneck, might not be difficult to think about a solution for it. But be aware that usually the first solutions we think are usually not addressing the real issues. In order to address the real issue, you’ll have to dig deeper into the bottleneck, understand which resources are involved and their relationship and finally experiment with some solutions. This won’t come easy for you. You’ll have to open to challenge some assumptions and pre-conceived solutions.

In the book, Clake shares a story of a bottleneck involving a printer that was not printing the pages fast enough. It was not coping with the demand that was put on it. One might think that a solution would be to buy more printers or to buy a modern one that could print pages faster. But when digging deeper into the problem, it was discovered that the bottleneck was not the printer, but the software that was sending pages to the printer. Thus, the printer was just following the speed of the real bottleneck, that was not so apparent as it was the slowness of the printer.

Conclusion

I really recommend The Bottleneck Rules to anyone that wants to learn what a bottleneck is and especially for those who work with software development processes such Scrum or Kanban and want to get another perspective on constraints without necessarily having to read “hardcore” books. This one is accessible both in terms of price and language, practical, and will teach you a valuable tool that you can use in your work with your clients or employers.

Finally, if you read the book, please let me know what your thoughts. I’m interested to know if you also will find it as good as I did.

You can find me on twitter @jcfausto or just leave a comment here below.

Happy reading.

PS: I didn’t say anything about the title of the book, did I? Well, read the book and you’ll know what I’m talking about!

Disclaimer

I’m not affiliated with the author nor receive any benefits for reviewing this book. This review is totally independent and based on my own perspectives and interpretation of what I’ve read.

Decentralized Decision-Making

October 21, 2018 / jcfausto / 0 Comments

“Everything you do for the group is one less thing they know they can do for themselves”
Chris Corrigan: The Tao of Holding Space

This Sunday I was reviewing some notes and found one where I captured the quote above.

When reading the quote I remembered a chat I had with a former colleague last Friday where we talked about something related to the quote:

How to act more as a facilitator instead of a decision maker even if you are in a position or have a title that implies that you’re the one in charge of making final decisions.

My colleague told me a story about a meeting he had with one of his teams about how to improve collaboration. While listening to the story, I noticed that the team didn’t have a clear idea of what types of decisions they could make. Questions such as “Can we make this types of decision?” was a clear evidence of that.

Imaginary limitations can hinder the ability to achieve a decentralized decision-making environment. My colleague’s team had so many imaginary limitations in their heads that they’re not seeing which types of decisions they could make. Someone else was deciding for them because they didn’t know they could do it themselves. They thought their bosses were the ones in charge to make decisions.

After listening to the story, I shared my thoughts.

You create more damage than benefit when you decide for someone else or a team. The benefit is that you help to keep things moving and avoid paralysis. Things move faster and towards the direction you want. It looks good at first sight. But if you look at what you’re taking from them you’ll see the big damages you’re creating. You’re preventing them to have a saying on commitments that they’ll have to make. You’re taking from them the opportunity to decide and learn from mistakes. And, you’re hindering their opportunities to improve their decision-making abilities.

I’m not saying you’ll never have to decide on something and that everything can be a team decision. There are for sure certain types of decisions that you will not be able to delegate. Having a clear decision-making framework in place at moments like this would be handy.

Nicolai Foss and Peter Klein argue in the article “Why Managers Still Matter” that “In today’s knowledge-based economy, managerial authority is supposedly in decline. But there is still a strong need for someone to define and implement the organizational rules of the game.”
Source: https://hbr.org/2017/12/when-to-decentralize-decision-making-and-when-not-to

There are many ways to let clear the “rules of the game” and create a decision-making framework. The one I always refer as a good example is the Delegation Board by Management 3.0.

Centralized decision making makes things very slow and bureaucratic. It doesn’t scale and doesn’t allow for self-management inside teams. The establishment of a clear decision-making process will create the necessary conditions to achieve decentralization and increase people’s autonomy. Speaking of self-management, I’d like to share this quote below:

Self-management is self-management of decisions! if there’s no change in who makes decisions and how decisions are made, there’s no self-management of anything and therefore no lasting transformation of anything at tall. And all gains are temporary.
Daniel Mezick.

If you want to create a learning organization you have to provide the right environment for that. Making decisions for others all the time and assuming they don’t have enough capacity to that that is not a good way to establish such conditions and an indicator that the level of trust is very low amongst peers.

When you decide on behalf of other you take from this person the chance to learn because the decision-making process is also a learning process. To make a decision one have to understand variables, explore topics you didn’t know before, have a better of how the business work. This thought process helps people to increase their frame of reference and making better decisions over time. Also, they’ll get a better of how their decisions contribute to the organization’s results.

The level of commitment to the decision is also affected. When you make a decision, it’s your commitment not other’s people commitment. If the team make a decision, it’s their commitment.

Sometimes we have to “learn to hold space”. We have to learn how to be patient and how to prompt discussions that will help people to realize what they have to. Some might argue that this takes much more time when compared to telling people what to do. You can do this for a while, but when you turn our attention to your people, all you’ll see is demotivation, low morale, bad mood. Everything we don’t want to have inside our teams and organizations.

When Scrum Becomes Toxic

October 6, 2018 / jcfausto / 2 Comments

Scrum is without any doubt the most known Agile framework nowadays. It became very popular as the easiest way to introduce Agile to organisations and especially, as an easy and efficient tool to start an Agile transition inside organizations. I had my first contact with Scrum in 2009 and it was exactly in this context: as a way to start a transition from a traditional model of software development to an Agile one.

The danger of this approach relies on how people are being taught about the framework and its origins, which I think didn’t change too much in this 9 years. It’s common to see in Scrum training an introduction to the Agile Values and Principles, that were written down and published in 2001 in the Manifesto for Agile Software Development. During the training, many correlations will be made between the Agile values and principles and Scrum practices and ceremonies as a way to justify the framework, its practices and structures, and make people believe that Scrum is the silver bullet they need.

What most people don’t realise is that Scrum is indeed a good agile management framework as it can provide a very good way to organise teams, structure roles that are needed to have a more customer-focused development approach, organize backlogs, support decision making, estimations, continuous improvement, etc. It’s fantastic on that matter, but it lacks severely one of the key components of Agile: Technical Practices.

There’s no Agile without Technical Practices. A team cannot achieve agility if they just use Agile frameworks as a means to improve how the work is managed. This is an illusion and will over time create demotivation and make people believe that Agile does not work. Yes, it does not work, and will never work, if you believe that it’s just about management practices.

There is no agile without technical practices

I saw many big fans of Scrum over my career, and just a few really understood how it could help the organization to become better. It took me some years to really understand how Scrum could help organisations, when it’s applicable and when it’s time to move from Scrum to something else more appropriate. It’s hard to think this way when people that teach you don’t have such vision and just follow or repeat the same lessons that they’ve learned during their certification course. That’s I’d highly recommend you to be very careful when choosing any training on Agile. Do some research and figure out if the person giving the training has actual experience instead of just theoretical experience. That’s important because some theories are beautiful, but they don’t quite work very well on the battlefield, and this you only learn if you have fought one this battles.

Getting back to the point of this article, the Technical Practices, the best way I see nowadays for any organization to become better at Technical Practices, apart from recruiting the right people, is to use eXtreme Programming practices, that somehow were forgotten after Scrum took over the market with its promises and the modern DevOps practices as well. Those two combined with any other Agile framework are the real recipe for creating the right culture that will generate the conditions to move organizations from low to high performance over time.

It won’t happen in days, weeks, or months, maybe it’ll take your organization years to become a high performer, but from my experience, and the experience of many other people much more experienced than me that’s the best way we know at the moment on how to enable business agility inside organizations and transform them into high performers.

jcfausto

Technology and People