Regardless of project management methodologies and how they handle change in requirements, the initial requirements, scope, backlog, budget, and time estimates would have to exist for a project’s commencement. Surprisingly, over 50% of projects miss their mark due to missing requirements not captured during the project’s initial scoping. The fundamental goal of requirements gathering is to explore, research, and document what success looks like for a given project. These requirements will eventually become a backlog of items representing the tasks needed for project completion without future changes. Such oversight can be problematic and have a disastrous effect on a project’s outcome. With the primary building blocks and assumptions lacking, the possibility of massive changes in order course correct will put a strain on deadlines and budgets. This article will outline different ways of approaching projects, requirements gathering techniques, and building a reliable project backlog for project planning, execution, and fulfillment, resulting in a solid foundation for a strong project start. 

How to approach a project:

Software development projects can fall into several categories, such as rewrites, system integrations, enhancement, and building a new greenfield, to name a few. Despite the variation, or how straight forward the objective is, “knowing is half the battle“; [a phrase popularized by the G.I. Joe cartoon in the 1980s].

Knowledge surrounding the problem that a stakeholder wants to solve, existing tools and applications in their ecosystem, business jargon, entities, end-users, and how they all fit into the big picture or domain adds tremendous value. This broad-based knowledge, commonly referred to as Domain knowledge, is applicable and attainable in your current industry or starting on a client project. Having such knowledge puts you and your team in a better position to grasp the end goal and build a better understanding of the problem while fostering ideas and discussions on how best to solve it. In his book Domain-Driven Design, Eric Evans states that “the heart of software is its ability to solve domain-related problems for its user.”  

There are several ways to build or improve domain knowledge, many of which are discussed in Eric Evans’ book. The most common is using diagrams as a means of communication, explanation, and brainstorming—the simpler the diagram, the better, as many people respond better to visual cues. Notably, there will always be some form of discovery and learning when a domain model is discussed and drawn out. Leveraging diagrams help establish system boundaries, their start, end, and all the associated entities within that context. Once those boundaries start to form, it will begin to clarify what aspects of the project are in or out of scope.  

Requirements gathering techniques:

Similar to starting a project, there are many ways to gather requirements. Starting with domain knowledge puts you on the right path to discovery, asking more questions about the system and the problem that it attempts to address. We can define requirements as the list of things in the application or project domain that we wish to be made valid by delivering the proposed system. 

We’ll use a bank’s automated teller machine (ATM) as the proposed system with a simple goal of allowing users to deposit and withdraw money at any given time.  

(I’m assuming that everyone has used an ATM before and thus has some domain knowledge around its usage) 

There are two techniques that we can use to gather and define requirements. 

• Modeling on Events
• Modeling on State  

These two go hand in hand as Modeling on Events builds on the fact that an event can occur whenever a system entity changes value. Consequently, Modeling on State looks at the state of the system when an event occurs. 

It is important to note that we’ll need to find a corresponding input event for each relevant application domain event. For each applicable state, ensure there is a way for the system to detect it. Finally, for each required action, find a corresponding output event.

Using the ATM and focusing on depositing cash, there is the initial input event of a user inserting their card. With the card insert event, we can start to question the system’s current state. In this case, the state will be card inserted. The following questions and answers may arise:

1. How does the system know that the user inserted a card? -> Card Detection 
2. How would the system know if a card is valid? -> Read Card 
3. System read card, does the state of the system change, and is there an output event? -> Valid Card State that will trigger a possible “prompt user to enter pin” action. 

As you can start to see, this process can get very detailed. Using the three questions and answers, we can already document that the system needs to know if a card is valid as a functional requirement.  

One thing to keep in mind, depending on the system, multiple input events can occur at once. For example, card insert and camera motion detection can happen within the same time frame, triggering the read card record event respectfully.

Building a project backlog:

A project backlog is a complete list of all the requirements with technical implementation details and time estimates at a high level. As a result, using the modeling methods previously mentioned should yield a detailed list of tasks. In the consulting space, a backlog’s task help determine the budget for a project. However, estimating these tasks can be difficult, subjective, and time-consuming. Most organizations have adopted a sizing model in which they attribute a certain level of effort needed for completion, for example, Small, Medium, and Large, akin to t-shirt sizes. Figuring out what an associated size is equivalent to in hours or days is another feat and is highly dependent on your team’s experience and knowledge.  

We’ve observed at Headspring that creating one screen that involves a CRUD operation (Create, read, update, and delete) is a medium task that, on average, takes three days to complete with appropriate testing included. A small task is usually one day, while a large is five days. A project task with an estimated size between small and large can be assigned to one developer expecting it to get done on time or raise exceptions or blockers once the effort has started. 

There are instances where tasks may be too challenging to categorize and estimate due to the sheer nature of the task or lack of expertise. These tasks typically fall within the XL and above range. As a rule of thumb, we usually try to keep all backlog tasks from going beyond large. A task beyond large suggests that the work needed for completion might be too much of one team member and can be broken down further. 

If the task cannot be broken down or estimated with a degree of confidence, then it’s time to “Spike it.” To “spike” a task refers to allocating time and accepting the risk to build a proof of concept, ensuring that the body of work is feasible from a technical, economical, operational, and schedule perspective. Identifying and performing these spikes early in the project road map can provide confidence for the project’s direction or allow timely course-correction. 

Conclusion:

As alluded to earlier, software development and project management have evolved and welcomes change. However, the reality is that crucial discoveries always emerge during the design/implementation effort because they were overlooked during the project’s requirements gathering phase. Those discoveries are not preventable; nevertheless, they can be reduced by leveraging domain knowledge to understand the system’s interworking, its boundaries, and the problem the project aims to solve. Correspondingly, we can utilize the modeling techniques to identify the potential inputs, outputs, events, and state changes to capture the foundational requirements. From there, we can take the requirements and break them down into smaller chunks, if applicable, for appropriate task sizing and estimation. 

Overall, there are many other techniques and thought processes that build upon and support these steps. However, the end goal is to capture as much information as possible regarding the project’s domain in its infancy. Doing so can foster a solid foundation for a substantial project start. 

It’s that time again, graduation season. As the joys of finishing school fades away, the thoughts of successfully landing a job start to surface. Not too long ago I was visiting the campus’ career center, asking professors to do me the honor of being my reference, and having my resume reviewed by my peers that graduated before me. This was all in an attempt to ensure that my resume was polished enough to make its way to someone’s desk. But how do I ensure that the reader will get passed my experience section before tossing it in the trash?

There are many great articles and books in circulation that cover best practices and tips on how to construct the “perfect” resume. One that would catch and hold the reader’s attention. In my search, I found some of the advice and tips to be palatable, and others not so much. Among those I liked was one that stood out the most to me, and that was Writing Strong Bullet Points. 

Considering the competitive nature of the job market, I personally believe that employers are no longer interested in our responsibilities; they’re looking for results. For an employer to spot those results, they have to be able to easily grasp and understand the Context, Action and Result (C.A.R). For the employer to catch that, you have to tell your story.

RESPONSIBILITIES VS. RESULTS

As you can see, the results provide more “color” to the individual’s responsibility. This “color” can easily be expounded on during a face to face interview. Below are three steps I found, on the University of Utah’s careers page, that can be used to convert one’s responsibilities to results.

3 Steps to Writing Strong Bullet Points

1. Start with a strong, specific verb that speaks to the strength or skill you want to highlight.
2. Provide specifics so the employer can visualize the setting – include answers to who, what, how many.
3. The most important piece is to show how what you did had an impact – focus on the result and share how it was positive for the organization or individuals you worked with. Quantify your results when possible.

I’ll be the first to say that coming up with the information to write strong bullet points isn’t easy. It requires some thought, self-awareness, introspection, and in most cases, a dash of imagination. Nonetheless, it’s worth mentioning that everything we do with our lives boils down to cause and effect. Every role/position that we held either paved the way for bigger things to happen or made someone’s life much easier. Writing strong bullet points is just a way of telling that story in a way that will capture and hold a reader’s attention.

If you get stuck, check out this simple worksheet from the University of Utah. It provides some more detail on how to write strong bullet points.

I recently finished reading Tony Dungy’s book, The Mentor Leader: Secrets to Building People and Teams That Win Consistently. It gave me new insight on what it means to be a Mentor Leader and how to effectively go about influencing lives for the greater good.

Tony defines Mentor leaders as individuals that seek to have a direct, intentional, and positive impact on those they lead. He went on to say that “At its core, mentoring is about building character into the lives of others, modeling and teaching attitudes and behaviors, and creating a constructive legacy to be passed along to future generations of leaders.”

I’ve had multiple opportunities to be both a mentor and a mentee. As such, I can appreciate the topics covered from both ends of the spectrum and agree with the support that mentees need and what mentors need to be conscience of. The biggest take away from his book was definitely the 7 E’s of Mentor Leadership, which are Engage, Educate, Equip, Encourage, Empower, Energize and Elevate.

Engage – It’s impossible to mentor from a distance. Building relationships with the people around you is imperative for having a positive effect on their lives. As a Mentor Leader, we have to walk alongside those we lead, and love every step of it.

Educate – Mentor leadership is all about helping others become the best they can be, it is the built on a foundation of teaching, helping and guiding. I was reminded of how important and effective taking a hands-on, one-on-one approach is in making that difference in a person’s life.

Equip – In essence, as mentor leaders, we need to ensure that an individual is physically, mentally, emotionally and spiritually prepared to accomplish a given task. Often times people are thrown into situations and expected to “swim”.  This one goes hand in hand with Educate. We not only have to provide the tools that they need to be successful, but also show them how to use it.

Encourage – Encouragement is the fuel that powers our efforts to engage, educate, and equip. People need affirmation and encouragement. Saying “Good Job” or acknowledging someone’s efforts, simply put, make them feel good.

Empower – True empowerment is preparation followed by appropriate freedom. At some point you have to let your mentee loose and watch them do their job.

Energize – Great leaders energize, motivate and inspire those they lead.

Elevate – The ultimate goal of every mentor leader is to build and grow other leaders for long-term, sustainable success. This was one of the biggest E’s I took to heart. In many of the relationships that I have provided some form of mentorship, I’ve challenged individuals to strive for excellence in the same way I did. The problem with that was that I didn’t challenge them to surpass me. To elevate your peers means to help them reach their God-given potential, even if it means preparing them to replace you. 

This coolest thing about being a mentor leader, is witnessing the success of the people you’ve elevated. It’s not about getting credit; it’s about helping everyone be the best they can be. A friend of mine once told me “It’s your journey, I’m just along for the ride.” In the same sense, we all need to buckle up and enjoy the ride. 

Like many elements in life, there is always a deliberate effort or approach that yields great results and creates that difference. Mentoring is no exception, it has to be deliberate. We need to Engage with those that we are blessed to lead. Once we’ve engaged them, we’re able to Educate and Equip them. Throughout that process, it is essential that we Encourage, Empower, and Energize in order to finally Elevate the people around us.

I’ve since then been looking at new and innovative ways to become a better learner, and was referred to Andy Hunt’s book: Pragmatic Thinking & Learning: Refactor Your Wetware. The book basically talks about how to harness intuition and get better at recognizing and applying patterns. It was filled with so much useful content that I ended up creating a Mind Map to represent my overall view of the valuable information, guides, and advice. 

Among the plethora of information, Andy Hunt gave me new insight regarding what it means to be an expert and an approach to learning in the form of an investment portfolio that will definitely boost one’s adaptability and level of productivity.

Novice vs. Expert

There has been much debate on the topic of Novices vs. Experts and what defines the two; especially experts. To gain better insight, we look to the Dreyfus Model of Skill Acquiction, coined by Hubert & Stuart Dreyfus (Dreyfus Brother). The model highlights five stages of skill levels, namely:

Novice: Has little or no experience, can be effective when relying on context free rule & don’t particularly want to learn; they just want to accomplish an immediate goal.

Advance Beginner: Can start to break away from the fixed set of rules and try tasks on their own. They want information fast and still have difficulty troubleshooting.

Competent: They can troubleshoot problems on their own, and begin to figure out how to solve novel problems—ones that they haven’t faced before. They can begin to seek out and apply advice from experts, and use it effectively.

Proficient: They can reflect on how they’ve done, and revise their approach to perform better the next time. They can learn from the experience of others, and know where to stop following the rules. In addition, they need a big picture.

Expert: Are the primary sources of knowledge and information in any field. They are the ones who continually look for better methods, better ways of doing things. They tend to have problems to articulate expertise and are surprisingly  thrown off by the rules.

The sad fact is that most people never get any higher than the second stage, Advance Beginner. In addition, people at lower skill levels tend to overestimate their own abilities – by as much as 50%.

Moving through the different levels, aiming for expertises, requires a change in perspective. One way to acquire that mental shift is through the Shu-Ha-Ri, a Japanese martial art concept, that describes the stages of learning to mastery.  It is broken down into three stages:

Shu – Learn the rules: In this first stage of the process, you’re basically learning the rules or following the step by step guide in that video tutorial. You concentration on following it precisely without worrying too much about the underlying theory.

Ha – Bend the rules: At this point, you’ve completed the tutorial and you’re beginning to branch out and look at other methods/guides as you start to understand the underlying principles and theory behind complete the task and how to put them into practice.

Ri – Break the rules: Now you’ve stopped learning from tutorials and guides, but from your own experience. You’re now starting to create your own approach and applying what you’ve learned to your own particular circumstances.

Another way to sum it up would be Imitate, Assimilate and Innovate. Reaching a level of expertise in a particular field is one thing, but you have to keep practicing in order to remain an expert.

Another way to simulate cognitive shifts in perspective to move towards mastery is through Deliberate Practice. Simply put, deliberate practice is not just trying something out. It involves specifically identifying what you’re going to work on and your areas of weakness, that when bettered will have the greatest impact. Effective deliberate practice should have well defined tasks that are appropriately difficult or challenging but doable. In addition, it needs to be supported by an environment that supplies informative feedback that one can act on. Lastly, it should provide opportunities for repetition and correction of errors.

Satisfying these conditions will provide accelerating growth in any particular field due to the fact that a random approach, without goals and feedback, tends to give random results. Also, keep in mind that leaving or regulating learning activities in your spare/free time is a recipe for failure. That’s why these practice sessions need to go along with a specific routing or regiment.

Furthermore, you can cement what you’ve learned by teaching others. Even if you have to start with a rubber duck as your protégé. Being able to regurgitate and put into your own words, thoughts, ideas and concepts is one of the best ways to prove to yourself that you have a firm grasp on a subject matter.

The Pragmatic Investment Portfolio: Creating a Knowledge Portfolio

Being able to move from Novice to Expert in a particular field is worth great recognition. However, most people, including myself, struggle with deciding which technology stack or skill to invest one’s time. In addition, there is also the fear that the chosen field may not have any longevity in the tech industry. Hence, it is necessary to have a diverse knowledge portfolio also referred to as a Pragmatic Investment Plan (PIP).

Similar to one’s financial investment portfolio, a PIP is a diversification of one’s knowledge and skill. The goal is to model and manage your knowledge portfolio with the same care as you would manage a financial investment portfolio. You’ll need to routinely review them to ensure that there is still value in its returns. Or there are greater returns that can be had if time is invested elsewhere. When picking up something new to invest time in, it’s important to approach/explore potential investments with a holistic and experimental approach and then shift to the more routine drills and skill to “PRODUCTIZE” learning.

Key to a successful portfolio 

1. Have a concrete plan:  Any subject area that you decide to invest your time in should reference goals and upcoming tasks. These goals can have a due day for next year or as far as five years out.
2. Diversify: Never put all your eggs in one basket. Consider the risk vs. return on investment ratio (more information below).
3. Active, not passive investment: “A random approach, without goals and feedback, tends to give random results.” Deliberate practice should be applied here.
4. Regular Investment: You’ll need to create a ritual and commit to the minimum amount of time needed per investment. Once you’ve created that ritual, stick to it. Even if it means you have to escape to a coffee shop, do it. Keep in mind that not all your planned sessions will be equally productive, but by scheduling them regularly enables you to win out in the long run cause you’re building a habit around it.

Risk vs. Return Ratio

With Any new technology or skill set that you invest time in, you always have to evaluate the Risk and Returns. For example, choosing to spend some time learning .NET will have minimum risk because it’s a popular stack that’s being used in the industry and has numerous books and articles surrounding it. However, it also has minimum returns due to the fact that it’s already a fully saturated and competitive field. Compared to a fairly new language or stack, that doesn’t have much supporting articles and book it can be viewed as a high risk, but can have high returns because not many people are on that bandwagon.

One should also keep in mind that Risk vs. Return can also be based on context. For Example: Are you looking for a new job or are you aiming to become the local expert within the office. On top of that, even if you never use a particular technology on the job, it will impact the way you think and solve problems. So anything you learn will have value, it just may not be direct, commercial, on-the-job value.

All knowledge investments have some value. That’s where the line is drawn between the investment portfolio analogy. If a financial investment goes bad, you lose money. However, with a Knowledge Portfolio you still get to keep the knowledge.

Moving Forward

“You can improve your performance—whether you’re playing a violin, debugging code, or designing a new architecture—by imagining that you’ve already done so successfully”. Overall, the book was a great read, and I’ve already blocked off time to review my Smart Goals and create my initial investment portfolio. The PIP was the solution to my concern about what technology or language I should invest my time in. The answer is, ANYTHING, once it fits into my overall goals.

With the Shi-Ha-Ri, deliberate practice and a knowledge portfolio, I’ll be able to boost my learning potential, make my learning experience more meaning full and on top of that, leveling up my productivity.

Malcolm Gladwell, the author of Outliers: The Story of Success, pointed out that you need to spend at least 10,000 hours on a particular subject matter to become a master in that field. However, one thing that I have to keep in mind is that Time != Value. Just because you spend a lot of time doing something, doesn’t mean it’s adding or providing value.

I love the Lord of the Rings trilogy, more importantly the role Sean Bean played in the first movie. In case you didn’t know, any character that’s portrayed by Sean Bean in a movie or TV series has a high probability of dying. Some of his deaths can leave you speechless and confused, as they are more grotesque than others. For instance, his death by separation in the movie Black Death where he was torn apart by horses running in opposite directions. Although extreme, that’s exactly how I felt when I was asked by one of my accountability buddies about career goals for the next 2 years. Like Sean Bean’s body, I was all over the place!

I couldn’t specifically narrow down what technology stack I wanted to work with, as there was a plethora of languages and technologies that I wanted to explore. In addition, there were so many different opportunities like working with non-profit organizations and open source projects that were available to take advantage of. However, one of my immediate fears was taking a deep dive into a technology stack only to find out that it may become obsolete in the years to come. But in the midst of all of this internal confusion, I knew that I wanted to become a senior developer.

The definition of senior developer varies from company to company and is mostly determined by years of experience and the number of projects one has been involved in. However, it felt that there was an underlying metric that stood above all. This unknown metric became painfully obvious when my accountability buddy asked me reasons for jumping into the list of technologies I presented to him. And to add insult to injury, he followed up by asking “How are those things going help you become a senior developer?” Honestly, at that point I really didn’t have a good answer. So rather than putting my foot in my mouth, I conceded and my journey to find the answer(s) began.

I recently read Richard St John’s book, titled The 8 Traits Successful People Have in Common. Richard personally interviewed approximately 500 successful people with the goal of finding out the common factors for success in any given field. In the end, he was able to identify 8 traits that his interviewees’ portrayed. And presented them in his book. They are as follows:

1. Passion
2. Work
3. Focus
4. Push
5. Ideas
6. Improve
7. Serve  
8. Persist

I won’t go into anymore detail, but you can get the gist of his research and his book from his TED-ED Talk.

In order the answer the question of “What does it really mean to be a Senior Developer”, I took Richard’s approach and interviewed a series of senior developers and sure enough found one word that resonated with all of the interview sessions. That word was Adaptable.

What does it mean to be Adaptable?

As long as you’re a developer you’re always having a new project to work on.  The project can range anywhere from the implementation of an existing business process, an entire system re-write or even as personal proof of concept. Regardless of the type, there’s always some ramp-up time that’s involved. Now, I must admit that at some point, ramping-up meant acquiring all the information that I needed to start committing code and getting my task or feature done in a timely manner. Most developers are okay with that; just knowing the bare minimum to get the job done. However, after conducting my interviews, it was evident that ramping up involves much more.

Ramping-up on a project should be geared towards understanding the domain and using that knowledge to make design and architectural decisions. Knowing how your feature fits into the domain’s bounded context will eventually affect the application in the long run. Most believe that domain knowledge is something that only project managers have to deal with. Taking the “Just tell me what I have to do and I’ll get it done” approach to every task. As Martin Fowler once said “Don’t just be a code monkey“. 

Now the word adaptable means being able to adjust to new situations or conditions. As such, in the context of Software Development an adaptable developer is one that can enter a project at any point in its Software Development Life Cycle and be able to exact change and produce results. In addition, an adaptable developer should be able to see a project through from start to finish. What I found interesting, was that ramping-up is an essential part of being adaptable. In fact, regardless of the domain, ramp-up time is indirectly proportional to one’s level of adaptability. Meaning the more adaptable you are, the less time you spend on ramping-up.

How to become adaptable?

When I started doing martial arts, my instructor would always have us do at least 100 squats before training. On other days he would have us stand in horse stance for as long as we can, even when we started shaking in the legs. This was all done so that we could build a strong base, as it was necessary to execute and display proper technique. Any karate expert will tell you that it takes a strong, solid base to land a powerful strike. The same principle is applicable in a career in software development. As such, building a strong technical foundation is the key to becoming adaptable.

One of the interviewees said: “The problems have not changed, but the tools have”.  In fact the existence of these problems is what lead to the development and introduction of basic principles that are applicable in particular situations, such as Design Patterns and Domain Driven Development. Understanding the problem is a major factor in understanding and taking advantage of different tools or languages. On the flip side, it’s also makes understanding their limitations much easier.

Yes, tools are great! Technology stack even better. But in order to make the best of them, one has to understand and master the basic underlying principles that they are based on.

Conclusion

My research not only gave the answers I was looking for, but a compendium of good advice. A lot of the things that were said to me were not necessarily eye openers but served as motivators and guidelines that can follow fearlessly. Nothing Good comes easy, unless your idea of “Good” is a Scoop of Ice Cream, in that case Ben and Jerry’s here I come. But on a serious note, each career path has its own set of challenges, some being more challenging than others. But regardless of the demand, one has to put in the WORK. Bruce Lee once said “..you put water into a cup, it becomes the cup, you put water into a teapot it becomes the teapot…” Become adaptable my friends.