Etiqueta: project management

  • Dilbert's Estimation

    Planning, Cone of Uncertainty and IT Estimation

    The Purpose of Planning

    Before talking about the Cone of Uncertainty and estimation lets clarify some things about planning. I constantly tell my friends and co-workers that ideas are not the same as planning. Remember the last time you started something that, for several reasons, you never ended, or that time you said my “plans” are …, but in reality, you never took real actions to execute those “plans” or you just keep putting them off. The main difference between ideas and plans is basically that ideas are vague, aspirational, and desirable; while true planning takes ideas further and establishes goals along with preconceived steps to take that eventually help to estimate, make decisions, and even refine or change the plan.

    In the same way that it happens in life, in the software and IT industry in general, estimations and planning are of the utmost importance for the success of any project. The plans are a guide that tells us where to invest our time, money, and effort. If we estimate that project will take us a month to complete and in return, it will generate a million dollars, then we may decide to carry out that project. However, if the same project generates that million dollars in 15 years, then perhaps it is better to reject it. Plans help us to think ahead and know if we are progressing as expected among other things. Without plans, we are exposed to any number of problems.

    In my experience as a developer, scrum master, project manager, etc., teams tend to two extremes: They don’t make any plans at all or they try so hard on a plan that they convince themselves that the plan is actually correct. Those who do not plan simply cannot answer the most basic questions, like, when do they finish? or, will it be ready before the end of the year? Those who plan too much, invest so much time in their plan that they fall into assumptions that they cannot confirm, their insecurity grows more and they begin to believe that even by planning more they will achieve more accurate estimations although this does not actually happen. If you feel identified with any of the previous scenarios, in your favor I can say that planning is not easy.

    But that plans fail and planning is complicated is not news. At the beginning of a project, many things can be unknown, such as the specific details of the requirements, the nature of the technology, details of the solution, the project plan itself, team members, business context among many other things. But then, how do we deal with these riddles? How do we deal with uncertainty?

    The Cone

    These questions represent a problem that is already quite old. In 1981, Barry Boehm drew what Steve McConnell later called the Cone of Uncertainty in 1998. The cone shows that in a sequential or “cascade” project that is in the feasibility stage, we will normally give an estimate that is far from reality, in a range of between 25% and 400%. This is for example, that a 40-week project will take between 10 and 160 weeks. By the time we finish obtaining requirements, our estimate will still be between 33% and 50% out of date. At this point, our 40-week project will take between 27 and 60 weeks. Imagine what happens with those projects that are never clear about their requirements.

    How to deal with the Cone of Uncertainty?

    Buffering (margin of error)

    This is to use a percentage of time and/or resources to cushion the effect of materializing risks. You have to be careful, a common reaction is to put double or triple the time to estimate a project, this is NOT buffering, this is “padding” which IS NOT a good practice. Giving a too large number will cause sponsors or clients to resist and not approve your project. Give them a too low number and you will take the risk of running out of time and money. This becomes doubly risky when you are using fixed contracts for your proposal, where there is even more pressure to keep costs down.

    It is important that you make use of historical data to compare your current project with other completed projects and obtain reasonable and justifiable numbers in order to get a margin of error or buffering. Include postmortem processes or lessons learned at the end of each project to support your buffering figures in the future.

    Estimate in ranges

    Something I like about agile approaches for project management is being honest from the beginning and never use closed figures, but be transparent and always use ranges, especially in projects that seek to innovate and try new things where there is a lot of uncertainty. This is for example:

    Look. We don’t know how long this is going to take, however, the following is our best bet based on the information we have so far. But if we can do a couple of iterations, we can develop something, evaluate how long it takes, and then have a much better idea of how big this is.

    Also, present the best estimate at the moment as a range. This can help project sponsors to decide how much risk they are willing to accept.

    Relative estimation

    There have been various investigations on how to make estimates of effort and it has been discovered that people are good at estimating the size of something comparing it with a reference (Software Development_Effort Estimation). For example, someone cannot tell you how high the building you live in is, but they can tell you that it is approximately twice the height of the other. You can apply this principle to projects too.

    Note. Agile approaches use interesting concepts like Story Points and Ideal Days to make relative estimates.

    This is not a foolproof measure, you can still misjudge. But it is certainly good to get initial funding that allows the team to build something and see how long it takes to complete this progress, while simultaneously they learn more about what needs to be achieved, in such a way that this experience is used to reduce the variance of that estimated starting number.

    Why is all this happening?

    There is no doubt that there is always pressure from the financial sector of organizations to make estimates for an entire project or for a whole year, although these practices ultimately backfire 😀

    The best thing to do is to permeate this knowledge in your organization, and constantly remind and communicate that the goal of estimating is not to guess the future, but to determine whether the project goals are realistic or even possible.

    Some interesting links:

    The Cone of Uncertainty

    Cone_of_Uncertainty

    Free PSM I Exam Simulator

    Part of the list of topics for this post and the idea of the graphic with the little sun 🙂 were partially based on articles from agilenutshell.com

    These are some recommended books to know more:

    No Comment
  • Size Matters, User Stories.

    Size matters?

    This is a very old question, but in this blog, we only will answer that question from the project management point of view (disappointed people please go to another kind of blogs). This time we will see what are and what is the purpose of the famous User Stories and how they differ from traditional requirements in a project.

    When I was a kid I spent a lot of time playing on the beach with my cousins, and in some of those games, I found myself digging, transporting and piling sand from one point to another (my tools were a shovel and a plastic bucket) after about 10 minutes my youngest cousin asked me how long it had taken me to gather all that sand, to which I replied: “about 30 laps”. After that, both my cousin and I assumed that with his own bucket he could double the amount of sand, doubled in another 30 laps. It wasn’t like that, it took a lot longer for my little cousin because we both failed to evaluate the capacity of his bucket and appreciating that Gabriel (my cousin) being very young (maybe 6 years old) he still had to strain to load a bucket of different size completely filled and finish in only 30 laps.

    As simple and obvious as this anecdote may seem, the reality is surprising, since many work teams responsible for projects of all sizes continue to fall into this same error. They are not yet fully aware of their capacity or speed, nor are they clear about the difference between size and distance in a project, and therefore, they fail from the beginning in their estimates.

    Not taking care of trying to measure the size of what you are going to do is an error, therefore the size does matter, and before measuring times and distances you should know the answer to questions like, what is the size of your bucket and shovel? How many buckets and shovels do you have? Are there enough people for each shovel and bucket?

    What are the User Stories?

    For ease, the concept is often oversimplified, saying that User Stories are the requirements of a system or a product, but they have serious differences with other common approaches such as use cases, IEEE 830 software requirements specifications, and design and interaction scenarios.

    User stories are short, simple descriptions of a feature told from the perspective of the person who wants the new functionality, usually a user or customer of the product that they want to create. In general, they follow a simple template:

    As <user type>, I want <some goal> so that <some reason>.

    User stories are often written on chips or sticky notes, stored in a box and organized on walls, boards or tables to facilitate planning and discussion. As such, they strongly change the approach of writing about characteristics, to discussing them. In fact, these discussions are more important than any text that is written.

    This is a simple definition about what a User Story is, but believe me, there is much more behind, writing good User Stories can be a challenge, and to create good stories you have to understand more about their purpose.

    Assign Value (points) to User Stories

    Eventually, when I became involved in project management and later Agile, I discovered that one way to estimate the size of what is needed is to use the User Stories. To explain what they are I will continue using the analogies.

    When was the last time you went to a restaurant and ordered a soup or a drink in milliliters? … That’s right, we usually don’t do that, we usually order a soup or a drink with a relative measure like “small, medium or large”. User stories are also relative, they are used to express size, they don’t have a standardized value, but the values must be relative to each other, that is, a User Story that has value 2 is twice the size of one User Story that it’s worth 1.

    To assign values or points to different sizes there are those who use shirt sizes, dog breeds, Fibonacci values (my favorite values) or other representations, no matter what you prefer, you should eventually use relative values. Take the following table as an example, with a possible assignment of points:

    Tamaño CamisaPuntos
    XS1
    S2
    M3
    L5
    XL8
    XLL12

    In an Agile project, it is not uncommon to start an iteration with requirements that are NOT fully specified, the details will be discovered later during the iteration. However, we must associate an estimate with each story that we can see at the moment, even those that are not completely defined.

    And where are the details?

    Those used to the detail added in advance into traditional requirements will immediately come up with this question. The detail can be added to User Stories in two ways:

    • Dividing a User Story into multiple User Stories and smaller ones.
    • Adding “conditions of satisfaction”.

    When a relatively large story is divided into Agile and multiple User Stories, it’s normal to assume that details have been added. After all, more has been written.

    Conditions of Satisfaction are simply high-level acceptance tests that must be met after the User Story is completed. Consider the following as another example of an Agile User Story:

    As a marketing director, I want to select a period of time so that I can review the past performance of advertising campaigns in that period.

    The detail could be added to this User Story example by adding the following satisfaction conditions:

    • Make sure it works with the data of the main retailers: Oxxo, Seven Eleven, Extra.
    • It must support the data for the last three years.
    • The periods are chosen in intervals of months (not days, nor weeks).

    Who writes User Stories?

    Anyone can write User Stories. However, it is the responsibility of the product owner to ensure that there is an accumulated backlog of Agile User Story products, but that does not necessarily mean that the owner of the product is the one who writes them. In the course of a good Agile project, you must have examples of User Story written by each member of the team.

    Also, keep in mind that who writes a User Story is much less important than who is involved in the discussions of it.

    When are User Stories written?

    The User Stories are written throughout an Agile project. Overall, a story writing workshop is held near the start of the Agile project, each release and/or at the beginning of each iteration (I personally take some of the first options, depending on the length of the project, and I only do refinement in each iteration). Everyone on the team participates with the goal of creating an “order list” or Product Backlog that fully describes the functionality that will be added during the course of the project, or in a release cycle of three to six months.

    Some of these Agile User Stories will undoubtedly be Epics (are not called Epics because they are dramatic…well sometimes 😄). Epics are very large stories that by their size will later decompose into smaller stories that fit more easily into a single iteration. In addition, new stories can be written and added to the “order list” of the product at any time and by anyone.

    Velocity

    I will not delve too much into this topic because it gives to write another post dedicated entirely to it, but to understand how estimation can work with Story Points that we assign in the table we showed above, it’s necessary to introduce a new concept: Velocity. Velocity is a measure of a team’s progress rate. It’s calculated by adding the number of Story Points assigned to each User Story that the team completed during the iteration.

    If the team completes three stories, each estimated at five story points, its velocity is fifteen. If the team completes two stories of five points, its velocity is ten.

    If a team completed ten points of work the last iteration, our best calculation is that this iteration will complete ten points. Because the story points are estimates of relative size, this will be true whether they work on two five-point stories or five two-point stories.

    As can you see, in order to make estimations, and after knowing the sizes It’s very important to calculate an estimate for the end of the project, or for a release (the distance).

    Do User Stories replace a requirements document?

    Agile projects, especially Scrum projects, use a product backlog, which is a prioritized list of functionalities that will be developed in a product or service. Although product backlog items may be what the team wants, User Stories have emerged as the best and most popular form of product backlog items.

    While a product backlog can be considered as a replacement for the requirements document of a traditional project and perhaps even a WBS, it’s important to remember that the written part of an Agile User Story (“As a user, I want …” ) is incomplete until the discussions about that story take place.

    It’s often better to think of the written part as an indicator of the actual requirement. User Stories can point to a diagram that represents a workflow, a spreadsheet that shows how to perform a calculation or any other artifact that the Product Owner or team wants.

    Until here I leave the User Stories topic, for now, let me know if you want to know more 😉.

    Links of interest:

    Without users (User Proxies)
    The Agile Team Approach
    What Scrum Master Certification to Choose?

    These are some recommended books to learn more:

    No Comment
  • Scrum Team Size

    The Scrum Team Size

    Much has been said about the Scrum team size or Agile team size, almost every client, boss, and collaborator with whom I have worked asks this question at some point: how many people do we include in the teams? The Scrum Guide sheds very little light on this, suggesting 10 or fewer members per team in its latest update, but giving us no context or reasons for these numbers.

    The Scrum Team Size is More Than a Number

    The truth is that there is no universally correct number of members to ensure optimal performance in a team, but what we know is that a Scrum team must consider certain factors that should include, beyond numbers:

    • Cross-Functional team. Sufficient skills and capabilities to build the product,
    • Dedicated team members. Dedicated members to one, and only one, team,
    • Consistent membership. Stable and long-term membership within the team[1],
    • Diversity of thought. A reasonable wide range of attitudes, beliefs, genders, and thinking patterns[2].

    Now, the above points already represent a challenge for some organizations, but at least they enjoy an important consensus, however, they are not the only ones. Once the team is formed, there are other important factors that high-performance teams must address, among others:

    • Psychological safety. A safe environment to share ideas and take risks[3].
    • Equal communication. The most expressive member should not communicate more than twice as much information as the quietest[4].
    • An open mind and willingness to learn[5].
    • Shared vision. Everyone knows and agrees on objectives[6].
    • Clear roles. Everyone knows their responsibilities and the expectations of their work[7].
    • External advice (coaching). In Scrum, this is done by the Scrum Master[8].

    And what does all this have to do with the size of the teams? Well, these factors don’t live isolated in a vacuum and just because I say so, so let’s explore the evidence so that together we discover what matters most to your team. After all, there is no universal answer 🙂

    Many Numbers Everywhere

    When we talk about the size of the teams within various organizations, the topic seems much more controversial and narrow to say the least. In the worst cases, staffing leaders respond by building teams guided by assumptions and even based on the burden caused by unrealistic dates and budgets and inadequate time horizons, thus harming the performance of teams and the organization itself in the medium and long term.

    In the early days of Agile, the XP and Scrum texts suggested that the optimal size of members was 7 ± 2, applying George A. Miller’s number, later it was adjusted to 6 ± 3, today the suggested number is 10 or less according to the Scrum Guide.

    The original support for the position of seven people, plus or minus two (7±2), comes from a well-known psychology study by research psychologist George A. Miller published in the 1950s, where according to the results of this study, there are limits on the amount of information we can process and retain in our heads.

    More recently in 2010, Nelson Cowan claimed that Miller was too ambitious and that the ideal limit was only four and not seven[9].

    Also, Ikujiro Nonaka and Hirotaka Takeuchi were formulating the ideal team size after conducting research and creating new products at technology companies such as Fuji-Xerox, Canon, Honda, Epson, Brother, 3M, and Hewlett-Packard[10].

    Many others cite historical examples dating back to the Roman army, which used small military units of around 8 people. Others watch bonobos, one of the closest genetic relatives to humans, often splitting into groups of 6-7 to forage for a day. Both conveniently support the number 7±2, but since neither example is about teams doing knowledge work, the relevance of this to agility is limited.

    As you can see, the topic has been discussed for some time and can be somewhat confusing, but thanks to this we have some clues, but it is worth having more sources to help us support our decision.

    What Happens to Relationships When Teams Grow?

    Within a team, each individual will have a connection with another individual, thereby creating a unique relationship; the bigger the team, the more the relationships. The equation that describes this is N(N-1)/2; but what does this mean? and how can it help us? To find out, let’s remember math problems from school and turn it into something we can use in real life.

    The above equation tells us how many different relationships will exist within a team of a certain size, where N = the number of people in the team. So, in the first example graph of a team of 5 people, where N=5 we have 10 relationships: 10 different combinations of team members who are related to other members of the same team.

    In the second example, where N=7, you have 21 relationships, and where N=9 in the third graph you have 36 relationships. Each pair of people represents a relationship, and that relationship defines how they collaborate. High-performance teams, by their nature, must have strong relationships between each of the team members in order to collaborate effectively.

    Knowing this is important for you and your team because it’s true that each new person adds some individual productivity to the team, but it also increases communication overhead in the form of an exponentially growing number of relationships. To grow a team from 5 to 7 people, you need to more than double the number of relationships. To go from 7 to 9, it doesn’t quite double, but the jump is still big.

    How expensive is it to maintain these relationships? Anecdotally, after studying the interactions of the members of several of my teams, I can say that in teams of 7 or 8 people, each day more than 90 minutes per person are spent interacting with other team members[11]. This excludes time spent on techniques like pair programming. Part of the interaction is talking about work, but she also spends time socializing. This is good and important because it is the combination of work and socializing that builds resilience and the ability of a team to handle challenges effectively.

    A general rule of thumb suggests that people typically have 3½ to 5 hours of productive time at work each day. As a team grows, we lose productivity or, more often, begin to withdraw socially rather than sacrifice productive time to interact with our peers because communication costs for each team member are becoming too high. We need strong relationships to become a high-performing team, but as the size of the group grows, we begin to avoid the interactions that build those relationships.

    Therefore, the number of relationships between team members and the time investment they require should be a factor when choosing team size because it will influence productivity.

    More People Make Lighter Work…But Only to a Point

    What everyone wants to believe is if we go from 1 person to 2 people, or from 2 people to 4 people, we will get double the work done, even top managers of transnational organizations have raised this with me. But even so, we intuitively know that this is not true, but why?

    In 1967, Amdahl’s Law was presented for the first time, which for those who are not systems or electronics engineers, tries to estimate how much speed gain can be obtained by executing computational tasks by running them in parallel parts. This means that sometimes there are computer programs that are viable to be worked on by multiple processors at the same time (e.g. parallel processing), but other parts must be taken care of one by one (e.g. serial programming).

    The formula derived from Amdahl’s Law may seem intimidating, but it is much simpler than it seems:

    If we take the 5 units of work and apply 3 processors to the parts that can be done concurrently (in parallel), it doesn’t take 1 and 2/3 units of time (5 divided by 3) to complete. Instead, 3 units are needed because 2 of the units of work can only be done by one (serial) processor. It’s certainly an improvement over time, but not as much as you’d expect at first glance.

    Teamwork works in much the same way. In fact, if we convert everything to a graph we can get an idea of how efficient the increase in team members can be:

    Let’s focus for now on the 80% line (the blue one, at the top) of the graph. Let’s be optimistic (and unrealistic) and assume that 80% of the work can be done by working in parallel. This suggests that the more people do it, the faster it will be over, right? Oh but wait. If we go from 1 person to 2 people, we don’t do twice as much work. To get an improvement of 2x the work completed, we actually need 3 people. 7 people only create a 3.2x improvement over 1 person. To do 4 times as much work as 1 person does, we would need 16 people!

    What if even less work can be done at the same time (parallel)? What if 50% of the work needs to be done serially (green line on the graph)? Then with 9 people we still have only 1.8x speedup.

    What is the solution? There is no easy solution, but there are things you can do to mitigate the effect of Amdahl’s Law:

    • Make as much of the work as possible can be done in parallel. This may mean increasing cross skills and collaboration.
    • Reduce dependencies between teams, so there are no bottlenecks or delays.
    • Increase the speed of the overall work process by improving quality and practices.

    Speed doesn’t come from sending more people to work and building bigger teams. It’s about building a high-performing team that is optimally sized for effectiveness, communication, and quality.

    Research-Backed Evidence

    American Sociological Association

    The American Sociological Association published a study by Hackman JR, Vidmar NJ called “Effects of size and task type on group performance and member reactions”[12].

    In this study, they had participants complete a series of tasks: a combination of production (writing), discussion, and problem-solving. Participants were placed into different groups of 2 to 7. After completing each task, the volunteers were asked a series of questions, including two shown in this graphic: “was your group too small?” your group was too big? As you can see from the graph, groups around 4-5 in size seemed to have the least negative reaction. The frequently touched number is 4.6. The participants were college students, the tasks were cognitively loaded but not related to technology, development, etc., and the groups were not together long enough for a true “sense of team” to form. Nevertheless, it is an interesting fact.

    In those days Hackman wrote the book Leading Teams, his rule of thumb for team size was 6[13].

    Social and Developmental Psychology Researcher Jennifer S. Mueller

    Research psychologist Jennifer S. Mueller, academic, author, and research collaborator, was quoted in the article “Is Your Team Too Big? Too small? What is the correct number?:”

    If companies are dealing with coordination tasks and motivational issues, and you ask, ‘What is your team size and what is optimal?’ that correlates to a team of six. “Above and beyond five, and you begin to see diminishing motivation,” says Mueller. “After the fifth person, you look for cliques. And the number of people who speak at any one time? That’s harder to manage in a group of five or more.”

    From the Scrum Creators…nothing less

    Based on studies by George A. Miller, and later work, Scrum creators Jeff Sutherland and Ken Schwaber showed the following levels of productivity creating their own research on team size:

    Agile TeamProductivityNO Agile Team Productivity
    < 7 members300 / 400%< 7 members 100% max
    > 7 members400%> 7 members < 90%

    And they added:

    A small team from three to four people can be very autonomous when it follows guidelines, has a well-defined focus, and everyone is physically in the same space. His work is often consistent, responsible, aligned and well directed, and communication is fluid. Things are relatively easy when there are only a few people on the team. The problems seem to increase along with the number of team members.

    Brook’s Law and Lawrence Putnam

    The mythical Frederick Brooks to whom we owe the famous “Brooks’ Law” establishes that “adding manpower to a late software project makes it even later”. This is due to the learning curve, that is, you must train each person new to the product or technology, and you must learn all the related non-technical knowledge, including the business strategies that the product or software addresses [14].

    According to important studies by renowned researchers such as Lawrence Putnam:

    MiembrosEsfuerzo
    < 9 miembros25% menos esfuerzo
    > 9 miembros25% más esfuerzo

    With an Agile Team:

    MiembrosProductividad
    125% más
    5125% más
    9225% más

    In summary, if we have an optimal team, we can have productivity from 300 to 400%.

    Putnam and Myers Hard Facts

    Beyond our personal opinions, those of clients, bosses, and team members, we also have objective statistics. Putnam and Myers examined data from 491 software projects from a large corporation as reported in their article “Familiar Metric Management: Small is Beautiful Once Again“. These were projects with 35,000 – 90,000 lines of source code. They divided the projects into groups called buckets based on the number of people involved in the project: 1.5-3, 3-5, 5-7, 9-11, and 15-20. On average, the smaller groups (3-5, 5-7) took much less time (11.9 and 11.6 months, respectively) than the larger groups (17.1 and 16.29 months) to complete projects of similar size.

    When you multiply the number of team members by the number of months, you get a graph that is even more impressive:

    A team of 9 to 11 people took 2.5 to 3.5 times as long as teams of 5 to 7 and 3 to 5 to complete projects of a similar size. That suggests that the seven-plus teams in this dataset were just a way to spend money faster due to increased team size but reduced net return.

    Evidence of Agile projects

    Larry Maccherone, in his work through Rally, Tasktop and AgileCraft exposed in “Impact of Agile Quantified” in late 2014, has helped build large datasets on Agile team practices. His data shows:

    Based on Larry’s data, it would appear that 1-3 teams are more productive but have lower quality. 3-5 teams are marginally more productive than 5-9 teams, although they may still be of slightly lower quality – the difference is small. Larry’s notes suggest that he thinks the entire range of 3 to 9 is fine [16]. The reason for the lower quality in the smaller teams is not obvious. Perhaps due to a lack of stability? Lack of diversity of thought and experience? Reduced cross-functionality? We cannot know, but it deserves consideration.

    My experience

    When clients, managers, etc. ask me how big Scrum teams should be, I don’t have a “correct” answer. But I try to share the above data, my personal opinions, and suggestions based on years of experience. And I won’t lie to you, there are organizations where bad habits are so ingrained that it’s hard to get that information across in a practical way (they don’t listen to it, they don’t take it into account enough, etc.). But I certainly try to make my suggestions based on evidence, simple logic, and common sense.

    For example, larger teams spend more time building, more time normalizing, and therefore more time reaching high performance. Why? Because there are more relationships to negotiate. As we saw before, in a team of 5, there are 10 relationships that need to be formed, a team of 7 has 21 relationships, and so on. More relationships take more time to build and establish trust, so that should be taken into account when deciding on team size.

    Assuming all else is equal (skills needed to get the job done, diversity of thought, etc.), the existing evidence supports the idea that teams of 4 to 6 work well in most situations. They take less time to train and are just as productive as larger teams. Also, teams of 5-7 can usually combine abilities enough to cover the loss of a team member.

    Personally, I would only pick a team of 8 if other pressures, like the breadth of skills required, forced it to happen. I don’t recommend teams with more members, because the overhead costs outweigh the value of the additional person.

    With teams of 10 or more, I recommend splitting into 2 teams. My own experience and that of other agile colleagues with scaling experience: Separate teams of 4 and 5 do more than their original large team.

    With teams of 9 or more, I recommend splitting into 2 teams. My own experience mirrors that of other agilists using Scrum: separate teams of 4 and 5 do more than their original big team.

    Why not 3 or less? Because it would result in very little diversity of thought and it would probably be very difficult to find 3 people with enough skills to get the job done on a complex project. There will also be very little collaboration, which correlates with the reduction in quality shown in Figure #2 (“Impact of Agile Quantified” data). And don’t forget the obvious 2v1 power issues that can make the journey more challenging for one team member.

    All the focus has been on the number of people on the team, but the bigger question should be this: does the team have the ability to get to “Done” or “Done” at the end of each Sprint? If not, you’ll want to re-examine and reconfigure to achieve a more effective team size and most likely do a re-analysis to break down work into requirements, user stories, or the like.


    [1] “The Impact of Lean and Agile Quantified” – Larry Maccherone showed that dedicated team members doubled productivity and stable teams (no turnover) improved productivity by 60%. https://www.infoq.com/presentations/agile-quantify

    [2] Wilkinson, David. Group decision-making. What he said in The Oxford Review, Diciembre 2019

    [3] “What Google Learned From Its Quest to Build the Perfect Team”: https://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html

    [4] “The New Science of Building Great Teams” – Alex “Sandy” Pentland https://hbr.org/2012/04/the-new-science-of-building-great-teams/ar/pr and also “Evidence for a Collective Intelligence Factor in the Performance of Human Groups

    [5] The Wisdom of Teams: Creating the High-Performance Organization – Jon Katzenbach and Douglas Smith – indicates that potential skills are as important as the skills people currently have in predicting effectiveness.

    [6] [7] [8] Wilkinson, David. Group decision-making. What he said in The Oxford Review, Diciembre 2019

    [9] “The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why?” – Nelson Cowan – https://www.psychologicalscience.org/journals/cd/19_1_inpress/Cowan_final.pdf?q=the-recall-of-information-from-working-memory

    [10] Knowledge management https://en.wikipedia.org/wiki/Knowledge_management

    [11] These are informal observations that anyone can get, but one of the most well-known investigations was done by the English magazine Nature Human Behavior in 2017.

    [12] Stable reference: https://www.jstor.org/stable/2786271

    [13] Familiar Metric Management – Small is Beautiful-Once Again – Lawrence H. Putnam and Ware Myers https://hbswk.hbs.edu/archive/2996.html

    [14] The Mythical Man-Month: Essays on Software Engineering – Frederick Brooks https://en.wikipedia.org/wiki/The_Mythical_Man-Month

    Related links:

    Agile’s Origins and Values
    The Agile Team Approach
    What Scrum Master Certification to Choose?
    Too Big to Scale – Optimal Scrum Team Size Guide

    Some books to know more:

    No Comment
  • Sin Usuarios

    Without users (User Proxies)

    Without Users (User Proxies)

    Ideally, when we pretend to develop a software, we need to talk with one or more real users who are part of the customer team. But, the reality has the bad habit of punching Dilbert and us right in the nose and continuously we found our selves in one of two situations:

    1. We have as primary contacts, people who pretend to guess how a final user wants the software behaves when only the real user actually knows it, and yet we have limited or no access at all to them.
    2. The product is so innovating that we actually don’t have a real user in advance.

    Unfortunately, very often is difficult to get the users that we need. For example, we could be developing a product with user all over the country, but we can’t bring one (or more) of them with us, to write requirements or user stories. Or maybe we could be writing software that will be used inside our company, but somebody says that we can’t talk directly with the users.

    When we can’t get as many users as we’d like us to represent the different perspectives to the product, we have to resort to people or intermediary resources, also known as user proxies, who maybe are not users, but we need to include them in the project in order to represent the users and so deal with the two mentioned situations.

    Warning

    What I going say in rest of this post can be controversial and is subject to my personal experience but is also based on publications (that I always put at the end). This time I will focus on what characterizes each type of user proxy.

    The user proxies selection can be critical to achieving the success of a project. The experience, motivations and possible agenda of a proxy must be considered. A user proxy involved in sales will have a completely different perspective from a domain expert’s. It’s important to be aware of these differences, that is why I’ll try to provide a synthesis of what characterizes some of them.

    Proxies:

    Final users supervisors

    When we try to create internal use applications is common that middle management to be reluctant about to give full access to final users for a variety of reasons, so is very likely that you as a requirements engineer, business analyst, product owner, etc., end up dealing with supervisors and managers of the users on what you’re interested in.

    We must be very careful when we dealing with those proxies, especially in public institutions that are very bureaucratic, because this they tend to fall in bad practices that try to minimize, dissimulate or hide during their process and operations.

    On other occasions, the users’ supervisors intercede and want to represent the role of a user because they think they know more than the real users. But usually, the managers or supervisors have different usage pattern. You should be skilled enough to “turn around” that proxy and reach the final users as much as you can without offending the supervisor. In the section, What to do without users (or almost)? you can read what to do in those cases.

    Development managers, development supervisors, development directors, development leaders and similar

    This type of proxy is one the worst options unless you are writing software specifically for this type of user. Even when the intentions of this type of user sometimes are good, it’s likely this type of leader has his/her own interests and prioritize in a different way the requirements or user stories than a final user would.

    This happens because this role tends to accelerate the introduction of new technologies, or in the worst case scenario, when there is too much technical debt or a disorganized operation, s/he will try to reduce her/his workload at the slightest opportunity.

    Finally, the development managers usually don’t have experience as final users of the solution that is being built and they aren’t domain experts of interest. If a development supervisor es a real final user then you can consider him an appropriate domain expert, otherwise I advise you to avoid using her/him as a proxy if possible.

    People involved in sales

    The danger of use people involved in sales as proxies is that they usually tend to want to close a sale quickly and no matter what, which leads to a distorted vision about how a product should be built.

    If the person in sales, lost the last sale due the lack of a specific characteristic, you can be sure that those people in sales instantly will include as a high priority requirement that characteristic or functionality. Another common situation is people in sales, according to the potential sale earning or commission tends to promise too much even with a small knowledge about other domains, with short-term benefit vision.

    A company that places too much emphasis on lost sales or short-term profits may lose track of its vision and long-term strategies.

    However, the people in sales can be a great conduct to reach final users and we should use them in that way. Ask to them introduce you to customers, join them in sales visits, in sales shows and promotion events, learn about how the products or services of your organization are exhibited and then talk to the users.

    Domain experts

    The domain experts are those who give us what we call experts’ domain and can be very important due to the knowledge that they have in the field of our product. Of course, some domains are more complex than others.

     

    The domain experts can be great resources, but their usefulness is very dependent on whether they are current users or former users of the type of solution that we are creating. Knowing this we must be aware that this kind of proxies can make us create products aimed to their domain level, and if we are not careful we could end creating a too much complex software for the real users level.

    Marketing groups

    People or groups focused on marketing tend to focus more on the market or in niches themselves, rather than on individual users, so the result is that they concentrate more on quantities of functionalities than on the quality of them.

    But do not dismiss our marketing friends, in many cases, they can provide us with valuable high-level information that can help us to establish relative priorities, but we shouldn’t expect a detailed vision for our requirements or user stories.

    Former users

    A former user can be a great proxy if their experience is recent. However, as with other proxies, we must be careful and consider that the objectives and incentives of our proxy are aligned with those of the current final user.

    Customers

    Customers are the ones who make the purchasing decision; they aren’t necessarily final users of the product. It’s important to consider the wishes of your customers because they, not your users, are the ones who sign the check to buy the solution unless of course, the final users and the clients are the same people.

    The features of a product like this should be enough so that the end users do not shout too loudly; but they must also be those that attract the customer who makes the purchasing decision.

    Trainers and technical support

    Trainers and technical support personnel may seem like logical options to use as user proxies. They spend their days talking to real users, so they must surely know what the users themselves want, right? Well, unfortunately, if you use a trainer as your user proxy, you will end up with a system, that is, easy to train.

    Similarly, if you use someone from technical support, you will end up with a system that is very compatible and easy for supporting. For example, someone from technical support can assign a low priority to advanced features that he anticipates will increase support work.

    While ease of training and compatibility are good objectives, it’s most likely that they aren’t what a true final user would prioritize.

    System analysts and business analysts

    Many business analysts and systems analysts make good user proxies because they have a foot in the world of technology and the other one in the processes and operation domain. An analyst who can balance this background and who strives to talk to real users is often an excellent proxy user.

    A problem that some analysts present is that they prefer to think about a detected problem instead of research about it to solve it. Another problem that I’ve encountered occasionally is they tend to spend too much time on project’s upfront tasks.

    What to do without users (or almost)?

    When access to users is limited

    When the team needs it to work with a proxy, it’s important to be very quick and establish with the sponsors, the proxy and management with sufficient authority, the fact that it’s necessary to establish a small “advanced post” group formed by real users, in order to evaluate any initiative, theory or assumption, and achieve validated knowledge as soon as possible.

    Be efficient and transparent by scheduling constant meetings of maximum established duration and at a constant pace to facilitate meetings and minimize external obstacles, making it clear from the beginning that the objective is to identify, write and prioritize user stories or requirements.

    If there are really no users available

    When a user is not really available and must use a user proxy, a valuable technique is using more than one user proxy. This helps to reduce the likelihood of building a system that only satisfies one person’s needs. When you use more than one user proxy, make sure use different types of proxy. For example, combine a domain expert with someone from marketing instead of using two domain experts.

    If you are developing software that competes with other commercial products, you can use the competitive products as a source of some user stories or requirements. What features of the products of the competition are mentioned in the reviews? What features are discussed in the online newsgroups? Are the features discussed because they are too complex to use or because they are very useful?

     

    Another technique that you can use when you’re working with a user proxy instead of real users, is releasing the product as soon as possible. Even whether you call it preliminary version, beta, early, etc., try to put it in the hand of the users as soon as possible and identify inconsistencies between the user proxy thoughts and the actual real users, so you also get validated knowledge. Even better, once the software is in the hand of one or more of the first users, you now have a communications path to these real users and can use that to talk with them about upcoming features.

    Can you do it your self?

    When you can’t find or access to a real user, don’t fall into the trap of thinking you know the users’ mind and you don’t need or you can ignore a user proxy. Even if each type of user proxy has some kind of inconvenience that makes her/him less desirable than a real user, most developers have even more deficiencies to pretend to be a real user.

    In general, developers don’t have marketing knowledge that allows them to understand the features’ relative value, they don’t have the same amount of contact with the customer as the salespeople, they are not domain experts, etc.

    Do you know another type of user? Do you have a different opinion about the proxies presented here?

    *Sorry about my English, I’m not natural speaker :p. Don’t be grumpy and help me to improve 😀

    Other links of interest:

    Agile’s Origins and Values
    The Agile Team Approach

    If you want to know more, these are some recommended books:

    Any help is welcome to help us keeping this effort alive! PayPal Account BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxw BTC: 1DDcWbphm1bKMvWruotNKLSM8ypVaHg5Nv ETH: 0x58D137fb142D946bCD815f0ded0fa3b3fE5AB3BF

    No Comment
  • The Agile Team / El Equipo Agile

    The Agile Team Approach

     

    First of All

    If you don’t know the four Agile Value Statements, I invite you to take a look at Agile’s origins and values post before continuing, if you already did or already know these values, now you can focus your attention on how the agile team approach actually is in the field. Together, the Agile Value Statements add up to a highly iterative and incremental process and deliver tested code at the end of each iteration. The next points, in general, include the overall way I which an agile team carries the project:

    • Works as one
    • Works in short iterations
    • Release something every iteration
    • Focuses on business priorities
    • Inspects and adapts

    The Agile team works as one

    Unfortunately, is usual to see some business and systems analysts throw processes or requirements to designers and programmers like a ball over the wall and just continuing with their lives, also there are designers and architects who elaborate their appealing designs without the slightest consultation to their programmer coworkers, or talented programmer who finish their assigned part of the system and then shake their hands and disappear; and we can go on with sad stories. A successful agile team must have a “we’re in this together” mindset.

    I really like using video games analogies, because are a great way to illustrate what happens in real life. A lot of online games are team games, where each member of the team has a role. In this teams, there are roles such as the healer who heals his teammates, the tank who receives hits becoming in a shield for the rest of team who can attack more efficiently, the DPS who do damage to the enemy and the special class who does some kind of damage. When a player doesn’t perform their role properly, puts the rest of the team at a considerable disadvantage, sometimes this breaks the whole team completely. Everybody must work as one!

    Just like happens in this games, the agile teams also have roles, and it’s worth identifying them in a general way:

    Product Owner

    The main responsibilities of the product owner include making sure that the whole team shares the same vision about the project, establishing priorities in a way that the functionalities that contribute the most value to the business are always in which the team is working on. Take decisions that take the best return on investment of the project is the highest priority.

    Customer

    The customer is the person who made the decision to finance the project, usually represents a group or division. In these cases, it is common for this role to be combined with the product owner. In other projects, the customer can be a user.

    Developer

    In the context of agile teams, a developer title is used in a wide way, this is a developer can be a programmer, a graphic designer, a database engineer, user experience experts, architects, etc.

    Project manager

    We have to take this carefully because an agile project manager focuses more on leadership than traditional management. In some projects and agile frameworks, this figure doesn’t even exist or if it does, the person in charge of this role shares the traditional project management responsibilities with other roles such as product owner. Also can be an advisor on the adoption and understanding of the agile approach. In very small projects can even have a role as a developer, but this practice is not recommended.

    The Agile team works in short iterations

    Already mentioned this in previous posts, in agile projects, there is not a phase delineation too marked. There are not an exhaustive establishment of requirements at the beginning of the project followed by an analysis, there is not architectural design phase for the entire project. Once the project really starts, all the work (analysis, coding design, testing, etc.) occurs together within an iteration.

    The iterations are done within a previously delimited time-space (timeboxed). This means that each iteration is completed is the agreed time without excuses, even if the planned functionalities are not finished. The iterations are often very short. Most agile teams use iterations between one week and four weeks.

    The Agile team release something every iteration

    Something crucial in each iteration is that within its space of time one or more requirements are transformed into codified, tested and potentially packageable software. In reality, this does not mean that something is delivered to the end users, but it must be possible to do so. The iterations one by one add up the construction of only some functionalities, in this way an incremental development is obtained by going from one iteration to the next.

    Because a single iteration usually does not provide enough time to develop all the functionalities that the customer wants, the concept of release was created. A release comprises one or more (almost always more) iterations. Releases can occur in a variety of intervals, but it’s common for releases to last between 2 and 6 months. At the end of a release, this can be followed by another release and this one can be followed by another, and so on until the project is finished.

    The Agile team focuses on business priorities

    Agile teams demonstrate a commitment to business priorities in two ways. First, they deliver functionalities in the order specified by the product owner, which is expected to prioritize and combine features in a release that optimizes the return on investment for the project organization. To achieve this, a plan is created for the release based on the capabilities of the team and a prioritized list of the new desired functionalities. For the product owner to have greater flexibility in prioritization, the features must be written down minimizing the technical dependencies between them.

    Secondly, agile teams focus on completing and delivering functionalities valued by the user instead of completing isolated tasks.

    The Agile team inspects and adapts

    It is always good to create a plan, but the plan created at the beginning does not guarantee what will happen in the future. In fact, a plan is just a guess at a point in time. If you live persecuted by Murphy’s Law like me 😀, there will be many things that will conspire against the plan. Project staff can come or go, technologies will work better or worse than expected, users will change their minds, competitors can force us to respond differently or faster, and so on. Agile teams see that each change represents both, an opportunity and the need to update the plan to improve and reflect the reality of the current situation.

    At the beginning of each new iteration, an agile team incorporates all the new knowledge obtained in the previous iteration and adapts accordingly. If a team learned something that is likely to affect the accuracy or value of the plan, the plan must be updated. That is, perhaps the team discovered that they have overestimated or underestimated their ability to progress (capacity) and that a certain type of work consumes more time than previously thought.

    In the same way, the plan can be affected by the knowledge that the product owner has gained from the users. Perhaps because of the feedback obtained from a previous iteration the product owner has learned that users want to see more of some kind of functionality and no longer value so much that they had considered. This type of situation can alter the plan, so you have to adapt it to improve its value.

    Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve).

    This is all for now folks, I hope this can be useful for you.

    Related links:

    Agile’s origins and values
    Roles on Agile Teams: From Small to Large Teams
    What Is Agile?

    These are some recommended books to know more:

    No Comment
  • Sin Usuarios

    Sin Usuarios (Proxies de Usuario)

    El ideal y la realidad

    Idealmente, cuando se pretende desarrollar un software, debemos conversar con uno o más usuarios reales que forman parte del equipo de un cliente. Pero, la realidad tiene la mala costumbre de golpearnos a nostros y a Dilbert justo en la nariz y continuamente nos podemos encontrar en una de dos situaciones:

    1. Tenemos como contactos primarios a personas que pretenden adivinar cómo un usuario final quiere que se comporte el software, cuando solo un usuario real lo sabe, y aun así tenemos acceso limitado a ellos o ningún acceso a ellos.
    2. El producto es muy innovador y no tenemos un usuario real existente de antemano.

    Desafortunadamente, a menudo es difícil obtener los usuarios que necesitamos. Por ejemplo, podríamos estar desarrollando un producto con usuarios en todo el país, pero no podemos traer uno (o más) de ellos con nosotros para escribir requerimientos o historias de usuario (user stories). O podríamos escribir software que se utilizará dentro de nuestra empresa, pero alguien nos dice que no podemos hablar con los usuarios.

    Cuando no podemos obtener tantos usuarios como desearíamos para representar las diferentes perspectivas del producto, tenemos que recurrir a personas o recursos intermediarios, también conocidos como proxies de los usuarios o user proxies, que pueden no ser usuarios, pero que debemos incluir en el proyecto para ayudar a representar a los usuarios y así lidiar con las dos situaciones mencionadas.

    Advertencia

    Lo que diré a continuación en el resto de esta entrada puede ser polémico y está sujeto a mi experiencia personal pero también en base a publicaciones (que siempre pongo al final). En esta ocasión me enfocaré en aquello que caracteriza a cada tipo de proxy de usuario.

    La selección de proxies de usuario puede ser crítica para lograr el éxito de un proyecto. La experiencia, motivos y posible agenda de los proxies de usuario debe considerarse. Un proxy de usuario involucrado en ventas tendrá una perspectiva completamente diferente a la de un experto de dominio. Es importante estar al tanto de estas diferencias, por lo que trataré de proporcionar una síntesis de lo que caracteriza a algunos.

    Proxies:

    Supervisores de usuarios finales

    Cuando se intentan crear aplicaciones de uso interno es común que los mandos medios se muestren reacios a dar un acceso completo a los usuarios finales por una variedad de razones, por lo que es muy probable que usted como ingeniero de requerimientos, analista de negocios, product owner, etc., termine lidiando con supervisores o gerentes de los usuarios de su interés.

    Hay que tener mucho cuidado cuando debemos tratar con estos proxies sobre todo en instituciones públicas muy burocratizadas, porque estas tienden a caer en malas prácticas que intentan minimizar, disimular u ocultar durante sus procesos y operación.

    En otras ocasiones los supervisores de usuario interceden y quieren representar el rol de usuario porque creen que saben más que los usuarios reales.  Pero usualmente los gerentes o supervisores tienen patrones de uso diferentes a los usuarios. Usted deberá ser lo suficientemente hábil para “dar la vuelta” a este proxy y llegar tanto como sea posible a los usuarios finales sin ofender al supervisor. En la sección ¿Que hacer sin usuarios (o casi)? puede ver que hacer casos así.

    Gerentes de desarrollo, supervisor de desarrollo, directores de desarrollo, líderes de desarrollo y similares

    Este tipo de proxy es uno de las peores opciones, a menos que usted esté escribiendo software específicamente para este tipo de usuario. Incluso cuando las intenciones de este tipo de proxy a veces sean buenas, lo más probable es que este tipo de líder tenga sus propios intereses y priorice de manera diferente, los requerimientos o historias de usuario, a como lo haría un usuario final.

    Esto sucede porque este rol tiende a querer acelerar la introducción de nuevas tecnologías, o en el peor de los casos, cuando se tiene mucha deuda técnica o una operación desorganizada, tratará de disminuir su carga de trabajo a la menor oportunidad.

    Finalmente, los encargados de desarrollo no suelen tener experiencia como usuarios finales de la solución que se está construyendo y no son expertos del dominio de interés. Si un encargado de desarrollo es realmente un usuario final entonces considérelo un experto de dominio apropiado, de lo contrario le aconsejo evitar en lo posible usarlo como proxy.

    Involucrados en ventas

    El peligro de utilizar a personas involucradas en ventas como proxies, está en que estas usualmente tienden a querer cerrar una venta rápido y a como dé lugar, lo cual lleva a una visión distorsionada acerca de cómo un producto debe ser construido.

    Si la persona en ventas, perdió la última venta por la carencia de una característica específica tenga por seguro que esa personas de ventas incluirá instantáneamente como requerimiento de alta prioridad a esa característica o funcionalidad. Otra situación común es que las persona en ventas, de acuerdo a la utilidad y comisión potencial de una venta específica, tienden a prometer demasiado incluso con poco conocimiento de otros dominios, con una visión de beneficio a corto plazo.

    Una compañía que pone demasiado énfasis en ventas perdidas o por beneficios a corto plazo puede perder la pista de su visión y estrategias de largo plazo.

    Sin embargo, las personas en ventas, pueden ser un gran conducto para llegar a usuarios finales y hay que usarlos de esa manera. Pídales que lo presenten con los clientes, acompáñelos a visitas de venta, a los shows y ferias de promoción, aprenda acerca de cómo se exhiben los productos o servicios de su organización y entonces hable con los usuarios.

    Expertos de dominio

    Los expertos de dominio, son aquellos que nos dan lo que llamamos la opinión de expertos, y pueden ser sumamente importantes debido al conocimiento que poseen en el área de nuestra aplicación. Desde luego algunos dominios son más complejos que otros.

     

    Los expertos de dominio pueden ser grandes recursos, pero su utilidad es muy dependiente de si son usuarios actuales o antiguos usuarios del tipo de solución que estamos creando. Sabiendo esto hay que estar conscientes que este tipo de proxies nos pueden hacer crear aplicaciones dirigidas a su nivel de dominio, y si no se tiene cuidado podríamos caer en crear un software demasiado complejo para el nivel de nuestros usuarios reales.

    Grupos de mercadeos (marketing)

    Las personas o grupos enfocadas al mercadeo tienden a concentrarse más en el mercado o en nichos en si, más que en usuarios individuales, por lo que el resultado es que se concentran más en cantidades de funcionalidades que en la calidad de las mismas.

    Pero no descartemos a nuestros amigos de marketing, en muchos casos nos pueden proveer de valiosa información de alto nivel que nos puede ayudar sobre todo a establecer prioridades relativas, pero no esperemos una visión detallada para nuestros requerimientos o historias de usuario.

    Antiguos usuarios

    Un antiguo usuario puede ser un gran proxy si su experiencia es reciente. Sin embargo, como sucede con otros proxies, hay que tener cuidado y considerar que los objetivos e incentivos de nuestro proxy se alineen con los del usuario final.

    Clientes

    Los clientes son los que toman la decisión de compra; ellos no son necesariamente usuarios finales del software. Es importante considerar los deseos de sus clientes porque ellos, no sus usuarios, son los que firman el cheque para comprar la solución, a menos que por supuesto, los usuarios finales y los clientes sean las mismas personas.

    Las características de un producto como este deben ser suficientes para que los usuarios finales no griten demasiado fuerte; pero también deben ser aquellas que atraen al cliente que toma la decisión de compra.

    Capacitadores y soporte técnico

    Los capacitadores y el personal de soporte técnico pueden parecer opciones lógicas para utilizar como proxies de usuario. Pasan sus días hablando con verdaderos usuarios, por lo que seguramente deben saber lo que quieren los usuarios mismos ¿correcto?. Bueno, desafortunadamente si usa un capacitador como su proxy de usuario, terminará con un sistema, eso es sí, fácil de capacitar.

    Del mismo modo, si utiliza a alguien de soporte técnico, terminará con un sistema que es muy compatible y fácil de soportar. Por ejemplo, alguien de soporte técnico puede dar baja prioridad a las funciones avanzadas que él anticipa que aumentarán el trabajo de  soporte.

    Si bien la facilidad de capacitación y la compatibilidad son buenos objetivos, lo más probable es que no sean lo que un usuario final verdadero priorizaría.

    Analistas de sistemas y analistas de negocio

    Muchos analistas de negocios y sistemas hacen buenos proxies de usuario porque tienen un pie en el mundo de la tecnología y un pie en el dominio de los procesos y la operación. Un analista que puede equilibrar estos antecedentes y que se esfuerza en hablar con los usuarios reales suele ser un excelente usuario proxy.

    Un problema que presenta algunos analistas es que prefieren pensar en un problema detectado en lugar de investigarlo para solucionarlo. Otro problema que he encontrado ocasionalmente es que tienden a pasar demasiado tiempo en las actividades de antemano de un proyecto.

    ¿Que hacer sin usuarios (o casi)?

    Si el acceso a los usuarios es limitado

    Cuando es necesario que el equipo trabaje con un proxy es importante ser muy rápido y establecer con los patrocinadores, el proxy y gerencia con suficiente autoridad, el hecho de que se requiere establecer un grupo pequeño “de avanzada” formado por usuarios reales, con el fin de evaluar cualquier iniciativas, teorías o suposiciones, y lograr conocimiento validado los más pronto posible.

    Sea eficiente y transparente programando reuniones constantes de duración máxima establecida y a ritmo constante para facilitar las reuniones y minimizar los obstáculos externos, dejando muy claro desde el inicio que el objetivo es identificar, escribir y priorizar historias de usuario y requerimientos.

    Si realmente no hay usuarios disponibles

    Cuando realmente no hay un usuario disponible y debe recurrir a un proxy de usuario, una técnica valiosa es usar más de un proxy de usuario. Esto ayuda a reducir la probabilidad de construir un sistema que satisfaga solamente las necesidades de una persona. Cuando use más de un proxy de usuario, asegúrese de usar diferentes tipos de proxy. Por ejemplo, combine un experto de dominio con alguien de marketing en lugar de usar dos expertos de dominio.

    Si está desarrollando un software que compita con otros productos comerciales, puede usar los productos de la competencia como fuente de algunas historias de usuario o requerimientos. ¿Qué características de los productos de la competencia se mencionan en las reseñas? ¿Qué características se discuten en los grupos de noticias en línea? ¿Se discuten las características porque son demasiado complejas de usar o porque son muy útiles?

     

    Otra técnica que puede usar cuando trabaja con un proxy de usuario en lugar de usuarios reales, es lanzar el producto lo antes posible. Incluso si la versión se llama preliminar, beta, temprana, etc., trate de ponerla en manos de los usuarios lo más pronto posible e identificar inconsistencias entre lo pensando por su proxy de usuario y sus usuarios reales, así también obtendrá conocimiento validado. Incluso mejor, una vez que el software está en manos de uno o más de los primeros usuarios, usted ahora tiene una ruta de comunicación para esos usuarios reales y puede usar eso para hablar con ellos sobre las próximas funciones.

    ¿Puede hacerlo usted mismo?

    Cuando no puede encontrar o acceder a un usuario real, evite caer en la trampa de pensar que conoce las mentes de sus usuarios y no necesita o puede ignorar a un proxy de usuario. Si bien cada tipo de proxy de usuario tiene algún tipo de inconveniente que lo hace menos deseable que un usuario real, la mayoría de los desarrolladores presentan aún más deficiencias para pretender ser un usuario real.

    En general, los desarrolladores no tienen conocimiento de marketing que les permita comprender el valor relativo de las características, no tienen la misma cantidad de contacto con el cliente que los vendedores, no son expertos en el dominio, etc.

    ¿Conoce otro tipo de usuario?¿Tiene una opinión diferente de los proxies que se presentaron aquí?

    Otros enlaces de interés:

    El Origen Y Los Valores De Agile
    El Enfoque del Equipo Agile
    Planeación, Cono de Incertidumbre y Estimaciones en IT

    Si quire saber más estos son algunos libros recomendables:

    No Comment
  • Agile Value / Valores de Agile

    Agile’s origins and values

    Agile Value / Valores de Agile

    Winds of Change

    Much is heard about Agile, Agile project management or the “Agile methodology” as something from the 21st century, but actually, the origin and Agile values began to take shape a little earlier. The 90s were a very interesting decade, MTV had its best moment, the Grunge music invaded the radio and the Internet came to the life of the masses. Along with the Internet boom, the way of making software changed completely, companies began to learn how to create software on a large scale and for interconnected users all over the world, which brought new demands. In the search for success, many of these companies began to import “good practices” from other industries expecting good results, which in the end were mixed in many cases (see Waterfall Model).

    Many electromechanical systems were already beginning to be replaced by electronic systems, and sometime later the software began to have more and more relevance, but the development and interaction of these elements were trapped in predictive models that tried to know all elements involved in a system of beforehand, which were (and still are) very difficult to establish at the beginning of software projects with high levels of uncertainty, which has since caused very long development periods with hard-to-predict end dates. This situation led to the frustration of many leaders, who despite the situation were creating and adapting their own techniques, methods, and frameworks to the traditional models of development, which eventually gave rise to the first winks of Agile thinking.

    Agile is born

    After several previous meetings, in February of 2001, a group of professionals had a new and now famous meeting whose main contribution was The Agile Manifesto. This manifesto was written and signed by seventeen software development leaders (now known as the Agile Community). Their document gave a name to how this group was developing software and provided a list of Agile value statements:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan
    And this group added:

    That is, while there is value in the items on the right, we value the items on the left more.

    You can know more about history and the original manifesto at agilemanifesto.org

    In particular, these opinion leaders looked for ways to quickly build functional software and put it in the hands of end users. This quick delivery approach provided a couple of important benefits. First, it allowed users to get some of the business benefits of the new software faster. Second, it allowed the software team to obtain quick feedback on the scope and direction of software projects on a regular basis. In other words, the Agile approach was born.

    Behind the Agile Value Statements

    You already know the list of value statements, but let’s see what are the reasons behind them:

    Value people and interactions over processes and tools. Those of us who have a path in the development world know that a team with great people works well even using mediocre tools also these teams always overcome other dysfunctional teams with mediocre people who have excellent tools and processes. If people are treated as disposable pieces there will be no process, tool or methodology capable of saving their projects from failing. Good development processes recognize the strengths (and weaknesses) of individuals and take advantage of it instead of trying to make everyone homogeneous.

    Value software that works over the comprehensive documentation. Because it leads us to have incrementally improved versions of the product at the end of each iteration. This allows us to collect early and often, some feedback about the product, and the process allows us to know if we should correct the course of action, make adjustments or move forward with the same vision. As the developed software grows with each iteration, it can be shown to the probable or real users. All this facilitates the relationship with customers and improves the chances of success.

    Value the collaboration with the customers over contracts negotiation. Because in order to create Agile teams we must seek that all parties involved in the project work to achieve the same set of goals. Contract negotiation sometimes conflicts with the development team and the customer from the beginning. I think the multiplayer online battle arena games are a great example, personally, I like games like Heroes of the Storm o League of Legends. These are cooperative games where teams with five members are formed, the objective is that the team must destroy the base of the enemy by working together. All players win, or all players lose. These matches are surprisingly fun, and what we would like, for software development teams and customers, is to come together with this same attitude of collaboration and shared goals. Yes, contracts are often necessary, but the terms and details of a contract can exert a great negative influence on the different parties involved, and turn a collaborative environment into an inner competitive one.

    Value responding to change over following a plan. Because the main objective is to provide the greatest possible amount of value to the project’s customers and users. In large and/or complex projects, you will find that it is very difficult even for users and/or customers, to know every detail of each feature they want. It is inevitable that users come with new ideas, or that they decide that some critical features initially are no longer so. For an Agile team, a plan is a vision of the future, but many points of view are possible and environmental factors can change over the time. As a team gains knowledge and experience about a project, the plan should be updated accordingly.

    With the four Agile Values Statements from the Agile Manifesto in mind, I think you can begin to understand what it means to have an Agile approach to estimating and planning.

    Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve 🙂 ).

    Related links:

    To agility and beyond: The history—and legacy—of agile development

    What Is Agile?

    What Scrum Master Certification to Choose?

    These are some books to know more:

    No Comment
  • Los Cinco Procesos De La Administración De Proyectos

    Los Cinco Procesos De La Administración De Proyectos (Video Curso)

    Los Cinco Procesos De La Administración De Proyectos

    Aquí está el cuarto video del curso gratuito en video de Introducción a la Administración de Proyectos desde cero. Esta vez se abordarán los cinco grupo de procesos de la administración de proyectos de acuerdo al Project Manament Institute o PMI. En mi opinión el PMI en su Project Management Body of Knowledge o PMBOK es donde mejor engloban los procesos generales y las áres de conocimiento requeridas para la gestión de proyectos; independientemente de metodologías, técnicas o herramientas.

    En el video se explica brevemente la relación entre los cinco grupo de procesos de la administración de proyecto y las preguntas que nos planteamos en el video Definición de Gestión de Proyectos. Los temas tratados en el video son:

    • Inicio
    • Planeación
    • Ejecución
    • Monitoreo y Control
    • Cierre

    Todos los videos previos están disponibles en YouTube o si prefiere, en los siguientes enlaces:

    1. Definición de Proyecto (Video)
    2. Definición de Gestión de Proyectos
    3. Lo Necesario Para Ser Un Administrador de Proyectos

    Estos videos forman parte del primer capítulo del curso Explorando La Administracion De Proyectos. La estructura del curso puede verla aquí, la cual estaré actualizando con los enlaces apropiados según suba los respectivos videos.

    El mundo de YouTube vive de vistas, likes y suscripciones (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares, suscripciones y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa 🙂 y además pueden obtener:

    • Video descargable en alta definición.
    • Transcripción del contenido.
    • Documentos y preguntas de práctica (sólo los videos que lo ameriten).

    Como parte de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos tenemos este cuarto video:

     

    Algunas publicaciones recomendables para saber más:

    No Comment
  • Lo Necesario Administrador De Proyectos

    Lo Necesario Para Ser Un Administrador de Proyectos (Video Curso)

    Lo Necesario Administrador De Proyectos

    Ahora tenemos el tercer video del curso gratuito en video de Introducción a la Administración de Proyectos desde cero. En esta oportunidad veremos lo necesario para ser un administrador de proyecto o project manager, veremos cuál es el perfil general que este rol require para hacer una adecuada gestión de proyectos, habilidades como:

    • Habilidades técnicas
    • Comprensión del negocio
    • Habilidades interpersonales
    • Liderazgo

    El primer y segundo video están disponibles en YouTube o si prefiere, en los siguientes enlaces:

    1. Definición de Proyecto (Video)
    2. Definición de Gestión de Proyectos
    3. Los Cinco Procesos De La Administración De Proyectos

    El mundo de YouTube vive de vistas, likes y suscripciones (un fastidio pero así es ¯\_(ツ)_/¯ ) por lo tanto agradeceré sus manitas arriba, shares y todo eso que los youtubers siempre piden. También puede ver todos los videos en Patreon ahí las almas voluntariosas puede ayudar a la causa y además pueden obtener:

    • Video descargable en alta definición.
    • Transcripción del contenido.
    • Documentos y preguntas de práctica (sólo los videos que lo ameriten).

    La estructura del curso puede verla aquí, estoy actualizando esta estructura según avanzo en la misma.

    *Algo que no mencioné en el video es que este aplica también para Scrum Masters, aunque en la aproximación Scrum este rol cambia un tanto respecto al de Project Manager tradicional, ambos comparten una buena cantidad de reponsabilidades y características.

    Sin más el tercer video de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos. Este tercer video se titula Lo Necesario Para Ser Administrador de Proyectos:

     

    Algunas publicaciones recomendables para saber más:

    No Comment
  • Agile Planning / Planeación Agile

    El Enfoque De La Planificación Agile

    Agile Planning / Planeación Agile

    Revelación

    Hacer la estimación y la planeación del desarrollo de un producto puede ser una tarea desalentadora que se hace más complicada por nuestra ignorancia o mala interpretación acerca de los proyectos, como concepto y en proyectos específicos. Hace tiempo leí (enlaces al final) que un proyecto no debía ser visto sólo como una secuencia de pasos, sino que también debía ser visto como un flujo rápido que genera nuevas capacidades y nuevo conocimiento. Las nuevas capacidades se entregan como parte del nuevo producto y el nuevo conocimiento se utiliza para hacer un mejor producto (Cohn 2006). Esto es la base para el enfoque de la Planificación Agile sobre la planeación.

    Al comenzar a leer sobre administración de proyectos, trabajaba como desarrollador, y esa frase (del párrafo anterior) fué una de mis primeras revelaciones serias acerca de porque trabajaba tan duro codificando para funcionalidades que al final no se utilizaban o bien en proyectos que no lograban sus objetivos plenamente. Parte de las fallas de esos proyectos fueron desde luego, a veces no planear en lo absoluto, pero también tratar de planear todo desde el principio.

    En un proyecto Agile utilizamos las nuevas capacidades y el nuevo conocimiento obtenido como guía para el trabajo mismo que se está realizando. El conocimiento obtenido puede ser acerca del producto o del mismo proyecto en general, lo importante es que este nuevo conocimiento nos da mejor idea de cómo debería ser el producto en el cual trabajamos o bien se convierte en mejor entendimiento sobre una tecnología, sobre el equipo, sobre los riesgos, etc.

    Cuando pretendemos planear todo desde el principio (ni hablar cuando no planeamos) estamos fallando en integrar nuevo conocimiento al plan, y por lo tanto eso nos lleva a caer en suposiciones erróneas, como creer que estamos incluyendo TODO lo necesario en nuestro plan (lo que en el mundo del software rara vez sucede).

    Mis amigos desarrolladores son mayormente gordos y feos (pero aún así los quiero 😃) y no les gusta correr (ejercitarse, hacer cardio, etc.) , pero a mí sí, por lo que utilizaré la siguiente analogía: Una aproximación tradicional a un proyecto puede ser como una carrera de 10km donde usted sabe exactamente dónde está la meta y trata de alcanzarla tan rápido como sea posible. Un proyecto Agile es como cuando usted se toma el tiempo y ve que tan lejos puede llegar en 60 minutos. Un equipo Agile sabe cuándo termina, pero no exactamente que entregará al final. Por lo tanto, planear se convierte en proceso en donde crean y revisan objetivos periódicamente que eventualmente llevan a una meta de más largo término.

    Niveles de planificación Agile

    Cuando estamos preparando los objetivos de un plan es importante reconocer que no podemos ver más allá de cierto horizonte y que la exactitud de nuestro horizonte será cada vez menor entre más lejos queramos ver. En mis cursos menciono los primeros capítulos de una serie de TV llamada Vikings en donde plantean someramente el uso regular de un compás solar, un piedra solar y cuervos para poder corregir el rumbo periódicamente y mantener un curso correcto; de esta misma manera nosotros debemos revisar el estado de nuestro proyecto y ajustar nuestro plan de acuerdo a ello. Desde este punto ya estamos hablando de la elaboración de una planeación estratégica con el enfoque Agile.

    Como ya expresé, el riesgo de un plan se incrementa de acuerdo a que tan lejos en el futuro queramos planear, por ello cada cierto tiempo debemos levantar nuestra vista para ver el nuevo horizonte y ajustar el plan. Los equipos Agile hacen esto planeando en por lo menos 3 distintos horizontes (podrían ser más dependiendo de la aproximación de su organización, pero en esta entrada solo explicare estos). Los 3 horizontes son el Release (Liberación), Iteración y Diaria (actual). Puede tomar como referencia el siguiente diagrama (este no es un estándar, puede encontrar diferentes diagramas similares, pero los 3 horizontes principales no cambian):

    Planificación del Release (Liberación).

    Aquí determinamos respuestas a preguntas que se relacionan con el alcance, el calendario y los recursos del proyecto. Este plan debe ser actualizado a lo largo del proyecto, usualmente al inicio de cada iteración para reflejar las expectativas actuales que serán incluidas en el Release.

    Planificación de la Iteración.

    Esta se lleva a cabo al inicio de cada iteración y basada en el trabajo que se hizo en la iteración anterior (si no es la primera desde luego). El cliente o sus representantes (el Product Owner) deben identificar los elementos de mayor prioridad en los cuales el equipo concentrará sus esfuerzos en la nueva iteración. Esto porque estamos en un horizonte más cercano que el del Release. En este horizonte se establecen las tareas requeridas para obtener una parte funcional y probada de nuestro producto.

    Planificación Diaria.

    Puede sonar muy excesivo (y quizá lo es) llamar planificación a este horizonte, esto no son más que reuniones diarias e informales (que usualmente se hacen de pie ya que solo deben durar unos minutos) en donde se sincronizan los esfuerzos diarios individualmente. Esto es, que cada miembro del equipo comparte que ha hecho el día anterior, que piensa hacer hoy y comunica los obstáculos que afronta.

    Con estos tres horizontes (Release, Iteración y Diaria) los equipos ágiles se concentran sólo en lo que es visible e importante en el plan que han creado. De esta manera han adoptado el enfoque de la planificación Agile.

    Condiciones de Satisfacción.

    En una futura entrada dedicaré más detalle a esto (lo merece) pero no quiero dejar de mencionar el tema en esta misma entrada, por lo menos de manera breve. Todo proyecto debe comenzar con una meta, quizá de esta se deriven varios objetivos relacionados con fechas, presupuesto, recursos humanos, etc., pero típicamente solo habrá una meta. No dé por hecho que usted debe crear el mejor auto del mundo, la mejor puerta del mundo, el mejor ERP del mundo; los objetivos sólo deben alinearse con las condiciones de satisfacción del Producto Owner (la voz del cliente); esto es, los criterios que serán utilizados para evaluar y determinar el éxito del proyecto.

    Lo pondré de otra forma, hace mucho tiempo, cuando estaba en la secundaria era común que a la clase entera nos asignaran escribir un artículo sobre un libro, y de inmediato aparecía la pregunta obligada al profesor, la cual era qué tan largo debía ser artículo. El respondía algo así como “cinco páginas”, entonces conociamos su primera Condición de Satisfacción. Hubo, por supuesto, una serie de condiciones adicionales de satisfacción no escritas, como que el documento estubiera bien escrito, que fuera mi propio trabajo (no plagios), sin faltas de ortografía, etc.

    Al comienzo de la planificación Agile del Release o lanzamiento, el equipo y el propietario del producto exploran en colaboración las condiciones de satisfacción del propietario del producto. Estos incluyen los elementos habituales (alcance, calendario, presupuesto y calidad), aunque los equipos ágiles suelen prefieren tratar la calidad como no negociable. El equipo y el propietario del producto buscan formas de cumplir con todas las condiciones de satisfacción. El propietario del producto puede, por ejemplo, estar igualmente satisfecho con un Release en cinco meses que incluya un conjunto de historias de usuarios, que con un sólo lanzamiento de un mes que incluya historias de usuarios adicionales.

    A veces, sin embargo, no se pueden cumplir todas las condiciones de satisfacción del propietario del producto. El equipo puede construir el mejor procesador de textos del mundo, pero no pueden construirlo para el próximo mes. Cuando no se puede encontrar una solución factible, las condiciones de satisfacción deben cambiar. Debido a esto, la planificación del lanzamiento y la exploración de las condiciones de satisfacción del propietario del producto son altamente iterativas

    Conclusión

    Los proyectos deben considerarse como una generación rápida y confiable de un flujo de nuevas capacidades útiles y nuevos conocimientos, en lugar de solo la ejecución de una serie de pasos. Los proyectos generan dos tipos de conocimiento nuevo: conocimiento sobre el producto o servicio y conocimiento sobre el proyecto. Este conocimiento debe ser validado para evitar trabajo infructuoso (waste).

    La siguiente imagen muestra como la planifiación Agile existe dentro de una dinámica que busca adaptar conocimiento de manera pronta y altamente iterativa (como ya se mencionó). Hemos basado esta ilustración en la propuesta del buen @sdelbecque quien toma en cuenta la filosofía de Lean, con la cual la agilidad es altamente compatible:

    Enlaces relacionados:

    El Origen Y Los Valores De Agile

    El Enfoque del Equipo Agile

    Planeación, Cono de Incertidumbre y Estimaciones en IT

    Estos son alguno libros recomendables para saber más:

    No Comment
  • Definición de Gestión de Proyectos (Video Curso)

    Definición de Gestión de Proyectos

    Este el segundo video del curso gratuito en video de Introducción a la Administración de Proyectos desde cero. En este video se muestra la definición de gestión de proyectos como actividad y se muestran las preguntas principales que buscan responder con ella.

    Las temas que se tratan en este video son:

    • ¿Qué problema se está resolviendo?
    • ¿Cómo va a resolver este problema?
    • ¿Cuál es su plan?.
    • ¿Cómo saber cuando ha terminado el proyecto?

    Puede ver el primer video en la entrada anterior o bien ir directo a YouTube. El video siguiente ya está diponible en esta entrada o bien en YouTube.

    Mi objetivo es mantener todo el contenido de este curso (y este blog) gratis para todos, pero también es cierto que mantener este esfuerzo vivo genera gastos y consume tiempo (que si estudias o trabajas es todo un reto), es por ello que pido su paciencia y apoyo si es que ven alguna imagen o enlace con contenido publicitario. Por otro lado, he abierto un espacio en Patreon donde la gente que así lo decida puede donar para mantener este barco a flote, desde luego las personas que donen obtendrán contenido adicional:

    • Video descargable en alta definición.
    • Transcripción del contenido.
    • Documentos y preguntas de práctica.

    La estructura del curso puede verla aquí, estoy actualizando la estructura según avanzo en la misma.

    Sin más preámbulo este es el segundo video de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos. Este segundo video se titula Definición de Gestión de Proyectos:

    Algunas publicaciones recomendables para saber más:

    No Comment
  • Definicion De Proyecto

    Definición de Proyecto (Video Curso)

    Definicion De Proyecto

    En esta ocasión estoy emprendiendo algo nuevo, esto es un curso gratuito en video de Introducción a la Administración de Proyectos desde cero. En este video habla de la definición de proyecto con el fin de diferenciarlo de otro tipo de esfuerzos. Se abordan las características esenciales de un proyecto como son:

    • Esfuerzo único
    • Meta específica
    • Fechas de inicio y fin
    • Recursos
    • Diferencia con operación y cadena de producción.

    Como instructor de estos cursos para diferentes compañías, sé que hacerlos de manera presencial tiene una serie de ventajas y requiere cierta dinámica, sin embargo, la realidad es que estos cursos no son precisamente económicos. Debido a esto he decidido hacer una serie de videos cortos preo precisos, que tienen como objetivo compartir las bases de este conocimiento. De  manera tal que pueda poner estos conocimientos en práctica o bien aquellos que resulten muy interesados pueden, posteriormente, profundizar aun más pero ya contando con los fundamentos necesarios para abordar conceptos más avanzados.

    Mi objetivo es mantener todo el contenido de este curso (y este blog) gratis para todos, pero también es cierto que mantener este esfuerzo vivo es un reto (sobre todo si estudias o trabajas), es por ello que pido su paciencia y apoyo si es que ven alguna imagen o enlace con contenido publicitario. Por otro lado, he abierto un espacio en Patreon donde la gente que así lo desee pueda apoyar para mantener este barco a flote, desde luego las personas que donen obtendrán contenido adicional:

    • Video descargable en alta definición.
    • Transcripción del contenido.
    • Documentos y preguntas de práctica.

    En este enlace puede consultar el contenido del curso, puede ver su estructura y decidir el ritmo y el orden en que quiere tomarlo. Los videos que conforman este curso se irán publicando progresivamente. Puede consultar las redes sociales de internet80.com para estar al pendiente de la publicación de cada video.

    Sin más preámbulo este es el primer video de Introducción a la Administración de Proyectos, del Capítulo 1 Explorando la Administración de Proyectos. Este primer video se titula Definición de Proyecto:

     

    Algunas publicaciones recomendables para saber más:

    No Comment
  • The Agile Team / El Equipo Agile

    El Enfoque del Equipo Agile

    Antes de continuar

    Si usted no conoce las cuatro Declaraciones de Valor Agile, lo invito a que antes de continuar le eche un vistazo a la entrada El Origen Y Los Valores De Agile, si ya lo hizo o bien ya conoce estos valores, ahora puede enfocar su atención en como es el enfoque del equipo Agile en la práctica. Las cuatro Declaraciones de Valor Agile juntas suman un proceso altamente iterativo e incremental y entregan código probado al final de cada iteración. Los siguientes puntos cubren en lo general la manera en que un equipo Agile lleva un proyecto:

    • Trabaja en unidad
    • Trabaja en iteraciones cortas
    • Libera algo en cada iteración
    • Se enfoca en las prioridades de negocio
    • Inspecciona y se adapta

    El equipo Agile trabaja en unidad

    Desafortunadamente es común ver que analistas de negocios y de sistemas arrojan procesos o requerimientos a diseñadores y programadores cual pelota sobre la barda y sin más continúan con su vida, también hay diseñadores y arquitectos que elaboran sus atractivos diseños sin la más mínima consulta a sus compañeros programadores, o bien programadores talentosos que terminan la parte del sistema que les toca y acto seguido se sacuden las manos y desaparecen; y así podemos seguir con historias tristes. Un equipo Agile exitoso debe tener una mentalidad de “todos estamos en esto juntos”.

    Me gusta mucho usar analogías de juegos online, porque son una gran manera de ilustrar lo que sucede en la vida real. Muchos juegos en línea se juegan en equipo, donde cada miembro de dicho equipo tiene un rol. En esos equipos de jugadores existen roles como el healer que cura a sus compañeros, el tank que recibe golpes haciendo de escudo para que el resto ataque más eficientemente, los DPS que se encargan de hacer daño al enemigo y la clase especial que hace algun tipo de daño. Cuando algún jugador no cumple con su rol pone al resto del equipo en desventaja considerable, a veces esto quiebra al resto del equipo por completo. ¡Todos deben trabajar como uno!

    Así como sucede en estos juegos los equipo ágiles también tienen roles, y vale la pena identificarlos de manera general:

    Product Owner

    Las responsabilidades principales del product owner incluyen el asegurarse de que todo el equipo comparte la misma visión para el proyecto, estableciendo prioridades de manera que las funcionalidades que aportan mayor valor al negocio sean siempre en las que se trabaja. Tomar decisiones que lleven al mejor retorno de inversión del proyecto y la satisfacción de usuarios finales es la máxima prioridad.

    El cliente

    El cliente es la persona que tomó la decisión de financiar el proyecto, usualmente representa a un grupo o división. En estos casos es común que este rol se combine con el de product owner. En otros proyectos puede ser que el cliente sea un usuario.

    Desarrollador

    En el contexto de equipos agile un desarrollador se usa en un contexto amplio, esto es que un desarrollador puede ser un programador, un diseñador gráfico, un ingeniero de base de datos, expertos en experiencia de usuario, arquitectos, etc.

    Project manager

    Hay que tomar esto con algo de cuidado, porque un agile project manager se enfoca más en el liderazgo que en el management o (gestión tradicional del proyecto). En algunos proyectos y marcos de trabajo ágiles la persona encargada de este rol comparte las responsabilidades de un project manager tradicional con otros roles como el de product owner. También puede hacerse cargo de asesorar en la adopción y comprensión del enfoque agile. En proyectos muy pequeños puede incluso tener un rol como desarrollador, pero esta práctica no recomendable.

    Un equipo Agile trabaja en iteraciones cortas

    Ya lo mencionaba anteriormente, en proyectos ágiles no hay una delineación de fases demasiado marcada. No hay un establecimiento exhaustivo de requerimientos al comienzo del proyecto seguido de un análisis, no hay fase de diseño de arquitectura para todo el proyecto. Una vez que el proyecto inicia de verdad, todo el trabajo (análisis, diseño codificación, testing, etc.) ocurre junto dentro de una iteración.

    Las iteraciones se hacen dentro de espacio de tiempo delimitado previamente (timeboxed). Esto significa que cada iteración se termina en el tiempo acordado sin excusas, incluso aunque las funcionalidades previstas no se terminen. Las iteraciones son a menudo muy cortas. La mayoría de los equipos ágiles utilizan iteraciones de entre una semana y cuatro semanas.

    Un equipo Agile libera algo en cada iteración

    Algo crucial en cada iteración es que dentro de su espacio de tiempo uno o más requerimientos se transformen en software codificado, probado y potencialmente empaquetable. En la realidad esto no significa que algo se les entregue a los usuarios finales, pero se debe estar en posibilidades de hacerlo. Las iteraciones una a una van sumando la construcción de solo algunas funcionalidades, de esta manera se va obteniendo un desarrollo incremental al ir de una iteración a la siguiente.

    Debido a que una sola iteración usualmente no provee tiempo suficiente para desarrollar todas las funcionalidades que el cliente desea, se creó el concepto de release. Un release comprende una o más (casi siempre más) iteraciones. Los releases pueden ocurrir en una gran variedad de intervalos, pero es común que los releases duren entre 2 y 6 meses. Al terminar un release a este le puede seguir otro release y a su vez a este le puede seguir otro, así hasta terminar el proyecto.

    Un equipo Agile se enfoca en las prioridades del negocio

    Los equipos ágiles demuestran un compromiso con las prioridades comerciales de dos maneras. Primero, entregan funcionalidades en el orden especificado por el product owner, de quien se espera priorice y combine características en un release que optimiza el retorno de inversión de la organización en el proyecto. Para lograr esto, se crea un plan para el release basado en las capacidades del equipo y en una lista priorizada de las nuevas funcionalidades deseadas. Para que el product owner tenga mayor flexibilidad en la priorización, las características deben ser escritas minimizando las dependencias técnicas entre ellas.

    En segundo lugar, los equipos ágiles se centran en completar y entregar funcionalidades valoradas por el usuario en lugar de completar tareas aisladas.

    Un equipo Agile inspecciona y adapta

    Siempre es bueno crear un plan, pero el plan creado al inicio no garantiza lo que ocurrirá en el futuro. De hecho un plan es solo una suposición en un punto del tiempo. Si usted vive perseguido por la Ley de Murphy como yo 😀, habrá muchas cosas que conspirarán contra el plan. El personal del proyecto puede ir o venir, las tecnologías funcionarán mejor o peor de lo esperado, los usuarios cambiarán de opinión, los competidores pueden obligarnos a responder de manera diferente o más rápida, y así sucesivamente. Los equipos ágiles ven que cada cambio representa tanto una oportunidad como la necesidad de actualizar el plan para mejorar y reflejar la realidad de la situación actual.

    Al comienzo de cada nueva iteración, un equipo agile incorpora todo el nuevo conocimiento obtenido en la iteración anterior y se adapta en consecuencia. Si un equipo aprendió algo que probablemente afecte la precisión o el valor del plan, hay que actualizar el plan. Esto es, que quizá el quipo descubrió que han sobreestimado o subestimado su capacidad de progreso (capacity) y que un cierto tipo de trabajo consume más tiempo del que se pensó anteriormente.

    De la misma forma el plan se puede ver afectado por el conocimiento que el product owner ha ganado de los usuarios. Quizá por la retroalimentación obtenida de una iteración previa el product owner ha aprendido que los usuarios quieren ver más de algún tipo de funcionalidad y ya no valoran tanto otra que havían considerado. Este tipo de situaciones pueden alterar el plan, de manera que hay que adaptar el mismo para mejorar su valor.

    Enlaces relacionados:

    Roles on Agile Teams: From Small to Large Teams
    El Origen Y Los Valores De Agile
    What Is Agile?
    Planeación, Cono de Incertidumbre y Estimaciones en IT

    Estos son alguno libros recomendables para saber más:

    ¡Caulquier ayuda en bienvenida para mantener este esfuerzo vivo! PayPal Account BTC (Bech32): bc1qx6f8nczr5ram6d57svlnsfmk5mhu6lsr9q7mxw BTC: 1DDcWbphm1bKMvWruotNKLSM8ypVaHg5Nv ETH: 0x58D137fb142D946bCD815f0ded0fa3b3fE5AB3BF

    No Comment
  • Scrum Master Certification / Certificación Scrum Master

    What Scrum Master Certification to Choose?

     Scrum Master Certification / Certificación Scrum Master

    About This Post

    Some years ago I get interested in Agile software development and I have been using the Scrum product development framework in several projects, but eventually, I decided to formalize this knowledge starting with a Scrum Master certification. When I talked about this with some friends and acquaintances I was surprised when a lot of them started to ask me about it with many doubts and confusions.

    To try to shed some light, I will get into a heated territory within the Scrum community, sharing my experience while and I will try to answer several of the first questions that come to mind when you’re interested in a Scrum certification. It should be noted that nobody is paying me for my opinion (I wish….).

    Why get a Scrum Master certification?

    I was a developer who finds himself involved with Agile and Scrum some years ago (more by emergency than by good judgment) in order to finish projects near of collapse. Little by little and still with many setbacks but also proposing good practices to the management and in an active role, the teams which I was part of, successfully managed to get out of several quagmires, but the truth is that I never felt the need to obtain any formal validation for that knowledge. Eventually, fate, time and several fellow developers pushed me to take a more active role on the project management side, but I found that several clients and employers were asking me for certified Skills in Scrum and/or Project Management (foolish!).

    Around 2013, while I was looking for a new job, I began to notice that more and more vacancies, for project managers and even developers, required Scrum knowledge. Considering that many times in the past managers, directors and even project managers asked me what was that Scrum thing, I noticed that things were changing in a remarkable way.

    So, the message was clear. If I wanted to have a better chance of finding interesting (and reasonably paid) jobs, I had to certify my knowledge. But that was the easy part; I spent a good amount of time researching what my options were. In the rest of this post, I condensed what I learned about Scrum certifications under the Scrum Master role.

    Scrum Master Certifications

    The first thing is to clarify that there are several organizations offering Scrum Master certifications, the best known are:

    This post only addresses these four certifications, but there are others that probably you want to consider:

    • PMI_ACP. Project Management Institute Agile Certified Practitioner is offered by the Project Management Institute.
    • ICAgile Certifications. Certifications offered by the International Consortium for Agile.

    *Please note that all figures presented are valid as of the date of publication of this entry and may change without prior notice.

    Certified Scrum Master (CSM) from Scrum Alliance

    certified scrum master

    This is the most known and long-lived certification of all. The Scrum Alliance was founded by one of the two creators of Scrum, Ken Schwaber along with other heavyweights of Agile and Scrum world such as Esther Derby and Mike Cohn.

    However, today there are some criticisms for this certification because although it is the most widely recognized certification, it’s open knowledge that all certifications issued before 2012 did not require any evaluation, being the only requirement to attend an official course of the Scrum Alliance. In response, the Scrum Alliance has changed the Certified Scrum Master (CSM) certification process to the following mandatory steps:

    1. Familiarize yourself with the basic concepts of Scrum.
    2. Attend the official CSM course.
    3. Obtain the certificate that verifies the completion of the CSM course and passes the CSM evaluation with a minimum score of 69% (still considered a low percentage by some practitioners).

    The courses can only be taught by the Certified Scrum Trainers, but as the courses are not approved, it seems that the quality of each course depends on the skills, experience, and materials that each instructor can offer independently.

    The course cost includes the evaluation, can change from region to region, but ranges are between *$850 USD and *$1,300 USD. To maintain valid CSM certification, it must be renewed every two years at a cost of *$100 USD but the Scrum Alliance also introduced the Scrum Education Units, which can be used to renew its certifications. In the same vein, for those holding PMI certifications, these courses also provide PDUs.

    Update 2018: The Scrum Alliance integrated new certifications to its offer, including one more as Scrum Master. Following a similar strategy to Scrum.org a certification called Advanced Certified ScrumMaster (A-CSM) have been added, which has as requirements:

    1. Attend to a required A-CSM course.
    2. Successfully complete the previous or later work to the course that the instructor may consider necessary in order to meet the learning goals.
    3. Validate at least one year of work experience specific to the role of ScrumMaster (within the past five years). This point is important because at least 12 months must be logged since you got your CSM certification before you can try for A-CSM.
    4. Hold an active Certified ScrumMaster (CSM) certification with the Scrum Alliance.

    The cost of the course and the right to A-CSM exam also can vary depending on the region but according to our investigation, this is about $2500 USD.

    Professional Scrum Master (PSM) from Scrum.org

    The Scrum Alliance and Ken Schwaber had a separation in 2009 and this led to the latter founding of a new organization called Scrum.org, which offers courses and certifications for PSM among others. After the Scrum Alliance certification, this is the most widespread Scrum Master certification, gaining more and more recognition in the industry. Something different in Scrum.org is they don’t offer just a single certification, you can get three different levels of Scrum Master certification from them, this is the PSM I, PSM II and PSM III.

    It’s important to mention that today a large part of the Scrum community address to these certifications as the most difficult to obtain, because PSM I, PSM II and PSM III require evaluations with minimum scores of 85% and since they include questions of high difficulty, being required to get the PSM I to be able to obtain the PSM II, and these two before being able to try the PSM III test. Several sources reported that there is a relatively high amount of people who, even with experience in Scrum or other certifications, fail these assessments.

    In spite of how intimidating this may sound, an encouraging point is that none of these evaluations require the applicant to attend a course, so in theory, these certifications can be achieved with the appropriate time for study, revision and/or experience, in addition, these certifications do not need to be renewed.

    The cost for the PSM I evaluation is *$150 USD, for the PSM II it’s *$250 USD and for the PSM III it’s *$500 USD, with the right to one single attempt.

    The optional Professional Scrum Master course offered by Scrum.org can only be taught by the Professional Scrum Trainers, who have approved materials. The costs of the courses seem to go between *$1295 and *$1995 USD.

    As with the Scrum Alliance courses, PMI certification holders can obtain PDUs for the PSM courses.

    PSM I Exam Simulator: In order to help those who want this certification, in internet80 we have undertaken the task of developing a simulator of this test completely free. The simulator is in the testing phase but is now available to everyone. Evaluate your knowledge about the Scrum framework now here: PSM I Exam Simulator 1

    Scrum Master Certified (SMC) from SCRUMstudy

    This is the most controversial certification of those mentioned in this post and within the Scrum community, So far I don’t know who is/are exactly the founders of this organization, but they have the credit of having created a free book in its digital version, called the SBOK Guide or Scrum Body of Knowledge whose main author is Tridibesh Satpathy. This organization offers SCM certification.

    The SCM certification bases its assessment on the SBOK Guide, which has a process approach (similar to the PMI’s PMBOK), and another concepts called principles and aspects, that is, everything is in the context of the interpretation made by the authors about Scrum in the SBOK Guide, which has caused this organization to have serious differences with many practitioners and founders of Scrum who even took part in the creation of the Agile manifesto and therefore with a large part of the Scrum community; although on the other hand, it has achieved a certain amount of acceptance from the industry.

    One point against this certification, which may be eventually important for some people, is that the most popular Scrum scaling frameworks such as SAFe, LeSS or Nexus are based on the Scrum Guide and do not recognize SBOK. This may be important since being SAFe the most influential scaling framework so far, and if you want to obtain a certification as  SAFe Advanced Scrum Master, the Scaled Agile organization does NOT consider relevant the SCRUMstudy certification.

    Update 2017:  The Scaled Agile Framework organization who provides SAFe, now offers its own Scrum Master certification, called SAFe Scrum Master (SSM), don’t get confused with SAFe Advanced Scrum Master certification, this one puts a pre-prerequisite neither CSM nor PSM anymore, but put them as highly suggested in order to take its certification course.

    The minimum score in their respective evaluation to obtain this certification is of *95%, although in my research I have obtained testimonies and mixed comments on their difficulty, they do not have prerequisites although their SBOK must be strongly studied since apparently the exam attacks only the perspective of this guide.

    The cost of the test is *$450 USD with *3 attempts and requires *40 re-certification units every *3 years (these units are obtained by different activities).

    According to my research, the SMC course content is approved and can only be provided by the SCRUMstudy Certified Trainers whose are based mostly on the SBOK guide, the costs are around *$450 USD, but costs can change between regions and partners. The testimonials I got were quite mixed, I got good comments about the courses materials offered but one thing I was told several times is that when the trainers face questions and/or scenarios outside the context of the SBOK Guide, these instructors really struggle a lot to solve doubts from the “real world”. SCRUMstudy has several partners to offer their courses.

    PDUs are also offered if you take the SMC course.

    Update 2018:  SCRUMstudy has followed the strategy that Scrum.org started and also Scrum Alliance followed. Now, this organization offers an advanced Scrum Master certification which is called Expert Scrum Master Certified (ESMC), and its requirements are:

    1. Having three years of experience in Scrum / Agile project management.
    2. Hold the certifications SMC, SAMC y SPOC.
    3. Submit 500 words write up about two Scrum / Agile projects.
    4. The official web page also indicates that you can attend to a 2-days ESMC face to face training, of course, provided by SCRUMstudy, however, doesn’t clearly indicate whether this is mandatory, substitute or facilitates any of the previous requirements.

    The cost of the exam to obtain this certification at the time of this publication is $800 USD which may vary depending on the region. You will also have to obtain 60 RCUs every 3 years to maintain this certification.

    SAFe Scrum Master

    I added this certification this year (2018) because this emerged in late 2016 (months after this post), don’t get confused with the SAFe Advanced Scrum Master certification. SAFe focuses on large organizations Agile model implementation and today is the most popular escalation framework, but it’s not the only one (there are others such as Nexus, LeSS, DaD, and others). But let’s take it one step at a time because I’ve discovered out that this certification has aroused some confusion.

    Previously the Scaled Agile Framework only offered the SAFe Advanced Scrum Master which is totally dedicated to this Scrum scaling framework approach, and within its prerequisites, it was required to have either CSM or PSM certifications.

    Now offers its own “basic” certification which uses the Scrum Guide approach but also introduces its SAFe escalation framework approach early on, this is the SAFe Scrum Master certification. The prerequisites for this certification are knowing the agile approach and knowing the Scrum, Kanban and XP frameworks, and at the same time having first-hand experience in the software and hardware development process, and of course to take obligatorily the SAFe Scrum Master course.

    According to the testimonies I’ve got, the contents of this course are homologated and are abundant, I didn’t find anything about the instructor’s qualifications who teach the courses, but apparently, both the instructors and the exam are totally oriented to the content provided during it. The first attempt for this certification test is included in the course cost (which varies between countries and regions), each additional attempt costs *$50 USD, it is a web-based test (is not clear for me if you can take the this from anywhere), to approve requires between *33 and 45 correct answers (73% of accuracy).

    Something good is that just about three years ago you had to travel to the United States to take some of the SAFe courses and exams, but now these are available in several countries on all continents, which speaks of the popularity of this scaling model. Keep in mind that if you get this certification you must renew it *every year at a cost of $100 USD (which is a short-term compared with rest of the certifications).

    This course offers PDUs for PMI certification holders and SEUs for those with some Scrum Alliance certifications.

    Resumen

    1. The Certified Scrum Master (CSM) certification is more widely known than the Professional Scrum Master (PSM) and the Scrum Master Certified (SMC).
    2. The training costs for PSM are (on average) higher than CSM and SMC training courses and are not available in all countries. The costs of CSM are usually higher than SMC.
    3. The costs of acquiring and maintaining CSM certification are higher than those for SMC and PSM, the latter being the cheapest since no payment is required to maintain the certification.
    4. The value of CSM certification is very questioned especially if it was issued before 2012 (it was granted without evaluation).
    5. The materials and the quality of the courses for CSM can vary greatly since they are not approved.
    6. The materials provided for PSM and SMC in their training are approved (and according to several testimonies are usually good).
    7. The SMC certification is based on the practices described in the SBOK and not necessarily as described in the Scrum Guide (text by the creators of Scrum).
    8. The value of the SMC certification is questioned by many important members and organizations in the Scrum community.
    9. The most important scaling framework at the moment (SAFe) strongly suggests holding either the SAFe Scrum Master (SSM), Certified Scrum Master (CSM) or Professional Scrum Master (PSM) certifications in order to obtain several of its certifications including the SAFe Advanced Scrum Master (SASM).
    10. SAFe offers the SAFe Scrum Master (SSM) certification which is oriented to Scrum scaling in large organizations but is not the only escalation model and not every organization have or plan to use this approach.
    11. The SAFe Scrum Master (SSM) certification must be renewed every year for a cost, which is short-term compared with the rest of the certification.

    * Correct figures at the time of publication. They can change without notice.

    Sorry about my English I’m not a natural speaker (don’t be grumpy, help me to improve 🙂 ).

    Related Links:

    PSM I FREE Exam Simulator 1
    Agile’s origins and values

    Some book that can be interesting for you:

    14 Comments
  • Agile Value / Valores de Agile

    El Origen Y Los Valores De Agile

    Agile Value / Valores de Agile

    Vientos de Cambio

    Mucho se oye de Agile, de Agile project management o de la “Agile methodology” como algo propio del siglo XXI, pero en realidad el origen y los valores Agile comezaron a gestarse un poco antes. Los 90s fueron una década muy interesante, MTV tuvo su mejor momento, la música Grunge invadió la radio y la Internet llegó a la vida de las masas. Junto con todo el boom de Internet la manera de hacer software cambió por completo, las empresas comenzaron a aprender cómo hacer software a gran escala y para usuarios interconectados en todo el mundo, lo que trajo nuevas exigencias. En la búsqueda del éxito muchas de esas compañías comenzaron a importar las “buenas prácticas” de otras industrias esperando buenos resultados, los cuales al final fueron mixtos en muchos casos (vea Waterfall Model).

    Muchos sistemas electromecánicos ya comenzaban a ser sustituidos por electrónica, y un tiempo después el software comenzó a tener cada vez más relevancia, pero el desarrollo y la interacción de estos elementos se vieron atrapados por modelos predictivos que intentaban saber todos elementos involucrados en un sistema de antemano, lo cual resultaba (y aún resulta) muy difícil de establecer al comienzo de un proyecto de software con altos niveles de incertidumbre, lo que causa desde entonces periodos de tiempo de desarrollo muy largos con fechas de término difíciles de predecir. Esta situación llevó a la frustración a muchos líderes, quienes a pesar de la situación fueron creando y adaptando sus propias técnicas, métodos y marcos de trabajo a los modelos tradicionalistas de desarrollo, lo que eventualmente dio pie a los primeros guiños del pensamiento Agile.

    Nace Agile

    Después de varias reuniones previas, en Febrero del 2001 un grupo de profesionales tuvieron una nueva y ahora famosa reunión cuyo mayor aporte fue el Manifiesto Agile (The Agile Manifesto). Este manifiesto fue escrito y firmado por diecisiete líderes del desarrollo de software (hoy conocidos como la Comunidad Agile). Su documento dio un nombre a cómo este grupo estaba desarrollando software y proporcionó una lista de declaraciones de valor Agile:

    • Individuos e interacciones sobre procesos y herramientas
    • Software trabajando sobre documentación completa
    • Colaboración del cliente sobre la negociación del contrato
    • Responder al cambio sobre seguir un plan
    Y el grupo añadió:
    Esto es, mientras que hay valor en los elementos en la derecha, valoramos más los elementos de la izquierda.

    Puede ver la historia y el manifiesto original en agilemanifesto.org

    En particular, estos líderes de opinión buscaron formas de construir rápidamente un software en funcionamiento y ponerlo en manos de los usuarios finales. Este enfoque de entrega rápida proporcionó un par de beneficios importantes. Primero, permitió a los usuarios obtener algunos de los beneficios comerciales del nuevo software más rápido. En segundo lugar, permitió que el equipo de software obtuviera retroalimentación rápida sobre el alcance y la dirección de los proyectos de software de forma periódica. En otros palabras el enfoque Agile había nacido.

    Detrás de las Declaraciones de Valor Agile.

    Ya conoce la lista de declaraciones de valor, pero veamos cuales son las razones detrás de ellas:

    Valorar las personas y las interacciones sobre los procesos y herramientas. Los que tenemos un camino en recorrido en el mundo de desarrollo sabemos que un equipo con grandiosas personas funciona bien aun utilizando mediocres herramientas y que estos equipos siempre superan a otros equipos disfuncionales con personas mediocres que tienen excelentes herramientas y procesos. Si se trata a las personas como piezas desechables no habrá proceso, herramienta o metodología que salve a sus proyectos de fallar. Los buenos procesos de desarrollo reconocen las fortalezas (y debilidades) de los individuos y sacan provecho de ello en lugar de intentar que todos sean homogéneos.

    Valorar el software que funciona sobre la documentación completa. Porque nos lleva a tener versiones incrementalmente mejoradas del producto al final de cada iteración. Esto hace posible recolectar temprana y frecuentemente algo de retroalimentación sobre el producto y el proceso nos permite saber si deberemos corregir el rumbo, hacer ajustes o seguir adelante con la misma visión. A medida que el software desarrollado crece con cada iteración, se puede mostrar a los usuarios probables o reales. Todo esto facilita la relación con los clientes y mejora las probabilidades de éxito.

    Valorar la colaboración con el cliente sobre la negociación de contratos. Porque para crear equipos ágiles debemos buscar que todas las partes involucradas en el proyecto trabajen para lograr el mismo conjunto de metas. La negociación de contratos a veces pone en conflicto al equipo de desarrollo y al cliente desde el principio. Creo que los juegos multiplayer online battle arena son un gran ejemplo, personalmente me gustan juegos como Heroes of the Storm o League of Legends. Estos son juegos cooperativos donde se forma un equipo de 5 miembros, el objetivo es que el equipo debe destruir la base del enemigo trabajando juntos. Todos los jugadores ganan, o todos los jugadores pierden. Estos juegos son sorprendentemente divertidos, y lo que nos gustaría es que los equipos de desarrollo de software y los clientes se acercaran con esta misma actitud de colaboración y objetivos compartidos. Sí, los contratos a menudo son necesarios, pero los términos y detalles en un contrato puede ejercer una gran influencia sobre las diferentes partes involucradas, y convertir un ambiente colaborativo a uno competitivo.

    Valorar responder a los cambios sobre seguir un plan. Porque el objetivo principal es aportar la mayor cantidad de valor posible al cliente del proyecto y usuarios. En proyectos grandes y/o complejos, encontrará que es muy difícil incluso para los usuarios y/o clientes, conocer cada detalle de cada característica que desean. Es inevitable que los usuarios vengan con nuevas ideas, o bien que decidan que algunas características críticas inicialmente ya no lo son tanto. Para un equipo ágil, un el plan es una visión del futuro, pero muchos puntos de vista son posibles y los factores ambientales pueden cambiar con el tiempo. A medida que un equipo gana conocimiento y experiencia sobre un proyecto, el plan debe ser actualizado de acuerdo a ello.

    Con las cuatro declaraciones de valores del Manifiesto Ágil en mente creo que puede comenzar a comprender que significa tener un enfoque ágil para estimar y planificar.

    Enlaces relacionados:

    To agility and beyond: The history—and legacy—of agile development
    What Is Agile?
    Planeación, Cono de Incertidumbre y Estimaciones en IT

    Estos son alguno libros recomendables para saber más:

    No Comment