Luis Gonçalves's Blog, page 12
September 28, 2014
20 Product Owner Anti Patterns
This blog post explain some of the most common mistakes of product owners. It explains as well the solutions to tackle those mistakes.
The post 20 Product Owner Anti Patterns appeared first on Luis Gonçalves - Blog.
Product Owner Anti Patterns
During whole my professional life, people spent hours telling me the importance of good design patterns. I believe all of us bought books about design partners, cookbook recipes or any other type of book that would give you the good practices of the industry. I do not have anything against that and how could I? Myself wrote a book about Agile Retrospectives tools box :). All these books are useful and necessary but during my career I understood that writing about good practices is not enough. We must write about what we should not do, the anti-patterns, the smells like I call them.
During the next few weeks I will be spending some time writing about this topic. I will be writing several blog posts about the smells of different roles in Scrum and about different errors that companies usually do when we implement scrum. I will start this series with Product Owner smells. I already wrote some of the common problems with Product Owners within organisations and that work can be found here, but today I am going to add more issues to that list. If you are interested in “Anti-Patterns” click here, you will find all my blog posts touching on this topic.
No single Product Owner for one team
I see this phenomenon happening quite often in organisations that implemented SAFe (Scaling Agile Framework) in the past, dropped and returned to simple Scrum. In the SAFe framework you have two roles: Product Manager and Product Owner. The Product Manager is the one thinking more in a strategically way, the Product Owner is the one thinking more on the daily activities.
When companies go back to Scrum there is no more two roles, there is only Product Owner but companies do not want to fire anyone so they assign two product owners to the team, even if they still use the same mind set: assigning one person to the strategically part and another to the daily activities I see this as a failure.
I believe its extremely difficult to work with this scenario, you must have one single person responsible for the whole product, like a friend of mine used to say “one single neck”.
Solution:
Companies must understand that is not possible to have this scenario and they must provide an environment where each team has one single product owner.
Interference with the daily work
I saw this happening in several organisations but mainly because of two big causes. First cause the Product Owner in his past was a typical project manager where he was chasing people in order to get job done. Second cause relies on the fact the scrum master is not strong and the Product Owner must step into and do a lot of the activities of the scrum master, taking the role to serious ending up controlling and interfering more than helping.
In this situation is normal to see Product Owners taking a quite active role on the dailies, manipulating the normal process. Another problem that I see quite often relies on the fact of Product Owners track what developers are doing,I saw several examples of Product Owners talking directly with developers asking what they are doing because his name is not assign to any task. Now imagine how developers felt when suffering this kind of control.
Solution:
I believe the solution for this case is to find a strong and experienced Scrum Master. An experienced Scrum Master understands quite well both roles (Scrum Master and Product Owner) and can coach the Product Owner to allow the team to take responsibility of their own tasks. One of the roles of Scrum Masters is to protect the team from intrusions, having a strong and experience strong master within the team will allow the team to remain isolated and protected from un wanted interferences, and at the same time will allow Product Owners to be coached on right behaviours.
Stories built around product layers
This is a tricky topic. Over the last months I have been working with teams that cannot deliver as fast as they could if they would use other approaches. They made a quite typical mistake, they have user stories that are built around layers of the product. As an outcome user stories are dependent on each others causing a lot of delays to deliver a product that can be usable by the customer.
Solution:
In general a good user story should be written covering all the layers of the product. Should be an end to end user story. The solution for this problem is coach the Product Owner and the team about this. For me works quite well when I explain to developers that does not matter if we deliver 200 back end user stories when in reality the customer cannot use them without the front end part. Below there is a picture from Ángel Medinilla that shows in a great way how stories should be built.
No projection of the product backlog
Usually the Scrum Master produces burn down charts showing how the sprint went. This is quite common, what is not so common is the Release/Program burn down or burn up. This is a quite common problem in many of the organisations where I worked for. Not having this kind of information make the life of product owner harder because it gets harder to know if the team is on track or not.
With this kind of information available the product owner can take better decisions about scope in order to deliver the product on time, bringing the biggest amount of value to the customer.
Solution:
The solution here is quite easy. The product owner should build a product burn down/burn up exactly like the scrum master does, but instead of being focused on the sprint, the product owner focus on the release. A possible example can be observed below.
Backlog is filled with a bunch of “Strings” not proper user stories
This problem is by far one of the most commons that I observed during the last years. Most of the times the product owner does not write the stories in a proper format, he just write few key words and that´s it. The problem with this approach relies on the fact that everyone outside of Product Owner head will not understand what the user story is about. And to be honest I saw some examples where not even the product owner knew what he wanted to solve with some of the user stories that he wrote.
Solution:
In order to point out to the solution I am using a blog post from Roman Pichler. “10 Tips to write good user stories“.
Hope you liked it :) During the next weeks I will write much more about these topics :)
Best Regards,
Luis
The post Product Owner Anti Patterns appeared first on Luis Gonçalves.
September 21, 2014
Green build policy
During the last months I have been working with several teams that are struggling with green build policy.
What is a green build?
A green build signals that the code is working, it means that the software developed by the teams is in a state that can be release to the customer.
Why is a green build important?
The importance of a green build is explained in detail here, but in summary having a green build means that the basic software development practices are in place allowing the team to concentrate in other areas that need improvement. This blog post is another post that explains quite well why is it important to have a green build.
Keeping a green build for a long term is something quite difficult and demands a lot of discipline by the development team, here you find several reasons explaining why is it so difficult to keep a green build.
Green Build Policy
Below I will present several items that should be met in order to consider a build as a green build:
X% of code coverage from Unit Test
(If test coverage is minor than % defined the build gets red)
Automated tests for the User Story pass
(If any test fails the build gets red)
Integration testing pass
(If any test fails the build gets red)
Acceptance testing for all stories pass
(If any test fails the build gets red)
All regression testing of the product pass
(If any test fails the build gets red)
System-level Non-Functional requirements pass
(If any test fails the build gets red)
Static program analysis
(If the analysis of the tool is not met the build gets red)
Depending on how mature your software development process is you can add more items or you will need to remove some of these items, but with this blog post I believe that I gave you some ideas to think about your green built policy and what you should include in order to have a green build.
If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content.
Cheers,
Luis
The post Green build policy appeared first on Luis Gonçalves.
September 14, 2014
How to have an efficient Stand Up Meeting
During the last years of my life every time I join a company I hear developers saying that Stand Up Meetings are boring and they are a waste of time.
For me its always fun to hear these kind of debates, because 90% of the cases the root causes are always the same. People think the purpose of the Stand Up Meeting is to provide status report to the scrum master, they believe Scrum Master is the most interested party in the Stand Up Meeting. Unfortunately they do not understand the Stand Up Meeting is for the team itself :)
Another quite common problem with Stand Up Meetings relies on the fact that stories are not End to End. As a result people will work in silos within the team, some people will work in FrontEnd tasks others will work in Backend tasks. Of course all team members work independently not having dependencies on each other making the Stand Up Meeting quite boring since people can work independently.
As a rule of tumb one of the basic things that teams/companies should do is to create End to End stories, this will create a lot of dependencies between people and the Stand Up Meeting will shift from reporting towards alignment. Of course this is not always so simple but this is a quite common problem that I faced during all my life in different companies.
Another good way to make Stand Up Meetings more interesting is to follow the steps that I describe below. I think when people follow these steps the Stand Up Meetings will be much more interesting and useful.
What stories did I work on yesterday?
Did I closed something?
Yes:
Completion of a known dependency?
Resolving someone’s blocker?
Did I change the interfaces, the design, or infrastructure?
New experience, process, practice?
No:
What problems did I face that blocked me to finish it?
Did I find something unexpected that others should know?
What stories will I be able to complete today?
Did I closed everything from previous day?
Yes:
Before I start a new story can I help someone with his tasks?
Is the sprint Goal in Risk? What can I do to help the team with the Sprint Goal?
No:
Someone’s dependencies on me?
My dependencies on the others?
Expectation of early story completion?
What’s getting in my way (blocking me)?
My dependencies on the others?
Did I change the story/task order?
Not a blocker but risk or difficulty or a slow-down factor?
The post How to have an efficient Stand Up Meeting appeared first on Luis Gonçalves.
September 7, 2014
32 Scrum master interview questions
Some time ago, I wrote a couple of blog posts about the interview process that I went through when I applied for the positions of Scrum Master and Agile Coach. Those were really interesting interviews, and they can be found here.
In this blog post, however, I am writing something different, a resource that you will hopefully find useful. I am providing 32 Scrum Master Interview Questions that anyone can use to interview Scrum Masters. This is a collection of questions that I have been accruing over several years and I believe they are extremely beneficial; please feel free to use them next time you are interviewing a candidate.
How would you help the team’s members find their role within the team?
How would you help the team to find a strong sense of purpose?
How would you help the team to maintain ideal Scrum Ceremonies?
How would you help the team to act as a team, and not just a bunch of individuals?
How would you help the team to Surface and Resolve Conflicts?
How would you help each individual to get better at what they do?
How would you help the team to raise the bar, so as to help them to continuously improve?
How would you help the team to identify possible improvements in their Engineering practices?
How would you help the team to establish effective team communication skills?
How would you encourage self-organisation within your team?
Are you aware of the 5 dysfunctions of a team, and can you create exercises to improve them?
How will you help the team to spread knowledge gained during development?
How would you coach the whole team to collaborate? (Give examples…)
Can you give examples that show that you allow the team to find their own answers instead of you giving them?
Are you focused on business value delivery? Give me examples of how you accomplish this.
How would you help and encourage everyone to express their opinions?
How would you help the team in identifying positive and negative changes during retrospectives?
How would you encourage team learning (fostering collaborative practices, pair programming, continuous integration, collective code ownership, short design sessions, specifications workshops, etc.)?
How would you encourage rotation in technical areas of concern: functionality, components/layers, roles, aspects, etc.?
How would you help the team in setting long term operating goals for all team members: agile practices to master, new skills to acquire, etc.?
How would you examine what is missing in order to make the environment better for everyone?
How would you prioritise improvement activities and make them happen?
How would you help the team to find access to external sources of information?
How would you help the team to find techniques to help them be more collaborative?
How would you encourage and facilitate open communication among the team members and with external colleagues?
How would you help and encourage healthy conflict during team meetings?
How would you help the team to mature their DoD?
How would you help the team create transparency and urgency around continuous system integration?
How would you help encourage the team to create small automated acceptance tests at the beginning and evolve from there?
How would you help encourage the team to coach each other in TDD, refactoring, and simple design?
How would you help encourage the team to use human-readable acceptance tests?
How would you help encourage the team to do pair and peer reviews?
Feel free to use part of these questions on your next interview. I would love to hear how it went.
Luis
The post 32 Scrum master interview questions appeared first on Luis Gonçalves.
August 31, 2014
Cross Functional Teams with agile managers
In my previous blog post, I explained how can we assemble cross-functional teams without the overhead of having horizontal line managers interfering with the normal daily activities of the team. The approach that I used is a bit radical, and not all companies can implement something similar to it.
In this blog post I will explain how we can keep the old cross-functional setup with a matrix organisation, creating the ability for the organisation to keep all middle management.
I want to be clear regarding how I feel about this approach, however; I believe this approach is not as optimal as the one suggested in my previous blog post, but I definitely feel it is better than the normal traditional approach used for cross-functional teams inside of a matrix organisation explained here.
Below you can find an example of a traditional cross-functional team with horizontal line managers:
So, what can we do in order to maximise this kind of setup and not suffer harm owing to the problems raised by my previous explanation? I believe the trick is to invest plenty of time into the coaching and training of middle management. In one of my previous blog posts, I explained what an Agile Manager does.
I explained that the Agile Manager is an Organisational Change Artist, Boundary Keeper, Value Maximiser, Lean Manager, Organisational Impediment Remover, and a Team Champion. Lyssa Adkins and Michael Spayd, in their article in Scrum Alliance: “The Manager’s Role in Agile” go deeper into this topic.
Organisations must involve and transform themselves; of course, this also applies to everyone within the company. The role of managers has changed, they cannot spend all day interfering with what´s going on within the team. They must spend most of their time analysing how the organisation is working and helping the organisation to grow and become leaner.
When the organisation chooses this approach, they must make sure that their managers will step away from controlling their people. They must understand their people belong to a product/project team and let them work with that team. Their people must feel part of the team and that´s their highest priority. Individual goals should be abolished and it should be established that only team goals matter.
When managers step away in this way, all the problems mentioned on my previous blog post: Political Environment, Blame Culture, Horizontal Line interference, Slow Decision Making, Individual Goals Mess, and New Hirings Interference will disappear, or at least that is the objective.
I still believe this is not the optimal solution, but I believe it can be a great intermediate approach for companies to reach the level of the “startup” set up that I presented here. Plus, having several managers caring about the organisation and helping the organisation to become leaner and faster is actually quite nice.
Did you like this post? If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content. Or follow me on twitter: @lgoncalves1979.
Subscribe to my mailing list
Cheers,
Luis
The post Cross Functional Teams with agile managers appeared first on Luis Gonçalves.
August 24, 2014
Cross functional team is not enough
In my previous blog post, I explained how cross-functional teams are not enough to create high performing organisations. Cross-functional teams are mandatory, but not a guarantee of, success. I explained that several organizations have cross-functional teams built around a matrix organization. The blog post explains quite well how this matrix setup can hurt companies quite badly.
In this blog post I will explain how to assemble cross-functional teams that have everything needed to allow high performance. Before I describe my approach, I want to warn you, this is quite a radical approach to traditional management. I know this cannot be implemented in most companies (or at least, those typical managers), but I truly believe in Peter Senge’s words:
“It´s not enough to change the structures if the mindset behind does not change“
I think this is one of most companies’ biggest problems: they keep trying to solve old problems with old ways of working. If you truly want to make a difference, you truly must change the way you think—to that end, I choose to present something more radical than the norm.
We want to create teams that:
Are small, directly communicating with each other
Where everyone takes responsibility for their own work
Make decisions fast
Celebrate small successes
Are not political
Have end to end responsibility
Are focused on real, important things
Can release their products several times a day if necessary
Budget independent
Have all the necessary people to make the product live
If you think about all these characteristics, this is exactly what a Startup is. So, why not create small Startups within our companies? Before you say this idea is ridiculous, consider the fact that there are several companies all over the world already testing this concept.
So, how can we assemble this kind of setup? To achieve this kind of setup we should create cross-functional teams that are fully independent. Everyone reports to the same person (the Startup CEO) and this small team has all the necessary people and necessary skills to make the product live. Below you can find a picture illustrating this setup
Pros and Cons of this approach
Since I presented the positive aspects above, I will now focus on the negative points of this approach:
There is no space for middle management – If companies chose to implement this approach, middle managers will not have a role. Of course, they can do any other job that is necessary to release the product, but typically this will not be a manager role—it will be a specialist role, which means that middle managers must adapt to new jobs.
Communication with other Start Ups – The ideal setup will be able to create fully independent products without requiring much communication with the rest of the organisation, but we still want to share best practices within the rest of the company. Here people must be careful to not get isolated from the other parts of the organisation. Typically a well-established Community of Practices will tackle this problem.
A lot of courage is needed – To implement this kind of approach, top management must have a lot of courage. This is a completely radical approach, and it requires a lot of courage to try something so new like this. Even if management is able to implement this, the company must have a great culture of learning from its mistakes, as this will be the only way to achieve success using this approach.
I believe if we have the courage and the vision to start building companies in this way, we will be able to create products faster and more successfully than ever..
In the next blog post I will explain an intermediate approach that your company can apply if you cannot be so radical..
If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content.
Subscribe to my mailing list
Cheers,
Luis
The post Cross functional team is not enough appeared first on Luis Gonçalves.
August 17, 2014
Organisational structure: Matrix Organisation harms your company
Organisation structure is extremely important for the success of any company. In this blog post I will explore how an organisation structure built in the style of a matrix organisation can harm your company. Before I continue, I want to clarify that there are some companies that are able to apply this organisation structure with success—Spotify, for example.
Spotify’s document about tribes and guilds became extremely popular (you can download it here) in the Agile community. If you take a look into their organisation structure, you will see they are using matrix organisation, but in my opinion this is not the best approach. I still believe they were not able to get rid of it because of political and human reasons, but that is another story, one not directly relevant to this post.
Before I continue, I would like to explain what an organisation structure based in a matrix organisation is, just to make sure that you fully understand what I want to say. In simple terms, a matrix organisation is an organisation where vertical projects are staffed with several individuals from different parts of the company belonging to several different departments. This approach is extremely common nowadays when companies start to implement Agile.
Agile asks for cross-functional teams, and therefore companies start to build teams around different people with different skills within the organisation. At first glance, this seems like an appealing concept, but as I will explain later on, the promised effect does not work out as intended. Below you can find a picture that represents an organisation structure based on the matrix method:
Over the years, I have worked with many companies where this organisation structure is present; based on my experience, I will outline the following problems common to it:
Extremely Political Environment
It is not uncommon for organisations with this kind of setup to suffer from political issues. The team in this situation is a bunch of individuals from different parts of the organisation that are brought together to deliver something. My experience tells me the problem is not with team members but with line managers. If everything is going well, line managers tend to say the success is a result of their team members
If something really bad happens, line managers tend to say the problems is due to the other departments. They enter into “save my ass” mode, trying to cover their ass instead of helping the organisation to find the problem.
Blame Culture
I believe this is partly the result of the previous problem. When something goes wrong, people within different departments try to save their asses and basically blame everyone other than themselves. Unfortunately, I see this happen too often.
Horizontal Line interference
Over the span of my career, I’ve seen this happen in almost every company where I worked: Moving towards Agile is something difficult for most of the middle managers. There are clear roles for Product Owners, Scrum Masters, and Team Members, but nothing for Agile Managers. In a previous blog post, I tried to explain the role of an Agile Manager—but still, I believe this is something quite challenging to navigate for many managers.
Managers try to do their best to help people, but in my humble opinion, most of the time their actions in these situations cause more harm than good. They try to give “one on one” help to people regarding career development, they try to establish team events, and they try to do many other things, but in reality, all these activities actually remove people’s focus from their product team.
Another typical example is the practice of having all these line managers in all kinds of meetings, for example: dailies, planning, reviews, etc., etc. Because they want to see what their guys are doing, they go to these meetings, but unfortunately most of them cannot keep their mouthes shut, and therefore they end up sabotaging the discussion and making all these meetings quite inefficient.
Decisions take a lot of time to be made
Of course, in theory, the team should own all their decisions, but with so many chefs in the kitchen, I can guarantee that any decision that ought to take just few minutes will take weeks of negotiation with this kind of organisation structure—Not productive at all.
Individual Goals mess
People that follow my work know how I love personal goals, especially the ones attached to individual performance. In this organisation structure, I believe we have the right setup to launch the company into chaos and drain people´s individual motivation.
Let me explain: Having several horizontal line managers implies (in most organisations) that each different person will have a different goal or goals defined by his/her manager.
Now, if you imagine that in a team of 7, everyone has 2 goals, for example this means that we have a total of 14 individual goals that have nothing to do with the team goal, which actually is the most important one.
Of course, you can say the team as a whole will have their own goal, and all the individual goals will end up aligned with the team goal, but do you really believe that with so many different managers, different people, and different goals, people will be aligned with the team goals? Good luck on that ;). If you want to know more about how personal individual goals destroy companies, take a look at my previous blog posts on the subject:
Rewards may destroy improvement efforts in our companies
Goals and Objectives attached to monetary rewards destroy your MVP!!!
Rewards are a great way to Punish people
Employee reward discourage risk-taking
SMART objectives are DUMB objectives!!!
Interference with new hirings
Several years ago I had the opportunity to be part of a sad story. At that time I was Scrum Master and the team was recruiting a developer; of course, we all looked for senior developers. We had several interviews with several candidates but only one guy seemed to be a perfect fit for our team. We all agreed he was our man. We communicated with everyone and said he should be hired.
A couple of days later, the head of software development informed us that HE had chosen another guy. So basically, a guy who was not part of our team, that would not work on a daily basis with the new developer, who did not have a clue about what we needed, decided the future of the whole team. Later on, we found out that he was simply trying to achieve his personal yearly goal (saving money for the department).
Our companies are full of such cases, demonstrating how the horizontal line manages without understanding their place in Agile Organisations, and how this can actually harm the company a great deal.
In my next blog post, I will explain how you should build a team in order to avoid all of these problems.
If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content.
Subscribe to my mailing list
Cheers,
Luis
The post Organisational structure: Matrix Organisation harms your company appeared first on Luis Gonçalves.
Organisation structure: Matrix Organisation harms your company
Organisation structure is something extremely important for the success of the company. In this blog post I will explore how an organisation structure built in a matrix organisation can harm your company. Before I continue I want to refer there are some companies that are able to apply this organisation structure with success, like for example Spotify.
Spotify document about tribes and guilds became extremely popular (you can download it here) in the Agile community. If you take a look into their organisation structure they are using a matrix organisation but in my opinion this is not the best approach. I still believe they were not able to get rid of it because of political and human reasons but that would be another story.
Before I continue I would like to explain what is an organisation structure based in a matrix organisation, just to make sure that you fully understand what I want to say. In a simple away a matrix organisation is an organisation where vertical projects are staffed with several individuals from different parts of the company belonging to several different departments. This approach is extremely common nowadays where companies start to implement Agile.
Agile asks for cross functional teams therefore companies start to build teams around different people with different skills in the organisation. At first glance this is something quite nice but as I will explain later on, the promised effect is not that great. Below you can find a picture that represents an organisation structure with a form of Matrix.
As you can see companies have several products/projects in parallel and different people from different departments are brought together to build a cross functional team. Like I referred before Agile asks for this kind of setup, so where is the problem?
During some years I have been working in companies where this organisation structure is present so below I am presenting the most common problems that arise.
Extremely Political Environment
It is not uncommon that organisations with this kind of setup suffer of political issues. In reality the team is a bunch of individuals from different parts of the organisations that are brought together to deliver something. My experience tells me the problem is not with team members but with line managers. If everything is going well line managers tend to say the success is result of their team members.
If something really bad happens, line managers tend to say the problems relies on the other departments. They enter into the “save my ass” mode, trying to cover their ass instead of helping the organisation to find the problem.
Blame Culture
I believe this is a bit the result of the previous problem. When something goes wrong people within different departments try to save their ass and basically blame everyone else than themselves. Unfortunately I see this happens too often.
Horizontal Line interference
In my career I see this happening almost in any company where I work. Moving towards Agile is something difficult for most of the middle managers. There are clear roles for Product Owners, Scrum Masters and Team Members but nothing for Agile Managers. In a previous blog I tried to explain the role of an Agile Manager but still, I believe this is something quite difficult for most of the people.
Managers try to do their best to help people but in my humble opinion most of the time this causes more harm than good. They try to have 1:1 to help people with career development, they try to have team events, they try to have many other things but in reality all these activities are defocusing people from their product team.
Another typical example is to have all these line managers in all meetings, like for example, dailies, planning’s, reviews, etc. etc. Because they want to see what their guys are doing they go to these meetings but unfortunately most of them cannot keep their mouth shut, therefore they end up sabotaging and making all these meetings quite inefficient.
Decisions take a lot of time to be made
Of course in theory team should own all their decisions, but with so many chefs in the kitchen I can guarantee that any decision that could take just few minutes with this kind of organisation structure will turn into a negotiation for weeks. Not productive at all.
Individual Goals mess
People that follow my work knows how I love personal Goals, specially the ones attached to Individual Performance. In this organisation structure we have the right setup to launch the company to chaos and drain people´s motivation.
Let me explain, having several horizontal line managers implies (in most of the organisations) that each different person will have a different goal or goals defined by his/her manager.
Now if you think that in a team of 7 everyone has 2 goals this means that we have a total of 14 individual goals that have nothing to do with the team goal, which actually is the most important one.
Of course you can say the team as a whole will have their own goal, and all the individual goals would be align with the team goal, but do you really believe that with so many different managers, different people and different goals, people will be align with Team goals? Good luck on that ;). If you want to know more about how personal individual goals destroy companies take a look into my previous blog posts:
Rewards may destroy improvement efforts in our companies
Goals and Objectives attached to monetary rewards destroy your MVP!!!
Rewards are a great way to Punish people
Employee reward discourage risk-taking
SMART objectives are DUMB objectives!!!
Interference with new hirings
Several years ago I had the opportunity to be part of a sad story. At that time I was Scrum Master and the team was recruiting a developer. Of course we all looked for senior developers. We had several interviews with several candidates but only one guy seemed to be a perfect fit for our team. We all agreed he was our man. We communicated with everyone and said he should be hired.
Couple of days later, the head of software development informed us that HE had chosen another guy. So basically a guy that is was not part of the team, that would not work on a daily basis with the new developer, that he did not have a clue about what we needed decided the future of the whole team. Later on we found out that he was simply trying to achieve his personal yearly goal (saving money for the department).
Our companies are full of these cases, this is another typical case how horizontal line manages without understanding their place in Agile Organisations can actually harm quite a lot the company.
On my next blog I will explain how you should build a team in order to avoid all these problems.
If you liked this idea and you want to receive many others subscribe the mailing list below. I promise to deliver only high quality content.
Subscribe to my mailing list
Cheers,
Luis
The post Organisation structure: Matrix Organisation harms your company appeared first on Welcome to.
August 10, 2014
Sick and tired of Agile estimation
During this last week, I finally had the opportunity to read a book that was on my reading list for long time: Black Swan by Nassim Nicholas Taleb. The book is about uncertainty and unexpected events.
NNT (as the author calls himself) explains that we live in an extremely complex world where we cannot predict all the events which will happen, and therefore it is silly to try to plan or predict future outcomes.
Throughout the book, he mentions several events that humankind did not dream of that caused terrific outcomes.
Even living in this complex world, we always try to plan everything. We always try to predict the future. But, like NNT shows us, Plans fail because of what is called “tunnelling”: the neglect of sources of uncertainty outside of the plan itself.
We humans believe that we are good at forecasting if we do the same task over and over again; we think the more routine the task, the better we learn to forecast… We just forget there is always something non-routine in our complex world that will destroy our forecasts.
Like NNT explains: most delays and cost overruns arise from unexpected elements that did not enter into the plan—that is, they lay outside the model at hand—such as strikes, electricity shortages, accidents, bad weather, or rumours of Martian invasions.
We cannot project the behaviour of a system if we do not know all possible conditions of that system, therefore we cannot truly plan; all estimations will be, most likely, completely wrong. Let’s make the bridge now into software development:
Everything that I described before can be applied directly to software development, so why the heck do most of the companies (in my experience) still ask for detailed plans and estimations? It’s ridiculous to even start when we already know that we will be wrong!
Why do we still have Senior Management asking for milestone plans with detailed lists of features for months? Why do we have people bothering themselves with Gant charts full of detailed information that will be obsolete as soon they finish printing out the Gant chart?
Why do we have management looking into sprint reports, asking why the Delivered stories are not as high in number as the Committed stories? Why do we even have management forcing people to learn “how to get better at estimation”?
Why do we have management bothering Scrum Masters with questions like: “Why does the sprint burn down have several peaks? I would like to have a normal line!” Why do we have teams spending hours in useless estimation meetings where they discuss if the story is a 3, 5, or 8? Even worse, why do we have teams spending entire days doing estimations for complete product backlogs?
All the previous examples can be considered evidence of fantastic waste! We spend days and days trying to achieve what we cannot, so what can we do to avoid all this waste? The solution is simple: DO NOT ESTIMATE.
