See this post in the new link.
See this post in the new link.
It’s quite common to find people who used to have technical positions earlier in their careers and then moved to management positions. There is nothing wrong with that career path but in some cases, those professionals forget to keep up with the technology evolution and end up missing great opportunities in their careers.
Consider, for instance, a Java developer who started her career 10 years ago. After 4 years she was promoted to manager and hasn’t been involved with Java coding for the last 6 years. You can (safely) assume her Java skills are so outdated that she’s not able to do a code review or design a microservice with Sprint Boot anymore. Fair enough, but when will a manager have to do that?
In a fast-paced industry with new frameworks popping up pretty much every month, the amount of content been produced is at the same time astonishing and impossible to keep up. So, if a manager can’t keep up with the speed technologies evolve, why should she even bother to try? Shouldn’t she just rely on her technical colleagues?
Inefficient communication is one of the main causes of project failures
Credibility is key and a solid background can enable that
Communication issues are usually among the top 5 reasons for project failure or challenging execution. Different elements contribute to inefficient communication, but establishing a common language is crucial for both the sender and the receiver to be on the same page about the topic being discussed.
A manager with technical skills can leverage the appropriate terms when talking to her development team to reduce miscommunication issues. Moreover, people usually get more engaged and receptive when they recognize the other ones have a similar level of understanding about the topic. Have you seen developers rolling their eyes when somebody tries to show off his technical skills and end up stumbling over?
Besides, having technical knowledge helps managers when elicitating requirements, troubleshooting issues, handling critical incidents, bridging the communication between developers and executives, and managing project dependencies. Finally, credibility is key and a solid background can enable that.
Projects are getting more and more complex and specialized
Try to think about Software Development projects you were involved about 10-15 years ago. If you were not a kid at that time, you might have remembered some sort of distributed application consuming a data source (most likely a relational database) and providing results to the user in a somewhat simplistic interface. Now let’s get back to today’s reality.
When you look at the current scenario, it’s hard not to think about integrated solutions that demand data analysis/processing, artificial intelligence, consume difference services, and provide multiple different UIs. Basic client-server DB applications have become commodities and no company can endure unless they embrace very specialized and deep knowledge from areas like machine learning, augmented/virtual reality, data processing, continuous delivery, and statistical analysis.
As a manager you’d be required to know at least at a high level:
- What those technologies are used for;
- How they can be incorporated in the business to generate more revenue;
- How to get started with them;
- Which alternative approaches exist and their pros/cons.
To get at that level you could 1) read the basics about the technologies, 2) join and actively listen to design sessions, and 3) have fun coding in your ‘spare’ time.
Influential people know their sources
Power is the ability to influence others and it can be identified in 5 forms:
- Formal: when you’re empowered to take decisions;
- Reward: when people realize that you’re responsible for rewarding them by deciding salaries, promotions, bonuses, and so on;
- Penalty: when people perceive you can penalize them if they don’t follow your directions;
- Expert: when people perceive you possess important functional knowledge;
- Referent: when people enjoy working with you or in the project you manage.
Formal and Reward types have to be granted and do not depend solely on the manager. Penalty may be effective, but it usually activates the sympathetic system which brings more stress to the relationship. Referent demands time and development of soft-skills which are quite hard to change. Expert power can be your best ally to enhance your ability to influence and lead your team.
Major tech companies look for Technical Managers
Understanding the market demand and how high-performing companies (like FAANG) structure themselves can give you a few hints about the kind of professionals that companies are looking for. If you follow these companies’ news or know people who work for them, you know that they have different flavors of technical management positions:
- Technical Program Manager
- Technical Engineering Manager
- Technical Project Manager
That model is already being used as a reference by other companies. So, career-wise, deepening your tech expertise can help better positioning yourself for high-demanding positions.
Putting the hours to learn technologies, even when you won’t immediately apply them, will pay off in the short to medium-term. Your team is more likely to value your opinion and feel like you’re one of them. Tech skills can be your competitive advantage if you enjoy getting your hands dirty, but as Uncle Ben says ‘with great power comes great responsibility’ 😉 . There are a few pitfalls that you need to avoid not to backfire your plan, but that’s a subject for another post.
Regardless of your position and company, you’re quite often requested to provide estimates for the work you need to do. Providing an accurate estimate is definitely a tough task but there are ways to improve your chances to get closer to the actual time spent to develop the work.
For time estimation, we can categorize the estimation techniques in two groups: absolute and relative. Absolute estimation is the more traditional way where you provide a quantified value according to a specific unit, for instance, 16 hours, 2 days, a week. Relative estimation turned out to be quite common too and focus on comparing the sizes of two or more tasks by abstracting the unit itself. Story points and T-shirt sizes are usual examples of relative estimation approaches. In this post, we’ll be focusing more on absolute estimates. Relative ones will be covered in a future post.
Regardless of the estimation approach you decide to follow, there are a few common mistakes you should try to avoid:
- Provide estimate without knowing the scope: Usually, people are pushed to provide estimates without understanding what they are supposed to do. If you’re estimating stories or tasks, make sure you’re able, based on the acceptance criteria and/or description, start developing that piece of work right away. If you cannot do that, ask for more explanation, discuss more with the PO or with the team.
- Be the only person weighing in on an estimate: If the estimate process takes into account the opinion exclusively of the assignee, it’s likely that few factors will not be considered in the estimate. Challenging someone’s estimate is simple and effective to make sure that different variables were analyzed when providing the ‘magical’ number.
- Be restrict to the coding effort: Developers will probably take into account only the time to write the code and build it. If you ask a QA analyst for an estimate, they will probably consider only the time to start validating and provide test results. None of them are to be blamed. They are just reacting to the environment and the kind of activities they are expected to perform. Unless you have an explicit list of expected checks/activities to be performed, usually referred as Definition of Done (DoD), your team will not have a consistent and common understanding about what’s provided when something is marked as Done.
- Be afraid of saying ‘I don’t know’: Saying ‘no’ or ‘I don’t know’ is usually seen as a sign of weakness or lack of experience. If your team is saying that, you’re blessed! Don’t judge them! Realize that’s an indication that they are being honest and that additional work may need to be done before an estimate can be provided. In those scenarios, you could 1) have more discussion to try to clarify the work or 2) create spikes (or Proof of Concept – PoC) stories/tasks to build the knowledge and reduce the risks of unrealistic estimates.
Without taking sides (absolute vs. relative), there are ways to improve your chances to come up with a realistic (or at least kind of). See below two techniques used for absolute time estimates:
- PERT (stands for Program Evaluation and Review Technique): Instead of providing one single value and stick to it, PERT requires the estimator to provide three values considering three different scenarios: pessimistic, most likely and optimistic. Those three values are included in a weighted average assuming weight = 4 for the most likely estimate. Optimistic estimates can, for instance, consider that some dependencies will be provided right away, while pessimistic ones can assume some risks will become true and will inflate the work to be done. The PERT formula is as follows: P = (O + 4*M + P) / 6. Adding one or two standard deviations can give you an extra cushion for unknowns. More details about how to calculate the standard deviation you can find here. By using PERT, you’re explicitly thinking about other scenarios and that exercise will help you to improve your estimates.
- Analogous estimation: This technique relies on estimates of past similar tasks to size a piece of work. Historical information is used and the differences between the past and current work are discussed with the team to come up with the estimate. Even though this can a useful technique, there are two aspects to keep in mind:
- Software development tasks are hard to be similar: While engineering activities (like building or painting a wall) can be quite similar from project to project, software tasks can look similar but may end up being quite different depending on the environment and the assignee.
- The time required to find a similar task: Depending on the amount of historical information, finding a similar task can lead to a waste of time. If using analogous estimation will slow down considerably your process, it’s an indication that it may not be a good fit. Remember that unconsciously everybody will end up using their previous experiences to estimate the work.
An elementary mistake is to consider effort = duration. If you estimate the effort in days and use that as the task duration, you’re unrealistically assuming 100% of allocation with no room for attending meetings, resting, reading e-mails and so on. A decent strategy (even though it requires more management work) is to consider a percentage (you could start with 75%, for instance) and tweak it for each team member depending on the average actual hours worked. That percentage will be tightly coupled with the environment and the internal processes of the company. The leaner and the more agile your company is, the higher that percentage will be.
In the next post, we’ll cover relative estimating and the different techniques to improve it.
If you have adopted Scrum for some time, you have probably worked in a team that has pushed back to have Daily Scrums or that haven’t seen much value in doing so. There are few common reasons that could lead to that situation:
- The team sees the Daily Scrum as a daily report to the Scrum Master or another member who attends the meeting
- The level of details is not properly set (too many details or too superficial and generic comments)
- The team believes they already talk during the day and don’t see a reason to have a formal event for that
- and many other reasons…
Those issues can be managed individually by showing the actual value of that Scrum ceremony. However, even if they bought in the idea, how do you know if your meeting is being effective? How do you know that you’re getting practical value from that theory?
Being effective is all about meeting its goals and IMHO the goals of a Daily Scrum should be:
- Setting (or adjusting) direction
- Understanding how the team is doing to meet the Sprint goals
- Understand where we want to be when we meet again
When attending the last TriAgile event, there were sessions and discussions about how to make Daily Scrums more effective. An interesting outcome from that day was the idea of slightly changing the 3 Daily Scrum questions to focus more on what can get done until the team meets again. According to the Scrum Guide, these are the 3 Daily Scrum questions:
- What did I do yesterday that helped the Development Team meet the Sprint Goal?
- What will I do today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Although these questions help on understanding what was done and what is planned to be done, it does not set short-term (1 day) commitments for each member to pursue and to get things done. You can easily say what you’ll do until tomorrow and have nothing actually done by tomorrow. What if instead of saying what you will work on you said what you’ll get done by tomorrow? It’s not about sharing what you’ll do. It’s about sharing which small increment of value you’ll be completing until the next meeting. With something simple like that you can change the perception of Daily Scrums from ‘reporting/planning’ to ‘achieving’. That will also force your team to have smaller tasks that can be done in a day or so.
Having said that, see below the suggested questions to make your Daily Scrum more effective:
- What did I say yesterday I would get done to help Development Team meet the Sprint Goal?
- What will I get done today to help the Development Team meet the Sprint Goal?
- Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?
Give it a try and share your experience!
It’s been 7 years since I had my first experience with Rails. Back in 2009 the version was 2.3.x (I’d guess 2.3.5, but not sure) and managing gems during that time was such a pain. Since then we got many different versions with features, bug fixes, security and performance improvements (yes, per-for-mance, if you’re still one of those skeptical haters that think Rails can’t perform/scale).
Last June 30 version 5.0 was released and it has few interesting features.
- Action Cable: A brand new framework for WebSockets. If you need to keep a connection open between a Web client and the server, that can be very handy. It’s definitely worth to take a look at.
- Puma: Instead of Webrick the development environment now comes with Puma.io server by default. Personally, I was never a big fan on Webrick. Making Puma the default server turns the development environment more professional and in case you need other devs accessing your env, it becomes less painful.
- Turbolinks 5: New version of Turbolinks. Great feature since developing mobile versions is a requirement for pretty much any app.
- API mode: This is the cherry on the cake, IMO. Creating a RESTful API skeleton has never been so straightforward. If you need only a backend app to respond some REST calls spitting JSON, that’s the way to go. By providing the –api parameter (rails new backend –api) you can create a basic backend app structure.
Give it a try and spend some time playing with it. Further sources can be found at the official page.
Feel free to download this JIRA Cheat sheet with the list of shortcuts as well as many available operators of JIRA Query Language (JQL) for advanced searches.
JIRA is definitely a flexible bug tracking tool and one of the most powerful features is workflow customization. This post describes how to add a label automatically when an issue is created. This can be useful when you want to flag an issue and later capture that in a filter or board. A practical example is to flag Bugs that are created so that they can be reviewed during Bug Scrub meetings. In order to add a label we need to add a custom script in a post-function.
- As admin, go to Administration >> Issues >> Workflows >> Click on Edit in the workflow you want to change
- Click on the ‘To Do’ step (assuming your workflow is the default one)
- Click on the ‘Create’ action >> Post Functions tab >> Add post function
- Select Script Post-Function >> Custom script post-function
- Paste the following code snippet replacing ‘BugScrub’ by the tag you want
- Publish the workflow => Important: If you don’t publish the draft workflow, no changes will be reflected.
import com.atlassian.jira.ComponentManager import com.atlassian.jira.issue.label.LabelManager import com.atlassian.jira.component.ComponentAccessor def user = ComponentAccessor.jiraAuthenticationContext.getLoggedInUser() LabelManager mgr = ComponentAccessor.getComponent(LabelManager.class) mgr.addLabel(user, issue.id, 'BugScrub', false)
For additional information about the addLabel method, please refer to the official documentation.
JIRA is one of the most used bug tracking system and one of its main features is the search mechanism. There are two modes when searching for issues on JIRA: Basic and Advanced. The basic one is composed of a set of filters you can select and define values. Even though the basic mode is enough for most cases, it does not allow you to run some more complex queries.
Today I’ll present the WAS operator that can be used by writing JQL queries in Advanced mode and that allows you to search for issues based on the property values in the past. This can be extremely useful if you want, for instance, to collect history data or to evaluate changes against to such a property.
This operator can only be used with the following properties: Assignee, Fix Version, Priority, Reporter, Resolution and Status fields only.
Find all bugs that were open last week
issuetype in (Bug, Defect) AND resolution WAS IN (Unresolved, EMPTY) before endOfWeek(-7d)
Find all stories that were resolved last week and that are now closed
issuetype = Story AND status WAS Resolved DURING (startOfWeek(-7d), endOfWeek(-7d)) AND status = Closed
Find all stories that were unassigned in the last two days
issuetype = Story AND assignee WAS EMPTY DURING (endOfDay(-2d), now()) AND assignee IS NOT EMPTY
I’d like to cover one topic that may be a little controversial among managers or agile practitioners: whether planning sprints in advance is acceptable or not in a Scrum project. Should I plan only the Sprint my team will start or should I plan future Sprints?
Being agile is about identifying and reacting to problems as soon as possible. The three pillars of a Scrum project emphasize how to do that by inspecting, adapting and being transparent during the Scrum events. However, there is no Scrum event to go beyond the planning of the current Sprint. This is why the most purist people don’t plan future Sprints.
Even though Scrum guide does not mention this, positive results may be realized when planning more Sprints in advance. These are some benefits of doing that:
- Anticipate problems that require immediate actions
- Increase likelihood of meeting external milestones (i.e. those that do not depend on or cannot be controlled by Scrum team)
- Identify need of hiring new people for the team
However, how can this be done without impacts (or with minimum impacts) in the current sprint, since team members should be focused on developing the scope of the Sprint?
Slightly change Backlog grooming sessions can be a good alternative. During grooming sessions the Scrum team and the Product Owner discuss about the Product Backlog with a clear goal: finish the meeting with an improved Backlog. The definition of “improved backlog” can vary from team to team, but usually attendees focus on detailing more the user stories and their acceptance criteria. However, these sessions can also be used to create sub-tasks, to estimate and to assign them.
With a Backlog with sub-tasks and their estimates, the Scrum Master can distribute Product Backlog items in the future sprints, based on the Product Owner prioritization. Having done that, it is possible to check if some milestones look feasible, if people are over-allocated, which may require hiring new people to meet some dates and features, and so on. In addition to this, having 1:1 meetings between the Scrum Master and each team member, once a Sprint for 30-60 minutes, to review estimations and assignments improve the accuracy of the Backlog. This would require an additional effort for the Scrum Master of about 8 hours / sprint, considering a 8-member team, as well as a total of 8 hours when summing up 1 hour of each member. This can be an important practice to mitigate risks.
Important: What is planned for future sprints is not a commitment. A Scrum team can only commit to a Sprint goal after the Sprint Planning.